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]
Date:   Mon, 23 Jan 2023 18:54:10 -0600
From:   David Vernet <void@...ifault.com>
To:     Jonathan Corbet <corbet@....net>
Cc:     Daniel Borkmann <daniel@...earbox.net>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        bpf@...r.kernel.org, ast@...nel.org, andrii@...nel.org,
        martin.lau@...ux.dev, song@...nel.org, yhs@...a.com,
        john.fastabend@...il.com, kpsingh@...nel.org, sdf@...gle.com,
        haoluo@...gle.com, jolsa@...nel.org, linux-kernel@...r.kernel.org,
        kernel-team@...a.com, memxor@...il.com
Subject: Re: [PATCH bpf-next v2 3/3] bpf: Use BPF_KFUNC macro at all kfunc
 definitions

On Mon, Jan 23, 2023 at 02:00:17PM -0700, Jonathan Corbet wrote:
> Daniel Borkmann <daniel@...earbox.net> writes:
> 
> > Did you look into making this similar to the EXPORT_SYMBOL() infra? If possible
> > that would look much more natural to developers, e.g. :
> >
> > struct nf_conn *
> > bpf_skb_ct_lookup(struct __sk_buff *skb_ctx, struct bpf_sock_tuple *bpf_tuple,
> >   		  u32 tuple__sz, struct bpf_ct_opts *opts, u32 opts__sz)
> > {
> > 	[...]
> > }
> >
> > EXPORT_BPF_KFUNC(bpf_skb_ct_lookup);
> 
> That was my question too; it's a similar functionality that would be
> nice to express in a similar way.  Even better, if possible, might be to
> fold it into BTF_ID_FLAGS, which I might then rename to EXPORT_KFUNC()
> or some such ... :)

Thanks Daniel and Jon for taking a look. These are good suggestions, and
I agree that using something like EXPORT_BPF_KFUNC or BTF_ID_FLAGS would
be preferred and probably a better and more intuitive UX.

I expect that it's going to require some nontrivial build integration
work to get this looking exactly like we want it to. AFAICT, one
difference between kfuncs and EXPORT_SYMBOL symbols is that
EXPORT_SYMBOL symbol signatures are all exported via headers, as the
intention is of course for them to be linked against by other core
kernel code or modules. For kfuncs, that's not really what we want given
that for many of the kfuncs we may not want non-BPF callers to invoke
them. I don't think any of this is impossible, just a SMOP.

I was perhaps a bit naive to think we could just throw a __bpf_kfunc
macro onto the function signatures and call it a day :-) I think it's
probably best to table this for now, and either I or someone else can
come back to it when we have bandwidth to solve the problem more
appropriately.

> 
> Thanks,
> 
> jon

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ