On Tue, Sep 16, 2025 at 11:51 AM Steven Rostedt <[email protected]> wrote: > > On Tue, 16 Sep 2025 11:23:03 -0700 > Kalesh Singh <[email protected]> wrote: > > > > 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? > > Ah, right. Can't the BPF infrastructure protect against it? > > > > > > > > > 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. > > Does it block all the other trace events that share pointers? > > Like nmi handler tracepoints, x86_fpu tracepoints, page_fault kernel > tracepoint, tasklet tracepoints, cpu hot plug tracepoints, timer > tracepoints, work queue tracepoints, ipi tracepoints, scheduling > tracepoints, locking tracepoints, rcu tracepoints, dma tracepoints, > module tracepoints, xdp tracepoints, filemap tracepoints, page map > tracepoints, vmscan tracepoints, percpu tracepoints, kmem_cache > tracepoints, mmap lock tracepoints, file lock tracepoints, and many > more! (I got tired of looking them up).
Hi Steve, I see your point :) I'll use the raw pointer and handle not exposing it from the BPF side. Thanks for discussing. --Kalesh > > Again, are you really protecting anything if this one trace point > hashes the pointer? Most other tracepoints expose this. If BPF can > access a tracepoint entry struct, it can access the raw address and > break KASLR. Thanks, Kalesh > > -- Steve
