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: <f3d47b6e-13ba-0667-f631-f30326b048d3@iogearbox.net> Date: Wed, 3 Apr 2019 01:00:35 +0200 From: Daniel Borkmann <daniel@...earbox.net> To: andrii.nakryiko@...il.com, bpf@...r.kernel.org, netdev@...r.kernel.org, kernel-team@...com Cc: Andrii Nakryiko <andriin@...com>, Masahiro Yamada <yamada.masahiro@...ionext.com>, Arnaldo Carvalho de Melo <acme@...hat.com>, Alexei Starovoitov <ast@...com>, Yonghong Song <yhs@...com>, Martin KaFai Lau <kafai@...com> Subject: Re: [PATCH bpf-next] kbuild: add ability to generate BTF type info for vmlinux On 04/02/2019 06:49 PM, andrii.nakryiko@...il.com wrote: > From: Andrii Nakryiko <andriin@...com> > > This patch adds new config option to trigger generation of BTF type > information from DWARF debuginfo for vmlinux and kernel modules through > pahole, which in turn relies on libbpf for btf_dedup() algorithm. > > The intent is to record compact type information of all types used > inside kernel, including all the structs/unions/typedefs/etc. This > enables BPF's compile-once-run-everywhere ([0]) approach, in which > tracing programs that are inspecting kernel's internal data (e.g., > struct task_struct) can be compiled on a system running some kernel > version, but would be possible to run on other kernel versions (and > configurations) without recompilation, even if the layout of structs > changed and/or some of the fields were added, removed, or renamed. > > This is only possible if BPF loader can get kernel type info to adjust > all the offsets correctly. This patch is a first time in this direction, > making sure that BTF type info is part of Linux kernel image in > non-loadable ELF section. > > BTF deduplication ([1]) algorithm typically provides 100x savings > compared to DWARF data, so resulting .BTF section is not big as is > typically about 2MB in size. > > [0] http://vger.kernel.org/lpc-bpf2018.html#session-2 > [1] https://facebookmicrosites.github.io/bpf/blog/2018/11/14/btf-enhancement.html > > Cc: Masahiro Yamada <yamada.masahiro@...ionext.com> > Cc: Arnaldo Carvalho de Melo <acme@...hat.com> > Cc: Daniel Borkmann <daniel@...earbox.net> > Cc: Alexei Starovoitov <ast@...com> > Cc: Yonghong Song <yhs@...com> > Cc: Martin KaFai Lau <kafai@...com> > Signed-off-by: Andrii Nakryiko <andriin@...com> LGTM! As subject is targetting bpf-next this time since this BPF-related patch in this form has been sitting on the list for over 1.5months, I've taken it in there now, thanks!
Powered by blists - more mailing lists