Re: [PATCH v3 02/11] arm64/cpufeature: Add system-wide FEAT_HACDBS detection

[Leonardo Bras <leo.bras@arm.com>]

]On Wed, Jul 29, 2026 at 11:02:11AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [Critical] Missing KVM ID register filtering exposes FEAT_HACDBS to guests, preventing VMMs from hiding the feature and breaking VM migration.
> - [Low] The new capability HACDBS is not alphabetically sorted in the cpucaps list.
> --
> 
> --- Patch [2]: [PATCH v3 02/11] arm64/cpufeature: Add system-wide FEAT_HACDBS detection ---
> commit 79552fba5f033b2becee395a64d0ccf3fbde7b1a
> Author: Leonardo Bras <leo.bras@arm.com>
> 
> arm64/cpufeature: Add system-wide FEAT_HACDBS detection
> 
> This commit adds system-wide CPU feature detection for FEAT_HACDBS
> (Hardware dirty bit Cleaning). It updates the cpufeature structures
> and cpucaps list to track the feature across the system.
> 
> > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > index aa327eebaf1ca..62f56bbd0a65c 100644
> > --- a/arch/arm64/kernel/cpufeature.c
> > +++ b/arch/arm64/kernel/cpufeature.c
> > @@ -523,6 +523,7 @@ static const struct arm64_ftr_bits ftr_id_aa64mmfr3[] = {
> >  static const struct arm64_ftr_bits ftr_id_aa64mmfr4[] = {
> >  	S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR4_EL1_E2H0_SHIFT, 4, 0),
> >  	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR4_EL1_NV_frac_SHIFT, 4, 0),
> > +	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR4_EL1_HACDBS_SHIFT, 4, 0),
> 
> [Severity: Critical]
> Does exposing this feature here break VM live migration for KVM?
> 
> By adding HACDBS to the host's sanitised ID register, it is subsequently
> read by KVM to form the guest's ID register limit.
> 
> Looking at arch/arm64/kvm/sys_regs.c:__kvm_read_sanitised_id_reg(), there is
> no case handling SYS_ID_AA64MMFR4_EL1, which means the host's HACDBS value
> unconditionally leaks into the guest's limit.
> 
> Furthermore, looking at sys_reg_descs in arch/arm64/kvm/sys_regs.c:
> 
> 	ID_WRITABLE(ID_AA64MMFR4_EL1, ID_AA64MMFR4_EL1_NV_frac),
> 
> The writable mask for ID_AA64MMFR4_EL1 does not include HACDBS. Because KVM
> strictly enforces that non-writable fields must match the destination host's
> limit, a VMM attempting to restore a saved VM state will fail if the source
> and destination hosts have different HACDBS support.
> 
> Could this be addressed by either masking HACDBS from the guest view or
> making the field writable by the VMM?

IIUC, this means the value is being leaked to guest, which means the guest 
could try to use it to clean an L2 guest's dirty-bits. 

In general usage, it should not happen as this feature is limited to VHE,
and requires the kernel to write to HACDBS*_EL2 registers, which should not 
be directly done by the guest. In any case, I guess it's fair to mask 
that out so guest does not believe it has access to that feature.
 
> 
> >  	ARM64_FTR_END,
> >  };
> 
> [ ... ]
> 
> > diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
> > index a87706c9d160e..bd2c0bb98da61 100644
> > --- a/arch/arm64/tools/cpucaps
> > +++ b/arch/arm64/tools/cpucaps
> > @@ -72,6 +72,7 @@ HAS_XNX
> >  HAS_HDBSS
> >  HAFT
> >  HW_DBM
> > +HACDBS
> 
> [Severity: Low]
> This isn't a bug, but HACDBS is inserted out of alphabetical order here.
> 
> Does this violate the "# Internal CPU capabilities constants, keep this list
> sorted" comment at the top of the arch/arm64/tools/cpucaps file?

Okay, will do.

Thanks!
Leo