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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20251027210939.53e4ippuz7c6qo4b@desk>
Date: Mon, 27 Oct 2025 14:09:39 -0700
From: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Brendan Jackman <jackmanb@...gle.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 Tue, Oct 21, 2025 at 04:30:12PM -0700, Pawan Gupta wrote:
> On Tue, Oct 21, 2025 at 09:48:30AM -0700, Sean Christopherson wrote:
> > On Tue, Oct 21, 2025, Brendan Jackman wrote:
> > > On Thu Oct 16, 2025 at 8:04 PM UTC, 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.
> > > 
> > > Presumably the assumption here was that the L1TF conditionality is good
> > > enough for the MMIO stale data vuln too? I'm not qualified to assess if
> > > that assumption is true, but also even if it's a good one it's
> > > definitely not obvious to users that the mitigation you pick for L1TF
> > > has this side-effect. So I think I'm on board with calling this a bug.
> > 
> > Yeah, that's where I'm at as well.
> > 
> > > If anyone turns out to be depending on the current behaviour for
> > > performance I think they should probably add it back as a separate flag.
> > 
> > ...
> > 
> > > > @@ -6722,6 +6722,7 @@ static noinstr void vmx_l1d_flush(struct kvm_vcpu *vcpu)
> > > >  		:: [flush_pages] "r" (vmx_l1d_flush_pages),
> > > >  		    [size] "r" (size)
> > > >  		: "eax", "ebx", "ecx", "edx");
> > > > +	return true;
> > > 
> > > The comment in the caller says the L1D flush "includes CPU buffer clear
> > > to mitigate MDS" - do we actually know that this software sequence
> > > mitigates the MMIO stale data vuln like the verw does? (Do we even know if
> > > it mitigates MDS?)
> > > 
> > > Anyway, if this is an issue, it's orthogonal to this patch.
> > 
> > Pawan, any idea?
> 
> I want to say yes, but let me first confirm this internally and get back to
> you.

The software sequence for L1D flush was not validated to mitigate MMIO
Stale Data. To be on safer side, it is better to not rely on the sequence.

OTOH, if a user has not updated the microcode to mitigate L1TF, the system
will not have the microcode to mitigate MMIO Stale Data either, because the
microcode for MMIO Stale Data was released after L1TF. Also I am not aware
of any CPUs that are vulnerable to L1TF and vulnerable to MMIO Stale Data
only(not MDS).

So in practice, decoupling L1D flush and MMIO Stale Data won't have any
practical impact on functionality, and makes MMIO Stale Data mitigation
consistent with MDS mitigation. I hope that makes things clear.