Re: [PATCH 05/28] KVM: arm64: Plumb HCRX_EL2.SRMASKEn in HCRX_EL2 sanitisation

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing RES0 constraints in system register feature map for `HCRX_EL2` allows nested guests to set reserved hardware bits.
--

commit 5fb0fde52515a7e2e03636fdc18f15c38a091ddd
Author: Marc Zyngier <maz@kernel.org>

KVM: arm64: Plumb HCRX_EL2.SRMASKEn in HCRX_EL2 sanitisation

This patch adds the HCRX_EL2.SRMASKEn bit to the HCRX_EL2 feature map to
enable FEAT_SRMASK for a guest. It also updates the system register
definitions to reflect the new bit field.

> diff --git a/arch/arm64/kvm/config.c b/arch/arm64/kvm/config.c
> --- a/arch/arm64/kvm/config.c
> +++ b/arch/arm64/kvm/config.c
> @@ -904,6 +904,7 @@ static const DECLARE_FEAT_MAP_FGT(hdfgwtr2_desc, hdfgwtr2_masks,
>  
>  
>  static const struct reg_bits_to_feat_map hcrx_feat_map[] = {
> +	NEEDS_FEAT(HCRX_EL2_SRMASKEn, FEAT_SRMASK),

[Severity: High]
This isn't a bug introduced by this patch, but a pre-existing issue in
hcrx_feat_map: does the omission of FORCE_RES0(HCRX_EL2_RES0) and
FORCE_RES1(HCRX_EL2_RES1) allow a nested guest to set architecturally reserved
hardware bits?

Because FORCE_RES0(HCRX_EL2_RES0) is omitted from this array, the architectural
RES0 bits (like 63:27, 25, 21:17) are not included in the virtual RES0 mask.
If a nested guest writes a 1 to these RES0 bits, KVM's dynamic mask application
in __vcpu_sys_reg() will leave those bits unmodified.

When KVM later transitions to the guest, it will write this unsanitized value
directly to the host's hardware SYS_HCRX_EL2 register. Can this violate
architectural invariants and trigger CONSTRAINED UNPREDICTABLE behavior or
silently enable unknown future hardware features?

[ ... ]

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