lkml.org 
[lkml]   [2022]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v2 18/39] x86/ibt: Add IBT feature, MSR and #CP handling
Date
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.
\
 
 \ /
  Last update: 2022-02-25 21:00    [W:0.607 / U:1.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site