linux-kernel - Re: [PATCH v1] arm64: Add TLB Conflict Abort Exception handler to KVM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250116104221.GB17031@mazurka.cambridge.arm.com>
Date: Thu, 16 Jan 2025 10:42:21 +0000
From: Mikołaj Lenczewski <miko.lenczewski@....com>
To: Marc Zyngier <maz@...nel.org>
Cc: kvmarm@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, ryan.roberts@....com,
	catalin.marinas@....com, mark.rutland@....com, james.morse@....com,
	will@...nel.org, oliver.upton@...ux.dev, joey.gouly@....com,
	suzuki.poulose@....com, yuzenghui@...wei.com
Subject: Re: [PATCH v1] arm64: Add TLB Conflict Abort Exception handler to KVM

On Wed, Jan 15, 2025 at 03:13:54PM +0000, Marc Zyngier wrote:
> On Fri, 10 Jan 2025 17:24:07 +0000,
> Mikołaj Lenczewski <miko.lenczewski@....com> wrote:
> > 
> > Currently, KVM does not handle the case of a stage 2 TLB conflict abort
> > exception. This can legitimately occurs when the guest is eliding full
> > BBM semantics as permitted by BBM level 2. In this case it is possible
> > for a confclit abort to be delivered to EL2. We handle that by
> > invalidating the full TLB.
> > 
> > The Arm ARM specifies that the worst-case invalidation is either a
> > `tlbi vmalls12e1` or a `tlbi alle1` (as per DDI0487K section D8.16.3).
> > We implement `tlbi alle1` by extending the existing
> > __kvm_flush_vm_context() helper to allow for differentiating between
> > inner-shareable and cpu-local invalidations.
> > 
> > This commit applies on top of v6.13-rc2 (fac04efc5c79).
> > 
> > Signed-off-by: Mikołaj Lenczewski <miko.lenczewski@....com>
> > ---
> >  arch/arm64/include/asm/esr.h       |  8 ++++++++
> >  arch/arm64/include/asm/kvm_asm.h   |  2 +-
> >  arch/arm64/kvm/hyp/nvhe/hyp-main.c |  2 +-
> >  arch/arm64/kvm/hyp/nvhe/tlb.c      |  9 +++++++--
> >  arch/arm64/kvm/hyp/vhe/tlb.c       |  9 +++++++--
> >  arch/arm64/kvm/mmu.c               | 13 +++++++++++++
> >  arch/arm64/kvm/vmid.c              |  2 +-
> >  7 files changed, 38 insertions(+), 7 deletions(-)
> >
> 
> [...]
> 
> > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > index c9d46ad57e52..7c0d97449d23 100644
> > --- a/arch/arm64/kvm/mmu.c
> > +++ b/arch/arm64/kvm/mmu.c
> > @@ -1756,6 +1756,19 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu)
> >  	ipa = fault_ipa = kvm_vcpu_get_fault_ipa(vcpu);
> >  	is_iabt = kvm_vcpu_trap_is_iabt(vcpu);
> >  
> > +	if (esr_fsc_is_tlb_conflict_abort(esr)) {
> > +
> > +		/* Architecturely, at this stage 2 tlb conflict abort, we must
> > +		 * either perform a `tlbi vmalls12e1`, or a `tlbi alle1`. Due
> > +		 * to nesting of VMs, we would have to iterate all flattened
> > +		 * VMIDs to clean out a single guest, so we perform a `tlbi alle1`
> > +		 * instead to save time.
> > +		 */
> > +		__kvm_flush_vm_context(true);
> > +
> > +		return 1;
> > +	}
> > +
> 
> This is broken. At this stage, you are preemptible, so whatever
> invalidation you are performing might be happening on the wrong CPU
> (and I really don't want to see a broadcast invalidation).
> 
> I really don't see why this can't be handled as a fixup in the inner
> run loop, which would save *a lot* of cycles and do the right thing.
> 
> Thanks,
> 
> 	M.
> 
> -- 
> Without deviation from the norm, progress is not possible.

Aplogies for my very late reply. Thank you for tatking the time to
review my patch. Will work on this.

-- 
Kind regards,
Mikołaj Lenczewski