linux-kernel - Re: [PATCH v3 00/24] KVM: TDX huge page support for private memory

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: <6184812b4449947395417b07ae3bad2f191d178f.camel@intel.com>
Date: Fri, 16 Jan 2026 16:58:02 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "seanjc@...gle.com" <seanjc@...gle.com>
CC: "Du, Fan" <fan.du@...el.com>, "Li, Xiaoyao" <xiaoyao.li@...el.com>,
	"Huang, Kai" <kai.huang@...el.com>, "kvm@...r.kernel.org"
	<kvm@...r.kernel.org>, "Hansen, Dave" <dave.hansen@...el.com>, "Zhao, Yan Y"
	<yan.y.zhao@...el.com>, "thomas.lendacky@....com" <thomas.lendacky@....com>,
	"vbabka@...e.cz" <vbabka@...e.cz>, "tabba@...gle.com" <tabba@...gle.com>,
	"david@...nel.org" <david@...nel.org>, "kas@...nel.org" <kas@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Weiny, Ira"
	<ira.weiny@...el.com>, "francescolavra.fl@...il.com"
	<francescolavra.fl@...il.com>, "pbonzini@...hat.com" <pbonzini@...hat.com>,
	"ackerleytng@...gle.com" <ackerleytng@...gle.com>, "nik.borisov@...e.com"
	<nik.borisov@...e.com>, "binbin.wu@...ux.intel.com"
	<binbin.wu@...ux.intel.com>, "Yamahata, Isaku" <isaku.yamahata@...el.com>,
	"Peng, Chao P" <chao.p.peng@...el.com>, "michael.roth@....com"
	<michael.roth@....com>, "Annapurve, Vishal" <vannapurve@...gle.com>,
	"sagis@...gle.com" <sagis@...gle.com>, "Gao, Chao" <chao.gao@...el.com>,
	"Miao, Jun" <jun.miao@...el.com>, "jgross@...e.com" <jgross@...e.com>,
	"pgonda@...gle.com" <pgonda@...gle.com>, "x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH v3 00/24] KVM: TDX huge page support for private memory

On Fri, 2026-01-16 at 08:31 -0800, Sean Christopherson wrote:
> > Dave wants safety for the TDX pages getting handed to the module.
> 
> Define "safety".  As I stressed earlier, blinding retrieving a
> "struct page" and dereferencing that pointer is the exact opposite of
> safe.

I think we had two problems.

1. Passing in raw PA's via u64 led to buggy code. IIRC we had a bug
with this that was caught before it went upstream. So a page needs a
real type of some sort.

2. Work was done on the tip side to prevent non-TDX capable memory from
entering the page allocator. With that in place, by requiring struct
page, TDX code can know that it is getting the type of memory it worked
hard to guarantee was good.

You are saying that shifting a PFN to a struct page blindly doesn't
actually guarantee that it meets those requirements. Makes sense.

For (1) we can just use any old type I think - pfn_t, etc. As we
discussed in the base series.

For (2) we need to check that the memory came from the page allocator,
or otherwise is valid TDX memory somehow. That is at least the only
check that makes sense to me.

There was some discussion about refcounts somewhere in this thread. I
don't think it's arch/x86's worry. Then Yan was saying something last
night that I didn't quite follow. We said, let's just resume the
discussion on the list. So she might suggest another check.

> 
> > 2. Invent a new tdx_page_t type.
> 
> Still doesn't provide meaningful safety.  Regardless of what type
> gets passed into the low level tdh_*() helpers, it's going to require
> KVM to effectively cast a bare pfn, because I am completely against
> passing anything other than a SPTE to tdx_sept_set_private_spte().

I'm not sure I was clear, like:
1. A raw PFN gets passed in to the conversion helper in arch/x86.
2. The helper does the check that it is TDX capable memory, or anything
it cares to check about memory safety, then returns the new type to
KVM.
3. KVM uses the type as an argument to any seamcall that requires TDX
capable memory.

> 
> > 1. Page is TDX capable memory
> 
> That's fine by me, but that's _very_ different than what was proposed
> here.

Proposed by me just now or the series? We are trying to find a new
solution now.