[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c5af620d027aba9c3cdf2d642c3611f908638a3c.camel@chromium.org>
Date: Fri, 27 Nov 2020 10:25:08 +0100
From: Florent Revest <revest@...omium.org>
To: KP Singh <kpsingh@...omium.org>
Cc: bpf <bpf@...r.kernel.org>, Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andrii@...nel.org>,
Florent Revest <revest@...gle.com>,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH bpf-next 1/2] bpf: Add a bpf_kallsyms_lookup helper
On Fri, 2020-11-27 at 03:32 +0100, KP Singh wrote:
> > + ret = strlen(name) + 1;
> > + if (symbol_size) {
> > + strncpy(symbol, name, symbol_size);
> > + symbol[symbol_size - 1] = '\0';
> > + }
> > +
> > + if (modname && module_size) {
> > + strncpy(module, modname, module_size);
>
> The return value does not seem to be impacted by the truncation of
> the module name, I wonder if it is better to just use a single
> buffer.
>
> For example, the proc kallsyms shows symbols as:
>
> <symbol_name> [module_name]
>
> https://github.com/torvalds/linux/blob/master/kernel/kallsyms.c#L648
>
> The square brackets do seem to be a waste here, so maybe we could use
> a single character as a separator?
I prefer Yongonhong's suggestion of having two helpers. This gives more
control to the BPF program. For example, they could decide to audit
only addresses coming from a module, and that would be easier to do
with two helpers than by parsing a string in BPF.
Powered by blists - more mailing lists