All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Borkmann <daniel@iogearbox.net>
To: Daniel Mack <daniel@zonque.org>, htejun@fb.com, ast@fb.com
Cc: davem@davemloft.net, kafai@fb.com, fw@strlen.de,
	pablo@netfilter.org, harald@redhat.com, netdev@vger.kernel.org,
	sargun@sargun.me
Subject: Re: [PATCH v3 5/6] net: core: run cgroup eBPF egress programs
Date: Tue, 06 Sep 2016 19:14:31 +0200	[thread overview]
Message-ID: <57CEF977.5030003@iogearbox.net> (raw)
In-Reply-To: <634bb3e7-ea27-bf4d-5597-0cb9d4379466@zonque.org>

On 09/05/2016 04:22 PM, Daniel Mack wrote:
> On 08/30/2016 12:03 AM, Daniel Borkmann wrote:
>> On 08/26/2016 09:58 PM, Daniel Mack wrote:
>
>>> diff --git a/net/core/dev.c b/net/core/dev.c
>>> index a75df86..17484e6 100644
>>> --- a/net/core/dev.c
>>> +++ b/net/core/dev.c
>>> @@ -141,6 +141,7 @@
>>>    #include <linux/netfilter_ingress.h>
>>>    #include <linux/sctp.h>
>>>    #include <linux/crash_dump.h>
>>> +#include <linux/bpf-cgroup.h>
>>>
>>>    #include "net-sysfs.h"
>>>
>>> @@ -3329,6 +3330,11 @@ static int __dev_queue_xmit(struct sk_buff *skb, void *accel_priv)
>>>    	if (unlikely(skb_shinfo(skb)->tx_flags & SKBTX_SCHED_TSTAMP))
>>>    		__skb_tstamp_tx(skb, NULL, skb->sk, SCM_TSTAMP_SCHED);
>>>
>>> +	rc = cgroup_bpf_run_filter(skb->sk, skb,
>>> +				   BPF_ATTACH_TYPE_CGROUP_INET_EGRESS);
>>> +	if (rc)
>>> +		return rc;
>>
>> This would leak the whole skb by the way.
>
> Ah, right.
>
>> Apart from that, could this be modeled w/o affecting the forwarding path (at some
>> local output point where we know to have a valid socket)? Then you could also drop
>> the !sk and sk->sk_family tests, and we wouldn't need to replicate parts of what
>> clsact is doing as well. Hmm, maybe access to src/dst mac could be handled to be
>> just zeroes since not available at that point?
>
> Hmm, I wonder where this hook could be put instead then. When placed in
> ip_output() and ip6_output(), the mac headers cannot be pushed before
> running the program, resulting in bogus skb data from the eBPF program.

But as it stands right now, RX will only see a subset of packets in sk_filter()
layer (depending on where it's called in the proto handler implementation,
so might not even include all control messages, for example) as opposed to
the TX hook going that far even 'seeing' everything incl. forwarded packets
in the sense that we know a priori that these kind of skbs going through the
cgroup_bpf_run_filter() handler when the hook is enabled will just skip this
hook eventually anyway. What about letting such progs see /only/ local skbs
for RX and TX, with skb->data from L3 onwards (iirc, that would be similar
to what current sk_filter() programs see)?

  reply	other threads:[~2016-09-06 17:14 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-26 19:58 [PATCH v3 0/6] Add eBPF hooks for cgroups Daniel Mack
2016-08-26 19:58 ` [PATCH v3 1/6] bpf: add new prog type for cgroup socket filtering Daniel Mack
2016-08-29 22:14   ` Daniel Borkmann
2016-09-05 12:48     ` Daniel Mack
2016-08-26 19:58 ` [PATCH v3 2/6] cgroup: add support for eBPF programs Daniel Mack
2016-08-27  0:03   ` Alexei Starovoitov
2016-09-05 12:47     ` Daniel Mack
2016-08-29 22:42   ` Daniel Borkmann
2016-09-05 12:50     ` Daniel Mack
2016-08-29 23:04   ` Sargun Dhillon
2016-09-05 14:49     ` Daniel Mack
2016-09-05 21:40       ` Sargun Dhillon
2016-09-05 22:39         ` Alexei Starovoitov
2016-08-26 19:58 ` [PATCH v3 3/6] bpf: add BPF_PROG_ATTACH and BPF_PROG_DETACH commands Daniel Mack
2016-08-27  0:08   ` Alexei Starovoitov
2016-09-05 12:56     ` Daniel Mack
2016-09-05 15:30       ` David Laight
2016-09-05 15:40         ` Daniel Mack
2016-09-05 17:29       ` Joe Perches
2016-08-29 23:00   ` Daniel Borkmann
2016-09-05 12:54     ` Daniel Mack
2016-09-05 13:56       ` Daniel Borkmann
2016-09-05 14:09         ` Daniel Mack
2016-09-05 17:09           ` Daniel Borkmann
2016-09-05 18:32             ` Alexei Starovoitov
2016-09-05 18:43               ` Daniel Mack
2016-08-26 19:58 ` [PATCH v3 4/6] net: filter: run cgroup eBPF ingress programs Daniel Mack
2016-08-29 23:15   ` Daniel Borkmann
2016-08-26 19:58 ` [PATCH v3 5/6] net: core: run cgroup eBPF egress programs Daniel Mack
2016-08-29 22:03   ` Daniel Borkmann
2016-08-29 22:23     ` Sargun Dhillon
2016-09-05 14:22     ` Daniel Mack
2016-09-06 17:14       ` Daniel Borkmann [this message]
2016-08-26 19:58 ` [PATCH v3 6/6] samples: bpf: add userspace example for attaching eBPF programs to cgroups Daniel Mack
2016-08-27 13:00 ` [PATCH v3 0/6] Add eBPF hooks for cgroups Rami Rosen

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=57CEF977.5030003@iogearbox.net \
    --to=daniel@iogearbox.net \
    --cc=ast@fb.com \
    --cc=daniel@zonque.org \
    --cc=davem@davemloft.net \
    --cc=fw@strlen.de \
    --cc=harald@redhat.com \
    --cc=htejun@fb.com \
    --cc=kafai@fb.com \
    --cc=netdev@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=sargun@sargun.me \
    /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.