netdev - Re: [PATCH net-next] net-loopback: allow lo dev initial state to be controlled

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: <CAF2d9jgHOqsQFHE7tMwkgAQv2N24t3UWcMrK+ZnmfYNXHsPWuQ@mail.gmail.com>
Date:   Tue, 1 Dec 2020 12:24:38 -0800
From:   Mahesh Bandewar (महेश बंडेवार) 
        <maheshb@...gle.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     nicolas.dichtel@...nd.com, David Ahern <dsahern@...il.com>,
        Ido Schimmel <idosch@...sch.org>,
        Jian Yang <jianyang.kernel@...il.com>,
        David Miller <davem@...emloft.net>,
        linux-netdev <netdev@...r.kernel.org>,
        Jian Yang <jianyang@...gle.com>,
        Eric Dumazet <edumazet@...gle.com>
Subject: Re: [PATCH net-next] net-loopback: allow lo dev initial state to be controlled

On Thu, Nov 19, 2020 at 8:56 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Thu, 19 Nov 2020 19:55:08 -0800 Mahesh Bandewar (महेश बंडेवार) wrote:
> > On Thu, Nov 19, 2020 at 12:03 AM Nicolas Dichtel
> > > Le 18/11/2020 à 18:39, Mahesh Bandewar (महेश बंडेवार) a écrit :
> > > > netns but would create problems for workloads that create netns to
> > > > disable networking. One can always disable it after creating the netns
> > > > but that would mean change in the workflow and it could be viewed as
> > > > regression.
> > > The networking is very limited with only a loopback. Do you have some real use
> > > case in mind?
> >
> > My use cases all use networking but I think principally we cannot
> > break backward compatibility, right?
> > Jakub, WDYT?
>
> Do you have more details on what the use cases are that expect no
> networking?
>
> TBH I don't get the utility of this knob. If you want to write vaguely
> portable software you have to assume the knob won't be useful, because
> either (a) kernel may be old, or (b) you shouldn't assume to own the
> sysctls and this is a global one (what if an application spawns that
> expects legacy behavior?)
>
> And if you have to check for those two things you're gonna write more
> code than just ifuping lo would be.
>
> Maybe you can shed some more light on how it makes life at Google
> easier for you? Or someone else can enlighten me?
>
> I don't have much practical experience with namespaces, but the more
> I think about it the more pointless it seems.

Thanks for the input.

Sorry, I was on vacation and couldn't process this response earlier.

There are two things that this patch is providing and let me understand the
objections well.

(a) Bring up lo by default
(b) sysctl to protect the legacy behavior

Frankly we really dont have any legacy-behavior use case and one can
bring it back to life by just doing 'ifdown lo' if necessary. Most of
the use cases involve using networking anyways. My belief was that we
need to protect legacy behavior and hence went lengths to add sysctl
to protect it. If we are OK not to have it, I'm more than happy to
remove the sysctl and just have the 3 line patch to bring loopback up.

If legacy-behavior is a concern (which I thought generally is), then
either we can have the sysctl to have it around to protect it (the
current implementation) but if we prefer to have kernel-command-line
instead of sysctl that defaults to legacy behavior but if provided, we
can set it UP by default during boot (or the other way around)?

My primary motive is (a) while (b) is just a side-effect which we can
get away if deemed unnecessary.