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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Thu, 7 Jul 2022 13:57:11 +0200
From:   Matthias May <matthias.may@...termo.com>
To:     Jakub Kicinski <kuba@...nel.org>
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 7/6/22 22:17, Jakub Kicinski wrote:
> 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?
> 

Yes sure, that is how i did the initial version of the patch
(and yes, how i verified that AD works for v2).
My concern is, that if i use 2 devices that are patched identically,
that i may work with a bug present on both sides, but doesn't work
together with a 3rd party implementation.

>>>> 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.
> 

Ah you mean with IPv6 as transport for the tunnel.
I haven't really looked into that, since i have IPv6 disabled in my env.
I will try come up with a patch.

Since this does not touch the same code, should i send it as a separate
patch, or integrate it into this?

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

I'm not really familiar with selftests.
I've taken a look at some of the files in testing/selftests/net/ which
seems to be just a bunch of shell.
I'll see if i can write such a script that verifies this functionality.

Again as with the above about IPv6.
This seems to be kind of standalone. Should i integrate it into this
patch, or send as a separate?

BR
Matthias

Download attachment "OpenPGP_0xDF76B604533C0DBE.asc" of type "application/pgp-keys" (670 bytes)

Download attachment "OpenPGP_signature" of type "application/pgp-signature" (237 bytes)