On 01/03/2022 11:36, Jan Beulich wrote:
> Suitable compiler options are passed only when the actual feature
> (XEN_IBT) is enabled, not when merely the compiler capability was found
> to be available.
>
> Fixes: 12e3410e071e ("x86/altcall: Check and optimise altcall targets")
> Signed-off-by: Jan Beulich <[email protected]>Hmm yes. This is fallout from separating CONFIG_HAS_CC_CET_IBT and CONFIG_XEN_IBT. Reviewed-by: Andrew Cooper <[email protected]> > --- > Furthermore, is "Optimised away ..." really appropriate in what > 37ed5da851b8 ("x86/altcall: Optimise away endbr64 instruction where > possible") added? If this really was an optimization (rather than > hardening), shouldn't we purge ENDBR also when !cpu_has_xen_ibt, and > then ideally all of them? Whereas if this is mainly about hardening, > wouldn't the message better say "Purged" or "Clobbered"? I did have an RFC about this. Turning ENDBR into NOP4 matters, on a CET-IBT-active system, to restrict the available options an attacker has when they have already managed to hijack a function pointer (i.e. already got a partial write gadget). From that point of view, it is hardening. The first version of this logic was trying to use UD1 in the same way as Linux does, to harden non-CET builds too, but that does depend on having objtool so all direct branches can have their targets updated to miss the UD1 instruction. ~Andrew P.S. I'd still like to have "away %u of %u endbr64's". It occurs to me that now we have check-endbr64.sh, we could `wc -l` the $VALID file and re-link this back in, but then we couldn't check the final objects.
