Re: [PATCH v15 4/7] x86: Add x86_64 Kernel Control Flow Integrity implementation

[Kees Cook <kees@kernel.org>]

On Wed, Aug 26, 2026 at 10:57:44AM +0200, Uros Bizjak wrote:
> On Wed, Aug 26, 2026 at 1:59 AM Kees Cook <kees@kernel.org> 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