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]
Message-ID: <53C68CF3.5070208@redhat.com>
Date:	Wed, 16 Jul 2014 16:32:19 +0200
From:	Paolo Bonzini <pbonzini@...hat.com>
To:	Andy Lutomirski <luto@...capital.net>
CC:	Daniel Borkmann <dborkman@...hat.com>,
	Gleb Natapov <gleb@...nel.org>, kvm list <kvm@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>, "Theodore Ts'o" <tytso@....edu>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Kees Cook <keescook@...omium.org>, X86 ML <x86@...nel.org>,
	Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>,
	Raghavendra K T <raghavendra.kt@...ux.vnet.ibm.com>
Subject: Re: [PATCH 0/4] random,x86,kvm: Add and use MSR_KVM_GET_RNG_SEED

Il 16/07/2014 16:07, Andy Lutomirski ha scritto:
> This patch has nothing whatsoever to do with how much I trust the CPU
> vs the hypervisor.  It's for the enormous installed base of machines
> without RDRAND.

Ok.  I think an MSR is fine, though I don't think it's useful for the 
guest to use it if it already has RDRAND and/or RDSEED.

> > In any case, is there a matching QEMU patch somewhere?
>
> What QEMU change is needed?  I admit I'm a bit vague on how QEMU and
> KVM cooperate here, but there's no state to save and restore.  I guess
> that QEMU wants the ability to turn this on and off for migration.
> How does that work?  I couldn't spot the KVM code that allows this
> type of control.

It is QEMU who decides the CPUID bits that are visible to the guest.  By 
default it blocks bits that it doesn't know about.  You would need to 
add the bit in the kvm_default_features and kvm_feature_name arrays.

For migration, we have "versioned" machine types, for example pc-2.1.
Once the versioned machine type exists, blocking the feature is a 
one-liner like

     x86_cpu_compat_disable_kvm_features(FEAT_KVM, KVM_FEATURE_NAME);

Unfortunately, QEMU is in hard freeze, so you'd likely be the one 
creating pc-2.2.  This is a boilerplate but relatively complicated 
patch.  But let's cross that bridge when we'll reach it.  For now, you 
can simply add the bit to the two arrays above.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ