linux-kernel - Re: [RFC PATCH v1 1/1] tracing/kprobe: Add multi-probe support for 'perf

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20230820221612.33dfc3b3072f8bd8517f95b5@kernel.org>
Date:   Sun, 20 Aug 2023 22:16:12 +0900
From:   Masami Hiramatsu (Google) <mhiramat@...nel.org>
To:     Song Liu <song@...nel.org>
Cc:     Steven Rostedt <rostedt@...dmis.org>,
        Francis Laniel <flaniel@...ux.microsoft.com>,
        linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v1 1/1] tracing/kprobe: Add multi-probe support for
 'perf_kprobe' PMU

On Sun, 20 Aug 2023 03:02:18 -0700
Song Liu <song@...nel.org> wrote:

> On Sun, Aug 20, 2023 at 2:32 AM Masami Hiramatsu <mhiramat@...nel.org> wrote:
> >
> [...]
> > > >
> > > > 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 :)
> >
> > >
> > > 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.

> > >
> > > 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.)

Thank you,

> 
> Thanks,
> Song


-- 
Masami Hiramatsu (Google) <mhiramat@...nel.org>