netdev - Re: [PATCH net] net/packet: tpacket_rcv: do not increment ring index on drop

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: <20200311171634-mutt-send-email-mst@kernel.org>
Date:   Wed, 11 Mar 2020 17:25:33 -0400
From:   "Michael S. Tsirkin" <mst@...hat.com>
To:     Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc:     Network Development <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>
Subject: Re: [PATCH net] net/packet: tpacket_rcv: do not increment ring index
 on drop

On Wed, Mar 11, 2020 at 10:31:47AM -0400, Willem de Bruijn wrote:
> I would expect packet sockets to behave the same with and without
> po->has_vnet_hdr. Without, they already pass all GSO packets up to
> userspace as is. Which is essential for debugging with tcpdump or
> wirehark. I always interpreted has_vnet_hdr as just an option to
> receive more metadata along, akin to PACKET_AUXDATA. Not something
> that subtly changes the packet flow.
>

So again just making sure:

	we are talking about a hypothetical case where we add a GSO type,
	then a hypothetical userspace that does not know about a specific GSO
	type, right?

I feel if someone writes a program with packet sockets, it is
important that it keeps working, and that means keep seeing
all packets, even if someone runs it on a new kernel
with a new optimization like gso. I feel dropping packets is
worse than changing gso type.

And that in turn means userspace must opt in to
seeing new GSO type, and old userspace must see old ones.

One way to do that would be converting packets on the socket, another
would be disabling the new GSO automatically as the socket is created
unless it opts in.

> That was my intend, but I only extended it to tpacket_rcv. Reading up
> on the original feature that was added for packet_rcv, it does mention
> "allows GSO/checksum offload to be enabled when using raw socket
> backend with virtio_net". I don't know what that raw socket back-end
> with virtio-net is. Something deprecated, but possibly still in use
> somewhere?

Pretty much. E.g. I still sometimes use it with an out of tree QEMU
patch - maybe I'll try to re-post it there just so we have an upstream
way to test the interface.

-- 
MST