** Description changed:
+ [ Impact ]
+
Enforce RETPOLINE and SLS mitigrations
Currently retpoline ABI checks in the kernel build do nothing. They
produce no output, as if everything is fine. And if one manually hacks
makefile to "forget" retpoline & SLS mitigration flags, objtool prints
lots of warnings, retpoline ABI check passes and the build is succesful.
Yet totally vulnerable.
Proposal is to enforce objtool warnings as fatal errors for RETPOLINE
and SLS, as tested to be passed on mantic for both kernel and all
available dkms. And otherwise rip out custom Ubuntu retpoline abi
checks.
I have prepared this for noble v6.7 kernel, once this lands, I will make
appropriate backports for earlier series as we likely want usable
retpoline build time enforcement in earlier series too where possible.
+
+ [ Test Plan ]
+
+ * Hack arch/x86/Makefile and comment out KBUILD_CFLAGS +=
+ $(RETPOLINE_CFLAGS)
+
+ This simulate a build infrastructure, or toolchain regression, or hand-
+ written assembly code that is susceptible to speculative attacks.
+
+ Attempt to build the kernel.
+
+ The kernel build must fail. Currently it doesn't, and retpoline ABI
+ checks do not catch it.
+
+
+ [ Where problems could occur ]
+
+ * This change will make our kernel build more strict, especially for
+ dkms packages. dkms packages that ship in Ubuntu archive have been build
+ tested to pass with these more strict requirements in place. Other
+ external modules that fail with such strict configuration should either
+ fix their code to be retpoline/redbleed safe - or use a config override
+ CONFIG_RETPOLINE=n to disable retpoline during their build, or otherwise
+ use one of the OBJTOOL_ settings in their dkms Makefiles to skip objtool
+ on given portions of code, or otherwise mark things as retpoline_safe /
+ noreturn / etc. See examples in the linux upstream source code.
+
+ [ Other Info ]
+
+ * This work was done as part of hackathon questioning abi checks usefulness,
given I have never experienced retpoline check failure. And they have always
been empty since early v4.15 days
https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/bionic/tree/debian.master/abi/4.15.0-13.14/amd64/generic.retpoline?h=Ubuntu-4.15.0-14.15
** Description changed:
[ Impact ]
Enforce RETPOLINE and SLS mitigrations
Currently retpoline ABI checks in the kernel build do nothing. They
produce no output, as if everything is fine. And if one manually hacks
makefile to "forget" retpoline & SLS mitigration flags, objtool prints
lots of warnings, retpoline ABI check passes and the build is succesful.
Yet totally vulnerable.
Proposal is to enforce objtool warnings as fatal errors for RETPOLINE
and SLS, as tested to be passed on mantic for both kernel and all
available dkms. And otherwise rip out custom Ubuntu retpoline abi
checks.
I have prepared this for noble v6.7 kernel, once this lands, I will make
appropriate backports for earlier series as we likely want usable
retpoline build time enforcement in earlier series too where possible.
[ Test Plan ]
- * Hack arch/x86/Makefile and comment out KBUILD_CFLAGS +=
+ Hack arch/x86/Makefile and comment out KBUILD_CFLAGS +=
$(RETPOLINE_CFLAGS)
This simulate a build infrastructure, or toolchain regression, or hand-
written assembly code that is susceptible to speculative attacks.
Attempt to build the kernel.
The kernel build must fail. Currently it doesn't, and retpoline ABI
checks do not catch it.
+ Another approach is to build a known buggy dkms modules on x86 - for
+ example zfs-dkms with ret -> RET changes reverted in assembly
+ accelerated code.
[ Where problems could occur ]
- * This change will make our kernel build more strict, especially for
- dkms packages. dkms packages that ship in Ubuntu archive have been build
+ This change will make our kernel build more strict, especially for dkms
+ packages. dkms packages that ship in Ubuntu archive have been build
tested to pass with these more strict requirements in place. Other
external modules that fail with such strict configuration should either
fix their code to be retpoline/redbleed safe - or use a config override
CONFIG_RETPOLINE=n to disable retpoline during their build, or otherwise
use one of the OBJTOOL_ settings in their dkms Makefiles to skip objtool
on given portions of code, or otherwise mark things as retpoline_safe /
noreturn / etc. See examples in the linux upstream source code.
[ Other Info ]
-
- * This work was done as part of hackathon questioning abi checks usefulness,
given I have never experienced retpoline check failure. And they have always
been empty since early v4.15 days
https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/bionic/tree/debian.master/abi/4.15.0-13.14/amd64/generic.retpoline?h=Ubuntu-4.15.0-14.15
+
+ This work was done as part of hackathon
