Re: [PATCH v2 14/28] arm64: sysreg: Add HCRX_EL2 bits related to FEAT_NV3

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Adding FEAT_NV3 fields to HCRX_EL2 in the sysreg file silently alters the auto-generated HCRX_EL2_RES0 mask. Because KVM's manually maintained feature maps were not updated to account for this change, it triggers a boot-time verification failure and allows guests to unconditionally set these unsupported bits, breaching hypervisor isolation.
--

--- Patch [14]: [PATCH v2 14/28] arm64: sysreg: Add HCRX_EL2 bits related to FEAT_NV3 ---
commit c8a8a5e81c8baa4b59a436c9bd034245cdeb5fa4
Author: Marc Zyngier <maz@kernel.org>

arm64: sysreg: Add HCRX_EL2 bits related to FEAT_NV3

This patch introduces 4 new HCRX_EL2 control bits related to FEAT_NV3 and
describes them in the sysreg file.

> diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
> index 42839d2b15ae4..67d013b376a3c 100644
> --- a/arch/arm64/tools/sysreg
> +++ b/arch/arm64/tools/sysreg
> @@ -4548,7 +4548,12 @@ Fields	ZCR_ELx
>  EndSysreg
>  
>  Sysreg	HCRX_EL2	3	4	1	2	2
> -Res0	63:27
> +Res0	63:35
> +Field	34	NVnTTLBOS
> +Field	33	NVnTTLBIS
> +Field	32	NVnTTLB
> +Res0	31:28
> +Field	27	NVTGE

[Severity: High]
Does this change require a corresponding update to KVM's feature map?

By defining these new fields here, the auto-generated HCRX_EL2_RES0 mask is
shrunk. Because KVM's manually maintained feature map consumes this mask
without adding NEEDS_FEAT rules for the new bits:

arch/arm64/kvm/config.c:hcrx_feat_map[] = {
        ...
        FORCE_RES0(HCRX_EL2_RES0),
        FORCE_RES1(HCRX_EL2_RES1),
};

Will this trigger a deterministic verification failure during host boot? 
When check_feat_map() validates the map coverage, it checks the mask:

arch/arm64/kvm/config.c:check_feat_map() {
        ...
        if (mask != ~resx)
                kvm_err("Undefined %s behaviour, bits %016llx\n",
                        str, mask ^ ~resx);
        ...
}

Furthermore, without these bits being tracked, could a nested guest be
permitted to unconditionally modify these FEAT_NV3 configuration bits via 
MSR HCRX_EL2, escaping the hypervisor's RES0 masking protections?

>  Field	26	SRMASKEn
>  Res0	25
>  Field	24	PACMEn

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260714091641.1970822-1-maz@kernel.org?part=14