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 C9F6626158B; Sat, 18 Jul 2026 08:43:58 +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=1784364239; cv=none; b=f5bPQOMhUsf+DeTUZXqSYSk3pdVQdOyzWBj0xzH6N1rD3IZ8e0OpQ1+BP44siMx6X4l/NLLtENPVJCBgatnxSkhx0wQLkx2ZWftAK/BDuVVgrvq3T+Mnh6V7TUdRPGcSMNGNI8auZftbnbebkiDXbw7ks15KzQyRvUZPodAGd+8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784364239; c=relaxed/simple; bh=WG4QyGgRAds4Fx+hUJ/f+/4iwh4iv0+ZRp8WPrJdW+g=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=LuinSHC4utly4HGbWQJ7BmV9fn1Cv5/q4LXpXncf+CLd3b8oR22SzuOiLWRV4DWfWSW07wo65qWdB2Zi0gc9h7xmZGuJKegKvOz+UUO+TQIl9iPr5Ugsg2yJKwpWCxEkLS63jG5ZcRbyg69+UbnHAtf9fBNEkignY83q/MC8QzY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cWRB8j95; 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="cWRB8j95" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5E97D1F000E9; Sat, 18 Jul 2026 08:43:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784364238; bh=HIuHp9Jni0inkQDV9bDTsEN515xgLllrv7OG/bjPhWI=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=cWRB8j95Z23pac909kh1HuO9zcZg/1I9gn5O3CRiu1rqVCHYe+tw0u9lb0WND+T8F FePN93zDkx4LBNW3qD8COcp+sm/ONTvzk/DP5XpJEC8g3UfqZPZJByZFTmluOhiIPX hXB/8IkeCBWsQR5lKMUpeFe2S0r21Vmyf362a9spam+D06GLyFpR7nGjziVWsHqacV lbJUo51GnOSX3ncM7qWqsArm7CbS58H5fUU/PPzXHdLIUpBXsiLMx91j4kfab7qgGc ZIln4WvRcLZZv4zhSz3BzZ6hIc+/8dpy0lf5SiVdTWLgi/ngSXi1WAhpUltUk9s+U3 voczSAVKlSi6g== Received: from sofa.misterjones.org ([185.219.108.64] helo=lobster-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wl0eK-00000006Imq-0XRT; Sat, 18 Jul 2026 08:43:56 +0000 Date: Sat, 18 Jul 2026 09:44:31 +0100 Message-ID: <87cxwkr8k0.wl-maz@kernel.org> From: Marc Zyngier To: Fuad Tabba Cc: sashiko-reviews@lists.linux.dev, kvmarm@lists.linux.dev, Oliver Upton Subject: Re: [PATCH v5 3/7] KVM: arm64: Top up stage-2 memcache for dirty logging faults In-Reply-To: References: <20260717130317.1953574-1-fuad.tabba@linux.dev> <20260717130317.1953574-4-fuad.tabba@linux.dev> <20260717131537.71F531F000E9@smtp.kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: fuad.tabba@linux.dev, sashiko-reviews@lists.linux.dev, kvmarm@lists.linux.dev, oupton@kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false 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. 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? M. -- Jazz isn't dead. It just smells funny.