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: <f4240495-120b-4124-b91a-b365e45bf50a@intel.com>
Date: Wed, 14 Jan 2026 10:56:03 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Sean Christopherson <seanjc@...gle.com>, Yan Zhao <yan.y.zhao@...el.com>
Cc: Ackerley Tng <ackerleytng@...gle.com>,
 Vishal Annapurve <vannapurve@...gle.com>, pbonzini@...hat.com,
 linux-kernel@...r.kernel.org, kvm@...r.kernel.org, x86@...nel.org,
 rick.p.edgecombe@...el.com, kas@...nel.org, tabba@...gle.com,
 michael.roth@....com, david@...nel.org, sagis@...gle.com, vbabka@...e.cz,
 thomas.lendacky@....com, nik.borisov@...e.com, pgonda@...gle.com,
 fan.du@...el.com, jun.miao@...el.com, francescolavra.fl@...il.com,
 jgross@...e.com, ira.weiny@...el.com, isaku.yamahata@...el.com,
 xiaoyao.li@...el.com, kai.huang@...el.com, binbin.wu@...ux.intel.com,
 chao.p.peng@...el.com, chao.gao@...el.com
Subject: Re: [PATCH v3 00/24] KVM: TDX huge page support for private memory

On 1/14/26 07:26, Sean Christopherson wrote:
...
> Dave may feel differently, but I am not going to budge on this.  I am not going
> to bake in assumptions throughout KVM about memory being backed by page+folio.
> We _just_ cleaned up that mess in the aformentioned "Stop grabbing references to
> PFNMAP'd pages" series, I am NOT reintroducing such assumptions.
> 
> NAK to any KVM TDX code that pulls a page or folio out of a guest_memfd pfn.

'struct page' gives us two things: One is the type safety, but I'm
pretty flexible on how that's implemented as long as it's not a raw u64
getting passed around everywhere.

The second thing is a (near) guarantee that the backing memory is RAM.
Not only RAM, but RAM that the TDX module knows about and has a PAMT and
TDMR and all that TDX jazz.

We've also done things like stopping memory hotplug because you can't
amend TDX page metadata at runtime. So we prevent new 'struct pages'
from coming into existence. So 'struct page' is a quite useful choke
point for TDX.

I'd love to hear more about how guest_memfd is going to tie all the
pieces together and give the same straightforward guarantees without
leaning on the core mm the same way we do now.