On Thu, Aug 27, 2026 at 7:03 AM Kees Cook <[email protected]> wrote: > > 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...
No, it is not *that* important, just noted that these magic constants are handled in a different way than elsewhere in the compiler. > I could improve the comment to note the ABI perhaps? Yes, this would be fine, too. Thanks, Uros.
