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]

Message-ID: <20181129154502.GA29066@localhost.localdomain>
Date:   Thu, 29 Nov 2018 16:45:03 +0100
From:   Lorenzo Bianconi <lorenzo.bianconi@...hat.com>
To:     Toke Høiland-Jørgensen <toke@...e.dk>
Cc:     Jesper Dangaard Brouer <brouer@...hat.com>,
        Kalle Valo <kvalo@...eaurora.org>,
        linux-wireless@...r.kernel.org, nbd@....name,
        Daniel Borkmann <borkmann@...earbox.net>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [RFC 0/5] add XDP support to mt76x2e/mt76x0e drivers

> Lorenzo Bianconi <lorenzo.bianconi@...hat.com> writes:
> 
> >> Lorenzo Bianconi <lorenzo.bianconi@...hat.com> writes:
> >> 
> >> >> On Wed, 28 Nov 2018 13:36:26 +0100
> >> >> Toke Høiland-Jørgensen <toke@...e.dk> wrote:
> >> >> 

[...]

> >> >
> >> > I guess it will be enough to avoid loading a 'non-WiFi' bpf program on
> >> > a 802.11 netdevice (and vice versa). We could add a flag (or something
> >> > similar) in XDP_SETUP_PROG section of netdev_bpf data structure and
> >> > use ieee80211_ptr netdevice pointer in order to guarantee that the bpf
> >> > program will work on the expected 'frame-type'
> >> 
> >> Yeah, a flag would be good; we've been discussing that for other XDP use
> >> cases; it's not a done deal yet, but I think it would be useful.
> >
> > Do you think something wifi specific is ok (e.g bool wifi) or do you prefer
> > something more general (e.g u32 frame_type)?
> 
> My thought was a feature flag where the program can set a flag which
> means "I expect 802.11 frames", and the driver can set a flag saying "I
> emit 802.11 frames", and if those two flags don't match, the verifier
> can refuse to load the program. This would not be fool-proof (an XDP
> program can still corrupt things if written incorrectly), but it would
> at least protect against the most obvious mistakes.

I guess we can use iee80211_ptr in dev_xdp_install to double check if it is
allowed to upload a 802.11 (or 802.3) bpf program

> 
> >> >> Option#2, leave it up to eBPF-programmer if they want to add runtime
> >> >> checks.  By extending xdp_rxq_info with frame-type (default to
> >> >> Ethernet), which allow the eBPF-programmer choose to write a generic
> >> >> XDP program that both work on Ethernet and WiFi, or skip-check as they
> >> >> know this will e.g. only run on Wifi.  (Note xdp_rxq_info is static
> >> >> read-only info per RX-queue, will all Wifi frames have same frame-type?.
> >> >> 
> >> >
> >> > 802.11 standards define three frame subtype (data, management and control).
> >> > Subtypes could be detected parsing 802.11 header
> >> >
> >> >> 
> >> >> Also consider what happens in case of XDP_REDIRECT, from a Wifi NIC to
> >> >> an Ethernet NIC.  It would of-cause be cool to get this working cross,
> >> >> Wifi-Ethernet.
> >> >> 
> >> >
> >> > Very cool :) On tx side the driver will accept standard ethernet frames in
> >> > ndo_xdp_xmit pointer
> >> 
> >> How do you envision that will work with drivers that build software
> >> 802.11 frames? The TX hook would have to be in mac80211 somewhere,
> >> wouldn't it?
> >
> > In order to perform 802.3 --> 802.11 xdp forwarding my current idea is
> > is to have ndo_xdp_xmit pointer in mac80211 that will forward the
> > frame to the low-level driver (more or less what I did in the RFC
> > series to upload the bpf program to mt76). We will probably need to
> > pass some info to the driver from mac80211 (e.g sequence number or hw
> > key idx to use)
> 
> So this means that the driver will need to do the 802.11 encapsulation?
> I guess we could have a fallback implementation in mac80211; but there
> is possibly quite a bit of refactoring needed to make the existing code
> work without an skb. Also, we need to think about queueing; I'm not sure
> it's a good idea to have redirected frames bypass the TXQs...
> 

good point :)

Regards,
Lorenzo

> -Toke