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]

Date:   Thu, 13 Apr 2017 11:38:10 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     johannes@...solutions.net
Cc:     alexei.starovoitov@...il.com, netdev@...r.kernel.org,
        xdp-newbies@...r.kernel.org
Subject: Re: [PATCH v3 net-next RFC] Generic XDP

From: Johannes Berg <johannes@...solutions.net>
Date: Thu, 13 Apr 2017 08:10:56 +0200

> 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?

Agreed, this is completely unusable.  Some wired ethernet drivers do the
same exact thing.