linux-kernel - Re: [PATCH bpf-next v2] bpf: Only call sock_from_file with CONFIG

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] [day] [month] [year] [list]

Message-ID: <889510dcd76082a63f218b8187b1d11004fb1849.camel@chromium.org>
Date:   Tue, 08 Dec 2020 18:27:25 +0100
From:   Florent Revest <revest@...omium.org>
To:     Martin KaFai Lau <kafai@...com>
Cc:     bpf@...r.kernel.org, ast@...nel.org, daniel@...earbox.net,
        andrii@...nel.org, kpsingh@...omium.org, rdunlap@...radead.org,
        linux-next@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH bpf-next v2] bpf: Only call sock_from_file with
 CONFIG_NET

On Mon, 2020-12-07 at 13:33 -0800, Martin KaFai Lau wrote:
> On Mon, Dec 07, 2020 at 09:06:05PM +0100, Florent Revest wrote:
> > This avoids
> >   ld: kernel/trace/bpf_trace.o: in function `bpf_sock_from_file':
> >   bpf_trace.c:(.text+0xe23): undefined reference to
> > `sock_from_file'
> > When compiling a kernel with BPF and without NET.
> > 
> > Reported-by: Randy Dunlap <rdunlap@...radead.org>
> > Signed-off-by: Florent Revest <revest@...omium.org>
> > ---
> >  kernel/trace/bpf_trace.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> > index 0cf0a6331482..29ec2b3b1cc4 100644
> > --- a/kernel/trace/bpf_trace.c
> > +++ b/kernel/trace/bpf_trace.c
> > @@ -1272,7 +1272,11 @@ const struct bpf_func_proto
> > bpf_snprintf_btf_proto = {
> >  
> >  BPF_CALL_1(bpf_sock_from_file, struct file *, file)
> >  {
> > +#ifdef CONFIG_NET
> >  	return (unsigned long) sock_from_file(file);
> > +#else
> > +	return 0;
> > +#endif
> >  }
> Should bpf_sock_from_file_proto belong to
> tracing_prog_func_proto() instead of bpf_tracing_func_proto()?
> bpf_skc_to_*_proto is also in tracing_prog_func_proto()
> where there is an existing "#ifdef CONFIG_NET".

I'm happy to move bpf_sock_from_file to tracing_prog_func_proto if
you'd prefer that. I'm actually unsure what the difference would be,
those function names are confusing, but this works for our use-case. :)

However, by itself, that wouldn't address the problem reported by Randy
since the helper definition would still be compiled and have an
undefined reference to sock_from_file. The existing socket helpers (for
example skc_to_tcp_sock) can get away without a patch like mine because
they are defined in net/core/filter.c which only gets compiled with
CONFIG_NET.

I will send a v3 where I move the sock_from_file helper definition to
net/core/filter.c and also move the usage of the helper to
tracing_prog_func_proto under CONFIG_NET and then you can feel free to
merge v2 or v3 depending on which approach you prefer (or a followup
version if I mess up again... :D)