linux-kernel - Re: [PATCH v2 18/39] x86/ibt: Add IBT feature, MSR and #CP handling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 25 Feb 2022 19:59:15 +0000
From:   "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To:     "Poimboe, Josh" <jpoimboe@...hat.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "hjl.tools@...il.com" <hjl.tools@...il.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "joao@...rdrivepizza.com" <joao@...rdrivepizza.com>,
        "Cooper, Andrew" <andrew.cooper3@...rix.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "rostedt@...dmis.org" <rostedt@...dmis.org>,
        "samitolvanen@...gle.com" <samitolvanen@...gle.com>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "alexei.starovoitov@...il.com" <alexei.starovoitov@...il.com>,
        "Milburn, Alyssa" <alyssa.milburn@...el.com>,
        "mhiramat@...nel.org" <mhiramat@...nel.org>,
        "mbenes@...e.cz" <mbenes@...e.cz>,
        "ndesaulniers@...gle.com" <ndesaulniers@...gle.com>
Subject: Re: [PATCH v2 18/39] x86/ibt: Add IBT feature, MSR and #CP handling

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.