On Mon, May 18, 2026 at 5:41 PM Peter Zijlstra <[email protected]> wrote: > Typically patches are supposed to a single thing, you're listing 4 > things. What gives? All four changes need to be made together to work properly. The second point could be pulled out as a separate patch, but will be replaced with the eventfs that Steve suggested. The other three points represent a single logical change: selectively loosening the perf_event_open() restrictions without exposing kernel data or breaking uprobe functionality.
> PERF_SAMPLE_IP should be here too, no? If PERF_SAMPLE_IP is added to the kaddr_leak mask it blocks uprobes, so the PERF_SAMPLE_IP check is in the trace_event_perf.c changes where I can exempt uprobes: + if ((p_event->attr.sample_type & PERF_SAMPLE_IP) && + !p_event->attr.exclude_kernel && + !(tp_event->flags & TRACE_EVENT_FL_UPROBE) && + sysctl_perf_event_paranoid > 1 && !perfmon_capable()) + return -EACCES; > And I'm not sure if tracepoints can trigger it, but PHYS_ADDR also seems > something we shouldn't allow. There's a check for unprivileged access to PHYS_ADDR at core.c:13917 so I didn't add it to kaddr_leak. > And we're sure RAW doesn't include pointers PERF_SAMPLE_RAW for TRACE_EVENT_FL_CAP_ANY tracepoints doesn't include kernel pointers. > Again, you're doing the same thing in multiple places. If only there was > something to re-use a previous expression. > > None of this gives me warm and fuzzy feelings. You're right. I'll factor the checks out for the next version. Anubhav
