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

[Marc Zyngier <maz@kernel.org>]

On Tue, 14 Jul 2026 10:45:36 +0100,
sashiko-bot@kernel.org wrote:
> 
> 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);
>         ...
> }

Yes, but that's done on purpose. We never update the two in lockstep,
which is why we have this warning. See the following patches.

> 
> 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?

An untracked bit defaults to being RES0. You should try reading the
code.

	M.

-- 
Without deviation from the norm, progress is not possible.