Re: [PATCH 04/28] KVM: arm64: Drop __HCRX_EL2_* masks

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Unsanitized architectural RES0/RES1 bits in HCRX_EL2 allow nested guests to enable hidden hardware features and trigger CONSTRAINED UNPREDICTABLE behavior.
--

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

KVM: arm64: Drop __HCRX_EL2_* masks

This patch removes the legacy __HCRX_EL2_* masks and the manual RES1
sanitization in get_reg_fixed_bits(). It intends to rely on existing
auto-generated masks and boot-time checks to prevent unhandled bits from
being exploited.

> diff --git a/arch/arm64/kvm/config.c b/arch/arm64/kvm/config.c
> index 0622162b089e5..16d8148dc3f12 100644
> --- a/arch/arm64/kvm/config.c
> +++ b/arch/arm64/kvm/config.c
[ ... ]
> @@ -933,7 +933,7 @@ static const struct reg_bits_to_feat_map hcrx_feat_map[] = {
>  };
>  
>  
> -static const DECLARE_FEAT_MAP(hcrx_desc, __HCRX_EL2,
> +static const DECLARE_FEAT_MAP(hcrx_desc, HCRX_EL2,
>  			      hcrx_feat_map, FEAT_HCX);

[Severity: High]
This is a pre-existing issue, but hcrx_feat_map lacks FORCE_RES0 and
FORCE_RES1 declarations. Unlike other system register maps, this means
compute_reg_resx_bits() will omit the architectural RES0/RES1 bits from
the KVM masks.

[ ... ]
> @@ -1579,7 +1579,6 @@ struct resx get_reg_fixed_bits(struct kvm *kvm, enum vcpu_sysreg reg)
>  		break;
>  	case HCRX_EL2:
>  		resx = compute_reg_resx_bits(kvm, &hcrx_desc, 0, 0);
> -		resx.res1 |= __HCRX_EL2_RES1;
>  		break;

[Severity: High]
Does removing this manual mask leave the RES1 bits completely unsanitized?

Since hcrx_feat_map doesn't supply the architectural bits to
compute_reg_resx_bits(), a nested guest might be able to write arbitrary
values to the HCRX_EL2 VNCR page. 

When KVM reads this in __activate_traps_common(), it only masks
NV_HCRX_GUEST_EXCLUDE before writing directly to the physical SYS_HCRX_EL2:

arch/arm64/kvm/hyp/include/hyp/switch.h:__activate_traps_common() {
        ...
        u64 val = __vcpu_sys_reg(vcpu, HCRX_EL2);
        hcrx |= (val & ~NV_HCRX_GUEST_EXCLUDE);
        hcrx &= ~(~val & ~NV_HCRX_GUEST_EXCLUDE);
        ...
        write_sysreg_s(hcrx, SYS_HCRX_EL2);
}

Could this allow the guest to bypass hypervisor feature emulation or trigger
CONSTRAINED UNPREDICTABLE hardware states?

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