On Sun, Aug 20, 2023 at 6:16 AM Masami Hiramatsu [off-list ref] wrote:

On Sun, 20 Aug 2023 03:02:18 -0700
Song Liu [off-list ref] wrote:

quoted

On Sun, Aug 20, 2023 at 2:32 AM Masami Hiramatsu [off-list ref] wrote:

quoted

[...]

quoted

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.

It's not so weired because it is a relative address, e.g. from _text,
this means "the address in the text section". And perf probe already
uses it a while.

quoted

quoted

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?

Yes, because /proc/kallsyms will expose the real address of the all
symbols, which makes KASLR useless. But on the other hand, it maybe
already useless because BPF program can read any real address, right?
Hmm, from this point of view, is the CAP_PERFMON meaningful?
(maybe it can avoid loading modules etc.)

kprobe BPF program has access to pt_regs, so it can read ip of the
attached function. Can we do the same with regular kprobe (no bpf)?

Thanks,
Song

Thank you,

quoted

Thanks,
Song

--
Masami Hiramatsu (Google) [off-list ref]