[MODERATED] Re: [PATCH] SPTE masking

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 09/08/18 12:54, speck for Paolo Bonzini wrote:
> On 09/08/2018 13:46, speck for Andrew Cooper wrote:
>>> I tried emulating guestphysaddr < hostphysaddr in KVM, but generating
>>> the reserved bits page fault from EPT violations doesn't work.  If the
>>> host processor thinks the bits are not reserved and generates e.g. a
>>> present-but-not-writable fault, no EPT violation happens
>> Sounds like you've got a KVM bug here.  Either an EPT misconfig or
>> violation is guaranteed to occur here, because you won't have allowed an
>> EPT mapping at a guest physical address above guest maxphysaddr, would you?
> The problem is that no access occurs at all in the case that becomes buggy.
>
> For example, say host mpa = 46, guest mpa = 40, and you write to a page
> table with PTE.P and PTE.40 set, but PTE.W cleared.  You'll get a page
> fault with error code present/writable, because the host does not think
> PTE.40 must be zero.  On a real processor you'd have gotten a reserved
> bit page fault.  Likewise for a CPL=3 access where PTE.U=0, etc.
>
> I know because I tried just yesterday :) and as soon as I saw the
> problem I remembered having tried at least once more in the past.  AFAIU
> Intel is also convinced that it should be possible, so maybe I'm missing
> something.  But I don't see a workaround.

Oh lovely :(

Yes - architecturally, there is no memory access when a #PF occurs, so
an EPT-based vmexit won't occur.

It would be interesting to hear an architects take on reserved pagefault
bits, but I expect "don't do that then" might be the answer.

>
>> Even with a strict interpretation 51:maxphysaddr, I don't see any
>> technical limitations with emulating it correctly.  Making this work in
>> Xen is on my todo list (once I've figured out exactly how Intel and
>> AMD's implementation of SMAP differ, so I can fix the software pagewalk
>> to match the hardware it is running on).
> Interesting, do you have pointers to the differences?

There is one case to do with implicit accesses which is definitely
different.  There is no Implicit access flag in the error code (i.e.
insufficient architectural state), which leads to the following corner case:

https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/mm/shadow/multi.c;h=021ae252e47f2cf43ee1aaea9508105ee855d771;hb=4b60c40659b34b6577a6bc91eb4115458a0e425f#l2977

From what I understand, Intels behaviour used to be sensible (from a
hypervisor point of view) in an earlier version of the SMAP spec, and
AMD implemented that version.  Then, a later version of the SMAP spec
inverted the supervisor implicit access to a user mapping case.

AMD raised erratum 1053 "When SMAP is Enabled and EFLAGS.AC is Set, the
Processor Will Fail to Page Fault on an Implicit Supervisor Access to a
User Page", but are considering whether to not even fix it in future
silicon as I pointed out that this is better behaviour from software's
point of view.

Beyond that, there further differences in the determination of access
rights, which I have yet to track down.  This work is on pause while I'm
L1TFing.

~Andrew