On 28/04/2020 14:00, H.J. Lu wrote: > On Tue, Apr 28, 2020 at 5:43 AM Andrew Cooper <andrew.coop...@citrix.com> > wrote: >> Hello, >> >> I raised https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93654 but it has >> had nothing but tumbleweeds in months, and it is continuing to cause >> problems for Xen. >> >> During the Spectre embargo period, it was specifically identified that >> kernels would need to be able to compile one single binary, which was >> retpoline safe on older hardware, and able to use CET on newer hardware. >> >> thunk-extern was deliberately constructed (along with >> -mindirect-branch-register) such that the thunk could be turned into >> something which wasn't a ROP gadget when hardware was less broken. Both >> Linux and Xen use this, with the ability to substitute the exact thunk >> in use to be suitable for the CPU booted on. (In particular, AMD >> recommend `lfence; jmp *%reg` over the traditional retpoline thunk.) >> >> >> A consequence of GCC rejecting this combination is that Linux has >> unilaterally disabled -fcf-protection >> >> # ensure -fcf-protection is disabled when using retpoline as it is >> # incompatible with -mindirect-branch=thunk-extern >> ifdef CONFIG_RETPOLINE >> KBUILD_CFLAGS += $(call cc-option,-fcf-protection=none) >> endif >> >> and a change similar to this is being proposed for Xen. However, doing >> this will leave distros with the choice between disabling retpoline or >> not using CET, which is not in the best security interest of the user. >> >> Please can the original change be partially reverted? thunk-extern >> means "I'm providing the thunks, and I'll take care of ensuring that >> they are appropriate", and that includes not being a ROP gadget when CET >> is active. >> > Please DO disable -fcf-protection in the kernel build. We are enabling > CET for the user space first. The kernel CET will be the next. > > I am enclosing a proposal to make -fcf-protection compatible with retpoline. > It targets user space. It can be made compatible with kernel.
Its fine to focus on userspace first, but the kernel is far more simple. Looking at that presentation, the only thing missing for kernel is the notrack thunks, in the unlikely case that such code would be tolerated (Frankly, I don't expect Xen or Linux to run with notrack enabled, as there is no legacy code to be concerned with). What is going to happen about unbreaking this combination of options? How will we know when kernel mode is supported (not that I can see anything further required from the toolchain)? I really hope you're not suggesting that we'll need to use something separate such as -fcf-protection=magic-kernel-mode when plain -fcf-protection would do. ~Andrew
