netdev - Re: question on random MAC in usbnet

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: <87zfzeexy8.fsf@miraculix.mork.no>
Date: Thu, 16 Nov 2023 12:31:43 +0100
From: Bjørn Mork <bjorn@...k.no>
To: Oliver Neukum <oneukum@...e.com>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        USB list <linux-usb@...r.kernel.org>
Subject: Re: question on random MAC in usbnet

Oliver Neukum <oneukum@...e.com> writes:

> I am wondering about the MAC address usbnet is handing
> out. In particular why that is a singular address.

This has been the case since long long before I ever looked at usbnet.c.
The variable declaration is in fact still attributed to the initial git
commit:

 ^1da177e4c3f4 drivers/usb/net/usbnet.c (Linus Torvalds              2005-04-16 15:20:36 -0700   64) // randomly generated ethernet address
 ^1da177e4c3f4 drivers/usb/net/usbnet.c (Linus Torvalds              2005-04-16 15:20:36 -0700   65) static u8   node_id [ETH_ALEN];

Pretty impressive given the churn we've had since then :)

If I were to guess why it ended up like that, I'd say that it probably
was because it was considered an exceptional fallback only.

If you wrote a driver with the USB-IF communication class spec in mind,
then it was reasonable to expect a functional decriptor pointing to a
string descriptor with a globally unique mac address, assigned by the
device manufacturer.

A host using more than one usbnet device was also unlikely 20 years
ago.  So host unique was good enough in any case.

These factors have change a lot since then, obviously.

> Frankly that seems plainly wrong. A MAC is supposed
> to be unique, which is just fundamentally incompatible
> to using the same MAC for multiple devices, as usbnet
> currently potentially does.

Agreed.

> Do you think that behavior should be changed to using
> a separate random MAC for each device that requires it?

I'm in favour.

I could be wrong, but I don't expect anything to break if we did that.
The current static address comes from eth_random_addr() in any case, so
the end result as seen from the mini drivers should be identical.  The
difference will be seen in userspace and surrounding equipment, And
those should be for the better.

Bjørn