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: <aNVbC2o8WlYKjEfL@gourry-fedora-PF4VCD3F>
Date: Thu, 25 Sep 2025 11:08:59 -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 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.

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

~Gregory