Linux Virtualization - Sep 2014 - Standardizing an MSR or other hypercall to get an RNG seed?

On 09/19/2014 04:12 PM, Andy Lutomirski wrote:
> 
> To force deterministic execution.
> 
> I incorrectly thought that the kernel could switch RDRAND on and off.
> It turns out that a hypervisor can do this, but not the kernel.  Also,
> determinism is lost anyway because of TSX, which *also* can't be
> turned on and off.
> 
Actually, a much bigger reason is because it lets rogue guest *user
space*, even will a well-behaved guest OS, do something potentially
harmful to the host.

	-hpa

On Fri, Sep 19, 2014 at 04:29:53PM -0700, H. Peter Anvin
wrote:
> 
> Actually, a much bigger reason is because it lets rogue guest *user
> space*, even will a well-behaved guest OS, do something potentially
> harmful to the host.
Right, but if the host kernel is dependent on the guest OS for
security, the game is over.  The Guest Kernel must NEVER been able to
do anything harmful to the host.  If it can, it is a severe security
bug in KVM that must be fixed ASAP.

						- Ted

On Fri, Sep 19, 2014 at 4:35 PM, Theodore Ts'o <tytso at mit.edu>
wrote:
> On Fri, Sep 19, 2014 at 04:29:53PM -0700, H. Peter Anvin wrote:
>>
>> Actually, a much bigger reason is because it lets rogue guest *user
>> space*, even will a well-behaved guest OS, do something potentially
>> harmful to the host.
>
> Right, but if the host kernel is dependent on the guest OS for
> security, the game is over.  The Guest Kernel must NEVER been able to
> do anything harmful to the host.  If it can, it is a severe security
> bug in KVM that must be fixed ASAP.
Nonetheless, I suspect that some OS kernel author, somewhere, will
object to having a hypervisor that exposes new capabilities to guest
CPL 3 without requiring the guest to opt in, if for no other reason
than that it slightly increases the attack surface.

I certainly object on these grounds.

--Andy

On 09/19/2014 04:35 PM, Theodore Ts'o wrote:
> On Fri, Sep 19, 2014 at 04:29:53PM -0700, H. Peter Anvin wrote:
>>
>> Actually, a much bigger reason is because it lets rogue guest *user
>> space*, even will a well-behaved guest OS, do something potentially
>> harmful to the host.
> 
> Right, but if the host kernel is dependent on the guest OS for
> security, the game is over.  The Guest Kernel must NEVER been able to
> do anything harmful to the host.  If it can, it is a severe security
> bug in KVM that must be fixed ASAP.
> 
"Security" and "resource well-behaved" are two different
things.

	-hpa