From: Alexei Starovoitov <ast@plumgrid.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>,
Ingo Molnar <mingo@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Andy Lutomirski <luto@amacapital.net>,
Hannes Frederic Sowa <hannes@stressinduktion.org>,
Eric Dumazet <edumazet@google.com>,
Kees Cook <keescook@chromium.org>,
linux-api@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next 1/2] bpf: enable non-root eBPF programs
Date: Tue, 6 Oct 2015 12:26:53 -0700 [thread overview]
Message-ID: <5614207D.4050708@plumgrid.com> (raw)
In-Reply-To: <1444154160.9555.5.camel@edumazet-glaptop2.roam.corp.google.com>
On 10/6/15 10:56 AM, Eric Dumazet wrote:
> On Tue, 2015-10-06 at 10:50 -0700, Alexei Starovoitov wrote:
>
>> was also thinking that we can do it only in paths that actually
>> have multiple protocol layers, since today bpf is mainly used with
>> tcpdump(raw_socket) and new af_packet fanout both have cb cleared
>> on RX, because it just came out of alloc_skb and no layers were called,
>> and on TX we can clear 20 bytes in dev_queue_xmit_nit().
>> af_unix/netlink also have clean skb. Need to analyze tun and sctp...
>> but it feels overly fragile to save a branch in sk_filter,
>> so planning to go with
>> if(unlikely(prog->cb_access)) memset in sk_filter().
>>
>
> This will break TCP use of sk_filter().
> skb->cb[] contains useful data in TCP layer.
oops. thanks for catching. In case of sk_filter on top of tcp sock,
it shouldn't be looking at cb at all.
I'm thinking to send a patch to get rid of cb access for socket filters
all together until better solution found.
next prev parent reply other threads:[~2015-10-06 19:26 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-05 20:48 [PATCH net-next 0/2] bpf: unprivileged Alexei Starovoitov
2015-10-05 20:48 ` [PATCH net-next 1/2] bpf: enable non-root eBPF programs Alexei Starovoitov
[not found] ` <1444078101-29060-2-git-send-email-ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
2015-10-05 21:00 ` Kees Cook
2015-10-05 21:00 ` Kees Cook
2015-10-05 21:12 ` Alexei Starovoitov
[not found] ` <5612E7C4.1010306-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
2015-10-05 21:16 ` Andy Lutomirski
2015-10-05 21:16 ` Andy Lutomirski
2015-10-05 21:32 ` Alexei Starovoitov
2015-10-05 22:02 ` Kees Cook
2015-10-06 0:28 ` Alexei Starovoitov
2015-10-08 2:29 ` Alexei Starovoitov
2015-10-08 2:29 ` Alexei Starovoitov
2015-10-05 22:14 ` Daniel Borkmann
[not found] ` <5612F639.2050305-FeC+5ew28dpmcu3hnIyYJQ@public.gmane.org>
2015-10-06 0:51 ` Alexei Starovoitov
2015-10-06 0:51 ` Alexei Starovoitov
[not found] ` <56131B1F.80002-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
2015-10-06 7:13 ` Ingo Molnar
2015-10-06 7:13 ` Ingo Molnar
2015-10-06 8:05 ` Daniel Borkmann
2015-10-06 8:20 ` Ingo Molnar
[not found] ` <20151006082048.GA18287-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-10-06 8:39 ` Daniel Borkmann
2015-10-06 8:39 ` Daniel Borkmann
[not found] ` <561388D1.30406-FeC+5ew28dpmcu3hnIyYJQ@public.gmane.org>
2015-10-06 17:50 ` Alexei Starovoitov
2015-10-06 17:50 ` Alexei Starovoitov
2015-10-06 17:56 ` Eric Dumazet
[not found] ` <1444154160.9555.5.camel-XN9IlZ5yJG9HTL0Zs8A6p/gx64E7kk8eUsxypvmhUTTZJqsBc5GL+g@public.gmane.org>
2015-10-06 18:05 ` Andy Lutomirski
2015-10-06 18:05 ` Andy Lutomirski
2015-10-07 6:05 ` Ingo Molnar
2015-10-06 19:26 ` Alexei Starovoitov [this message]
[not found] ` <561409EC.5050005-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
2015-10-06 18:03 ` Daniel Borkmann
2015-10-06 18:03 ` Daniel Borkmann
2015-10-06 12:45 ` Daniel Borkmann
2015-10-06 12:45 ` Daniel Borkmann
2015-10-07 21:20 ` Alexei Starovoitov
[not found] ` <56158CAF.9030209-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
2015-10-07 22:07 ` Daniel Borkmann
2015-10-07 22:07 ` Daniel Borkmann
2015-10-07 22:22 ` Kees Cook
2015-10-07 23:49 ` Alexei Starovoitov
[not found] ` <5615AF92.50402-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
2015-10-08 6:21 ` Ingo Molnar
2015-10-08 6:21 ` Ingo Molnar
2015-10-08 6:30 ` Alexei Starovoitov
2015-10-08 17:42 ` Kees Cook
2015-10-05 20:48 ` [PATCH net-next 2/2] bpf: charge user for creation of BPF maps and programs Alexei Starovoitov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5614207D.4050708@plumgrid.com \
--to=ast@plumgrid.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eric.dumazet@gmail.com \
--cc=hannes@stressinduktion.org \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mingo@kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.