netdev - Re: [PATCH net v4] net: xdp: account for layer 3 packets in generic skb handler

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHmME9rt-8Z1FJo9YSEqQHyEd1178cfizNa08BiakZYr+FR=Wg@mail.gmail.com>
Date:   Fri, 14 Aug 2020 23:04:56 +0200
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Netdev <netdev@...r.kernel.org>,
        Thomas Ptacek <thomas@...kpuppet.org>,
        Adhipati Blambangan <adhipati@...a.io>,
        David Ahern <dsahern@...il.com>,
        Toke Høiland-Jørgensen <toke@...hat.com>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>
Subject: Re: [PATCH net v4] net: xdp: account for layer 3 packets in generic
 skb handler

On 8/14/20, Jakub Kicinski <kuba@...nel.org> wrote:
> On Fri, 14 Aug 2020 08:56:48 +0200 Jason A. Donenfeld wrote:
>> On Thu, Aug 13, 2020 at 11:01 PM Jakub Kicinski <kuba@...nel.org> wrote:
>> > > I had originally dropped this patch, but the issue kept coming up in
>> > > user reports, so here's a v4 of it. Testing of it is still rather
>> > > slim,
>> > > but hopefully that will change in the coming days.
>> >
>> > Here an alternative patch, untested:
>>
>> Funny. But come on now... Why would we want to deprive our users of
>> system consistency?
>
> We should try for consistency between xdp and cls_bpf instead.

And still require users to reimplement their packet processing logic twice?

>
>> Doesn't it make sense to allow users to use the same code across
>> interfaces? You actually want them to rewrite their code to use a
>> totally different trigger point just because of some weird kernel
>> internals between interfaces?
>
> We're not building an abstraction over the kernel stack so that users
> won't have to worry how things work. Users need to have a minimal
> understanding of how specific hooks integrate with the stack and what
> they are for. And therefore why cls_bpf is actually more efficient to
> use in L3 tunnel case.

It's not like adding 7 lines of code constitutes adding an abstraction
layer. It's a pretty basic fix to make real things work for real
users. While you might argue that users should do something different,
you also can't deny that being able to hook up the same packet
processing to eth0, eth1, extrafancyeth2, and tun0 is a huge
convenience.

>
>> Why not make XDP more useful and more generic across interfaces? It's
>> very common for systems to be receiving packets with a heavy ethernet
>> card from the current data center, in addition to receiving packets
>> from a tunnel interface connected to a remote data center, with a need
>> to run the same XDP program on both interfaces. Why not support that
>> kind of simplicity?
>>
>> This is _actually_ something that's come up _repeatedly_. This is a
>> real world need from real users who are doing real things. Why not
>> help them?
>
> I'm sure it comes up repeatedly because we don't return any errors,
> so people waste time investigating why it doesn't work.

What? No. It comes up repeatedly because people want to reuse their
XDP processing logic with layer 3 devices. You might be right that if
we tell them to go away, maybe they will, but on the other hand, why
not make this actually work for them? It seems pretty easy to do, and
saves everyone a lot of time.

Are you worried about adding a branch to the
already-slower-and-discouraged non-hardware generic path? If so, I
wouldn't object if you wanted to put unlikely() around the branch
condition in that if statement.

Jason