linux-kernel - Re: [Regression?] Commit cb4f71c429 deliberately changes order of network interfaces

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:   Wed, 24 Aug 2016 21:48:36 +0000
From:   Jason Cooper <jason@...edaemon.net>
To:     Ralph Sennhauser <ralph.sennhauser@...il.com>
Cc:     Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Gregory CLEMENT <gregory.clement@...e-electrons.com>,
        Lennart Sorensen <lsorense@...lub.uwaterloo.ca>
Subject: Re: [Regression?] Commit cb4f71c429 deliberately changes order of
 network interfaces

All,

On Wed, Aug 24, 2016 at 10:41:02PM +0200, Ralph Sennhauser wrote:
> On Wed, 24 Aug 2016 20:15:31 +0200
> Thomas Petazzoni <thomas.petazzoni@...e-electrons.com> wrote:
> > On Wed, 24 Aug 2016 19:10:04 +0200, Ralph Sennhauser wrote:
> > 
> > The people who can take this decision are rather the maintainers of
> > the platform itself, or possibly the arm-soc maintainers if you still
> > don't like what the platform maintainers decided.
> 
> We both have a conflict of interest here, so your offer in an other
> message to let the platform maintainers decide is appreciated.

Ok, I'm going to jump in here with the caveats that a) I don't mind
being overruled, and b) I'm not going to participate in a never-ending
thread on this topic.  ;-)

So, I'm just a back-seat co-maintainer for mvebu nowadays, my opinion
should be taken with a grain of salt.

>From the kernel-side, there is no guarantee of device naming.  The
kernel simply doesn't have sufficient information at boot time.  This is
why udev, systemd-udev-ntpd-syslog-kitchensink, and others were created.
To read immutable attributes of a device and apply consistent naming to
them based on configuration files.  That's why userspace frequently uses
uuids to locate partitions, rather than /dev/sdX[0-9] nodes.

The devicetree "ordered by address" rule is, in my opinion, an arbitrary
CDO-rule [1].  It doesn't describe the hardware, or a relationship
between them.  As such, it's just as arbitrary as probe order.  It just
happens to be something we can twiddle.  It also depends on dtc
preserving that order.

>From the user side, without udev and friends, shit changed from one
kernel to the next.  That's not good.  I can certainly see the point
that it should have been left alone to begin with.  But we aren't there
today.

So what happens if we revert now?  Right or wrong, in a couple of
months, someone else will complain, asking to revert the revert.
And what will our answer be?  "We did it last time, but not this time."
or "Ok, but gosh-darnit, this is the last time."

To be blunt, I think our best path forward is to just hold our noses and
let it stand as is.  Some will fix their userspace to adapt, others will
carry a patch.  It's more important at this point to be consistent
moving forward.  It's better to hear "Yeah, it fucking changed once."
rather than "I don't know what to expect, it changes every few releases."

thx,

Jason.

[1] CDO: OCD with the letters neatly arranged in alphabetical order.