netdev - Re: [PATCH net-next] bpf: fix cb access in socket filter programs

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] [day] [month] [year] [list]

Message-ID: <56154E25.3050309@plumgrid.com>
Date:	Wed, 7 Oct 2015 09:53:57 -0700
From:	Alexei Starovoitov <ast@...mgrid.com>
To:	Daniel Borkmann <daniel@...earbox.net>,
	"David S. Miller" <davem@...emloft.net>
Cc:	Andy Lutomirski <luto@...capital.net>,
	Ingo Molnar <mingo@...nel.org>,
	Hannes Frederic Sowa <hannes@...essinduktion.org>,
	Eric Dumazet <edumazet@...gle.com>,
	Kees Cook <keescook@...omium.org>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] bpf: fix cb access in socket filter programs

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.

--
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