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

Message-ID: <20251113142000.GAaRXpEKHh1oQgN65e@fat_crate.local>
Date: Thu, 13 Nov 2025 15:20:00 +0100
From: Borislav Petkov <bp@...en8.de>
To: Sean Christopherson <seanjc@...gle.com>
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 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...

> 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.

> 		      X86_FEATURE_CLEAR_CPU_BUF_VM_MMIO,					  \
> 		      __stringify(VERW), X86_FEATURE_CLEAR_CPU_BUF_VM
> 
> 	/* Check if vmlaunch or vmresume is needed */
> 	testl $VMX_RUN_VMRESUME, WORD_SIZE(%_ASM_SP)
> 	jz .Lvmlaunch

Yap, that's as nice as it gets. Looks much more straight-forward and
contained.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette