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: <9a1d9340-8fd0-4e27-0938-adf361fe6939@redhat.com>
Date:   Mon, 20 Aug 2018 14:34:40 +0800
From:   Jason Wang <jasowang@...hat.com>
To:     David Ahern <dsahern@...il.com>,
        Jesper Dangaard Brouer <jbrouer@...hat.com>
Cc:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        ast@...nel.org, daniel@...earbox.net, mst@...hat.com
Subject: Re: [RFC PATCH net-next V2 0/6] XDP rx handler



On 2018年08月18日 05:15, David Ahern wrote:
> On 8/15/18 9:34 PM, Jason Wang wrote:
>> I may miss something but BPF forbids loop. Without a loop how can we
>> make sure all stacked devices is enumerated correctly without knowing
>> the topology in advance?
> netdev_for_each_upper_dev_rcu
>
> BPF helpers allow programs to do lookups in kernel tables, in this case
> the ability to find an upper device that would receive the packet.

So if I understand correctly, you mean using 
netdev_for_each_upper_dev_rcu() inside a BPF helper? If yes, I think we 
may still need device specific logic. E.g for macvlan, 
netdev_for_each_upper_dev_rcu() enumerates all macvlan devices on top a 
lower device. But what we need is one of the macvlan that matches the 
dst mac address which is similar to what XDP rx handler did. And it 
would become more complicated if we have multiple layers of device.

So let's consider a simple case, consider we have 5 macvlan devices:

macvlan0: doing some packet filtering before passing packets to TCP/IP stack
macvlan1: modify packets and redirect to another interface
macvlan2: modify packets and transmit packet back through XDP_TX
macvlan3: deliver packets to AF_XDP
macvtap0: deliver packets raw XDP to VM

So, with XDP rx handler, what we need to just to attach five different 
XDP programs to each macvlan device. Your idea is to do all things in 
the root device XDP program. This looks complicated and not flexible 
since it needs to care a lot of things, e.g adding/removing 
actions/policies. And XDP program needs to call BPF helper that use 
netdev_for_each_upper_dev_rcu() to work correctly with stacked device.

Thanks

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ