netdev - Re: [PATCH bpf-next 2/2] bpf: split cgroup_bpf

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: <X+FSd9IEvxqEXmIr@google.com>
Date:   Mon, 21 Dec 2020 17:57:11 -0800
From:   sdf@...gle.com
To:     Song Liu <song@...nel.org>
Cc:     Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>
Subject: Re: [PATCH bpf-next 2/2] bpf: split cgroup_bpf_enabled per attach type

On 12/21, Song Liu wrote:
> On Thu, Dec 17, 2020 at 9:26 AM Stanislav Fomichev <sdf@...gle.com> wrote:
> >
> > When we attach any cgroup hook, the rest (even if unused/unattached)  
> start
> > to contribute small overhead. In particular, the one we want to avoid is
> > __cgroup_bpf_run_filter_skb which does two redirections to get to
> > the cgroup and pushes/pulls skb.
> >
> > Let's split cgroup_bpf_enabled to be per-attach to make sure
> > only used attach types trigger.
> >
> > I've dropped some existing high-level cgroup_bpf_enabled in some
> > places because BPF_PROG_CGROUP_XXX_RUN macros usually have another
> > cgroup_bpf_enabled check.
> >
> > I also had to copy-paste BPF_CGROUP_RUN_SA_PROG_LOCK for
> > GETPEERNAME/GETSOCKNAME because type for cgroup_bpf_enabled[type]
> > has to be constant and known at compile time.
> >
> > Signed-off-by: Stanislav Fomichev <sdf@...gle.com>

> [...]

> > @@ -252,8 +252,10 @@ int bpf_percpu_cgroup_storage_update(struct  
> bpf_map *map, void *key,
> >  #define BPF_CGROUP_RUN_PROG_INET6_BIND_LOCK(sk,  
> uaddr)                        \
> >         BPF_CGROUP_RUN_SA_PROG_LOCK(sk, uaddr, BPF_CGROUP_INET6_BIND,  
> NULL)
> >
> > -#define BPF_CGROUP_PRE_CONNECT_ENABLED(sk) (cgroup_bpf_enabled && \
> > -                                           sk->sk_prot->pre_connect)
> > +#define  
> BPF_CGROUP_PRE_CONNECT_ENABLED(sk)                                    \
> > +       ((cgroup_bpf_enabled(BPF_CGROUP_INET4_CONNECT) | 
> |                      \
> > +         cgroup_bpf_enabled(BPF_CGROUP_INET6_CONNECT))  
> &&                     \
> > +        sk->sk_prot->pre_connect)

> Patchworks highlighted the following (from checkpatch.pl I guess):

> CHECK: Macro argument 'sk' may be better as '(sk)' to avoid precedence  
> issues
> #99: FILE: include/linux/bpf-cgroup.h:255:
> +#define BPF_CGROUP_PRE_CONNECT_ENABLED(sk)       \
> + ((cgroup_bpf_enabled(BPF_CGROUP_INET4_CONNECT) ||       \
> +  cgroup_bpf_enabled(BPF_CGROUP_INET6_CONNECT)) &&       \
> + sk->sk_prot->pre_connect)

> Other than, looks good to me.
Good point, will fix in a respin.

> Acked-by: Song Liu <songliubraving@...com>