Re: [PATCH 2/2] KVM: MMU: fix relaxing permission

From: Avi Kivity
Date: Thu May 27 2010 - 07:18:32 EST


On 05/27/2010 02:00 PM, Xiao Guangrong wrote:

The host always sets cr0.wp (in shadow mode) so we can write protect
page tables. So when the guest clears cr0.wp, we emulate a gpte with
gpte.w=0 and gpte.u=1 in two ways:

- spte.w=1, spte.u=0: this will allow the guest kernel to write but trap
on guest user access
- spte.w=0, spte.u=1: allows guest user access but traps on guest kernel
writes

If the guest attempts an access that is currently disallowed, we switch
to the other spte encoding.
Avi,

Thanks for your explanation, but i not see where to implement what you say,
could you please point it out for me? :-(

b70ccb0b3fd removed it accidentally:

- } else
- /*
- * Kernel mode access. Fail if it's a read-only page and
- * supervisor write protection is enabled.
- */
- if (!writable_shadow) {
- if (is_write_protection(vcpu))
- return 0;
- *shadow_ent &= ~PT_USER_MASK;
- }

:(

And, i think use 'spte.w=1, spte.u=0' to emulate 'guest cr0.wp=0 and gpte.w=0'
is not a good way since it can completely stop user process access, but in this
case, user process is usually read and kernel lazily to write, just like vdso,
it will generate a lots of #PF

As soon as the guest kernel stops writing we switch back to gpte.w=gpte.u=1 and the guest can access it completely. For the case where both the kernel and userspace use interleaved access, you are right, but I don't see a better way, do you?


--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/