** 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 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 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2046440 Title: Enforce RETPOLINE and SLS mitigrations Status in linux package in Ubuntu: New Bug description: [ 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. 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 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2046440/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
