netdev - Re: [PATCH net-next] net: filter: rename 'struct sk_filter' to 'struct 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMEtUux+dw_GoafXE3ukvmOK2JmZWWf-y0VMobe60TSTfZeNmw@mail.gmail.com>
Date:	Fri, 25 Jul 2014 10:24:29 -0700
From:	Alexei Starovoitov <ast@...mgrid.com>
To:	Daniel Borkmann <dborkman@...hat.com>
Cc:	Pablo Neira Ayuso <pablo@...filter.org>,
	"David S. Miller" <davem@...emloft.net>,
	Network Development <netdev@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>, willemb@...gle.com,
	netfilter-devel@...r.kernel.org
Subject: Re: [PATCH net-next] net: filter: rename 'struct sk_filter' to
 'struct bpf_prog'

On Fri, Jul 25, 2014 at 6:00 AM, Daniel Borkmann <dborkman@...hat.com> wrote:
> On 07/25/2014 01:54 PM, Pablo Neira Ayuso wrote:
>>
>> On Fri, Jul 25, 2014 at 01:25:35PM +0200, Daniel Borkmann wrote:
>>>
>>> [ also Cc'ing Willem, Pablo ]
>>>
>>> On 07/25/2014 10:04 AM, Alexei Starovoitov wrote:
>>>>
>>>> 'sk_filter' name is used as 'struct sk_filter', function sk_filter() and
>>>> as variable 'sk_filter', which makes code hard to read.
>>>> Also it's easily confused with 'struct sock_filter'
>>>> Rename 'struct sk_filter' to 'struct bpf_prog' to clarify semantics and
>>>> align the name with generic BPF use model.
>>>
>>>
>>> Agreed, as we went for kernel/bpf/, renaming makes absolutely sense.
>>
>>
>> My nft socket filtering changes are accomodated into struct sk_filter,
>> and will still be, so I still need some generic name there...
>
>
> All the parts from filter.c which is BPF's core engine have been moved
> into kernel/bpf/ to get it ready for tracing et al, since there is not
> always a socket context anymore. The *whole* infrastructure around struct
> sk_filter is [e]BPF and used in non-net related contexts as well, whereas
> nft socket filtering is *only* for sockets. Due to the socket-only specific
> use case why doesn't it make more sense to have a union in struct sock
> around sk_filter (or however we name it) and only allow one of the two
> being loaded on a socket?

yep.
Adding nft specific things to struct sk_filter/bpf_prog is not correct,
since this struct is already part of seccomp and will be used
in net-less configurations. SK_RUN_FILTER() macro will also be
renamed into something like RUN_BPF_RPOG(). It's one and only
way to invoke eBPF programs. Adding nft selector cannot work,
since eBPF is used with generic context whereas nft is skb specific.
If you want to add nft filtering capabilities to sockets, you'd need
to add union around 'struct bpf_prog' inside 'struct sock', which will be
much cleaner way.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html