linux-kernel - Re: [PATCH] fs/proc: Expose mm

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: <fzu354ripzrd4ygxtftbx6mhymb4rzhbkbyogezlmb6pezclwu@tmnelgqjoupy>
Date: Thu, 18 Dec 2025 21:06:34 -0500
From: Aaron Tomlin <atomlin@...mlin.com>
To: "David Hildenbrand (Red Hat)" <david@...nel.org>
Cc: oleg@...hat.com, akpm@...ux-foundation.org, gregkh@...uxfoundation.org, 
	brauner@...nel.org, mingo@...nel.org, sean@...e.io, linux-kernel@...r.kernel.org, 
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] fs/proc: Expose mm_cpumask in /proc/[pid]/status

On Thu, Dec 18, 2025 at 09:30:53AM +0100, David Hildenbrand (Red Hat) wrote:
> I agree with Oleg's comments.
> 
> Given that everybody has read access to /proc/$PID/status IIUC, I wonder if
> that information could somehow help an attacker to better attack a target
> program (knowing which CPUs have dirty TLB etc). As you saise, it's
> primarily for TLB and cache sync ...
> 
> Just a thought, have nothing concrete in mind.

Hi David,

Thank you for raising this point; security and information leakage are,
quite rightly, paramount considerations when adding new entries to
world-readable interfaces like /proc/[pid]/status. Upon reflection, I
submit that the risk here is minimal for a few reasons:

    1. Existing Visibility: The kernel already exposes a significant amount
    of CPU residency information. For instance, /proc/[pid]/stat explicitly
    shows the CPU a task is currently running on (field 39)
    i.e., task_cpu(task), and "Cpus_allowed" already defines the bounds of
    where a task can be. See do_task_stat().

    2. Resolution of Data: The mm_cpumask is a relatively coarse-grained
    diagnostic. While it indicates where TLB entries might be valid, it
    does not provide the fine-grained timing or cache-line information
    typically required for sophisticated side-channel attacks.

    3. Diagnostic Value: The primary intent is to provide visibility into
    the "memory footprint" across CPUs, which is invaluable for debugging
    performance issues related to IPI storms and TLB shootdowns in
    large-scale NUMA systems. The CPU-affinity sets the boundary; the
    mm_cpumask records the arrival; they complement each other.

I trust that the diagnostic utility is seen to outweigh the theoretical
risk in this instance.


Kind regards,
-- 
Aaron Tomlin

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)