netdev - Re: ethernet<n> dt aliases implications in U-Boot and Linux

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YvPMJLSuG3CBC//n@lunn.ch>
Date:   Wed, 10 Aug 2022 17:17:56 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Michal Suchánek <msuchanek@...e.de>
Cc:     Tim Harvey <tharvey@...eworks.com>,
        Pali Rohár <pali@...nel.org>,
        Sean Anderson <sean.anderson@...o.com>,
        Stephen Hemminger <stephen@...workplumber.org>,
        netdev <netdev@...r.kernel.org>, u-boot <u-boot@...ts.denx.de>,
        Device Tree Mailing List <devicetree@...r.kernel.org>
Subject: Re: ethernet<n> dt aliases implications in U-Boot and Linux

> > I guess you are new to the netdev list :-)
> > 
> > This is one of those FAQ sort of things, discussed every
> > year. Anything like this is always NACKed. I don't see why this time
> > should be any different.
> > 
> > DSA is somewhat special because it is very old. It comes from before
> > the times of DT. Its DT binding was proposed relatively earl in DT
> > times, and would be rejected in modern days. But the rules of ABI mean
> > the label property will be valid forever. But i very much doubt it
> > will spread to interfaces in general.
> 
> And if this is a FAQ maybe you can point to a summary (perhaps in
> previous mail discusssion) that explains how to provide stable interface
> names for Ethernet devices on a DT based platform?

As far so the kernel is concerned, interface names are unstable. They
have never been truly stable, but they have got more unstable in the
past decade with multiple busses being probed in parallel, which did
not happen before so much.

> On x86 there is a name derived from the device location in the bus
> topology

This is nothing to do with x86. That is userspace, e.g. systemd,
renaming the interfaces. This applies for any architecture for which
systemd runs on.

> which may be somewhat stable but it is not clear that it
> cannot change, and there is an optional BIOS provided table that can
> asssign meaningful names to the interfaces.

I doubt the kernel is looking at ACPI tables. It is user space which
does that.

The kernel provides udev with a bunch of information about the
interface, its bus location, MAC address, etc. Userspace can then
decide what it wants to call it, and what its alternative names are,
etc.

Also, this is not just a network interface name problem. Any device
with a number/letter in it is unstable. I2C bus devices: i2c0,
i2c1... SPI bus deviceS: spi0, spi1..., Block devices, sda, sdb, sdc,
TPM device, tpm0, tpm1. Nothing is stable in the kernel.

       Andrew