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 19:26:18 +0000
From:	tytso@....edu
To:	Andy Lutomirski <luto@...capital.net>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Florian Weimer <fweimer@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Kees Cook <kees@...flux.net>, kvm list <kvm@...r.kernel.org>
Subject: Re: random: Providing a seed value to VM guests

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

--
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/