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]

Message-ID: <20160824180727.GE14311@csclub.uwaterloo.ca>
Date:   Wed, 24 Aug 2016 14:07:27 -0400
From:   lsorense@...lub.uwaterloo.ca (Lennart Sorensen)
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>
Subject: Re: [Regression?] Commit cb4f71c429 deliberately changes order of
 network interfaces

On Wed, Aug 24, 2016 at 07:10:04PM +0200, Ralph Sennhauser wrote:
> And in how many places this discrepancy was documented? You won't be
> able to update them all. Mailing lists, blogs, fora posts and what ever
> else. I'd say the damage is done and can't be fixed by simply changing
> the order now.
> 
> Whether strong rule or not, obviously it went in so bending the rule is
> at least accepted. It's not what I have an issue with but with the
> reordering at this point.
> 
> I'm clearly not convinced reverting would do more harm than good,
> otherwise I wouldn't have brought it up.

I would agree, although if you see below I think it maybe something
that user space will have to figure out a way to deal with sooner or
later anyhow.

> It's not about being able to fix the code or documentation but about
> having to do so in the first place.
> 
> The nice thing about having the order in the dtb I thought was that it
> wont ever change.

I wonder, if someone was to build a box with this cpu, and add a PCIe
network device, which order would they get probed in?  Any chance the
PCIe could grab eth0 before the mvneta devices get probed?

I also would not count on this not changing in the future potentially
by accident.  The mmc block devices used to get probed in DTB order, then
that changed at some point and reordering the dtb no longer controlled it,
rather it was whichever device seemed to finish fastests, and then later
that was changed to using the controller's opinion of the device number
(which at least made it predicable again, even if not controllable from
the dtb).

So at the moment the dtb order controls ethernet probe order.  Well if
other things have stopped doing that, why expect ethernet won't some
day stop doing that too?

"Fixing" the port numbering by reordering is hence a hack as far as I
am concerned and not certain to stay working long term.

> Going forward, as we disagree and it's basically a political decision,
> whom do we ask to rule here? Linus?

-- 
Len Sorensen