netdev - Re: [PATCH net 1/2] net/af_packet: adjust network header position for VLAN tagged packets

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:   Tue, 19 Apr 2022 11:02:43 +0800
From:   Hangbin Liu <liuhangbin@...il.com>
To:     Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc:     Maxim Mikityanskiy <maximmi@...lanox.com>,
        Mike Pattrick <mpattric@...hat.com>,
        "Michael S . Tsirkin" <mst@...hat.com>, netdev@...r.kernel.org,
        Eric Dumazet <edumazet@...gle.com>,
        virtualization@...ts.linux-foundation.org,
        Balazs Nemeth <bnemeth@...hat.com>,
        Flavio Leitner <fbl@...hat.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        "David S . Miller" <davem@...emloft.net>
Subject: Re: [PATCH net 1/2] net/af_packet: adjust network header position
 for VLAN tagged packets

On Mon, Apr 18, 2022 at 11:38:14AM -0400, Willem de Bruijn wrote:
> Strictly speaking VLAN tagged GSO packets have never been supported.

OK, I thought we just forgot to handle the VLAN header for RAW af socket.
As in the later path skb_mac_gso_segment() deal with VLAN correctly.

If you think this should be a new feature instead of fixes. I can remove the
fixes tag and re-post it to net-next, as you said.

> The only defined types are TCP and UDP over IPv4 and IPv6:
> 
>   define VIRTIO_NET_HDR_GSO_TCPV4        1       /* GSO frame, IPv4 TCP (TSO) */
>   define VIRTIO_NET_HDR_GSO_UDP          3       /* GSO frame, IPv4 UDP (UFO) */
>   define VIRTIO_NET_HDR_GSO_TCPV6        4       /* GSO frame, IPv6 TCP */
> 
> I don't think this is a bug, more a stretching of the definition of those flags.

I think VLAN is a L2 header, so I just reset the network header position.

I'm not familiar with virtio coded. Do you mean to add a new flag like VIRTIO_NET_HDR_GSO_VLAN?
> > @@ -3055,11 +3068,6 @@ static int packet_snd(struct socket *sock, struct msghdr *msg, size_t len)
> >                 virtio_net_hdr_set_proto(skb, &vnet_hdr);
> >         }
> >
> > -       packet_parse_headers(skb, sock);
> > -
> > -       if (unlikely(extra_len == 4))
> > -               skb->no_fcs = 1;
> > -
> 
> Moving packet_parse_headers before or after virtio_net_hdr_to_skb may
> have additional subtle effects on protocol detection.
> 
> I think it's probably okay, as tpacket_snd also calls in the inverse
> order. But there have been many issues in this codepath.

Yes

> 
> We should also maintain feature consistency between packet_snd,
> tpacket_snd and to the limitations of its feature set to
> packet_sendmsg_spkt. The no_fcs is already lacking in tpacket_snd as
> far as I can tell. But packet_sendmsg_spkt also sets it and calls
> packet_parse_headers.

Yes, I think we could fix the tpacket_snd() in another patch.

There are also some duplicated codes in these *_snd functions.
I think we can move them out to one single function.

> Because this patch touches many other packets besides the ones
> intended, I am a bit concerned about unintended consequences. Perhaps

Yes, makes sense.

> stretching the definition of the flags to include VLAN is acceptable
> (unlike outright tunnels), but even then I would suggest for net-next.

As I asked, I'm not familiar with virtio code. Do you think if I should
add a new VIRTIO_NET_HDR_GSO_VLAN flag? It's only a L2 flag without any L3
info. If I add something like VIRTIO_NET_HDR_GSO_VLAN_TCPV4/TCPV6/UDP. That
would add more combinations. Which doesn't like a good idea.

Thanks
Hangbin