From mboxrd@z Thu Jan 1 00:00:00 1970 From: tytso@mit.edu Subject: Re: random: Providing a seed value to VM guests Date: Thu, 1 May 2014 19:26:18 +0000 Message-ID: <20140501192618.GA25829@thunk.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "H. Peter Anvin" , Florian Weimer , "linux-kernel@vger.kernel.org" , Kees Cook , kvm list To: Andy Lutomirski Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org 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