From: Alexei Starovoitov <ast@plumgrid.com>
To: Daniel Borkmann <daniel@iogearbox.net>,
"David S. Miller" <davem@davemloft.net>
Cc: Andy Lutomirski <luto@amacapital.net>,
Ingo Molnar <mingo@kernel.org>,
Hannes Frederic Sowa <hannes@stressinduktion.org>,
Eric Dumazet <edumazet@google.com>,
Kees Cook <keescook@chromium.org>,
netdev@vger.kernel.org
Subject: Re: [PATCH net-next] bpf: fix cb access in socket filter programs
Date: Wed, 7 Oct 2015 09:53:57 -0700 [thread overview]
Message-ID: <56154E25.3050309@plumgrid.com> (raw)
In-Reply-To: <56151977.10302@iogearbox.net>
On 10/7/15 6:09 AM, Daniel Borkmann wrote:
>> bpf_prog_run_clear_cb() wouldn't work on dev_forward_skb() as
>> skb->pkt_type is then being scrubbed to PACKET_HOST, so on the
>> receive path, AF_PACKET might not always see clean skbs->cb[]
>> as assumed ... I think that the skb->pkt_type part needs to be
>> dropped, no?
right. will respin.
> Thinking a bit more about this part, which only accounts for
> fanout_demux_bpf() and run_filter(), so AF_PACKET only, this
> logic still needs to be slightly different:
>
> You currently can have eBPF on packet fanout as a demux and behind
> that eBPF on the actual packet socket. So, for some reason, fanout
> could transfer some state to the socket along the way, which could
> break when cleared as-is via bpf_prog_run_clear_cb().
>
> So we need to make sure to only clear this once, either in front
> of fanout, or when not present, in front of the socket filter.
no. that would be anti-feature. user space shouldn't rely on such
things. If somebody wants to pass data between two disjoint
programs (not called via tail_call), they should be using maps or
some future per-cpu scratch area that will guarantee such semantics.
cb as part of skb is not suitable for that, since it will limit
what kernel can do in-between.
prev parent reply other threads:[~2015-10-07 16:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-07 2:18 [PATCH net-next] bpf: fix cb access in socket filter programs Alexei Starovoitov
2015-10-07 9:39 ` Daniel Borkmann
2015-10-07 13:09 ` Daniel Borkmann
2015-10-07 16:53 ` Alexei Starovoitov [this message]
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=56154E25.3050309@plumgrid.com \
--to=ast@plumgrid.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hannes@stressinduktion.org \
--cc=keescook@chromium.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.