On 10/17/18 8:08 AM, Andrew Cooper wrote: > On 05/10/18 18:02, Andrew Cooper wrote: >> When using shadow paging, EFER.NX is a Xen controlled bit, and is required by >> the shadow pagefault handler to distinguish instruction fetches from data >> accesses. >> >> This can be observed by a guest which has NX and SMEP clear but SMAP active >> by >> attempting to execute code on a user mapping. The first attempt to build the >> target shadow will #PF so is handled by the shadow code, but when walking the >> the guest pagetables, the lack of PFEC_insn_fetch being signalled causes the >> shadow code to mistake the instruction fetch for a data fetch, and believe >> that it is a real guest fault. As a result, the guest receives #PF[-d-srP] >> for an action which should complete successfully. >> >> The suspicious-looking gymnastics with LME is actually a subtle corner case >> with shadow paging. When dropping out of Long Mode, a guests choice of LME >> and Xen's choice of CR0.PG cause hardware to operate in Long Mode, but the >> shadow code to operate in 2-on-3 mode. >> >> In addition to describing this corner case in the SVM side, extend the >> comment >> for the same fix on the VT-x side. (I have a suspicion that I've just worked >> out why VT-x doesn't tolerate LMA != LME when Unrestricted Guest is clear.) >> >> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
