On 28/04/2020 16:09, H.J. Lu wrote: > 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
That's all I was asking for. I understand and completely accept that -fcf-protection and most -mindirect-branch options are incompatible, and rejecting those are reasonable. But by building with thunk-extern, I (the kernel) am taking responsibility for providing suitable thunks. ~Andrew P.S. It is not just Xen. Microkernels don't tend to use -mcmodel=kernel either.
