netdev - Re: Removing skb_orphan() from ip_rcv

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: <5f916eb2-9971-f3a8-fac8-b4b51cd881b0@gmail.com>
Date:   Tue, 25 Jun 2019 19:03:36 +0200
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Daniel Borkmann <daniel@...earbox.net>,
        Joe Stringer <joe@...d.net.nz>, Florian Westphal <fw@...len.de>
Cc:     netdev <netdev@...r.kernel.org>,
        john fastabend <john.fastabend@...il.com>,
        Lorenz Bauer <lmb@...udflare.com>,
        Jakub Sitnicki <jakub@...udflare.com>,
        Paolo Abeni <pabeni@...hat.com>,
        Flavio Leitner <fbl@...hat.com>, ast@...nel.org
Subject: Re: Removing skb_orphan() from ip_rcv_core()



On 6/25/19 2:35 AM, Daniel Borkmann wrote:

> 
> But wasn't the whole point of 9c4c325252c5 ("skbuff: preserve sock reference when
> scrubbing the skb.") to defer orphaning to as late as possible? If I'm not missing
> anything, then above would reintroduce the issues that 9c4c325252c5 was trying to
> solve wrt TSQ/XPS/etc when skb was sent via veth based data path to cross netns and
> then forwarded to phys dev for transmission; meaning, skb->sk is lost at the point
> of dev_queue_xmit() for the latter. A side-effect this would also have is that this
> changes behavior again for tc egress programs sitting on phys dev (e.g. querying
> sock cookie or other related features).


Unless we can detect/decide that a packet going through veth pair is going to be locally
consumed, or forwarded to a physical device (another ndo_start_xmit()), we need
to skb_orphan() the packet, exactly the same way than loopback ndo_start_xmit()

(We could have setups where these packets going through lo interface could be forwarded
to a NIC...)

Backpressure is a best effort, we should not make it an absolute requirement and
prevent doing early demux as early as possible in RX path.