netdev - Re: [PATCH net-next] bpf: add helper capable of reading out instructions

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: <20170725112006.261bf04f@cakuba.netronome.com>
Date:   Tue, 25 Jul 2017 11:20:06 -0700
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Daniel Borkmann <daniel@...earbox.net>
Cc:     netdev@...r.kernel.org, alexei.starovoitov@...il.com,
        oss-drivers@...ronome.com, kafai@...com
Subject: Re: [PATCH net-next] bpf: add helper capable of reading out
 instructions

On Tue, 25 Jul 2017 18:40:23 +0200, Daniel Borkmann wrote:
> [ +Martin ]

Sorry, I thought I CCed Martin.

> On 07/24/2017 11:22 PM, Jakub Kicinski wrote:
> > To read translated and jited instructions from the kernel,
> > one has to set certain pointers of struct bpf_prog_info to
> > pre-allocated user buffers.  Unfortunately, the existing
> > bpf_obj_get_info_by_fd() helper zeros struct bpf_prog_info
> > before passing it to the kernel.
> >
> > Keeping the zeroing seems like a good idea in general, since
> > kernel will check if the structure was zeroed.  Add a new
> > helper for those more advanced users who can be trusted to
> > take care of zeroing themselves.
> >
> > Signed-off-by: Jakub Kicinski <jakub.kicinski@...ronome.com>
> > ---
> > I'm happy to change the name of the new function.
> >
> >   tools/lib/bpf/bpf.c | 10 ++++++++--
> >   tools/lib/bpf/bpf.h |  2 ++
> >   2 files changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
> > index 412a7c82995a..2703fa282b65 100644
> > --- a/tools/lib/bpf/bpf.c
> > +++ b/tools/lib/bpf/bpf.c
> > @@ -308,13 +308,12 @@ int bpf_map_get_fd_by_id(__u32 id)
> >   	return sys_bpf(BPF_MAP_GET_FD_BY_ID, &attr, sizeof(attr));
> >   }
> >
> > -int bpf_obj_get_info_by_fd(int prog_fd, void *info, __u32 *info_len)
> > +int __bpf_obj_get_info_by_fd(int prog_fd, void *info, __u32 *info_len)
> >   {
> >   	union bpf_attr attr;
> >   	int err;
> >
> >   	bzero(&attr, sizeof(attr));
> > -	bzero(info, *info_len);  
> 
> Looks a bit unintentional to me, e.g. 95b9afd3987f ("bpf: Test for bpf
> ID") did set up pointers in test_bpf_obj_id(), but later only checked
> for the {jited,xlated}_prog_len.
> 
> Clearing out the pointers looks not to useful. Lets just push the need
> for bzero() to call-sites in general in this case.

Should I target this at net then?  To avoid backwards compatibility
issues?