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.

Thanks,

~Andrew

Reply via email to