Messages in this thread | | | Date | Tue, 31 Jan 2023 18:10:10 -0800 | Subject | Re: [PATCH 3/7] x86/cpu: Disable kernel LASS when patching kernel alternatives | From | Sohil Mehta <> |
| |
On 1/11/2023 4:37 PM, Dave Hansen wrote: > clearcpuid=smap means that the kernel should be running as if > CPUID.(EAX=07H,ECX=0H):EBX.SMAP[bit 20]==0. STAC/CLAC should #UD in > that case. > > The only reason that it happens to work is that STAC/CLAC apparently > actually continue to work even if CR4.SMAP==0. >
It seems this is by design. I was trying to experiment with clearcpuid=smap on an older platform (KBL). I noticed that even if CR4.SMAP==0 the STAC/CLAC instructions do not fault.
The STAC instruction operation in the SDM also suggests that it may be intentional. It does *not* list CR4.SMAP=0 as a reason for #UD.
#UD If the LOCK prefix is used. If the CPL > 0. If CPUID.(EAX=07H, ECX=0H):EBX.SMAP[bit 20] = 0.
> I'm actually a _bit_ surprised by this, but I bet there's a good reason > for it. >
I would love to find out the actual reasoning behind this. I'll try to poke some of the architects internally.
> In any case, please just make LASS dependent on SMAP. It's the right > thing to do on several levels.
Anyway, the end result still remains the same. We should still make LASS dependent on SMAP since:
1) The spec says that LASS enforcement only happens when SMAP is enabled. "A supervisor-mode data access causes a LASS violation only if supervisor-mode access protection is enabled (because CR4.SMAP = 1)"
2) In the extremely improbably case that LASS is available but SMAP is not available on the hardware, the STAC and CLAC instructions will fault due to the missing SMAP CPUID bit.
-Sohil
| |