| From | "Edgecombe, Rick P" <> | Subject | Re: [PATCH v2 18/39] x86/ibt: Add IBT feature, MSR and #CP handling | Date | Fri, 25 Feb 2022 19:59:15 +0000 |
| |
On Thu, 2022-02-24 at 15:51 +0100, Peter Zijlstra wrote: > +__noendbr void cet_disable(void) > +{ > + if (cpu_feature_enabled(X86_FEATURE_IBT)) > + wrmsrl(MSR_IA32_S_CET, 0); > +} > +
Did this actually work? There are actually two problems with kexecing when CET is enabled. One is leaving the enforcement enabled when the new kernel can't handle it. The other is that CR4.CET and CR0.WP are tied together such that if you try to disable CR0.WP while CR4.CET is still set, it will #GP. CR0.WP gets unset during kexec/boot in the new kernel, so it blows up if you just disable IBT with the MSR and leave the CR4 bit set.
I was under the impression that this had been tested in the userspace series, but apparently not as I've just produced the CR0.WP issue. So it needs to be fixed in that series too. Userspace doesn't really need it pinned, so it should be easy.
For kernel IBT, to enumerate a few options for kexec/pinning:
1. Just remove CR4.CET from the pinning mask, and unset it normally. 2. Leave it in the pinning mask and add separate non-pin-checking inlined CR4 write late in the kexec path to unset CR4.CET. 3. Remove the unsetting of CR0.WP in the boot path. This would only support kexecing to new kernels (there were actually patches for this from the KVM CR pinning stuff that detected whether the new kernel was bootable and failed gracefully IIRC). It's potentially fraught and not great to lose kexecing to old kernels. 4. Do (1) for now and then follow this series with a larger solution that does (2) and also adds some level of MSR pinning.
|