netdev - Re: [PATCH v3 bpf-next 4/4] bpftool: support loading flow dissector

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: <20181108135247.33cfabdf@cakuba.hsd1.ca.comcast.net>
Date:   Thu, 8 Nov 2018 13:52:47 -0800
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Stanislav Fomichev <sdf@...ichev.me>
Cc:     Quentin Monnet <quentin.monnet@...ronome.com>,
        Stanislav Fomichev <sdf@...gle.com>, netdev@...r.kernel.org,
        linux-kselftest@...r.kernel.org, ast@...nel.org,
        daniel@...earbox.net, shuah@...nel.org, guro@...com,
        jiong.wang@...ronome.com, bhole_prashant_q7@....ntt.co.jp,
        john.fastabend@...il.com, jbenc@...hat.com,
        treeze.taeung@...il.com, yhs@...com, osk@...com,
        sandipan@...ux.vnet.ibm.com
Subject: Re: [PATCH v3 bpf-next 4/4] bpftool: support loading flow dissector

On Thu, 8 Nov 2018 13:25:39 -0800, Stanislav Fomichev wrote:
> > > > +			goto err_close_obj;
> > > > +		}
> > > > +
> > > >   		const char *sec_name = bpf_program__title(prog, false);
> > > >   
> > > >   		err = libbpf_prog_type_by_name(sec_name, &attr.prog_type,
> > > > @@ -936,8 +958,13 @@ static int do_load(int argc, char **argv)
> > > >   			goto err_close_obj;
> > > >   		}
> > > >   	}
> > > > -	bpf_program__set_type(prog, attr.prog_type);
> > > > -	bpf_program__set_expected_attach_type(prog, expected_attach_type);
> > > > +
> > > > +	bpf_object__for_each_program(pos, obj) {
> > > > +		bpf_program__set_ifindex(pos, ifindex);
> > > > +		bpf_program__set_type(pos, attr.prog_type);
> > > > +		bpf_program__set_expected_attach_type(pos,
> > > > +						      expected_attach_type);
> > > > +	}    
> > > 
> > > I still believe you can have programs of different types here, and be 
> > > able to load them. I tried it and managed to have it working fine. If no 
> > > type is provided from command line we can retrieve types for each 
> > > program from its section name. If a type is provided on the command 
> > > line, we can do the same, but I am not sure we should do it, or impose 
> > > that type for all programs instead.  
> > 
> > attr->prog_type is one per object, though.  How do we set that one?  
> Isn't it used only in __bpf_object__open_xattr to require/not-require kernel
> version in the bpf prog?
> 
> It will probably work quite nicely for both of our options:
> 
> * type not specified: prog_type = BPF_PROG_TYPE_UNSPEC, need kernel
>   version (over cautious?)
> * type specified (and applied to all progs): using bpf_prog_type__needs_kver
>   to require/not requqire kernel version

Right, but they you can't infer it from the program name, since there's
multiple.