netdev - Re: [PATCH] net/ethernet : set default assignment identifier to NET_NAME

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:   Mon, 4 Apr 2022 10:55:27 +1000
From:   Ian Wienand <iwienand@...hat.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH] net/ethernet : set default assignment identifier to
 NET_NAME_ENUM

On Sat, Apr 02, 2022 at 08:40:08PM +0200, Andrew Lunn wrote:
> So is there a risk here that Xen user suddenly find their network
> interfaces renamed, where as before they were not, and their
> networking thus breaks?

Well, this is actually what "got" us.  The interfaces *are* renamed on
CentOS 9-stream, but not on earlier releases, because systemd makes
different choices [1].  Tomorrow someone might "fix" something in that
systemd/udev chain that flips interfaces without specific use flags
back to not being renamed again.  I'm certain it would vary based on
what distro and release you chose to boot.

> Consistency is good, but it is hard to do in retrospect when there are
> deployed systems potentially dependent on the inconsistency.

As noted, it is already the case that if your names are falling into
this path, they are unstable? (there are many pages for every distro
that go on and on about this, systemd/udev interactions, rules, link
files, and so on; e.g. [2]).

I get what you are saying, that in a fixed virtual environment booting
some relatively fixed distro, perhaps the names are "stable enough"
and nobody has bothered updating this yet, so everyone is probably
happy enough with what they have.

But ultimately it seems like nobody is regression testing this, and
all it takes is a seemingly unrelated change to struct layout or list
walking and things might change anyway.  Then the answer would then be
-- well sorry about that but we never guaranteed that anyway.

Reflecting reality and labeling the interface as named in a
unstable way just seems like the way forward here, to me.

-i

[1] For too much detail; it wasn't actually the interface renaming
    that was the problem, as such; but udev issuing a "move" event
    rather than an "add" event that our custom udev rules didn't match
    for (our bug, uncovered by this).  Of course it's more
    interesting, because the Xen cloud is the only one that doesn't
    use DHCP.  So although we were missing the event on the other
    clouds where things were renamed, we didn't notice because that
    rule was ultimatley a no-op in that situation anyway as it
    auto-configures.  It was only on Xen that networking was not
    configured.

[2] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/consistent-network-interface-device-naming_configuring-and-managing-networking