netdev - Re: [PATCH v3 net-next RFC] Generic XDP

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: <1492063856.19193.4.camel@sipsolutions.net>
Date:   Thu, 13 Apr 2017 08:10:56 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        David Miller <davem@...emloft.net>
Cc:     netdev@...r.kernel.org, xdp-newbies@...r.kernel.org
Subject: Re: [PATCH v3 net-next RFC] Generic XDP

On Wed, 2017-04-12 at 21:20 -0700, Alexei Starovoitov wrote:

> > +	if (skb_linearize(skb))
> > +		goto do_drop;
> 
> when we discussed supporting jumbo frames in XDP, the idea
> was that the program would need to look at first 3+k bytes only
> and the rest of the packet will be in non-contiguous pages.
> If we do that, it means that XDP program would have to assume
> that the packet is more than [data, data_end] and this range
> only covers linear part.
> If that's the future, we don't need to linearize the skb here
> and can let the program access headlen only.

I'm not sure how you think that would work - at least with our (wifi)
driver, the headlen should be maybe ETH_HLEN or so at this point. We'd
let the program know that it can only look at so much, but then the
program can't do anything at all with those frames. At some point then
we go back to bpf_skb_load_bytes() being necessary in one form or
another, no?

johannes