Re: [PATCH v2 03/11] arm64: Add logic to fully remove features from sanitised id registers

[Catalin Marinas <catalin.marinas@arm.com>]

On Mon, Mar 02, 2026 at 11:56:44AM +0000, Marc Zyngier 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.

I wouldn't oppose to it really. If there are features affecting the
kernel compilation (e.g. kasan/mte), we need configs but for most
features I don't think we should bother, especially if they don't
take significantly more code/data memory when not present. It makes it
easier for us to reason about.

Of course, I'd keep the command-line overriding, it helps with
debugging.

> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 102c5bac4d502..965dd2acf0640 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,				\
> @@ -1063,16 +1063,33 @@ 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)
>  			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:
> +			/*
> +			 * 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_safe_value(ftrp, val);
>  			reg->user_val = arm64_ftr_set_safe_value(ftrp,
>  								 reg->user_val);

IIUC, if a feature is now disabled in .config and marked as
FTR_ALL_HIDDEN, we end up with a 0 field in the sanitised sysreg (or
whatever the safe value is). We now have a discrepancy between VHE and
nVHE in finalise_el2_state. The check_override_idreg macro uses the
sanitised sysregs for nVHE and the actual hw ones with VHE. Maybe not an
issue in the cases you are targeting but it's something that may bite us
in the future.

One ugly workaround is to add #ifdefs or .ifs to el2_setup.h. A slightly
better one (I think) would be to force the above visibility into the
override masks/values rather than adding FTR_ALL_HIDDEN. Let the
override checks end up with a safe value.

And, of course, my preferred way would be to drop this config-based
visibility altogether ;).

-- 
Catalin