netdev - Re: [PATCH bpf-next v3 0/3] Annotate kfuncs in .BTF

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: <2dhmwvfnnqnlrui2qcr5fob54gdsuse5caievct42trvvia6qe@p24nymz3uttv>
Date: Fri, 12 Jan 2024 13:03:59 -0700
From: Daniel Xu <dxu@...uu.xyz>
To: Jiri Olsa <olsajiri@...il.com>
Cc: linux-input@...r.kernel.org, coreteam@...filter.org, 
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, netfilter-devel@...r.kernel.org, 
	linux-kselftest@...r.kernel.org, linux-trace-kernel@...r.kernel.org, fsverity@...ts.linux.dev, 
	bpf@...r.kernel.org, netdev@...r.kernel.org, linux-stm32@...md-mailman.stormreply.com, 
	cgroups@...r.kernel.org, alexei.starovoitov@...il.com, quentin@...valent.com, 
	alan.maguire@...cle.com, memxor@...il.com
Subject: Re: [PATCH bpf-next v3 0/3] Annotate kfuncs in .BTF_ids section

On Fri, Jan 12, 2024 at 05:20:39PM +0100, Jiri Olsa wrote:
> On Sat, Jan 06, 2024 at 11:24:07AM -0700, Daniel Xu wrote:
> > === Description ===
> > 
> > This is a bpf-treewide change that annotates all kfuncs as such inside
> > .BTF_ids. This annotation eventually allows us to automatically generate
> > kfunc prototypes from bpftool.
> > 
> > We store this metadata inside a yet-unused flags field inside struct
> > btf_id_set8 (thanks Kumar!). pahole will be taught where to look.
> > 
> > More details about the full chain of events are available in commit 3's
> > description.
> > 
> > The accompanying pahole changes (still needs some cleanup) can be viewed
> > here on this "frozen" branch [0].
> 
> so the plan is to have bpftool support to generate header file
> with detected kfuncs?

Yep, that's the major use case. But I see other use cases as well like
precision probing of kfuncs. Rather than guess and check which progs can
load (in the event of backwards incompatible kfunc changes), programs
can look at kfunc type signature thru BTF.