netdev - Re: [PATCH bpf-next 0/7] Add XDP_ATTACH bind() flag to AF

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

Message-ID: <20181208213726.4b33f7f7@redhat.com>
Date:   Sat, 8 Dec 2018 21:37:26 +0100
From:   Jesper Dangaard Brouer <brouer@...hat.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Björn Töpel 
        <bjorn.topel@...il.com>, magnus.karlsson@...el.com,
        magnus.karlsson@...il.com, ast@...nel.org, daniel@...earbox.net,
        netdev@...r.kernel.org,
        Björn Töpel 
        <bjorn.topel@...el.com>, u9012063@...il.com, qi.z.zhang@...el.com,
        brouer@...hat.com
Subject: Re: [PATCH bpf-next 0/7] Add XDP_ATTACH bind() flag to AF_XDP
 sockets

On Sat, 8 Dec 2018 17:55:05 +0100
Andrew Lunn <andrew@...n.ch> wrote:

> On Sat, Dec 08, 2018 at 04:12:12PM +0100, Jesper Dangaard Brouer wrote:
> > On Fri, 7 Dec 2018 13:21:08 -0800
> > Alexei Starovoitov <alexei.starovoitov@...il.com> wrote:
> >   
> > > for production I suspect the users would want
> > > an easy way to stay safe when they're playing with AF_XDP.
> > > So another builtin program that redirects ssh and ping traffic
> > > back to the kernel would be a nice addition.  
> > 
> > Are you saying a buildin program that need to parse different kinds of
> > Eth-type headers (DSA, VLAN, QinqQ)  
> 
> Hi Jesper
> 
> Parsing DSA headers is quite hard, since most of them are not
> discoverable, you need to know they are there, and where they actually
> are.
> 
> I also don't think there are any use cases for actually trying to
> parse them on the master interface. You are more likely to want to run
> the eBPF program on the slave interface, once the DSA header has been
> removed, and it is clear what interface the frame is actually for.

That is not how XDP works. XDP must run on the "master" physical driver
interface, as the "slave" interface is a virtual DSA interface.  I did
mention DSA because I'm handling that on the EspressoBin implementation.

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer