linux-kernel - Re: [PATCH net-next] net: geneve: accept every ethertype

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: <ZA9s2Ti9PlUzsq/m@corigine.com>
Date:   Mon, 13 Mar 2023 19:35:05 +0100
From:   Simon Horman <simon.horman@...igine.com>
To:     Josef Miegl <josef@...gl.cz>
Cc:     Eyal Birger <eyal.birger@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, Pravin B Shelar <pshelar@....org>
Subject: Re: [PATCH net-next] net: geneve: accept every ethertype

On Mon, Mar 13, 2023 at 05:14:58PM +0000, Josef Miegl wrote:
> March 13, 2023 5:48 PM, "Simon Horman" <simon.horman@...igine.com> wrote:
> 
> > +Pravin
> > 
> > On Sun, Mar 12, 2023 at 05:37:26PM +0100, Josef Miegl wrote:
> > 
> >> The Geneve encapsulation, as defined in RFC 8926, has a Protocol Type
> >> field, which states the Ethertype of the payload appearing after the
> >> Geneve header.
> >> 
> >> Commit 435fe1c0c1f7 ("net: geneve: support IPv4/IPv6 as inner protocol")
> >> introduced a new IFLA_GENEVE_INNER_PROTO_INHERIT flag that allowed the
> >> use of other Ethertypes than Ethernet. However, it imposed a restriction
> >> that prohibits receiving payloads other than IPv4, IPv6 and Ethernet.
> >> 
> >> This patch removes this restriction, making it possible to receive any
> >> Ethertype as a payload, if the IFLA_GENEVE_INNER_PROTO_INHERIT flag is
> >> set.
> >> 
> >> This is especially useful if one wants to encapsulate MPLS, because with
> >> this patch the control-plane traffic (IP, IS-IS) and the data-plane
> >> traffic (MPLS) can be encapsulated without an Ethernet frame, making
> >> lightweight overlay networks a possibility.
> > 
> > Hi Josef,
> > 
> > I could be mistaken. But I believe that the thinking at the time,
> > was based on the idea that it was better to only allow protocols that
> > were known to work. And allow more as time goes on.
> 
> Thanks for the reply Simon!
> 
> What does "known to work" mean? Protocols that the net stack handles will
> work, protocols that Linux doesn't handle will not.

Yes, a good question. But perhaps it was more "known to have been tested".

> > Perhaps we have moved away from that thinking (I have no strong feeling
> > either way). Or perhaps this is safe because of some other guard. But if
> > not perhaps it is better to add the MPLS ethertype(s) to the if clause
> > rather than remove it.
> 
> The thing is it is not just adding one ethertype. For my own use-case,
> I would need to whitelist MPLS UC and 0x00fe for IS-IS. But I am sure
> other people will want to use GENEVE` for xx other protocols.

Right, so the list could be expanded for known cases.
But I also understand your point,
which I might describe as this adding friction.

> The protocol handling seems to work, what I am not sure about is if
> allowing all Ethertypes has any security implications. However, if these
> implications exist, safeguarding should be done somewhere down the stock.

Yes, I believe that the idea was to limit the scope of such risks.
(Really, it was a long time ago, so I very likely don't recall everything.)

As I said in my previous email, I'm somewhat ambivalent towards this.
My main purpose in mentioning it is to make sure any changes
made in this area are made deliberately with due consideration.

> > This would be after any patches that enhance the
> > stack to actually support this (I'm thinking of [1], though I haven't
> > looked at it closely).
> > 
> > [1] [PATCH net-next] net: geneve: set IFF_POINTOPOINT with IFLA_GENEVE_INNER_PROTO_INHERIT
> > Link: https://lore.kernel.org/netdev/20230312164557.55354-1-josef@miegl.cz
> 
> This patch just adds IFF_POINTOPOINT to a GENEVE device, it is unrelated.

Understood.

> >> Signed-off-by: Josef Miegl <josef@...gl.cz>
> >> ---
> >> drivers/net/geneve.c | 9 ++-------
> >> 1 file changed, 2 insertions(+), 7 deletions(-)
> >> 
> >> diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
> >> index 89ff7f8e8c7e..32684e94eb4f 100644
> >> --- a/drivers/net/geneve.c
> >> +++ b/drivers/net/geneve.c
> >> @@ -365,13 +365,6 @@ static int geneve_udp_encap_recv(struct sock *sk, struct sk_buff *skb)
> >> if (unlikely(geneveh->ver != GENEVE_VER))
> >> goto drop;
> >> 
> >> - inner_proto = geneveh->proto_type;
> >> -
> >> - if (unlikely((inner_proto != htons(ETH_P_TEB) &&
> >> - inner_proto != htons(ETH_P_IP) &&
> >> - inner_proto != htons(ETH_P_IPV6))))
> >> - goto drop;
> >> -
> >> gs = rcu_dereference_sk_user_data(sk);
> >> if (!gs)
> >> goto drop;
> >> @@ -380,6 +373,8 @@ static int geneve_udp_encap_recv(struct sock *sk, struct sk_buff *skb)
> >> if (!geneve)
> >> goto drop;
> >> 
> >> + inner_proto = geneveh->proto_type;
> >> +
> >> if (unlikely((!geneve->cfg.inner_proto_inherit &&
> >> inner_proto != htons(ETH_P_TEB)))) {
> >> geneve->dev->stats.rx_dropped++;
> >> --
> >> 2.37.1