netdev - Re: __sk_buff.data

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, 20 Apr 2017 16:48:11 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Daniel Borkmann <daniel@...earbox.net>,
        Alexei Starovoitov <ast@...nel.org>
Cc:     netdev <netdev@...r.kernel.org>
Subject: Re: __sk_buff.data_end

On Thu, 2017-04-20 at 16:46 +0200, Daniel Borkmann wrote:
> > Hmm. I don't see what "somewhere else" I could possibly have
> > though, given that I want the (kernel-side) context to be "struct
> > sk_buff *" to allow the skb helpers?
> 
> I have not enough context on the wireless side, perhaps could be
> somewhere under skb->dev->ieee80211_ptr or so, iff suitable. 

I don't think I even have skb->dev assigned at this point :)

> But
> it also really doesn't matter much since this is all transparently
> handled in the kernel, meaning these kind of rewrites can still be
> changed at a later point in time, f.e. if it's only 'u64 boottime_ns'
> right now, that could live directly in the cb[] w/o extra pointer,
> and should that grow to more members, then it could be moved behind
> a pointer later on and it still works as-is from the program point
> of view.

Well, there are 48 bytes in the cb already, so doing this would mean
moving two pointer-sized things out, but yeah - as long as we don't add
everything right now we can keep those things that are available to BPF
in the cb and move something else out.

As long as what I described there with the indirect load works, I'm
fine with this, and I can even do data_end pretty easily then.

johannes