linux-kernel - Re: [PATCH v2 7/7] mm/tracing: introduce max_vma_count

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250916140245.5894a2aa@gandalf.local.home>
Date: Tue, 16 Sep 2025 14:02:45 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Kalesh Singh <kaleshsingh@...gle.com>
Cc: akpm@...ux-foundation.org, minchan@...nel.org,
 lorenzo.stoakes@...cle.com, david@...hat.com, Liam.Howlett@...cle.com,
 rppt@...nel.org, pfalcato@...e.de, kernel-team@...roid.com,
 android-mm@...gle.com, Alexander Viro <viro@...iv.linux.org.uk>, Christian
 Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>, Kees Cook
 <kees@...nel.org>, Vlastimil Babka <vbabka@...e.cz>, Suren Baghdasaryan
 <surenb@...gle.com>, Michal Hocko <mhocko@...e.com>, Masami Hiramatsu
 <mhiramat@...nel.org>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>, Juri
 Lelli <juri.lelli@...hat.com>, Vincent Guittot
 <vincent.guittot@...aro.org>, Dietmar Eggemann <dietmar.eggemann@....com>,
 Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>, Valentin
 Schneider <vschneid@...hat.com>, Jann Horn <jannh@...gle.com>, Shuah Khan
 <shuah@...nel.org>, linux-kernel@...r.kernel.org,
 linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
 linux-trace-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v2 7/7] mm/tracing: introduce max_vma_count_exceeded
 trace event

On Tue, 16 Sep 2025 10:57:43 -0700
Kalesh Singh <kaleshsingh@...gle.com> wrote:

> > BTW, why the hash of the mm pointer and not the pointer itself? We save
> > pointers in lots of places, and if it is the pointer, you could use an
> > eprobe to attache to the trace event to dereference its fields.  
> 
> In Android we try to avoid exposing raw kernel pointers to userspace
> for security reasons: raising /proc/sys/kernel/kptr_restrict to 2
> immediately after symbols are resolved for necessary telemetry tooling
> during early boot. I believe this is also why rss_stat uses the hash
> and not the raw pointer.

When it comes to tracing, you already lost. If it goes into the ring buffer
it's a raw pointer. BPF doesn't use the output of the trace event, so you
are exposing nothing from that. It uses the proto directly.

Heck, if you enable function tracing, you are exposing every function
address it traces via the raw data output.

-- Steve