Re: [PATCH v3 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] A `.sysreg` declarative change alters the generated `HCRX_EL2_RES0` mask by allocating new fields, but KVM's feature maps were not updated, leading to semantic drift.
--

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

arm64: sysreg: Add HCRX_EL2 bits related to FEAT_NV3

FEAT_NV3 introduces 4 new HCRX_EL2 control bits. Describe 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]
Will this change to the declarative definition of HCRX_EL2 inadvertently break
KVM's guest register sanitization?

By changing bits 27, 32, 33, and 34 from Res0 to Field, this silently removes
them from the auto-generated HCRX_EL2_RES0 mask. 

However, KVM's hcrx_feat_map in arch/arm64/kvm/config.c relies on that mask
and was not updated to explicitly restrict these newly defined FEAT_NV3 fields:

arch/arm64/kvm/config.c:hcrx_feat_map[] = {
    NEEDS_FEAT(HCRX_EL2_SRMASKEn, FEAT_SRMASK),
    ...
};

Because these fields are now unmapped, check_feat_map() strictly enforces the
initialization check and will fail unconditionally on host boot:

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

More importantly, KVM uses these feature maps in compute_reg_resx_bits() to
calculate the valid bits a guest can modify. Without the fields present in
HCRX_EL2_RES0 or mapped in hcrx_feat_map, KVM fails to mark these bits as
RES0 for guests. 

Could this allow an untrusted L1 nested guest to write to these unsanitized
EL2-level nested virtualization control bits, propagating to physical hardware
when context-switching?

>  Field	26	SRMASKEn
>  Res0	25
>  Field	24	PACMEn

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