On Tue, Sep 16, 2025 at 11:01 AM Steven Rostedt rostedt@goodmis.org wrote:
On Tue, 16 Sep 2025 10:57:43 -0700 Kalesh Singh kaleshsingh@google.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.
My understanding is that the BPF tracepoint type uses the trace event fields from TP_STRUCT__entry(); whereas the raw tracepoint type has access to the proto arguments. Please CMIW: Isn't what we'd be adding to the trace buffer is the hashed mm_id value?
Heck, if you enable function tracing, you are exposing every function address it traces via the raw data output.
Right, security doesn't allow compiling CONFIG_FUNCTION_TRACER in Android production kernels.
Thanks, Kalesh
-- Steve