linux-kernel - Re: [PATCH v4 4/8] KVM: VMX: Handle MMIO Stale Data in VM-Enter assembly via ALTERNATIVES

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] [day] [month] [year] [list]

Message-ID: <aRZVNWFBPAQAtlWL@google.com>
Date: Thu, 13 Nov 2025 14:01:25 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Borislav Petkov <bp@...en8.de>
Cc: Paolo Bonzini <pbonzini@...hat.com>, Thomas Gleixner <tglx@...utronix.de>, 
	Peter Zijlstra <peterz@...radead.org>, Josh Poimboeuf <jpoimboe@...nel.org>, kvm@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>, 
	Brendan Jackman <jackmanb@...gle.com>
Subject: Re: [PATCH v4 4/8] KVM: VMX: Handle MMIO Stale Data in VM-Enter
 assembly via ALTERNATIVES_2

On Thu, Nov 13, 2025, Borislav Petkov wrote:
> On Wed, Nov 12, 2025 at 12:30:36PM -0800, Sean Christopherson wrote:
> > They're set based on what memory is mapped into the KVM-controlled page tables,
> > e.g. into the EPT/NPT tables, that will be used by the vCPU for that VM-Enter.
> > root->has_mapped_host_mmio is per page table.  vcpu->kvm->arch.has_mapped_host_mmio
> > exists because of nastiness related to shadow paging; for all intents and purposes,
> > I would just mentally ignore that one.
> 
> And you say they're very dynamic because the page table will ofc very likely
> change before each VM-Enter. Or rather, as long as the fact that the guest has
> mapped host MMIO ranges changes. Oh well, I guess that's dynamic enough...

In practice, the flag will be quite static for a given vCPU.  The issue is that
it _could_ be extremely volatile depending on VMM and/or guest behavior, and so
I don't want to try and optimize for any particular behavior/pattern, because
KVM effectively doesn't have any control over whether or not the vCPU can access
MMIO.

> > Very lightly tested at this point, but I think this can all be simplified to
> > 
> > 	/*
> > 	 * Note, ALTERNATIVE_2 works in reverse order.  If CLEAR_CPU_BUF_VM is
> > 	 * enabled, do VERW unconditionally.  If CPU_BUF_VM_MMIO is enabled,
> > 	 * check @flags to see if the vCPU has access to host MMIO, and do VERW
> > 	 * if so.  Else, do nothing (no mitigations needed/enabled).
> > 	 */
> > 	ALTERNATIVE_2 "",									  \
> > 		      __stringify(testl $VMX_RUN_CLEAR_CPU_BUFFERS_FOR_MMIO, WORD_SIZE(%_ASM_SP); \
> > 				  jz .Lskip_clear_cpu_buffers;					  \
> > 				  VERW;								  \
> > 				  .Lskip_clear_cpu_buffers:),					  \
> 
> And juse because that label is local to this statement only, you can simply
> call it "1" and reduce clutter even more.

Eh, sort of.  In the past, this code used "simple" numeric labels, and it became
nearly impossible to maintain.  This is quite contained code and so isn't likely
to cause maintenance problems, but unless someone feels *really* strongly about
numeric labels, I'll keep a named label to match the rest of the code.

Though with it just being VERW, I can shorten it a wee bit and make it more
precise at the same time:

		      __stringify(testl $VMX_RUN_CLEAR_CPU_BUFFERS_FOR_MMIO, WORD_SIZE(%_ASM_SP); \
				  jz .Lskip_mmio_verw;						  \
				  VERW;								  \
				  .Lskip_mmio_verw:),					  	  \