linux-kernel - CPU Cache in Linux MemTest

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] [day] [month] [year] [list]

Message-ID: <20260123144908.65146-1-tomas.mudrunka@gmail.com>
Date: Fri, 23 Jan 2026 15:49:08 +0100
From: Tomas Mudrunka <tomas.mudrunka@...il.com>
To: tomas.mudrunka@...il.com
Cc: akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org,
	linux-mm@...ck.org,
	rppt@...nel.org
Subject: CPU Cache in Linux MemTest

Also it seems that CPU cache is not disabled during early_memtest()
and there is no easy way to disable it globally at this stage of boot.
However it can be invalidated using macros like clflush() and mb().
Unfortunately those are very x86 architecture-specific.

This probably means we can use ifdefs to call the correct cache flush
macro for given architecture and disable the test altogether for
unsupported architectures.

Alternatively it might be possible to do large write somewhere else
to flush the cache. After all current memtest seems to heavily rely
solely on the fact the test pattern is written in large regions at time.

It might be possible to do opportunistic cache flush based on the same
ifdef logic when flush instruction is available on given architecture
for use in existing memtest code.
Hopefully even implementing some simple abstraction layer for this.

Can you please give me some feedback on this approach?

Thanks
Tom