linux-kernel - Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns

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: <87tvta67gl.fsf@xmission.com>
Date:   Tue, 20 Mar 2018 11:24:26 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Liran Alon <liran.alon@...cle.com>
Cc:     <shmulik.ladkani@...il.com>, <netdev@...r.kernel.org>,
        <mrv@...atatu.com>, <daniel@...earbox.net>, <davem@...emloft.net>,
        <linux-kernel@...r.kernel.org>, <yuval.shaia@...cle.com>,
        <idan.brown@...cle.com>
Subject: Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns

Liran Alon <liran.alon@...cle.com> writes:

> ----- shmulik.ladkani@...il.com wrote:
>
>> On Thu, 15 Mar 2018 09:35:51 -0700 (PDT) Liran Alon
>> <liran.alon@...cle.com> wrote:
>> > ----- shmulik.ladkani@...il.com wrote:
>> > 
>> > > On Thu, 15 Mar 2018 08:01:03 -0700 (PDT) Liran Alon
>> > > <liran.alon@...cle.com> wrote:  
>> > > > 
>> > > > I still think that default behavior should be to zero skb->mark
>> only  
>> > > when skb  
>> > > > cross netdevs in different netns.  
>> > > 
>> > > But the previous default was scrub the mark in *both* xnet and
>> > > non-xnet
>> > > situations.
>> > > 
>> > > Therefore, there might be users which RELY on this (strange)
>> default
>> > > behavior in their same-netns-veth-pair setups.
>> > > Meaning, changing the default behavior might break their apps
>> relying
>> > > on
>> > > the former default behavior.
>> > > 
>> > > This is why the "disable mark scrubbing in non-xnet case" should
>> be
>> > > opt-in.  
>> > 
>> > We think the same.
>> > The only difference is that I think this for now should be
>> controllable
>> > by a global /proc/sys/net/core file instead of giving a flexible
>> per-netdev
>> > control.
>> > Because that is a larger change that could be done later.
>> 
>> A flags attribute to veth newlink is a very scoped change.
>> User controls this per veth creation.
>> This is way more neat than /proc/sys/net and provides the desired
>> granular
>> control.
>> 
>> Also, scoping this to veth has the advantage of not affecting the many
>> other
>> dev_forward_skb callers.
>
> Agreed. But isn't this an issue also for the
> many others (& future) callers of dev_forward_skb()?
> This seems problematic to me.
>
> This will kinda leave a kernel interface with broken default behavior
> for backwards comparability.
>
> A flag to netdev or /proc/sys/net/core to "fix" default behavior
> will avoid this.

I don't believe the current behavior is a bug.

I looked through the history.  Basically skb_scrub_packet
started out as the scrubbing needed for crossing network
namespaces.

Then tunnels which needed 90% of the functionality started
calling it, with the xnet flag added.  Because the tunnels
needed to preserve their historic behavior.

Then dev_forward_skb started calling skb_scrub_packet.

A veth pair is supposed to give the same behavior as a cross-over
cable plugged into two local nics.  A cross over cable won't
preserve things like the skb mark.  So I don't see why anyone would
expect a veth pair to preserve the mark.

Right now I don't see the point of handling packets that don't cross
network namespace boundaries specially, other than to preserve backwards
compatibility.

Eric