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: <20160825194034.GI14311@csclub.uwaterloo.ca>
Date:   Thu, 25 Aug 2016 15:40:34 -0400
From:   lsorense@...lub.uwaterloo.ca (Lennart Sorensen)
To:     Ralph Sennhauser <ralph.sennhauser@...il.com>
Cc:     Jason Cooper <jason@...edaemon.net>,
        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 Thu, Aug 25, 2016 at 09:38:39AM +0200, Ralph Sennhauser wrote:
> I'm also not interested in a never ending thread. It's moot that udev
> can't rename to kernel names sanely and we were sold ep34aj17asz98 as
> the replacement. Or that tearing apart the casing to replace the wifi
> modules with an ethernet one when there are already 5 Gbit ports is not
> a case I care about.
> 
> Relying on the order might in theory have flaws but works just fine in
> practice. Thomas Petazzoni, I, OpenWrt / Lede / etc all do so with
> success.

It has worked so far.  I expect it to break at some point.

> It's also not a side effect from major changes, so it didn't break by
> accident but as the subject says deliberately.

In this case that is certainly true.

> How exceptional is this exception we are talking about? I mean if it's
> the only place you might want to change it even in 2 years but you
> can't because of the very same rule which was broken here.

I did a quick look at the dts files, and there are quite a few cases
that are not ordered, and I can't find anything in Documentation that
says they should be sorted.  It just appears that in most cases people
do sort them, since that just makes sense for finding things and it is
as good an order as any other.

> I think if we were at 4.6-rcX reverting would be an easy call. I know
> it's more difficult to make this call now.
> 
> Ltsi is 4.1, longterm is 4.4, so penetration is probably marginal at
> best at this time. From my view the damage caused by a revert would be
> less than the damage that will be caused by the commit if left in but we
> can't wait much much longer until this changes.

Certainly no longterm kernels have this change yet, so it certainly does
seem the impact would be rather minimal.  Usually the rule seems to be
"Don't break user space".  This did potentially break userspace, so then
the question is whether what user space was doing was considred proper
and something that should expect not to break.

> If you use the ordering by address as main argument for the revert there
> will be nothing to argue about.

If only there was a documented place that had that rule.  I can't find it.

-- 
Len Sorensen