On 25/06/15 12:18, David Vrabel wrote: > On 24/06/15 17:31, Andrew Cooper wrote: >> Experimentally, older Linux guests perform construction of `init` with user >> pagetable mappings. This is fine for native systems as such a guest would >> not >> set CR4.SMAP itself. >> >> However if Xen uses SMAP itself, 32bit PV guests (whose kernels run in ring1) >> are also affected. Older Linux guests end up spinning in a loop assuming >> that >> the SMAP violation pagefaults are spurious, and make no further progress. >> >> One option is to disable SMAP completely, but this is unreasonable. A better >> alternative is to disable SMAP only in the context of 32bit PV guests, but >> reduces the effectiveness SMAP security. A 3rd option is for Xen to fix up >> behind a 32bit guest if it were SMAP-aware. It is a heuristic, and does >> result in a guest-visible state change, but allows Xen to keep CR4.SMAP >> unconditionally enabled. > [...] >> --- a/docs/misc/xen-command-line.markdown >> +++ b/docs/misc/xen-command-line.markdown >> @@ -1261,11 +1261,32 @@ Set the serial transmit buffer size. >> Flag to enable Supervisor Mode Execution Protection >> >> ### smap >> -> `= <boolean>` >> +> `= <boolean> | compat | fixup` >> >> > Default: `true` >> >> -Flag to enable Supervisor Mode Access Prevention >> +Handling of Supervisor Mode Access Prevention. >> + >> +32bit PV guest kernels qualify as supervisor code, as they execute in ring >> 1. >> +If Xen uses SMAP protection itself, a PV guest which is not SMAP aware may >> +suffer unexpected pagefaults which it cannot handle. (Experimentally, there >> +are 32bit PV guests which fall foul of SMAP enforcement and spin in an >> +infinite loop taking pagefaults early on boot.) >> + >> +Two further SMAP modes are introduced to work around buggy 32bit PV guests >> to >> +prevent functional regressions of VMs on newer hardware. At any point if >> the >> +guest sets `CR4.SMAP` itself, it is deemed aware, and **compat/fixup** cease >> +to apply. > Guests that is not aware of SMAP or do not support it are not "buggy".
Taking and not understanding a SMAP #PF is understandable. The way it spins in an infinite loop is unquestionably buggy. > >> + >> +A SMAP mode of **compat** causes Xen to disable `CR4.SMAP` in the context of >> +an unaware 32bit PV guest. This prevents the guest from being subject to >> SMAP >> +enforcement, but also prevents Xen from benefiting from the added security >> +checks. >> + >> +A SMAP mode of **fixup** causes Xen to set `EFLAGS.AC` when discovering a >> SMAP >> +pagefault in the context of an unaware 32bit PV guest. This allows Xen to >> +retain the added security from SMAP checks, but results in a guest-visible >> +state change which it might object to. > What does the PV ABI say about the use of EFLAGS.AC? Have guests > historically been allowed to use this bit? If so, does Xen fiddling > with it potentially break some guests? If there were an ABI written down anywhere, I might be able to answer that question. 32bit PV guest kernels cannot make use of AC themselves; alignment checking is only available in cpl3. AC is however able to be changed by a popf instruction even in cpl3 (which make it very curious as to why stac/clac are strictly cpl0 instructions). Fundamentally, smap=fixup might indeed break a PV guest, but testing shows that RHEL/CentOS 5/6, SLES 11/12 and Debian 6/7 PV guests are all fine with it. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel