linux-kernel - Re: random: Providing a seed value to VM guests

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 1 May 2014 13:56:29 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	"Theodore Ts'o" <tytso@....edu>,
	Andy Lutomirski <luto@...capital.net>,
	"H. Peter Anvin" <hpa@...or.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	kvm list <kvm@...r.kernel.org>,
	Florian Weimer <fweimer@...hat.com>,
	Kees Cook <kees@...flux.net>
Subject: Re: random: Providing a seed value to VM guests

On Thu, May 1, 2014 at 1:39 PM,  <tytso@....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@...or.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/