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
| ||
|
Message-ID: <20191211225052.se2yyk4j5fpt2fdp@kafai-mbp> Date: Wed, 11 Dec 2019 22:50:56 +0000 From: Martin Lau <kafai@...com> To: Andrii Nakryiko <andriin@...com> CC: "bpf@...r.kernel.org" <bpf@...r.kernel.org>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, Alexei Starovoitov <ast@...com>, "daniel@...earbox.net" <daniel@...earbox.net>, "andrii.nakryiko@...il.com" <andrii.nakryiko@...il.com>, Kernel Team <Kernel-team@...com> Subject: Re: [Potential Spoof] [PATCH bpf-next 11/15] bpftool: add skeleton codegen command On Mon, Dec 09, 2019 at 05:14:34PM -0800, Andrii Nakryiko wrote: > Add `bpftool gen skeleton` command, which takes in compiled BPF .o object file > and dumps a BPF skeleton struct and related code to work with that skeleton. > Skeleton itself is tailored to a specific structure of provided BPF object > file, containing accessors (just plain struct fields) for every map and > program, as well as dedicated space for bpf_links. If BPF program is using > global variables, corresponding structure definitions of compatible memory > layout are emitted as well, making it possible to initialize and subsequently > read/update global variables values using simple and clear C syntax for > accessing fields. This skeleton majorly improves usability of > opening/loading/attaching of BPF object, as well as interacting with it > throughout the lifetime of loaded BPF object. > > Generated skeleton struct has the following structure: > > struct <object-name> { > /* used by libbpf's skeleton API */ > struct bpf_object_skeleton *skeleton; > /* bpf_object for libbpf APIs */ > struct bpf_object *obj; > struct { > /* for every defined map in BPF object: */ > struct bpf_map *<map-name>; > } maps; > struct { > /* for every program in BPF object: */ > struct bpf_program *<program-name>; > } progs; > struct { > /* for every program in BPF object: */ > struct bpf_link *<program-name>; > } links; > /* for every present global data section: */ > struct <object-name>__<one of bss, data, or rodata> { > /* memory layout of corresponding data section, > * with every defined variable represented as a struct field > * with exactly the same type, but without const/volatile > * modifiers, e.g.: > */ > int *my_var_1; > ... > } *<one of bss, data, or rodata>; > }; > > This provides great usability improvements: > - no need to look up maps and programs by name, instead just > my_obj->maps.my_map or my_obj->progs.my_prog would give necessary > bpf_map/bpf_program pointers, which user can pass to existing libbpf APIs; > - pre-defined places for bpf_links, which will be automatically populated for > program types that libbpf knows how to attach automatically (currently > tracepoints, kprobe/kretprobe, raw tracepoint and tracing programs). On > tearing down skeleton, all active bpf_links will be destroyed (meaning BPF > programs will be detached, if they are attached). For cases in which libbpf > doesn't know how to auto-attach BPF program, user can manually create link > after loading skeleton and they will be auto-detached on skeleton > destruction: > > my_obj->links.my_fancy_prog = bpf_program__attach_cgroup_whatever( > my_obj->progs.my_fancy_prog, <whatever extra param); > > - it's extremely easy and convenient to work with global data from userspace > now. Both for read-only and read/write variables, it's possible to > pre-initialize them before skeleton is loaded: > > skel = my_obj__open(raw_embed_data); > my_obj->rodata->my_var = 123; This will be very useful. I can think of one immediate use on this for my current TCP work. > my_obj__load(skel); /* 123 will be initialization value for my_var */ >
Powered by blists - more mailing lists