linux-kernel - Re: [RFC PATCH v2 0/8] mm: Hot page tracking and promotion infrastructure

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: <aNVdRdXVzXSm_4SJ@gourry-fedora-PF4VCD3F>
Date: Thu, 25 Sep 2025 11:18:29 -0400
From: Gregory Price <gourry@...rry.net>
To: Jonathan Cameron <jonathan.cameron@...wei.com>
Cc: Yiannis Nikolakopoulos <yiannis.nikolakop@...il.com>,
	Wei Xu <weixugc@...gle.com>, David Rientjes <rientjes@...gle.com>,
	Matthew Wilcox <willy@...radead.org>,
	Bharata B Rao <bharata@....com>, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, dave.hansen@...el.com, hannes@...xchg.org,
	mgorman@...hsingularity.net, mingo@...hat.com, peterz@...radead.org,
	raghavendra.kt@....com, riel@...riel.com, sj@...nel.org,
	ying.huang@...ux.alibaba.com, ziy@...dia.com, dave@...olabs.net,
	nifan.cxl@...il.com, xuezhengchu@...wei.com,
	akpm@...ux-foundation.org, david@...hat.com, byungchul@...com,
	kinseyho@...gle.com, joshua.hahnjy@...il.com, yuanchu@...gle.com,
	balbirs@...dia.com, alok.rathore@...sung.com, yiannis@...corp.com,
	Adam Manzanares <a.manzanares@...sung.com>
Subject: Re: [RFC PATCH v2 0/8] mm: Hot page tracking and promotion
 infrastructure

On Thu, Sep 25, 2025 at 11:08:59AM -0400, Gregory Price wrote:
> On Thu, Sep 25, 2025 at 04:00:58PM +0100, Jonathan Cameron wrote:
> > Now, if we can put this into a special pool where it is acceptable to drop the writes
> > and return poison (so the application crashes) then that may be fine.
> > 
> > Or block writes.   Running compressed memory as read only CoW is one way to
> > avoid this problem.
> >
> 
> This is an interesting thought.  If you drop a write and return poison,
> can you instead handle the poison message as a fault and promote on
> fault?  Then you might just be able to turn this whole thing into a
> zswap backend that promotes on write.
>

I just realized this would require some mechanism to re-issue the write.

So yeah, you'd have to do this via some some heroic page table
enforcement.  The key observation here is that zswap hacks off all the
page table entries - rather than leave them present and readable.  In
this design, you want to leave them present and readable, and therefore
need some way to prevent entries from changing out from under you.

> Then you don't particular care about stronger isolation controls
> (except maybe keeping kernel memory out of those regions).
> 
> ~Gregory