[PATCH 1/9] arm64: Add logic to fully remove features from sanitised id registers
Marc Zyngier
maz at kernel.org
Fri Feb 20 02:09:46 PST 2026
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?
>
> > 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.
More information about the linux-arm-kernel
mailing list