linux-kernel - Re: [PATCH 23/33] KVM: TDX: create/destroy VM structure

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: <aFwgBs2Gdvcj98nH@google.com>
Date: Wed, 25 Jun 2025 09:12:54 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Dave Hansen <dave.hansen@...el.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>, linux-kernel@...r.kernel.org, kvm@...r.kernel.org, 
	Yan Zhao <yan.y.zhao@...el.com>, Rick Edgecombe <rick.p.edgecombe@...el.com>, 
	Isaku Yamahata <isaku.yamahata@...el.com>, Tony Lindgren <tony.lindgren@...ux.intel.com>, 
	Sean Christopherson <sean.j.christopherson@...el.com>, Kai Huang <kai.huang@...el.com>, 
	Adrian Hunter <adrian.hunter@...el.com>
Subject: Re: [PATCH 23/33] KVM: TDX: create/destroy VM structure

On Wed, Jun 25, 2025, Dave Hansen wrote:
> On 2/26/25 10:14, Paolo Bonzini wrote:
> > +static void tdx_clear_page(struct page *page)
> > +{
> > +	const void *zero_page = (const void *) page_to_virt(ZERO_PAGE(0));
> > +	void *dest = page_to_virt(page);
> > +	unsigned long i;
> > +
> > +	/*
> > +	 * The page could have been poisoned.  MOVDIR64B also clears
> > +	 * the poison bit so the kernel can safely use the page again.
> > +	 */
> > +	for (i = 0; i < PAGE_SIZE; i += 64)
> > +		movdir64b(dest + i, zero_page);
> > +	/*
> > +	 * MOVDIR64B store uses WC buffer.  Prevent following memory reads
> > +	 * from seeing potentially poisoned cache.
> > +	 */
> > +	__mb();
> > +}
> 
> Hey guys,
> 
> This ended up in KVM code when we already have the *VERY* similar
> reset_tdx_pages().
> 
> Could we consolidate them, please? There's no reason to sprinkle
> knowledge of movdir64b's memory ordering rules all across the tree.
> 
> Adrian, this is probably something to go do, first, before you try and
> poke at this code that probably shouldn't be in KVM in the first place.

+1