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: <20191211225506.w3cv6sur3we6qiu3@kafai-mbp> Date: Wed, 11 Dec 2019 22:55:25 +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: [PATCH bpf-next 00/15] Add code-generated BPF object skeleton support On Mon, Dec 09, 2019 at 05:14:23PM -0800, Andrii Nakryiko wrote: > This patch set introduces an alternative and complimentary to existing libbpf > API interface for working with BPF objects, maps, programs, and global data > from userspace side. This approach is relying on code generation. bpftool > produces a struct (a.k.a. skeleton) tailored and specific to provided BPF > object file. It includes hard-coded fields and data structures for every map, > program, link, and global data present. > > Altogether this approach significantly reduces amount of userspace boilerplate > code required to open, load, attach, and work with BPF objects. It improves > attach/detach story, by providing pre-allocated space for bpf_links, and > ensuring they are properly detached on shutdown. It allows to do away with by > name/title lookups of maps and programs, because libbpf's skeleton API, in > conjunction with generated code from bpftool, is filling in hard-coded fields > with actual pointers to corresponding struct bpf_map/bpf_program/bpf_link. > > Also, thanks to BPF array mmap() support, working with global data (variables) > from userspace is now as natural as it is from BPF side: each variable is just > a struct field inside skeleton struct. Furthermore, this allows to have > a natural way for userspace to pre-initialize global data (including > previously impossible to initialize .rodata) by just assigning values to the > same per-variable fields. Libbpf will carefully take into account this > initialization image, will use it to pre-populate BPF maps at creation time, > and will re-mmap() BPF map's contents at exactly the same userspace memory > address such that it can continue working with all the same pointers without > any interruptions. If kernel doesn't support mmap(), global data will still be > successfully initialized, but after map creation global data structures inside > skeleton will be NULL-ed out. This allows userspace application to gracefully > handle lack of mmap() support, if necessary. > > A bunch of selftests are also converted to using skeletons, demonstrating > significant simplification of userspace part of test and reduction in amount > of code necessary. Changes look good to me. Acked-by: Martin KaFai Lau <kafai@...com> which should not stop the on-going discussion.
Powered by blists - more mailing lists