On 03/09/2016 03:41 PM, Yang Zhang wrote:
On 2016/3/9 15:21, Xiao Guangrong wrote:
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.
This is the access case. I don't think guest is interesting in such access.
See below.
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...
Can you give a example how a evil guest can attack host?
One question is if host and guest are both using pkeys, how to handle this case? I don't see current
patch consider this case?
This is exact what i said...
Currently, this patchset did not recover host's PKRU then host will use
guest's PKRU to do memory access.
--
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
