From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 27C5434B695 for ; Wed, 22 Oct 2025 15:04:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761145480; cv=none; b=LpFsnn9xNDzkrM72f7NAVXKf+lS4Hcs3uWrWCAZxxlYakkLEY/39J986qHZmQO34xSZPKuqhidqdOXdnpiQR9rUuXu6eoIU7ux4L0YHMwaXcxdY8CQknqm7vxqg0e6p97aOV4Uj+Bf6lvUUM4TdfJAfIMg+rsMDaaYNGPP4rkf0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761145480; c=relaxed/simple; bh=nZQfmaq7moybwbWzm06XV/8/By6UQtVLqwmofRufDnI=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=UXDAjfXFVlx7+WWNPkOGnK4WYwy/abkyAG/I8DYsP3Cpu2TusTOqXwXMWL56ZeJR7MIS8x5/3RjXX6Pct1GwNvLHXy414blv2bYKvtA0fT4Okgf/II/vvUSRRhRT9wZukY6eqr0jnlTA50ZMl/F8WzBYsLguzY3Ts+9khCCU7G0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=iZjB6egw; arc=none smtp.client-ip=209.85.214.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="iZjB6egw" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-277f0ea6fbaso89114925ad.0 for ; Wed, 22 Oct 2025 08:04:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1761145478; x=1761750278; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=ZeDoTHxRwcTS0U/KOB71AKaMICpadOQ/ESmZ45ZtCPU=; b=iZjB6egwfkGRQW7asm1yvaNn79dpx8H2GCe5grmgzEUmJED4jl41MeTrCx/8JrAaS+ 67Z7o20X9u3jPgoOIExf33r9nih7ylWjcTdRmJOhRYQftxsnj4FoiBJ39XJSfhkMpInm SQLnPMMUtl6o008CaZZsSesp4hjiM7S0c/4saT3kjGfP9BOzo+Wy+b7xEtPTywZyhNPK HvlnEGQRAdl37M7i0niCrUUpPSXhfNlu7oJdONff3vUr/75WkiLf9ZEsdOufQl4H+L3Q ZNf4H/FWLc5vOOZ9NBIVvV4OqCzUoOQ8ffNHbFOkJYjB84qckOHPVcR9pfH6cQI9yACz Os2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761145478; x=1761750278; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ZeDoTHxRwcTS0U/KOB71AKaMICpadOQ/ESmZ45ZtCPU=; b=NyrM6fBsxFu63SJuwoTE3ZOsFsx0QcPwcJPwbClu5g+P+M7mdsrJse1NoEHhX053Ap f5Z9t2fuBmRTVlK63Woyg/gggcK8rmq2nGlhjoWZBqUsAa0CJPZ9QkaHQhka8VRGw3pr E0p9tdw4JCH+mIeEIYugtzypyZQaqDVsT8iRrfbqtcWUyLwozHpCbVlAsHusodKyDehv 9c8ly2MGhcdGe6PABkySd9ERlfBxGxU31zB/LdXewn2BPDZgbbNboAIBU+mfLdViyeVH fajP4FfvsDXSWi9X73kr9Z5SSAlGqUl0qgQ2aMFsoOqfHTUlTRzc23WUxWbgtdIjdBYo XL2Q== X-Forwarded-Encrypted: i=1; AJvYcCUr1HbdTB1gvu2hb0bb5HUbgIprmOELmKWJ3qyIFBd7pkwIXi3A4a6g9U7yfJjBcq4GdGDP1PvUIlG4bp8=@vger.kernel.org X-Gm-Message-State: AOJu0YysUExjBNQ7cQPPknxgGRK0+B5vMkBFZ1guiA/TIJMa12kgfBOD AXpu7kn0F6kvsG39gAtv06skDT2qUYtAT/6OT8673ZC9c4ZkMOHk2bu7wICW+6HGjTHT5tKKV05 hisiJOA== X-Google-Smtp-Source: AGHT+IE1dZw0eGxjpS+GgO8lvLCozsqVIb14AspJ8xG436SZwB7we6zJwtkw1VmC+yZCSr85pE3qdf5/kZE= X-Received: from pjbrr12.prod.google.com ([2002:a17:90b:2b4c:b0:33d:b520:bb61]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:4b30:b0:27e:e55f:c6c3 with SMTP id d9443c01a7336-290ccaca5cemr259712015ad.55.1761145478495; Wed, 22 Oct 2025 08:04:38 -0700 (PDT) Date: Wed, 22 Oct 2025 08:04:37 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20251016200417.97003-1-seanjc@google.com> <20251016200417.97003-2-seanjc@google.com> <20251021231831.lofzy6frinusrd5s@desk> Message-ID: Subject: Re: [PATCH v3 1/4] KVM: VMX: Flush CPU buffers as needed if L1D cache flush is skipped From: Sean Christopherson To: Brendan Jackman Cc: Pawan Gupta , Paolo Bonzini , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="us-ascii" On Wed, Oct 22, 2025, Brendan Jackman wrote: > On Tue Oct 21, 2025 at 11:18 PM UTC, Pawan Gupta wrote: > > On Thu, Oct 16, 2025 at 01:04:14PM -0700, Sean Christopherson wrote: > >> If the L1D flush for L1TF is conditionally enabled, flush CPU buffers to > >> mitigate MMIO Stale Data as needed if KVM skips the L1D flush, e.g. > >> because none of the "heavy" paths that trigger an L1D flush were tripped > >> since the last VM-Enter. > >> > >> Note, the flaw goes back to the introduction of the MDS mitigation. > > > > I don't think it is a flaw. If L1D flush was skipped because VMexit did not > > touch any interested data, then there shouldn't be any need to flush CPU > > buffers. But as Brendan alludes to below, that assumes certain aspects of L1TF and MDS are equal. Obliterating the L1D is far more costly than flushing CPU buffers, as evidenced by the much more conditional flushing for L1TF. My read of the L1TF mitigation is that the conditional flushing is that it's a compromise between performance and security. Skipping the flush doesn't necessarily mean nothing interesting was accessed, it just means that KVM didn't hit any of the flows where a large amount of interesting data was guaranteed to have been accessed. > > Secondly, when L1D flush is skipped, flushing MDS affected buffers is of no > > use, because the data could still be extracted from L1D cache using L1TF. > > Isn't it? > > This is assuming an equivalence between what L1TF and MMIO Stale Data > exploits can do, that isn't really captured in the code/documentation > IMO. And again, the cost. To fully mitigate L1TF, KVM would need to flush on every entry, but that completely tanks performance. But that doesn't > This probably felt much more obvious when the vulns were new... > > I dunno, in the end this definitely doesn't seem like a terrifying big > deal, I'm not saying the current behaviour is crazy or anything, it's > just slightly surprising and people with sophisticated opinions about > this might not be getting what they think they are out of the default > setup. Ya. I highly doubt this particular combination matters in practice, but I don't like surprises. And I find it surprising that the behavior of KVM's mitigation for MMIO Stale Data changes based on whether or not the L1TF mitigation is enabled. > But I have no evidence that these sophisticated dissidents actually > exist, maybe just adding commentary about this rationale is more than > good enough here.