On Wed, Aug 26, 2026 at 10:57:44AM +0200, Uros Bizjak wrote: > On Wed, Aug 26, 2026 at 1:59 AM Kees Cook <[email protected]> wrote: [...] > > +/* Apply x86-64 specific masking to KCFI type ID. TYPE_ID is the 32-bit > > + KCFI type identifier to potentially mask. Returns the type ID with > > + x86-64 specific adjustments to avoid embedding ENDBR instruction > > + sequences in the type identifier values. */ > > + > > +static uint32_t > > +ix86_kcfi_mask_type_id (uint32_t type_id) > > +{ > > + /* Avoid embedding ENDBR instructions in KCFI type IDs. > > + ENDBR64: 0xfa1e0ff3, ENDBR32: 0xfb1e0ff3 > > + If the type ID matches either instruction encoding, increment by 1. > > */ > > + if (type_id == 0xfa1e0ff3U || type_id == 0xfb1e0ff3U) > > This should use the ix86_endbr_immediate_operand predicate. Exactly > one target dependent immediate (0xfa1... for TARGET_64BIT and 0xfb1 > for TARGET_32BIT) should be avoided only with flag_cf_protection & > CF_BRANCH. All this is handled in the predicate.
Ah yeah. Hmm, I double checked, and Clang doesn't gate this on -fcf-protection nor arch, which means we have a potential ABI mismatch if I change that logic in GCC's version of this. If this is really important, I could look at making Clang check for the flag/arch too, though honestly, I haven't even been able to generate a collision with these values either, so the whole thing is theoretical... I could improve the comment to note the ABI perhaps? -- Kees Cook
