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: <CAOi6=wS6s2FAAbMbxX5zCZzPQE7Mm73pbhxpiM_5e44o6yyPMw@mail.gmail.com>
Date: Thu, 16 Oct 2025 18:16:31 +0200
From: Yiannis Nikolakopoulos <yiannis.nikolakop@...il.com>
To: Jonathan Cameron <jonathan.cameron@...wei.com>
Cc: Wei Xu <weixugc@...gle.com>, David Rientjes <rientjes@...gle.com>, 
	Gregory Price <gourry@...rry.net>, 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 5:01 PM Jonathan Cameron
<jonathan.cameron@...wei.com> wrote:
>
> On Thu, 25 Sep 2025 16:03:46 +0200
> Yiannis Nikolakopoulos <yiannis.nikolakop@...il.com> wrote:
>
> Hi Yiannis,
Hi Jonathan! Thanks for your response!

[snip]
> > There are several things that may be done on the device side. For now, I
> > think the kernel should be unaware of these. But with what I described
> > above, the goal is to have the capacity thresholds configured in a way
> > that we can absorb the occasional dirty cache lines that are written back.
>
> In worst case they are far from occasional. It's not hard to imagine a malicious
This is correct. Any simplification on my end is mainly based on the
empirical evidence of the use cases we are testing for (tiering). But
I fully respect that we need to be proactive and assume the worst case
scenario.
> program that ensures that all L3 in a system (say 256MiB+) is full of cache lines
> from the far compressed memory all of which are changed in a fashion that makes
> the allocation much less compressible.  If you are doing compression at cache line
> granularity that's not so bad because it would only be 256MiB margin needed.
> If the system in question is doing large block side compression, say 4KiB.
> Then we have a 64x write amplification multiplier. If the virus is streaming over
This is insightful indeed :). However, even in the case of the 64x
amplification, you implicitly assume that each of the cachelines in
the L3 belongs to a different page. But then one cache-line would not
deteriorate the compressed size of the entire page that much (the
bandwidth amplification on the device is a different -performance-
story). So even in the 4K case the two ends of the spectrum are to
either have big amplification with low compression ratio impact, or
small amplification with higher compression ratio impact.
Another practical assumption here, is that the different HMU
mechanisms would help promote the contended pages before this becomes
a big issue. Which of course might still not be enough on the
malicious streaming writes workload.
Overall, I understand these are heuristics and I do see your point
that this needs to be robust even for the maliciously behaving
programs.
> memory the evictions we are seeing at the result of new lines being fetched
> to be made much less compressible.
>
> Add a accelerator (say DPDK or other zero copy into userspace buffers) into the
> mix and you have a mess. You'll need to be extremely careful with what goes
Good point about the zero copy stuff.
> in this compressed memory or hold enormous buffer capacity against fast
> changes in compressability.
To my experience the factor of buffer capacity would be closer to the
benefit that you get from the compression (e.g. 2x the cache size in
your example).
But I understand the burden of proof is on our end. As we move further
with this I will try to provide data as well.
>
> Key is that all software is potentially malicious (sometimes accidentally so ;)
>
> 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.
These could be good starting points, as I see in the rest of the thread.

Thanks,
Yiannis