Re: [PATCH v4 14/29] arm64: sysreg: Add HCRX_EL2 bits related to FEAT_NV3

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Adding new HCRX_EL2 fields (NVnTTLBOS, NVnTTLBIS, NVnTTLB, NVTGE) to the sysreg file silently removes them from the auto-generated HCRX_EL2_RES0 mask, but KVM's feature map was not updated to handle them. This semantic drift breaks KVM validation and allows guests to inject unvirtualized CPU features into the host.
--

--- Patch [14]: [PATCH v4 14/29] arm64: sysreg: Add HCRX_EL2 bits related to FEAT_NV3 ---
commit 98082153874cf6a7ea1e64f1536725fa89404dc8
Author: Marc Zyngier <[email protected]>

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]
By changing these bits from Res0 to Field, they are silently removed from the
auto-generated HCRX_EL2_RES0 mask. Does this cause KVM's boot-time validation
loop to fail?

In arch/arm64/kvm/config.c, check_feat_map() asserts that all non-RES0 bits
are accounted for. Since hcrx_feat_map is not updated with NEEDS_FEAT()
mappings for these new fields, it seems this will unconditionally trigger an
error on boot:

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 in KVM's feature map, can a
nested guest set them in its virtual HCRX_EL2 register?

If the guest writes these bits, it appears they could bypass filtering during
guest entry and be written directly into the physical CPU register:

arch/arm64/kvm/hyp/include/hyp/switch.h:__activate_traps_common() {
    ...
    hcrx |= (val & ~NV_HCRX_GUEST_EXCLUDE);
    hcrx &= ~(~val & ~NV_HCRX_GUEST_EXCLUDE);
    ...
}

Could this allow an untrusted guest to misconfigure unvirtualized hardware
state?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=14