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] [thread-next>] [day] [month] [year] [list]
Message-ID: <865xmgw1n1.wl-maz@kernel.org>
Date: Wed, 15 Jan 2025 15:13:54 +0000
From: Marc Zyngier <maz@...nel.org>
To: Mikołaj Lenczewski <miko.lenczewski@....com>
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 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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ