On Tue, Apr 28, 2020 at 6:41 AM Andrew Cooper <andrew.coop...@citrix.com> wrote: > > 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
My proposal requires assembler, linker and compiler changes. > suggesting that we'll need to use something separate such as > -fcf-protection=magic-kernel-mode when plain -fcf-protection would do. -mcmodel=kernel should be sufficient. If -mcmodel=kernel -fcf-protection -mindirect-branch=thunk-extern works, your toolchain has implemented my proposal. -- H.J.
