netdev - Re: [RFC 1/3] bpf/wireless: add wifimon program type

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:   Tue, 18 Apr 2017 13:35:15 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Daniel Borkmann <daniel@...earbox.net>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     David Miller <davem@...emloft.net>, linux-wireless@...r.kernel.org,
        netdev@...r.kernel.org, ast@...nel.org
Subject: Re: [RFC 1/3] bpf/wireless: add wifimon program type

So actually, come to think of it ...

> > The mapping in samples/bpf/bpf_helpers.h, for example, for
> > mentioned
> > bpf_skb_load_bytes() would also work out of the box, since it takes
> > a
> > void *ctx as an argument, so you can just pass the __wifi_sk_buff
> > pointer as ctx there from program side.
> 
> Hah. That's what I was missing - I always assumed the argument was
> "struct __sk_buff *" without ever checking that assumption.

Given this, I think I'll actually make a __wifi_sk_buff.

> The thing is that __wifi_sk_buff doesn't have much information that's
> generally useful available

Because I just realized that this isn't true. To make sense of the SKB
beyond the 802.11 header, which may not be possible at all though due
to encryption happening in software later, it will have to know a few
things like whether or not it was encrypted and if the IV was stripped
etc.

Actually, perhaps we should just restrict it to just look at the header
;-)

johannes