netdev - Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers

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]

Date:   Thu, 29 Nov 2018 14:48:42 +0100
From:   Toke Høiland-Jørgensen <toke@...e.dk>
To:     Michał Kazior <kazikcz@...il.com>
Cc:     lorenzo.bianconi@...hat.com, brouer@...hat.com,
        kvalo@...eaurora.org,
        linux-wireless <linux-wireless@...r.kernel.org>,
        Felix Fietkau <nbd@....name>, borkmann@...earbox.net,
        alexei.starovoitov@...il.com,
        Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers

Michał Kazior <kazikcz@...il.com> writes:

> On Thu, 29 Nov 2018 at 14:31, Toke Høiland-Jørgensen <toke@...e.dk> wrote:
> [...]
>> >> Option#3 is to say, Wifi XDP is so different that we should create a
>> >> new (enum) bpf_prog_type.  And then still see if we can leverage some
>> >> of the same core-code (as long as it doesn't slowdown performance).
>> >>
>> >
>> > Do you think that Option#3 will be more 'future-proof' respect to
>> > Option#1?
>>
>> My feeling is that WiFi devices are not sufficiently different to
>> warrant a whole new program type. We risk combinatorial explosion for
>> all the stuff that is the same, but now need to be tested for two (or N)
>> types...
>
> I'm not sure if my understanding is correct, but XDP seems like it can
> (and intends to be able to?) act as a general purpose packet
> accelerator (REDIRECT action was mentioned so I'm inferring..). In
> such case you'll need to be able to perform transformations on packets
> too, e.g. strip/prepend vlan tags, gre headers and what have you. The
> 802.3 <-> 802.11 conversion could be treated on equal terms.

Sure, that is perfectly possible. It just needs to be implemented by the
eBPF program being loaded; and there is a facility to shrink/expand the
packet size for encapsulation processing. It's just that since currently
all interfaces process Ethernet frames, this frame type assumption has
kinda been built in. So something needs to be done to handle that.

The minimum is just to ignore the issue and make it up to the program
writer to handle this or risk breaking things, but something a bit
friendlier (such as an ability for the loaded program to indicate which
frame type it is prepared to handle, which can be sanity-checked by the
loader) might be a good idea... Especially if different WiFi devices
will emit different frame types (so we can't just go "it's a WiFi
device, you should know this").

Then there's the additional issue that since mac80211 and/or the driver
may have internal state, we need to expose appropriate helpers for an
XDP program to be able to update this as it's processing packets (before
bypassing the stack, for instance).

-Toke