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: Fri, 17 May 2024 16:07:08 +0200
From: Andrew Lunn <andrew@...n.ch>
To: "Leon M. Busch-George" <leon@...rgemail.de>
Cc: linux-kernel@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
	devicetree@...r.kernel.org, netdev@...r.kernel.org,
	Matthias Brugger <matthias.bgg@...il.com>
Subject: Re: [PATCH 1/2] net: add option to ignore 'local-mac-address'
 property

On Fri, May 17, 2024 at 02:39:07PM +0200, Leon M. Busch-George wrote:
> From: "Leon M. Busch-George" <leon@...rgemail.eu>
> 
> Here is the definition of a mac that looks like its address would be
> loaded from nvmem:
> 
>   mac@0 {
>     compatible = "mediatek,eth-mac";
>     reg = <0>;
>     phy-mode = "2500base-x";
>     phy-handle = <&rtl8221b_phy>;
> 
>     nvmem-cell-names = "mac-address";
>     nvmem-cells = <&macaddr_bdinfo_de00 1>; /* this is ignored */
>   };
> 
> Because the boot program inserts a 'local-mac-address', which is preferred
> over other detection methods, the definition using nvmem is ignored.
> By itself, that is only a mild annoyance when dealing with device trees.
> After all, the 'local-mac-address' property exists primarily to pass MAC
> addresses to the kernel.
> 
> But it is also possible for this address to be randomly generated (on each
> boot), which turns an annoyance into a hindrance. In such a case, it is no
> longer possible to set the correct address from the device tree. This
> behaviour has been observed on two types of MT7981B devices from different
> vendors (Cudy M3000, Yuncore AX835).
> 
> Restore the ability to set addresses through the device tree by adding an
> option to ignore the 'local-mac-address' property.

I'm not convinced you are fixing the right thing here.

To me, this is the bootloader which is broken. You should be fixing
the bootloader.

One concession might be, does the bootloader correctly generate a
random MAC address? i.e. does it have the locally administered bit
set? If that bit is set, and there are other sources of a MAC address,
then it seems worth while checking them to see if there is a better
MAC address available, which as global scope.

    Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ