netdev - Re: [PATCH net] ip_tunnel: allow to inherit from VLAN encapsulated IP frames

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: <20220706131735.4d9f4562@kernel.org>
Date:   Wed, 6 Jul 2022 13:17:35 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Matthias May <matthias.may@...termo.com>
Cc:     <netdev@...r.kernel.org>, <davem@...emloft.net>,
        <yoshfuji@...ux-ipv6.org>, <dsahern@...nel.org>,
        <edumazet@...gle.com>, <pabeni@...hat.com>
Subject: Re: [PATCH net] ip_tunnel: allow to inherit from VLAN encapsulated
 IP frames

On Wed, 6 Jul 2022 09:07:36 +0200 Matthias May wrote:
> >> The current code allows to inherit the TOS, TTL, DF from the payload
> >> when skb->protocol is ETH_P_IP or ETH_P_IPV6.
> >> However when the payload is VLAN encapsulated (e.g because the tunnel
> >> is of type GRETAP), then this inheriting does not work, because the
> >> visible skb->protocol is of type ETH_P_8021Q.
> >>
> >> Add a check on ETH_P_8021Q and subsequently check the payload protocol.  
> > 
> > Do we need to check for 8021AD as well?
> 
> Yeah that would make sense.
> I can add the check for ETH_P_8021AD in v2.
> Will have to find some hardware that is AD capable to test.

Why HW, you should be able to test with two Linux endpoints, no?

> >> Signed-off-by: Matthias May <matthias.may@...termo.com>
> >> ---
> >>   net/ipv4/ip_tunnel.c | 21 +++++++++++++--------  
> > 
> > Does ipv6 need the same treatment?  
> 
> I don't think i changed anything regarding the behaviour for ipv6
> by allowing to skip from the outer protocol to the payload protocol.

Sorry, to be clear what I meant - we try to enforce feature parity for
IPv6 these days in Linux. So I was asking if ipv6 needs changes to be
able to deal with VLANs. I think you got that but just in case.

> The previous code already
> * got the TOS via ipv6_get_dsfield,
> * the TTL was derived from the hop_limit,
> * and DF does not exist for ipv6 so it doesn't check for ETH_P_IPV6.

Purely by looking at the code I thought that VLAN-enabled GRETAP frames
would fall into ip6gre_xmit_other() which passes dsfield=0 into
__gre6_xmit(). key->tos only overrides the field for "external" tunnels, 
not normal tunnels with a dedicated netdev per tunnel.

A selftest to check both ipv4 and ipv6 would be the ultimate win there.