Re: [PATCH 1/9] arm64: Add logic to fully remove features from sanitised id registers

[Marc Zyngier <maz@kernel.org>]

Hey Fuad,

Thanks for taking a look.

On Fri, 20 Feb 2026 08:36:04 +0000,
Fuad Tabba <tabba@google.com> wrote:
> 
> Hi Marc,
> 
> On Thu, 19 Feb 2026 at 19:55, Marc Zyngier <maz@kernel.org> wrote:
> >
> > We currently make support for some features such as Pointer Auth,
> > SVE or S1POE a compile time decision.
> >
> > However, while we hide that feature from userspace when such support
> > is disabled, we still leave the value provided by the HW visible to
> > the rest of the kernel, including KVM.
> >
> > This has the potential to result in ugly state leakage, as half of
> > the kernel knows about the feature, and the other doesn't.
> >
> > Short of completely banning such compilation options and restore
> > universal knowledge, introduce the possibility to fully remove such
> > knowledge from the sanitised id registers.
> >
> > This has more or less the same effect as the idreg override that
> > a user can pass on the command-line, only defined at build-time.
> >
> > For that purpose, we provide a new macro (FTR_CONFIG()) that defines
> > the behaviour of a feature, both when enabled and disabled.
> >
> > At this stage, nothing is making use of this anti-feature.
> >
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> >  arch/arm64/include/asm/cpufeature.h | 15 ++++++++++-----
> >  arch/arm64/kernel/cpufeature.c      | 21 ++++++++++++++++-----
> >  2 files changed, 26 insertions(+), 10 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> > index 4de51f8d92cba..2731ea13c2c86 100644
> > --- a/arch/arm64/include/asm/cpufeature.h
> > +++ b/arch/arm64/include/asm/cpufeature.h
> > @@ -53,15 +53,20 @@ enum ftr_type {
> >  #define FTR_SIGNED     true    /* Value should be treated as signed */
> >  #define FTR_UNSIGNED   false   /* Value should be treated as unsigned */
> >
> > -#define FTR_VISIBLE    true    /* Feature visible to the user space */
> > -#define FTR_HIDDEN     false   /* Feature is hidden from the user */
> > +enum ftr_visibility {
> > +       FTR_HIDDEN,             /* Feature hidden from the user */
> > +       FTR_ALL_HIDDEN,         /* Feature hidden from kernel, user and KVM */
> > +       FTR_VISIBLE,            /* Feature visible to all observers */
> > +};
> > +
> > +#define FTR_CONFIG(c, e, d)                            \
> > +       (IS_ENABLED(c) ? FTR_ ## e : FTR_ ## d)
> >
> > -#define FTR_VISIBLE_IF_IS_ENABLED(config)              \
> > -       (IS_ENABLED(config) ? FTR_VISIBLE : FTR_HIDDEN)
> > +#define FTR_VISIBLE_IF_IS_ENABLED(c)   FTR_CONFIG(c, VISIBLE, HIDDEN)
> >
> >  struct arm64_ftr_bits {
> >         bool            sign;   /* Value is signed ? */
> > -       bool            visible;
> > +       enum ftr_visibility visibility;
> >         bool            strict; /* CPU Sanity check: strict matching required ? */
> >         enum ftr_type   type;
> >         u8              shift;
> 
> This introduces bloat. Should you group the bools together and the
> enums together?

That should be possible as long as everybody ends up using the
__ARM64_FTR_BITS macro. On the other hand, I could reduce the width of
the enum to something more appropriate and keep the current layout.

With the current changes, this looks like this:

struct arm64_ftr_bits {
	bool                       sign;                 /*     0     1 */

	/* XXX 3 bytes hole, try to pack */

	enum ftr_visibility        visibility;           /*     4     4 */
	bool                       strict;               /*     8     1 */

	/* XXX 3 bytes hole, try to pack */

	enum ftr_type              type;                 /*    12     4 */
	u8                         shift;                /*    16     1 */
	u8                         width;                /*    17     1 */

	/* XXX 6 bytes hole, try to pack */

	s64                        safe_val;             /*    24     8 */

	/* size: 32, cachelines: 1, members: 7 */
	/* sum members: 20, holes: 3, sum holes: 12 */
	/* last cacheline: 32 bytes */
};

which is 8 bytes larger than the upstream version. But if I do this:

diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index adaae3060851c..d8accc9c94fab 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -64,9 +64,9 @@ enum ftr_visibility {
 
 struct arm64_ftr_bits {
 	bool		sign;	/* Value is signed ? */
-	enum ftr_visibility visibility;
+	enum ftr_visibility visibility:8;
 	bool		strict;	/* CPU Sanity check: strict matching required ? */
-	enum ftr_type	type;
+	enum ftr_type	type:8;
 	u8		shift;
 	u8		width;
 	s64		safe_val; /* safe value for FTR_EXACT features */

I end up with the following layout:

struct arm64_ftr_bits {
	bool                       sign;                 /*     0     1 */

	/* Bitfield combined with previous fields */

	enum ftr_visibility        visibility:8;         /*     0: 8  4 */

	/* Bitfield combined with next fields */

	bool                       strict;               /*     2     1 */

	/* Bitfield combined with previous fields */

	enum ftr_type              type:8;               /*     0:24  4 */
	u8                         shift;                /*     4     1 */
	u8                         width;                /*     5     1 */

	/* XXX 2 bytes hole, try to pack */

	s64                        safe_val;             /*     8     8 */

	/* size: 16, cachelines: 1, members: 7 */
	/* sum members: 12, holes: 1, sum holes: 2 */
	/* sum bitfield members: 16 bits (2 bytes) */
	/* last cacheline: 16 bytes */
};

which is 8 bytes *smaller* than the upstream version, without
reordering. WDYT?

> 
> > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > index c840a93b9ef95..b34a39967d111 100644
> > --- a/arch/arm64/kernel/cpufeature.c
> > +++ b/arch/arm64/kernel/cpufeature.c
> > @@ -192,7 +192,7 @@ void dump_cpu_features(void)
> >  #define __ARM64_FTR_BITS(SIGNED, VISIBLE, STRICT, TYPE, SHIFT, WIDTH, SAFE_VAL) \
> >         {                                               \
> >                 .sign = SIGNED,                         \
> > -               .visible = VISIBLE,                     \
> > +               .visibility = VISIBLE,                  \
> >                 .strict = STRICT,                       \
> >                 .type = TYPE,                           \
> >                 .shift = SHIFT,                         \
> > @@ -1057,17 +1057,28 @@ static void init_cpu_ftr_reg(u32 sys_reg, u64 new)
> >                                 ftrp->shift);
> >                 }
> >
> > -               val = arm64_ftr_set_value(ftrp, val, ftr_new);
> > -
> >                 valid_mask |= ftr_mask;
> >                 if (!ftrp->strict)
> 
> Should FTR_ALL_HIDDEN also be removed from strict_mask? i.e.
> 
> -                 if (!ftrp->strict)
> +                 if (!ftrp->strict || || ftrp->visibility == FTR_ALL_HIDDEN)
> 
> (or under the ALL_HIDDEN case below).

If we run on a system that has diverging features, we probably want to
know irrespective of the feature being enabled. After all, the
integration is out of spec, and conveying that information is
important, just in case the diverging feature affects behaviour in
funny ways...

> 
> 
> >                         strict_mask &= ~ftr_mask;
> > -               if (ftrp->visible)
> > +
> > +               switch (ftrp->visibility) {
> > +               case FTR_VISIBLE:
> > +                       val = arm64_ftr_set_value(ftrp, val, ftr_new);
> >                         user_mask |= ftr_mask;
> > -               else
> > +                       break;
> > +               case FTR_ALL_HIDDEN:
> > +                       val = arm64_ftr_set_value(ftrp, val, ftrp->safe_val);
> > +                       reg->user_val = arm64_ftr_set_value(ftrp,
> > +                                                           reg->user_val,
> > +                                                           ftrp->safe_val);
> 
> Should we also take the safe value in update_cpu_ftr_reg() for FTR_ALL_HIDDEN?

I would expect arm64_ftr_safe_value() to do the right thing at that
stage, given that we have primed the boot CPU with the safe value, and
that we rely on that bootstrap to make the registers converge towards
something safe. This is also what happens for the command-line override.

Or have you spotted a case where this go wrong?

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.