Il 29/08/2014 02:13, Andy Lutomirski ha scritto:
> Hmm. Then, assuming that someone manages to allocate a
> cross-hypervisor MSR number for this, what am I supposed to do in the
> KVM code? Just make it available unconditionally? I don't see why
> that wouldn't work reliably, but it seems like a
On Thu, Aug 28, 2014 at 12:46 PM, Paolo Bonzini wrote:
> Il 28/08/2014 18:22, Andy Lutomirski ha scritto:
>> Is there a non-cpuid interface between QEMU and KVM for this?
>
> No.
Hmm. Then, assuming that someone manages to allocate a
cross-hypervisor MSR number for this, what am I supposed to do
Il 28/08/2014 18:22, Andy Lutomirski ha scritto:
> Is there a non-cpuid interface between QEMU and KVM for this?
No.
> AFAICT, even turning off cpuid bits for things like async pf doesn't
> actually disable the MSRs (which is arguably an attack surface issue).
No, it doesn't. You cannot disable
On Aug 28, 2014 7:17 AM, "Gleb Natapov" wrote:
>
> On Tue, Aug 26, 2014 at 04:58:34PM -0700, Andy Lutomirski wrote:
> > hpa pointed out that the ABI that I chose (an MSR from the KVM range
> > and a KVM cpuid bit) is unnecessarily KVM-specific. It would be nice
> > to allocate an MSR that everyon
On Tue, Aug 26, 2014 at 04:58:34PM -0700, Andy Lutomirski wrote:
> hpa pointed out that the ABI that I chose (an MSR from the KVM range
> and a KVM cpuid bit) is unnecessarily KVM-specific. It would be nice
> to allocate an MSR that everyone involved can agree on and, rather
> than relying on a cp
On 08/27/2014 12:00 AM, Paolo Bonzini wrote:
> Il 27/08/2014 01:58, Andy Lutomirski ha scritto:
>> hpa pointed out that the ABI that I chose (an MSR from the KVM range
>> and a KVM cpuid bit) is unnecessarily KVM-specific. It would be nice
>> to allocate an MSR that everyone involved can agree on
Il 27/08/2014 01:58, Andy Lutomirski ha scritto:
> hpa pointed out that the ABI that I chose (an MSR from the KVM range
> and a KVM cpuid bit) is unnecessarily KVM-specific. It would be nice
> to allocate an MSR that everyone involved can agree on and, rather
> than relying on a cpuid bit, just ha
hpa pointed out that the ABI that I chose (an MSR from the KVM range
and a KVM cpuid bit) is unnecessarily KVM-specific. It would be nice
to allocate an MSR that everyone involved can agree on and, rather
than relying on a cpuid bit, just have the guest probe for the MSR.
This leads to a few ques
Il 13/08/2014 20:33, Andy Lutomirski ha scritto:
> As for doing arch_random_init after clone/migration, I think we'll
> need another KVM extension for that, since, AFAIK, we don't actually
> get notified that we were cloned or migrated. That will be
> nontrivial. Maybe we can figure that out at K
On Wed, Aug 13, 2014 at 7:41 PM, H. Peter Anvin wrote:
> On 08/13/2014 11:44 AM, H. Peter Anvin wrote:
>> On 08/13/2014 11:33 AM, Andy Lutomirski wrote:
>>>
>>> As for doing arch_random_init after clone/migration, I think we'll
>>> need another KVM extension for that, since, AFAIK, we don't actual
On 08/13/2014 11:44 AM, H. Peter Anvin wrote:
> On 08/13/2014 11:33 AM, Andy Lutomirski wrote:
>>
>> As for doing arch_random_init after clone/migration, I think we'll
>> need another KVM extension for that, since, AFAIK, we don't actually
>> get notified that we were cloned or migrated. That will
On 08/13/2014 11:33 AM, Andy Lutomirski wrote:
>
> As for doing arch_random_init after clone/migration, I think we'll
> need another KVM extension for that, since, AFAIK, we don't actually
> get notified that we were cloned or migrated. That will be
> nontrivial. Maybe we can figure that out at
On Wed, Aug 13, 2014 at 11:22 AM, Theodore Ts'o wrote:
> On Wed, Aug 13, 2014 at 10:45:25AM -0700, H. Peter Anvin wrote:
>> On 08/13/2014 09:13 AM, Andy Lutomirski wrote:
>> >
>> > Sounds good to me.
>> >
>> > FWIW, I'd like to see a second use added in random.c: I think that we
>> > should do thi
On Wed, Aug 13, 2014 at 10:45:25AM -0700, H. Peter Anvin wrote:
> On 08/13/2014 09:13 AM, Andy Lutomirski wrote:
> >
> > Sounds good to me.
> >
> > FWIW, I'd like to see a second use added in random.c: I think that we
> > should do this, or even all of init_std_data, on resume from suspend
> > an
On 08/13/2014 09:13 AM, Andy Lutomirski wrote:
>
> Sounds good to me.
>
> FWIW, I'd like to see a second use added in random.c: I think that we
> should do this, or even all of init_std_data, on resume from suspend
> and especially on resume from hibernate / kexec.
>
Yes, we should. We also ne
On Wed, Aug 13, 2014 at 7:32 AM, Theodore Ts'o wrote:
> On Wed, Aug 13, 2014 at 12:48:41AM -0700, H. Peter Anvin wrote:
>> The proposed arch_get_rng_seed() is not really what it claims to be; it
>> most definitely does not produce seed-grade randomness, instead it seems
>> to be an arch function f
On Wed, Aug 13, 2014 at 12:48:41AM -0700, H. Peter Anvin wrote:
> The proposed arch_get_rng_seed() is not really what it claims to be; it
> most definitely does not produce seed-grade randomness, instead it seems
> to be an arch function for best-effort initialization of the entropy
> pools -- whic
On Aug 13, 2014 12:48 AM, "H. Peter Anvin" wrote:
>
> On 08/12/2014 12:22 PM, Andy Lutomirski wrote:
> > On Tue, Aug 12, 2014 at 12:17 PM, Theodore Ts'o wrote:
> >> On Tue, Aug 12, 2014 at 12:11:29PM -0700, Andy Lutomirski wrote:
> >>>
> >>> What's the status of this series? I assume that it's t
On 08/12/2014 12:22 PM, Andy Lutomirski wrote:
> On Tue, Aug 12, 2014 at 12:17 PM, Theodore Ts'o wrote:
>> On Tue, Aug 12, 2014 at 12:11:29PM -0700, Andy Lutomirski wrote:
>>>
>>> What's the status of this series? I assume that it's too late for at
>>> least patches 2-5 to make it into 3.17.
>>
>
On Tue, Aug 12, 2014 at 12:17 PM, Theodore Ts'o wrote:
> On Tue, Aug 12, 2014 at 12:11:29PM -0700, Andy Lutomirski wrote:
>>
>> What's the status of this series? I assume that it's too late for at
>> least patches 2-5 to make it into 3.17.
>
> Which tree were you hoping this patch series to go th
On Tue, Aug 12, 2014 at 12:11:29PM -0700, Andy Lutomirski wrote:
>
> What's the status of this series? I assume that it's too late for at
> least patches 2-5 to make it into 3.17.
Which tree were you hoping this patch series to go through? I was
assuming it would go through the x86 tree since t
On Wed, Jul 23, 2014 at 9:57 PM, Andy Lutomirski wrote:
> This introduces and uses a very simple synchronous mechanism to get
> /dev/urandom-style bits appropriate for initial KVM PV guest RNG
> seeding.
>
> It also re-works the way that architectural random data is fed into
> random.c's pools. I
This introduces and uses a very simple synchronous mechanism to get
/dev/urandom-style bits appropriate for initial KVM PV guest RNG
seeding.
It also re-works the way that architectural random data is fed into
random.c's pools. I added a new arch hook called arch_get_rng_seed.
The default impleme
23 matches
Mail list logo
