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] [day] [month] [year] [list]
Date:   Thu, 29 Nov 2018 17:06:54 +0100
From:   Toke Høiland-Jørgensen <toke@...e.dk>
To:     Lorenzo Bianconi <lorenzo.bianconi@...hat.com>
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\@vger.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:
>> 
>> >> 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

Yeah, I think it's more an issue of convincing the wider XDP community
that support for feature flags is in fact needed ;)

-Toke

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ