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. Jan
