Re: [RFC PATCH v1 1/1] tracing/kprobe: Add multi-probe support for 'perf_kprobe' PMU

From
Song Liu <song@kernel.org>
Date
2023-08-20 10:07:11
Also in
lkml
Reply to
Masami Hiramatsu (Google), 2023-08-20
On Sun, Aug 20, 2023 at 2:32 AM Masami Hiramatsu [off-list ref] wrote:
[...]
quoted
quoted
perf_event_attr::kprobe_func = "_text";
perf_event_attr::probe_offset = OFFSET;

Then, it should be able to specify the correct one. Of course you can use
other unique symbols around the target symbol.
Trying to catch up with the thread.
Thanks for your reply :)
quoted
Besides the CAP_* issue, we can do this with

perf_event_attr::kprobe_func = NULL;
perf_event_attr::kprobe_addr = address;
As I pointed, you don't need actual address, instead, you can specify the
probe point via "unique symbol" + offset.
Technically, this works. But it is weird to me.
quoted
Then for the CAP_*, I think we should give CAP_PERFMON access to
/proc/kallsyms. Would this work?
For the "unique symbol" + offset, you don't need the kallsyms, but need to
access the System.map or vmlinux image. In this case, we don't need to expand
the CAP_PERFMON capabilities.
I agree this is not needed in this case. But I wonder whether it makes sense
to give CAP_PERFMON access to /proc/kallsyms. Will this change make
CAP_PERFMON less secure?

Thanks,
Song
Thread (35 messages) 35 messages, 6 authors, last reply 2023-08-23
Keyboard shortcuts
hback out one level
jnext message in thread / next series-diff position
kprevious message in thread / previous series-diff position
ldrill in
Escclose help / fold thread tree
?toggle this help