linux-kernel - Re: [RFC PATCH v2 03/23] x86/tdx: Enhance tdh_phymem_page_wbinvd

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: <858777470674b2ddd594997e94116167dee81705.camel@intel.com>
Date: Wed, 12 Nov 2025 10:29:11 +0000
From: "Huang, Kai" <kai.huang@...el.com>
To: "Zhao, Yan Y" <yan.y.zhao@...el.com>
CC: "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "Li, Xiaoyao"
	<xiaoyao.li@...el.com>, "quic_eberman@...cinc.com"
	<quic_eberman@...cinc.com>, "Hansen, Dave" <dave.hansen@...el.com>,
	"david@...hat.com" <david@...hat.com>, "thomas.lendacky@....com"
	<thomas.lendacky@....com>, "vbabka@...e.cz" <vbabka@...e.cz>,
	"tabba@...gle.com" <tabba@...gle.com>, "Du, Fan" <fan.du@...el.com>,
	"michael.roth@....com" <michael.roth@....com>, "seanjc@...gle.com"
	<seanjc@...gle.com>, "binbin.wu@...ux.intel.com" <binbin.wu@...ux.intel.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"pbonzini@...hat.com" <pbonzini@...hat.com>, "Weiny, Ira"
	<ira.weiny@...el.com>, "kas@...nel.org" <kas@...nel.org>,
	"ackerleytng@...gle.com" <ackerleytng@...gle.com>, "Peng, Chao P"
	<chao.p.peng@...el.com>, "zhiquan1.li@...el.com" <zhiquan1.li@...el.com>,
	"Yamahata, Isaku" <isaku.yamahata@...el.com>, "Annapurve, Vishal"
	<vannapurve@...gle.com>, "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
	"Miao, Jun" <jun.miao@...el.com>, "x86@...nel.org" <x86@...nel.org>,
	"pgonda@...gle.com" <pgonda@...gle.com>
Subject: Re: [RFC PATCH v2 03/23] x86/tdx: Enhance
 tdh_phymem_page_wbinvd_hkid() to invalidate huge pages

On Wed, 2025-11-12 at 16:43 +0800, Yan Zhao wrote:
> On Tue, Nov 11, 2025 at 05:23:30PM +0800, Huang, Kai wrote:
> > On Thu, 2025-08-07 at 17:42 +0800, Yan Zhao wrote:
> > > -u64 tdh_phymem_page_wbinvd_hkid(u64 hkid, struct page *page)
> > > +u64 tdh_phymem_page_wbinvd_hkid(u64 hkid, struct folio *folio,
> > > +				unsigned long start_idx, unsigned long npages)
> > >  {
> > > +	struct page *start = folio_page(folio, start_idx);
> > >  	struct tdx_module_args args = {};
> > > +	u64 err;
> > > +
> > > +	if (start_idx + npages > folio_nr_pages(folio))
> > > +		return TDX_OPERAND_INVALID;
> > >  
> > > -	args.rcx = mk_keyed_paddr(hkid, page);
> > > +	for (unsigned long i = 0; i < npages; i++) {
> > > +		args.rcx = mk_keyed_paddr(hkid, nth_page(start, i));
> > >  
> > 
> > Just FYI: seems there's a series to remove nth_page() completely:
> > 
> > https://lore.kernel.org/kvm/20250901150359.867252-1-david@redhat.com/
> Ah, thanks!
> Then we can get rid of the "unsigned long i".
> 
> -       for (unsigned long i = 0; i < npages; i++) {
> -               args.rcx = mk_keyed_paddr(hkid, nth_page(start, i));
> +       while (npages--) {
> +               args.rcx = mk_keyed_paddr(hkid, start++);
> 

You may want to be careful about doing '++' on a 'struct page *'.  I am not
expert, but I saw below discussion on the thread [*] which led to the series
to get rid of nth_page():

  > 
  > I wish we didn't have nth_page() at all. I really don't think it's a
  > valid operation. It's been around forever, but I think it was broken
  > as introduced, exactly because I don't think you can validly even have
  > allocations that cross section boundaries.

  Ordinary buddy allocations cannot exceed a memory section, but hugetlb and
  dax can with gigantic folios ... :(

  We had some weird bugs with that, because people keep forgetting that you
  cannot just use page++ unconditionally with such folios.

So, why not just get the actual page for each index within the loop?

[*]:
https://lore.kernel.org/all/CAHk-=wiCYfNp4AJLBORU-c7ZyRBUp66W2-Et6cdQ4REx-GyQ_A@mail.gmail.com/T/#m49ba78f5f630b27fa6d3d0737271f047af599c60