linux-kernel - Re: [PATCH v3 1/4] KVM: VMX: Flush CPU buffers as needed if L1D cache flush is skipped

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 for Android: free password hash cracker in your pocket

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

Message-ID: <aPjyhYS-jZxtx4zr@google.com>
Date: Wed, 22 Oct 2025 08:04:37 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Brendan Jackman <jackmanb@...gle.com>
Cc: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>, Paolo Bonzini <pbonzini@...hat.com>, 
	kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/4] KVM: VMX: Flush CPU buffers as needed if L1D cache
 flush is skipped

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.