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

Hey Fuad,

Thanks for taking a look.

On Fri, 20 Feb 2026 08:36:04 +0000,
Fuad Tabba [off-list ref] wrote:

quoted

Hi Marc,

On Thu, 19 Feb 2026 at 19:55, Marc Zyngier [off-list ref] wrote:

quoted

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?