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: <ada17021-83c9-3dad-5992-4885e824ecac@linux.dev>
Date:   Fri, 16 Sep 2022 13:20:41 -0700
From:   Martin KaFai Lau <martin.lau@...ux.dev>
To:     Daniel Xu <dxu@...uu.xyz>
Cc:     pablo@...filter.org, fw@...len.de, toke@...nel.org,
        netfilter-devel@...r.kernel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, bpf@...r.kernel.org, ast@...nel.org,
        daniel@...earbox.net, andrii@...nel.org, memxor@...il.com
Subject: Re: [PATCH bpf-next] bpf: Move nf_conn extern declarations to
 filter.h

On 9/11/22 11:19 AM, Daniel Xu wrote:
> We're seeing the following new warnings on netdev/build_32bit and
> netdev/build_allmodconfig_warn CI jobs:
> 
>      ../net/core/filter.c:8608:1: warning: symbol
>      'nf_conn_btf_access_lock' was not declared. Should it be static?
>      ../net/core/filter.c:8611:5: warning: symbol 'nfct_bsa' was not
>      declared. Should it be static?
> 
> Fix by ensuring extern declaration is present while compiling filter.o.
> 
> Signed-off-by: Daniel Xu <dxu@...uu.xyz>
> ---
>   include/linux/filter.h                   | 6 ++++++
>   include/net/netfilter/nf_conntrack_bpf.h | 7 +------
>   2 files changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/include/linux/filter.h b/include/linux/filter.h
> index 527ae1d64e27..96de256b2c8d 100644
> --- a/include/linux/filter.h
> +++ b/include/linux/filter.h
> @@ -567,6 +567,12 @@ struct sk_filter {
>   
>   DECLARE_STATIC_KEY_FALSE(bpf_stats_enabled_key);
>   
> +extern struct mutex nf_conn_btf_access_lock;
> +extern int (*nfct_bsa)(struct bpf_verifier_log *log, const struct btf *btf,
> +		       const struct btf_type *t, int off, int size,
> +		       enum bpf_access_type atype, u32 *next_btf_id,
> +		       enum bpf_type_flag *flag);

Can it avoid leaking the nfct specific details like 
'nf_conn_btf_access_lock' and the null checking on 'nfct_bsa' to 
filter.c?  In particular, this code snippet in filter.c:

         mutex_lock(&nf_conn_btf_access_lock);
         if (nfct_bsa)
                 ret = nfct_bsa(log, btf, ....);
	mutex_unlock(&nf_conn_btf_access_lock);


Can the lock and null check be done as one function (eg. 
nfct_btf_struct_access()) in nf_conntrack_bpf.c and use it in filter.c 
instead?

btw, 'bsa' stands for btf_struct_access? It is a bit too short to guess ;)

Also, please add a Fixes tag.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ