On 03/09/2016 02:37 PM, Yang Zhang wrote:
On 2016/3/9 13:51, Xiao Guangrong wrote:
On 03/08/2016 06:02 PM, Paolo Bonzini wrote:
On 08/03/2016 10:32, Xiao Guangrong wrote:
On 03/08/2016 04:47 PM, Paolo Bonzini wrote:
Some XSAVE features (currently only MPX, but in the future PKRU too)
will force eagerfpu on, see fpu__init_system_ctx_switch:
if (xfeatures_mask & XFEATURE_MASK_EAGER) {
if (eagerfpu == DISABLE) {
xfeatures_mask &= ~XFEATURE_MASK_EAGER;
So if the kernel parameter, eagerfpu is set to "off", then eager is not
enabled, so PKRU can not work in KVM?
Yes. Neither PKRU nor MPX.
Er... I noticed fpregs is not switched if the CPU is running in KVM module
(vcpu is not scheduled out and does not exit to userspace), that is why
read_pkru() can be used to read guest's PKRU in the patch 4.
However, then guest can fully control the access of userspace's memory if
CR4.PKRU is enabled on host and KVM needs to access QEMU's memory to do
some
emulation anyway. Is it really safe？
I think it depends on how we understand the guest uses Pkeys. From my point, guest only wants to
protect the pages from guest's view, not kvm. So the access from KVM should be totally transparent
to guest. And should not be aware by guest. For modification, i think current KVM only touch the DMA
buffer which is setup by guest driver. It's guest responsibility to ensure the pages he want to
protect are not used as DMA buffer.
No really. A example is KVM need to read guest memory to emulate some instructions.
More worse, the pkey-bits on pte entry is different between guest and host (they
are using different page tables) so guest can not know what index in PKRU will be
used by KVM. A evil guest can use it to attack host...
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
