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

Hi Fuad,

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

quoted

I think we must prevent this downgrade the same way, meaning that
ALL_HIDDEN and FTR_HIGHER are mutually exclusive.

How about that:

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index d58931e63a0b6..2cae00b4b0c5f 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c

@@ -1067,7 +1067,14 @@ static void init_cpu_ftr_reg(u32 sys_reg, u64 new)
                        user_mask |= ftr_mask;
                        break;
                case FTR_ALL_HIDDEN:
-                       val = arm64_ftr_set_value(ftrp, val, ftrp->safe_val);
+                       /*
+                        * ALL_HIDDEN and HIGHER_SAFE are incompatible.
+                        * Only hide from userspace, and log the oddity.
+                        */
+                       if (WARN_ON(ftrp->type == FTR_HIGHER_SAFE))
+                               val = arm64_ftr_set_value(ftrp, val, ftr_new);
+                       else
+                               val = arm64_ftr_set_value(ftrp, val, ftrp->safe_val);
                        reg->user_val = arm64_ftr_set_value(ftrp,
                                                            reg->user_val,
                                                            ftrp->safe_val);

Yes, I think WARN_ON() here is the right call.

That said, I still think you should explicitly short-circuit
update_cpu_ftr_reg() for FTR_ALL_HIDDEN features, in addition to the
WARN_ON(). Relying on arm64_ftr_safe_value() to naturally preserve the
safe_val during secondary CPU boot seems mathematically fragile.

Take MTE_frac as an example. It uses S_ARM64_FTR_BITS and
FTR_LOWER_SAFE with a safe_val of 0. If it were marked FTR_ALL_HIDDEN,
init_cpu_ftr_reg() would prime sys_val with 0. But if a secondary CPU
boots and reports -1 (NI), arm64_ftr_safe_value() will execute min(-1,
0) and return -1. update_cpu_ftr_reg() will then overwrite the primed
safe_val (0) with -1. The "hidden" state established by the boot CPU
is gone, and the feature's hardware state is now exposed globally.

Note that MTE is currently ALL_HIDDEN when configured out, so it's not
totally inconceivable that someone decides to make MTE_frac ALL_HIDDEN
as well. Explicitly short-circuiting for FTR_ALL_HIDDEN features in
update_cpu_ftr_reg() seems to be the safer bet here.

Right, the signed feature is a pretty compelling argument. And we
should do the same thing for overrides, probably as a preliminary
patch.

Thanks,

	M.

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