Re: [PATCH] random: Add "initialized" variable to proc

Re: [PATCH] random: Add "initialized" variable to proc

[Andy Lutomirski]

On Thu, May 1, 2014 at 8:35 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Thu, May 1, 2014 at 8:05 AM,  <tytso@mit.edu> wrote:
>> On Wed, Apr 30, 2014 at 09:05:00PM -0700, H. Peter Anvin wrote:
>>>
>>> Giving the guest a seed would be highly useful, though.  There are a
>>> number of ways to do that; changing the boot protocol is probably
>>> only useful if Qemu itself bouts the kernel as opposed to an in-VM
>>> bootloader.
>>
>> So how about simply passing a memory address and an optional offset on
>> the boot command line?  That way the hypervisor can drop the seed in
>> some convenient real memory location, and the kernel can just copy it
>> someplace safe, or in the case of kernel ASLR, the relocator can use
>> it to seed its CRNG, and then after it relocates the kernel, it can
>> crank the CRNG to pass a seed to the kernel's urandom driver.
>>
>> That way, we don't have to do something which is ACPI or DT dependent.
>> Maybe there will be embedded architectures where using DT might be
>> more convenient, but this would probably be simplest for KVM/qumu-based
>> VM's, I would think.
>
> One problem with passing a seed in memory like this is that it
> provides no benefit if the guest reboots without restarting the
> hypervisor.  Using an MSR or something avoids that issue.
>
> Passing an address in I/O space that can be read to synchronously
> obtain a seed would work, but it could still be messy to get the
> address to propagate through the booatloader and the reboot process.
>

A CPUID leaf or an MSR advertised by a CPUID leaf has another
advantage: it's easy to use in the ASLR code -- I don't think there's
a real IDT, so there's nothing like rdmsr_safe available.  It also
avoids doing anything complicated with the boot process to allow the
same seed to be used for ASLR and random.c; it can just be invoked
twice on boot.

Here are two easyish ways to do it:

a. Add a new CPUID leaf KVM_CPUID_URANDOM = 0x40000002.  The existence
of the leaf is signaled by KVM_CPUID_SIGNATURE.eax >= 0x40000002.
Reading the leaf either gives all zeros to indicate that it's
unsupported or disabled or it gives 256 bits of urandom-style data in
rax,rbx,rcx,edx.  32-bit callers will have trouble extracting more
than 128 of those 256 bits, but that should be fine.

b. Add a new MSR_KVM_URANDOM and indicate support using
KVM_FEATURE_URANDOM.  The is cleaner, since it matches existing
practice, but it's awkward to return more than 64 bits at a time from
rdmsr.  128 bits is straightforward by cheating and using the high
bits in rax and rdx, but that's kind of gross.  Clobbering any more
registers is awful, and passing a pointer into wrmsr seems
overcomplicated.

There's also the hypercall interface, but it looks like hyperv support
can interfere with it, and I'm not sure whether the guest needs to
cooperate with whatever the magical vmcall patching code is doing.

What's the right forum for this?  This thread is probably not it.

--Andy

random: Providing a seed value to VM guests

[H. Peter Anvin]

On 05/01/2014 11:53 AM, Andy Lutomirski wrote:
> 
> A CPUID leaf or an MSR advertised by a CPUID leaf has another
> advantage: it's easy to use in the ASLR code -- I don't think there's
> a real IDT, so there's nothing like rdmsr_safe available.  It also
> avoids doing anything complicated with the boot process to allow the
> same seed to be used for ASLR and random.c; it can just be invoked
> twice on boot.
> 

At that point we are talking an x86-specific interface, and so we might
as well simply emulate RDRAND (urandom) and RDSEED (random) if the CPU
doesn't support them.  I believe KVM already has a way to report CPUID
features that are "emulated but supported anyway", i.e. they work but
are slow.

> What's the right forum for this?  This thread is probably not it.

Change the subject line?

	-hpa

Re: random: Providing a seed value to VM guests

[Andy Lutomirski]

On Thu, May 1, 2014 at 11:59 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 05/01/2014 11:53 AM, Andy Lutomirski wrote:
>>
>> A CPUID leaf or an MSR advertised by a CPUID leaf has another
>> advantage: it's easy to use in the ASLR code -- I don't think there's
>> a real IDT, so there's nothing like rdmsr_safe available.  It also
>> avoids doing anything complicated with the boot process to allow the
>> same seed to be used for ASLR and random.c; it can just be invoked
>> twice on boot.
>>
>
> At that point we are talking an x86-specific interface, and so we might
> as well simply emulate RDRAND (urandom) and RDSEED (random) if the CPU
> doesn't support them.  I believe KVM already has a way to report CPUID
> features that are "emulated but supported anyway", i.e. they work but
> are slow.

Do existing kernels and userspace respect this?  If the normal bit for
RDRAND is unset, then we might be okay, but, if not, then I think this
may kill guest performance.

Is RDSEED really reasonable here?  Won't it slow down by several
orders of magnitude?

>
>> What's the right forum for this?  This thread is probably not it.
>
> Change the subject line?

:)

>
>         -hpa
>
>



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: random: Providing a seed value to VM guests

[tytso]

On Thu, May 01, 2014 at 12:02:49PM -0700, Andy Lutomirski wrote:
> 
> Is RDSEED really reasonable here?  Won't it slow down by several
> orders of magnitude?

That is I think the biggest problem; RDRAND and RDSEED are fast if
they are native, but they will involve a VM exit if they need to be
emulated.  So when an OS might want to use RDRAND and RDSEED might be
quite different if we know they are being emulated.

Using the RDRAND and RDSEED "api" certainly makes sense, at least for
x86, but I suspect we might want to use a different way of signalling
that a VM guest can use RDRAND and RDSEED if they are running on a CPU
which doesn't provide that kind of access.  Maybe a CPUID extended
function parameter, if one could be allocated for use by a Linux
hypervisor?

						- Ted

Re: random: Providing a seed value to VM guests

[H. Peter Anvin]

As I said... I think KVM has already added an emulated instructions enumeration API.

On May 1, 2014 12:26:18 PM PDT, tytso@mit.edu wrote:
>On Thu, May 01, 2014 at 12:02:49PM -0700, Andy Lutomirski wrote:
>> 
>> Is RDSEED really reasonable here?  Won't it slow down by several
>> orders of magnitude?
>
>That is I think the biggest problem; RDRAND and RDSEED are fast if
>they are native, but they will involve a VM exit if they need to be
>emulated.  So when an OS might want to use RDRAND and RDSEED might be
>quite different if we know they are being emulated.
>
>Using the RDRAND and RDSEED "api" certainly makes sense, at least for
>x86, but I suspect we might want to use a different way of signalling
>that a VM guest can use RDRAND and RDSEED if they are running on a CPU
>which doesn't provide that kind of access.  Maybe a CPUID extended
>function parameter, if one could be allocated for use by a Linux
>hypervisor?
>
>						- Ted

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.

Re: random: Providing a seed value to VM guests

[Andy Lutomirski]

On May 1, 2014 12:26 PM, <tytso@mit.edu> wrote:
>
> On Thu, May 01, 2014 at 12:02:49PM -0700, Andy Lutomirski wrote:
> >
> > Is RDSEED really reasonable here?  Won't it slow down by several
> > orders of magnitude?
>
> That is I think the biggest problem; RDRAND and RDSEED are fast if
> they are native, but they will involve a VM exit if they need to be
> emulated.  So when an OS might want to use RDRAND and RDSEED might be
> quite different if we know they are being emulated.
>
> Using the RDRAND and RDSEED "api" certainly makes sense, at least for
> x86, but I suspect we might want to use a different way of signalling
> that a VM guest can use RDRAND and RDSEED if they are running on a CPU
> which doesn't provide that kind of access.  Maybe a CPUID extended
> function parameter, if one could be allocated for use by a Linux
> hypervisor?
>

I'm still not convinced.  This will affect userspace as well as the
guest kernel, and I don't see why guest user code should be able to
access this API.  RDRAND for CPL0 only would work, but that seems odd.

And I think that RDSEED emulation is asking for trouble.  RDSEED is
synchronous, but /dev/random is asynchronous.  And making bootup wait
for even a single byte from /dev/random seems bad.  In any event,
virtio-rng should be a better interface for this.

>                                                 - Ted
>

Re: random: Providing a seed value to VM guests

[H. Peter Anvin]

RDSEED is not synchronous.  It is, however, nonblocking.

On May 1, 2014 1:16:40 PM PDT, Andy Lutomirski <luto@amacapital.net> wrote:
>On May 1, 2014 12:26 PM, <tytso@mit.edu> wrote:
>>
>> On Thu, May 01, 2014 at 12:02:49PM -0700, Andy Lutomirski wrote:
>> >
>> > Is RDSEED really reasonable here?  Won't it slow down by several
>> > orders of magnitude?
>>
>> That is I think the biggest problem; RDRAND and RDSEED are fast if
>> they are native, but they will involve a VM exit if they need to be
>> emulated.  So when an OS might want to use RDRAND and RDSEED might be
>> quite different if we know they are being emulated.
>>
>> Using the RDRAND and RDSEED "api" certainly makes sense, at least for
>> x86, but I suspect we might want to use a different way of signalling
>> that a VM guest can use RDRAND and RDSEED if they are running on a
>CPU
>> which doesn't provide that kind of access.  Maybe a CPUID extended
>> function parameter, if one could be allocated for use by a Linux
>> hypervisor?
>>
>
>I'm still not convinced.  This will affect userspace as well as the
>guest kernel, and I don't see why guest user code should be able to
>access this API.  RDRAND for CPL0 only would work, but that seems odd.
>
>And I think that RDSEED emulation is asking for trouble.  RDSEED is
>synchronous, but /dev/random is asynchronous.  And making bootup wait
>for even a single byte from /dev/random seems bad.  In any event,
>virtio-rng should be a better interface for this.
>
>>                                                 - Ted
>>

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.

Re: random: Providing a seed value to VM guests

[Andy Lutomirski]

On Thu, May 1, 2014 at 1:30 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> RDSEED is not synchronous.  It is, however, nonblocking.

What I mean is: IIUC it's reasonable to call RDSEED a few times in a
loop and hope it works.  It makes no sense to do that with
/dev/random.

>
> On May 1, 2014 1:16:40 PM PDT, Andy Lutomirski <luto@amacapital.net> wrote:
>>On May 1, 2014 12:26 PM, <tytso@mit.edu> wrote:
>>>
>>> On Thu, May 01, 2014 at 12:02:49PM -0700, Andy Lutomirski wrote:
>>> >
>>> > Is RDSEED really reasonable here?  Won't it slow down by several
>>> > orders of magnitude?
>>>
>>> That is I think the biggest problem; RDRAND and RDSEED are fast if
>>> they are native, but they will involve a VM exit if they need to be
>>> emulated.  So when an OS might want to use RDRAND and RDSEED might be
>>> quite different if we know they are being emulated.
>>>
>>> Using the RDRAND and RDSEED "api" certainly makes sense, at least for
>>> x86, but I suspect we might want to use a different way of signalling
>>> that a VM guest can use RDRAND and RDSEED if they are running on a
>>CPU
>>> which doesn't provide that kind of access.  Maybe a CPUID extended
>>> function parameter, if one could be allocated for use by a Linux
>>> hypervisor?
>>>
>>
>>I'm still not convinced.  This will affect userspace as well as the
>>guest kernel, and I don't see why guest user code should be able to
>>access this API.  RDRAND for CPL0 only would work, but that seems odd.
>>
>>And I think that RDSEED emulation is asking for trouble.  RDSEED is
>>synchronous, but /dev/random is asynchronous.  And making bootup wait
>>for even a single byte from /dev/random seems bad.  In any event,
>>virtio-rng should be a better interface for this.
>>
>>>                                                 - Ted
>>>
>
> --
> Sent from my mobile phone.  Please pardon brevity and lack of formatting.



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: random: Providing a seed value to VM guests

[tytso]

On Thu, May 01, 2014 at 01:32:55PM -0700, Andy Lutomirski wrote:
> On Thu, May 1, 2014 at 1:30 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> > RDSEED is not synchronous.  It is, however, nonblocking.
> 
> What I mean is: IIUC it's reasonable to call RDSEED a few times in a
> loop and hope it works.  It makes no sense to do that with
> /dev/random.

RDSEED is allowed to return an error if there is insufficient entropy.
So long as the caller understands that this is an emulated
instruction, I don't see a problem.

						- Ted

Re: random: Providing a seed value to VM guests

[Andy Lutomirski]

On Thu, May 1, 2014 at 1:39 PM,  <tytso@mit.edu> wrote:
> On Thu, May 01, 2014 at 01:32:55PM -0700, Andy Lutomirski wrote:
>> On Thu, May 1, 2014 at 1:30 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> > RDSEED is not synchronous.  It is, however, nonblocking.
>>
>> What I mean is: IIUC it's reasonable to call RDSEED a few times in a
>> loop and hope it works.  It makes no sense to do that with
>> /dev/random.
>
> RDSEED is allowed to return an error if there is insufficient entropy.
> So long as the caller understands that this is an emulated
> instruction, I don't see a problem.

What's the point?

I think this is too caught up in x86 architectural stuff.  As I see
it, the goal is to give guests a way to ask their hosts to give them,
immediately and synchronously, some bytes suitable for seeding an RNG.
 These bytes need not contain true entropy, because the host may not
be able to provide entropy an a timely manner.  The mechanism should
be usable extremely early after boot, it should be usable after a
guest reboot, and it should be reliable.  I think there's an added
benefit if all architectures can implement a semantically equivalent
function, even if the interface is completely different.

There's no need for anything new to provide asynchronous and-or very
slow true random data -- virtio-rng already exists. *

Emulating RDRAND for this purpose is a little weird because it's
normally available to user code and it has the flag indicating
failure.  We're also not going to want the guest kernel to access it
through the arch_get_random interface.

Even if we could emulate RDSEED effectively**, I don't really
understand what the guest is expected to do with it.  And I generally
dislike defining an interface with no known sensible users, because it
means that there's a good chance that the interface won't end up
working.

* I still don't know why it doesn't work for me.  I'll fiddle with it,
but I think that the right solution is to fix it for this purpose, not
to replace it.
** Doing this sensibly in the host will be awkward.  Is the host
supposed to use non-blocking reads of /dev/random?  Getting anything
remotely fair may be difficult.

>
>                                                 - Ted



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: random: Providing a seed value to VM guests

[H. Peter Anvin]

On 05/01/2014 01:56 PM, Andy Lutomirski wrote:
> 
> Even if we could emulate RDSEED effectively**, I don't really
> understand what the guest is expected to do with it.  And I generally
> dislike defining an interface with no known sensible users, because it
> means that there's a good chance that the interface won't end up
> working.
>
> ** Doing this sensibly in the host will be awkward.  Is the host
> supposed to use non-blocking reads of /dev/random?  Getting anything
> remotely fair may be difficult.

The host can use nonblocking reads of /dev/random.  Fairness would have
to be implemented at the host level, but that is true for anything.

	-hpa

Re: random: Providing a seed value to VM guests

[Andy Lutomirski]

On Thu, May 1, 2014 at 2:01 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 05/01/2014 01:56 PM, Andy Lutomirski wrote:
>>
>> Even if we could emulate RDSEED effectively**, I don't really
>> understand what the guest is expected to do with it.  And I generally
>> dislike defining an interface with no known sensible users, because it
>> means that there's a good chance that the interface won't end up
>> working.
>>
>> ** Doing this sensibly in the host will be awkward.  Is the host
>> supposed to use non-blocking reads of /dev/random?  Getting anything
>> remotely fair may be difficult.
>
> The host can use nonblocking reads of /dev/random.  Fairness would have
> to be implemented at the host level, but that is true for anything.
>

I still don't see the point.  What does this do better than virtio-rng?

The ASLR code doesn't even try to use RDSEED.  RDSEED is used in
add_interrupt_randomness, which should drain the host's /dev/random
even if it could, and it's used in init_std_data.  The logic there is:

                if (!arch_get_random_seed_long(&rv) &&
                    !arch_get_random_long(&rv))
                        rv = random_get_entropy();

I think this is better achieved by having the host try to supply the
highest quality data it can.

The third RDSEED use is arch_random_refill.  This purpose would be
much better served by the khwrng stuff and virtio-rng.

So I still claim that fancy emulated RDSEED support will have no users.

--Andy

Re: random: Providing a seed value to VM guests

[tytso]

On Thu, May 01, 2014 at 02:06:13PM -0700, Andy Lutomirski wrote:
> 
> I still don't see the point.  What does this do better than virtio-rng?

I believe you had been complaining about how complicated it was to set
up virtio?  And this complexity is also an issue if we want to use it
to initialize the RNG used for the kernel text ASLR --- which has to
be done very early in the boot process, and where making something as
simple as possible is a Good Thing.

And since we would want to use RDRAND/RDSEED if it is available
*anyway*, perhaps in combination with other things, why not use the
RDRAND/RDSEED interface?

							- Ted

Re: random: Providing a seed value to VM guests

[Andy Lutomirski]

On Thu, May 1, 2014 at 3:28 PM,  <tytso@mit.edu> wrote:
> On Thu, May 01, 2014 at 02:06:13PM -0700, Andy Lutomirski wrote:
>>
>> I still don't see the point.  What does this do better than virtio-rng?
>
> I believe you had been complaining about how complicated it was to set
> up virtio?  And this complexity is also an issue if we want to use it
> to initialize the RNG used for the kernel text ASLR --- which has to
> be done very early in the boot process, and where making something as
> simple as possible is a Good Thing.

It's complicated, so it won't be up until much later in the boot
process.  This is completely fine for /dev/random, but it's a problem
for /dev/urandom, ASLR, and such.

>
> And since we would want to use RDRAND/RDSEED if it is available
> *anyway*, perhaps in combination with other things, why not use the
> RDRAND/RDSEED interface?

Because it's awkward.  I don't think it simplifies anything.

--Andy

Re: random: Providing a seed value to VM guests

[H. Peter Anvin]

On 05/01/2014 03:32 PM, Andy Lutomirski wrote:
> On Thu, May 1, 2014 at 3:28 PM,  <tytso@mit.edu> wrote:
>> On Thu, May 01, 2014 at 02:06:13PM -0700, Andy Lutomirski wrote:
>>>
>>> I still don't see the point.  What does this do better than virtio-rng?
>>
>> I believe you had been complaining about how complicated it was to set
>> up virtio?  And this complexity is also an issue if we want to use it
>> to initialize the RNG used for the kernel text ASLR --- which has to
>> be done very early in the boot process, and where making something as
>> simple as possible is a Good Thing.
> 
> It's complicated, so it won't be up until much later in the boot
> process.  This is completely fine for /dev/random, but it's a problem
> for /dev/urandom, ASLR, and such.
> 
>>
>> And since we would want to use RDRAND/RDSEED if it is available
>> *anyway*, perhaps in combination with other things, why not use the
>> RDRAND/RDSEED interface?
> 
> Because it's awkward.  I don't think it simplifies anything.
> 

It greatly simplifies discovery, which is a Big Deal[TM] in early code.

	-hpa

Re: random: Providing a seed value to VM guests

[Andy Lutomirski]

On Thu, May 1, 2014 at 3:46 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 05/01/2014 03:32 PM, Andy Lutomirski wrote:
>> On Thu, May 1, 2014 at 3:28 PM,  <tytso@mit.edu> wrote:
>>> On Thu, May 01, 2014 at 02:06:13PM -0700, Andy Lutomirski wrote:
>>>>
>>>> I still don't see the point.  What does this do better than virtio-rng?
>>>
>>> I believe you had been complaining about how complicated it was to set
>>> up virtio?  And this complexity is also an issue if we want to use it
>>> to initialize the RNG used for the kernel text ASLR --- which has to
>>> be done very early in the boot process, and where making something as
>>> simple as possible is a Good Thing.
>>
>> It's complicated, so it won't be up until much later in the boot
>> process.  This is completely fine for /dev/random, but it's a problem
>> for /dev/urandom, ASLR, and such.
>>
>>>
>>> And since we would want to use RDRAND/RDSEED if it is available
>>> *anyway*, perhaps in combination with other things, why not use the
>>> RDRAND/RDSEED interface?
>>
>> Because it's awkward.  I don't think it simplifies anything.
>>
>
> It greatly simplifies discovery, which is a Big Deal[TM] in early code.

I think we're comparing:

a) cpuid to detect rdrand *or* emulated rdrand followed by rdrand

to

b) cpuid to detect rdrand or the paravirt seed msr/cpuid call,
followed by rdrand or the msr or cpuid read

this seems like it barely makes a difference, especially since (a)
probably requires detecting KVM anyway.


For the real kernel code, it's probably even closer to making no
difference, since I don't think we'll want arch_get_random_long to use
emulated rdrand.

--Andy

Re: random: Providing a seed value to VM guests

[H. Peter Anvin]

On 05/01/2014 03:56 PM, Andy Lutomirski wrote:
> 
> I think we're comparing:
> 
> a) cpuid to detect rdrand *or* emulated rdrand followed by rdrand
> 
> to
> 
> b) cpuid to detect rdrand or the paravirt seed msr/cpuid call,
> followed by rdrand or the msr or cpuid read
> 
> this seems like it barely makes a difference, especially since (a)
> probably requires detecting KVM anyway.

Well, it lets one do something like:

	if (boot_cpu_has(X86_FEATURE_RDRAND) ||
            boot_cpu_has(X86_FEATURE_RDRAND_SIMULATED))
		rdrand_long(...);

We need the ifs anyway for early code; the arch_*() interfaces are only
available after alternatives run.

	-hpa

Re: random: Providing a seed value to VM guests

[H. Peter Anvin]

The normal CPUID bit is unset I believe.

On May 1, 2014 12:02:49 PM PDT, Andy Lutomirski <luto@amacapital.net> wrote:
>On Thu, May 1, 2014 at 11:59 AM, H. Peter Anvin <hpa@zytor.com> wrote:
>> On 05/01/2014 11:53 AM, Andy Lutomirski wrote:
>>>
>>> A CPUID leaf or an MSR advertised by a CPUID leaf has another
>>> advantage: it's easy to use in the ASLR code -- I don't think
>there's
>>> a real IDT, so there's nothing like rdmsr_safe available.  It also
>>> avoids doing anything complicated with the boot process to allow the
>>> same seed to be used for ASLR and random.c; it can just be invoked
>>> twice on boot.
>>>
>>
>> At that point we are talking an x86-specific interface, and so we
>might
>> as well simply emulate RDRAND (urandom) and RDSEED (random) if the
>CPU
>> doesn't support them.  I believe KVM already has a way to report
>CPUID
>> features that are "emulated but supported anyway", i.e. they work but
>> are slow.
>
>Do existing kernels and userspace respect this?  If the normal bit for
>RDRAND is unset, then we might be okay, but, if not, then I think this
>may kill guest performance.
>
>Is RDSEED really reasonable here?  Won't it slow down by several
>orders of magnitude?
>
>>
>>> What's the right forum for this?  This thread is probably not it.
>>
>> Change the subject line?
>
>:)
>
>>
>>         -hpa
>>
>>

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.