[PATCH 1/9] arm64: Add logic to fully remove features from sanitised id registers
Fuad Tabba
tabba at google.com
Fri Feb 20 03:06:03 PST 2026
Hi Marc,
On Fri, 20 Feb 2026 at 10:09, Marc Zyngier <maz at kernel.org> wrote:
>
> Hey Fuad,
>
> Thanks for taking a look.
>
> On Fri, 20 Feb 2026 08:36:04 +0000,
> Fuad Tabba <tabba at google.com> wrote:
> >
> > Hi Marc,
> >
> > On Thu, 19 Feb 2026 at 19:55, Marc Zyngier <maz at 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 at 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?
Using 8-bit bitfields for the enums shrinks the footprint from 24 to
16 bytes while preserving the structure's semantic readability. I like
this approach.
>
> >
> > > 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...
I see. If the kernel is booted on broken/asymmetric hardware, we still
want to warn the user about the underlying violation, even if we are
pretending the feature doesn't exist for our own purposes. Leaving it
in the strict_mask is the correct approach to retain that diagnostic
capability.
> >
> >
> > > 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?
I think so... What if a future FTR_ALL_HIDDEN feature is defined as
FTR_HIGHER_SAFE? Wouldn't that cause problems on secondary CPUs?
init_cpu_ftr_reg() primes sys_val with safe_val on the boot CPU,
update_cpu_ftr_reg() on secondary CPUs compares the hardware value
(ftr_new) against safe_val (ftr_cur). For FTR_HIGHER_SAFE,
arm64_ftr_safe_value() returns max(ftr_new, safe_val). Since the
hardware value is higher, update_cpu_ftr_reg() overwrites sys_val with
the hardware value, resurrecting the hidden feature globally.
The features in this patch are FTR_LOWER_SAFE or FTR_EXACT (which
happen to sink to safe_val), which is why it's not a problem with
these current features.
Cheers,
/fuad
> Thanks,
>
> M.
>
> --
> Without deviation from the norm, progress is not possible.
More information about the linux-arm-kernel
mailing list