Re: [PATCH 19/22] KVM: arm64: nv: Expose FEAT_HAFT

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] KVM's AT instruction emulation incorrectly evaluates HD and HAFT without ensuring the Hardware Access Flag (HA) is enabled, leading to unauthorized hardware updates of the Access flag on table descriptors.
--

commit e646aa23aa5bcaa5e6bc04545e6c0d319fc3a058
Author: Oliver Upton <oupton@kernel.org>

KVM: arm64: nv: Expose FEAT_HAFT

Both stages of translation now support the access flag on table descriptors,
advertise the feature.

> diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
> index 6f540d3481d5a..dc2a8b6483c2a 100644
> --- a/arch/arm64/kvm/nested.c
> +++ b/arch/arm64/kvm/nested.c
> @@ -1799,7 +1799,7 @@ u64 limit_nv_id_reg(struct kvm *kvm, u32 reg, u64 val)
>  		if (test_bit(KVM_ARM_VCPU_HAS_EL2_E2H0, kvm->arch.vcpu_features))
>  			val &= ~ID_AA64MMFR1_EL1_VH;
>  
> -		val = ID_REG_LIMIT_FIELD_ENUM(val, ID_AA64MMFR1_EL1, HAFDBS, DBM);
> +		val = ID_REG_LIMIT_FIELD_ENUM(val, ID_AA64MMFR1_EL1, HAFDBS, HAFT);

[Severity: Medium]
Does exposing HAFT here uncover an issue in AT instruction emulation where
hardware updates are authorized even when the hardware access flag is
disabled?

Looking at setup_s1_walk() in arch/arm64/kvm/at.c, wi->hd and wi->haft
are evaluated without checking if the hardware access flag (HA) is enabled:

arch/arm64/kvm/at.c:setup_s1_walk() {
        ...
        wi->haft  = kvm_has_feat(vcpu->kvm, ID_AA64MMFR1_EL1, HAFDBS, HAFT) &&
                    FIELD_GET(TCR2_EL1_HAFT, effective_tcr2(vcpu, wi->regime));
        ...
}

Then in should_set_access_flag(), this could return wi->haft for table
descriptors, inadvertently authorizing hardware updates even when HA == 0:

arch/arm64/kvm/at.c:should_set_access_flag() {
        ...
        return kvm_pte_table(ws->desc, ws->level) ? wi->haft : wi->ha;
}

If a nested guest sets TCR_ELx.HD = 1 or TCR2_ELx.HAFT = 1 but leaves
TCR_ELx.HA = 0, and then executes an AT instruction, could KVM incorrectly
evaluate the guest's page table permissions as writable or perform an
unauthorized hardware update of the Access flag on table descriptors?

>  		break;
>  
>  	case SYS_ID_AA64MMFR2_EL1:

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260623184201.1518871-1-oupton@kernel.org?part=19