linux-kernel - Re: [RFC PATCH 08/21] KVM: TDX: Increase/decrease folio ref for huge pages

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <zlxgzuoqwrbuf54wfqycnuxzxz2yduqtsjinr5uq4ss7iuk2rt@qaaolzwsy6ki>
Date: Thu, 26 Jun 2025 18:16:14 +0300
From: "Shutemov, Kirill" <kirill.shutemov@...el.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
Cc: "ackerleytng@...gle.com" <ackerleytng@...gle.com>, 
	"Zhao, Yan Y" <yan.y.zhao@...el.com>, "quic_eberman@...cinc.com" <quic_eberman@...cinc.com>, 
	"Li, Xiaoyao" <xiaoyao.li@...el.com>, "Du, Fan" <fan.du@...el.com>, 
	"Hansen, Dave" <dave.hansen@...el.com>, "david@...hat.com" <david@...hat.com>, 
	"thomas.lendacky@....com" <thomas.lendacky@....com>, "tabba@...gle.com" <tabba@...gle.com>, 
	"vbabka@...e.cz" <vbabka@...e.cz>, "michael.roth@....com" <michael.roth@....com>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "seanjc@...gle.com" <seanjc@...gle.com>, 
	"Peng, Chao P" <chao.p.peng@...el.com>, "pbonzini@...hat.com" <pbonzini@...hat.com>, 
	"Yamahata, Isaku" <isaku.yamahata@...el.com>, "binbin.wu@...ux.intel.com" <binbin.wu@...ux.intel.com>, 
	"Weiny, Ira" <ira.weiny@...el.com>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>, 
	"Annapurve, Vishal" <vannapurve@...gle.com>, "jroedel@...e.de" <jroedel@...e.de>, 
	"Miao, Jun" <jun.miao@...el.com>, "Li, Zhiquan1" <zhiquan1.li@...el.com>, 
	"pgonda@...gle.com" <pgonda@...gle.com>, "x86@...nel.org" <x86@...nel.org>
Subject: Re: [RFC PATCH 08/21] KVM: TDX: Increase/decrease folio ref for huge
 pages

On Thu, Jun 26, 2025 at 02:19:36AM +0300, Edgecombe, Rick P wrote:
> On Wed, 2025-06-25 at 16:09 -0700, Ackerley Tng wrote:
> > > I do think that these threads have gone on far too long. It's probably about
> > > time to move forward with something even if it's just to have something to
> > > discuss that doesn't require footnoting so many lore links. So how about we
> > > move
> > > forward with option e as a next step. Does that sound good Yan?
> > > 
> > 
> > Please see my reply to Yan, I'm hoping y'all will agree to something
> > between option f/g instead.
> 
> I'm not sure about the HWPoison approach, but I'm not totally against it. My
> bias is that all the MM concepts are tightly interlinked. If may fit perfectly,
> but every new use needs to be checked for how fits in with the other MM users of
> it. Every time I've decided a page flag was the perfect solution to my problem,
> I got informed otherwise. Let me try to flag Kirill to this discussion. He might
> have some insights.

We chatted with Rick about this.

If I understand correctly, we are discussing the situation where the TDX
module failed to return a page to the kernel.

I think it is reasonable to use HWPoison for this case. We cannot
guarantee that we will read back whatever we write to the page. TDX module
has creative ways to corrupt it. 

The memory is no longer functioning as memory. It matches the definition
of HWPoison quite closely.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov