From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AEF5C382395; Fri, 31 Jul 2026 07:11:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785481863; cv=none; b=aeerBXGiiwt4eBLtngGicgnOSN+4ZHy8AuqnQFa+zOWMKn4TSxpLlmv8jWHuA0Qy4Ck017EPp2RfylSW5JmxmhSQ8oj+Ag9PUEyMLh1qDIDzp7mBZGmlSAV/HOwTbbrPXV1LoNldagbaeI+gymuOxeCNjx+4iptVOGsPbqQPT8s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785481863; c=relaxed/simple; bh=MXzkrYuvsCb0qqg0G1EONJG5W5ibP0p+dOf6h7DteOg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lS9wTFHHvzVEb5lxvXpq1FATLjcJQY7595sde4k27McpYtLpG56mVrsChzt/RzKbz1/Zd8aflmbxIJ+ZinsiAu7RhJ54xK/iG2K1+0AmfCziOGVQlkhjaUzKkdrY8QRabpbyoF804PgaJ4tODmjgUOp6IZZ48xapY0QPz0wpkEE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=obgnUr6L; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="obgnUr6L" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 368741F000E9; Fri, 31 Jul 2026 07:10:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785481858; bh=dhiyG6dFAiisC771zhYNfSU/aHXT390YSfJ8cCf1xsQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=obgnUr6LEvDaZws8YVFJmgidXu/Q5fXNoZpZfMcZPgN+h11RByhxHJhP8Sl1ZZpGR 7BHEXgB6wdgkP78dF44+2CeVH78Clxkap/Ymyh4gZft1wjpGbPIlT2GLl986t0gP2Y NTL+xUWrJPdC2gAxxNvyfQt7JxiRaFxAn4FnBUrtI1Ahll1vEexduPE2a+AcAwPiSU Z5MFRDydvuV0g0h1oJzGLExMTxvuBS2w3E3BVwoGrsfqJ/CJyZ34g4tMQiOzaJhagJ rKooOCCtH0p0CGN2cDpYQRUlof5ReevjrZbUZf1LT2Jx98u1iWwlGvyIql/gDAN8IX WzBFYFrEyTe7g== Date: Fri, 31 Jul 2026 00:10:56 -0700 From: Oliver Upton To: Marc Zyngier Cc: Fuad Tabba , sashiko-reviews@lists.linux.dev, kvmarm@lists.linux.dev Subject: Re: [PATCH v5 3/7] KVM: arm64: Top up stage-2 memcache for dirty logging faults Message-ID: References: <20260717130317.1953574-1-fuad.tabba@linux.dev> <20260717130317.1953574-4-fuad.tabba@linux.dev> <20260717131537.71F531F000E9@smtp.kernel.org> <87cxwkr8k0.wl-maz@kernel.org> Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87cxwkr8k0.wl-maz@kernel.org> Hey, Sorry for the latency, stumbled upon this as I was looking for stuff to grab for 7.3... On Sat, Jul 18, 2026 at 09:44:31AM +0100, Marc Zyngier wrote: > On Fri, 17 Jul 2026 15:17:00 +0100, > Fuad Tabba wrote: > > > > On Fri, 17 Jul 2026 at 14:15, wrote: > > > > > > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: > > > > > > Pre-existing issues: > > > - [High] A malicious nested (L1) guest can crash the KVM host via a Break-Before-Make (BBM) violation that triggers a BUG_ON() due to an empty memory cache during a permission fault. > > > > From my understanding of NV code, this looks like a real issue. I > > don't think it changes this patch, though: this one only widens the > > top-up for the dirty-logging case, and the path you describe is a > > non-logging permission fault. So, it would be a separate fix, a top up > > for nested permission faults too, the same way we already do for pKVM? > > > > if (!perm_fault || memslot_is_logging(s2fd->memslot) || > > is_protected_kvm_enabled() || s2fd->nested) { > > > > If that's right, I'll send a separate fix later. Marc, what do you think? > > I don't think this is correct. Yes, this papers over the guest being > buggy, but i don't think that's what we should really do. > > Doing the same thing (changing the output size without a TLBI) on real > HW would result in a permission fault being signalled to EL2, and we > should model our SW MMU the same way. FEAT_BBML3 shifts responsibility onto the implementation to reconcile multihit due to mapping granularity changes. A hypervisor could choose to do eager page splitting at the beginning of dirty logging and elide TLBIs. > I think the latent bug here is the way we always walk L1's S2 on S2 > fault, irrespective of the fault type, and that feels wrong. This is > ignoring the fact that we already have a TLB (the shadow S2) for this > mapping, and rewalk anyway. Since we now find valid permissions, we > take it at face value and try to install this new translation (which > could point to a different OA, and even bigger problem). > > So ideally we'd simply tell the guest to bugger off, but we need to > solve a few problems first: > > - some permission faults are caused by the host rather than the guest > (dirty logging, HAFDBS), and we need to treat those specially. > > - we need to rebuild an ESR based on the content of our TLB, not L1's > S2, which is not always easy to obtain (we have some limited TTL > caching in the shadow S2, but that's not always reliable). > > All of this strongly intersects with Wei-Lin's reverse map, and > Oliver's HAFDBS support. > > Oliver? Hmm, I'm more of the mind that we should just keep the memcache topped up for any fault because clearly the prediction has gotten out of sync with what happens later down the line. We're bound to screw it up again. Generating faults solely based on the TLB seems to be at odds with supporting FEAT_ETS* in the shadow stage-2 and practically means we need to re-walk for most stage-2 aborts anyway. And as you point out, I need to do this for HAFDBS dirty state updates. BBML3 and ETS2/3 aren't terribly high priority but I'd rather not paper over a rather straightforward KVM bug by making design decisions that limit our feature set for nested. Thanks, Oliver