On Tue, Apr 28, 2020 at 8:06 AM Jan Beulich <jbeul...@suse.com> wrote: > > On 28.04.2020 17:00, H.J. Lu wrote: > > 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. > > But please note that Xen doesn't get built with -mcmodel=kernel, so > the two remaining options ought to work together also without this > one.
Then -fcf-protection -mindirect-branch=thunk-extern for Xen. -- H.J.
