Hi, This is an (almost!) complete Kernel IBT implementation. It's been self-hosting for a few days now. That is, it runs on IBT enabled hardware (Tigerlake) and is capable of building the next kernel. It is also almost clean on allmodconfig using GCC-11.2. The biggest TODO item at this point is Clang, I've not yet looked at that. Patches are also available here: git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git x86/wip.ibt This series is on top of tip/master along with the linkage patches from Mark: https://lore.kernel.org/all/20220216162229.1076788-1-mark.rutland@arm.com/ Enjoy!
On Fri, 2022-02-18 at 17:49 +0100, Peter Zijlstra wrote: > This is an (almost!) complete Kernel IBT implementation. It's been > self-hosting > for a few days now. That is, it runs on IBT enabled hardware > (Tigerlake) and is > capable of building the next kernel. > > It is also almost clean on allmodconfig using GCC-11.2. > > The biggest TODO item at this point is Clang, I've not yet looked at > that. Do you need to turn this off before kexec?
On Sat, Feb 19, 2022 at 01:29:45AM +0000, Edgecombe, Rick P wrote:
> On Fri, 2022-02-18 at 17:49 +0100, Peter Zijlstra wrote:
> > This is an (almost!) complete Kernel IBT implementation. It's been
> > self-hosting
> > for a few days now. That is, it runs on IBT enabled hardware
> > (Tigerlake) and is
> > capable of building the next kernel.
> >
> > It is also almost clean on allmodconfig using GCC-11.2.
> >
> > The biggest TODO item at this point is Clang, I've not yet looked at
> > that.
>
> Do you need to turn this off before kexec?
Probably... :-) I've never looked at that code though; so I'm not
exactly sure where to put things.
I'm assuming kexec does a hot-unplug of all but the boot-cpu which then
leaves only a single CPU with state in machine_kexec() ? Does the below
look reasonable?
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -638,6 +638,12 @@ static __always_inline void setup_cet(st
}
}
+void cet_disable(void)
+{
+ cr4_clear_bits(X86_CR4_CET);
+ wrmsrl(MSR_IA32_S_CET, 0);
+}
+
/*
* Some CPU features depend on higher CPUID levels, which may not always
* be available due to CPUID level capping or broken virtualization
diff --git a/arch/x86/include/asm/cpu.h b/arch/x86/include/asm/cpu.h
index 33d41e350c79..cf26356db53e 100644
--- a/arch/x86/include/asm/cpu.h
+++ b/arch/x86/include/asm/cpu.h
@@ -72,4 +72,7 @@ void init_ia32_feat_ctl(struct cpuinfo_x86 *c);
#else
static inline void init_ia32_feat_ctl(struct cpuinfo_x86 *c) {}
#endif
+
+extern void cet_disable(void);
+
#endif /* _ASM_X86_CPU_H */
diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
index f5da4a18070a..29a2a1732605 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -310,6 +310,7 @@ void machine_kexec(struct kimage *image)
/* Interrupts aren't acceptable while we reboot */
local_irq_disable();
hw_breakpoint_disable();
+ cet_disable();
if (image->preserve_context) {
#ifdef CONFIG_X86_IO_APIC
On 19/02/2022 09:58, Peter Zijlstra wrote: > On Sat, Feb 19, 2022 at 01:29:45AM +0000, Edgecombe, Rick P wrote: >> On Fri, 2022-02-18 at 17:49 +0100, Peter Zijlstra wrote: >>> This is an (almost!) complete Kernel IBT implementation. It's been >>> self-hosting >>> for a few days now. That is, it runs on IBT enabled hardware >>> (Tigerlake) and is >>> capable of building the next kernel. >>> >>> It is also almost clean on allmodconfig using GCC-11.2. >>> >>> The biggest TODO item at this point is Clang, I've not yet looked at >>> that. >> Do you need to turn this off before kexec? > Probably... :-) I've never looked at that code though; so I'm not > exactly sure where to put things. > > I'm assuming kexec does a hot-unplug of all but the boot-cpu which then > leaves only a single CPU with state in machine_kexec() ? Does the below > look reasonable? If you skip writing to S_CET on hardware that doesn't have it, probably. ~Andrew
On February 19, 2022 1:58:27 AM PST, Peter Zijlstra <peterz@infradead.org> wrote:
>On Sat, Feb 19, 2022 at 01:29:45AM +0000, Edgecombe, Rick P wrote:
>> On Fri, 2022-02-18 at 17:49 +0100, Peter Zijlstra wrote:
>> > This is an (almost!) complete Kernel IBT implementation. It's been
>> > self-hosting
>> > for a few days now. That is, it runs on IBT enabled hardware
>> > (Tigerlake) and is
>> > capable of building the next kernel.
>> >
>> > It is also almost clean on allmodconfig using GCC-11.2.
>> >
>> > The biggest TODO item at this point is Clang, I've not yet looked at
>> > that.
>>
>> Do you need to turn this off before kexec?
>
>Probably... :-) I've never looked at that code though; so I'm not
>exactly sure where to put things.
>
>I'm assuming kexec does a hot-unplug of all but the boot-cpu which then
>leaves only a single CPU with state in machine_kexec() ? Does the below
>look reasonable?
>
>--- a/arch/x86/kernel/cpu/common.c
>+++ b/arch/x86/kernel/cpu/common.c
>@@ -638,6 +638,12 @@ static __always_inline void setup_cet(st
> }
> }
>
>+void cet_disable(void)
>+{
>+ cr4_clear_bits(X86_CR4_CET);
I'd rather keep the pinning...
>+ wrmsrl(MSR_IA32_S_CET, 0);
>+}
Eh, why not just require kexec to be IBT safe? That seems a reasonable exercise if we ever expect UEFI to enforce IBT when starting the kernel on a normal boot...
-Kees
>+
> /*
> * Some CPU features depend on higher CPUID levels, which may not always
> * be available due to CPUID level capping or broken virtualization
>diff --git a/arch/x86/include/asm/cpu.h b/arch/x86/include/asm/cpu.h
>index 33d41e350c79..cf26356db53e 100644
>--- a/arch/x86/include/asm/cpu.h
>+++ b/arch/x86/include/asm/cpu.h
>@@ -72,4 +72,7 @@ void init_ia32_feat_ctl(struct cpuinfo_x86 *c);
> #else
> static inline void init_ia32_feat_ctl(struct cpuinfo_x86 *c) {}
> #endif
>+
>+extern void cet_disable(void);
>+
> #endif /* _ASM_X86_CPU_H */
>diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
>index f5da4a18070a..29a2a1732605 100644
>--- a/arch/x86/kernel/machine_kexec_64.c
>+++ b/arch/x86/kernel/machine_kexec_64.c
>@@ -310,6 +310,7 @@ void machine_kexec(struct kimage *image)
> /* Interrupts aren't acceptable while we reboot */
> local_irq_disable();
> hw_breakpoint_disable();
>+ cet_disable();
>
> if (image->preserve_context) {
> #ifdef CONFIG_X86_IO_APIC
--
Kees Cook
On Mon, Feb 21, 2022 at 12:42:25AM -0800, Kees Cook wrote:
> >+void cet_disable(void)
> >+{
> >+ cr4_clear_bits(X86_CR4_CET);
>
> I'd rather keep the pinning...
Uff. is that still enforced at this point?
> >+ wrmsrl(MSR_IA32_S_CET, 0);
> >+}
>
> Eh, why not just require kexec to be IBT safe? That seems a reasonable
> exercise if we ever expect UEFI to enforce IBT when starting the
> kernel on a normal boot...
Well, it makes it impossible to kexec into an 'old' kernel. That might
not be very nice.
On Fri, 2022-02-18 at 17:49 +0100, Peter Zijlstra wrote: > This is an (almost!) complete Kernel IBT implementation. BTW, I've successfully tested this on what /proc/cpuinfo calls an "11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz" (in a Lenovo "Yoga 7 15ITL5"). Normal laptop-y things all seem happy and it correctly blows up on a new LKDTM test I'll send out tomorrow. So, even though the series is young and has some TODOs still: Tested-by: Kees Cook <keescook@chromium.org> One thought: should there be a note in dmesg about it being active? The only way to see it is finding "ibt" in cpuinfo... -Kees -- Kees Cook
On Tue, Feb 22, 2022 at 11:26:57PM -0800, Kees Cook wrote: > > On Fri, 2022-02-18 at 17:49 +0100, Peter Zijlstra wrote: > > This is an (almost!) complete Kernel IBT implementation. > > BTW, I've successfully tested this on what /proc/cpuinfo calls an "11th > Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz" (in a Lenovo "Yoga 7 15ITL5"). > Normal laptop-y things all seem happy and it correctly blows up on a new > LKDTM test I'll send out tomorrow. For me it boots and can build kernel on a desktop with "12th Gen Intel(R) Core(TM) i9-12900K" > So, even though the series is young and has some TODOs still: > > Tested-by: Kees Cook <keescook@chromium.org> So, FWIW: Tested-by: Mike Rapoport <rppt@linux.ibm.com> > One thought: should there be a note in dmesg about it being active? The > only way to see it is finding "ibt" in cpuinfo... > > -Kees > > -- > Kees Cook -- Sincerely yours, Mike.
© 2016 - 2026 Red Hat, Inc.