NetBSD Problem Report #58702

From www@netbsd.org  Fri Sep 27 13:29:20 2024
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id BD6721A923B
	for <gnats-bugs@gnats.NetBSD.org>; Fri, 27 Sep 2024 13:29:19 +0000 (UTC)
Message-Id: <20240927132918.4A2B81A923D@mollari.NetBSD.org>
Date: Fri, 27 Sep 2024 13:29:18 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: eqos(4) MAC address fallback is busted
X-Send-Pr-Version: www-1.0

>Number:         58702
>Category:       kern
>Synopsis:       eqos(4) MAC address fallback is busted
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Sep 27 13:30:00 +0000 2024
>Last-Modified:  Thu Jul 16 12:05:01 +0000 2026
>Originator:     Taylor R Campbell
>Release:        current, ...
>Organization:
The NetBSD FFFFFFFFFFFE
>Environment:
>Description:
eqos_get_eaddr has a fallback for randomly generating a MAC address, but it can't be taken:

   1265 	maclo = RD4(sc, GMAC_MAC_ADDRESS0_LOW);
   1266 	machi = RD4(sc, GMAC_MAC_ADDRESS0_HIGH) & 0xFFFF;
   1267 	if ((maclo & 0x00000001) != 0) {
   1268 		aprint_error_dev(sc->sc_dev,
   1269 		    "Wrong MAC address. Clearing the multicast bit.\n");
   1270 		maclo &= ~0x00000001;
   1271 	}
   1272 
   1273 	if (maclo == 0xFFFFFFFF && machi == 0xFFFF) {
   1274 		/* Create one */
   1275 		maclo = 0x00f2 | (cprng_strong32() & 0xffff0000);
   1276 		machi = cprng_strong32() & 0xffff;
   1277 	}

https://nxr.netbsd.org/xref/src/sys/dev/ic/dwc_eqos.c?r=1.39#1264

If maclo is 0xffffffff, then the first branch clears the low bit, making it 0xffffffe, so the second branch can never be taken.

Even if it were taken, why do we always set the low 16 bits to be 0x00f2, instead of setting the low 2 bits to be 0x2 (local=1, multicast=0)?  Maybe we should have a random_mac_address routine so these magic constants don't get duplicated everywhere.
>How-To-Repeat:
code inspection
>Fix:
Yes, please!

>Audit-Trail:
From: "David H. Gutteridge" <david@gutteridge.ca>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/58702: eqos(4) MAC address fallback is busted
Date: Wed, 15 Jul 2026 21:02:44 -0400

 The main (functional ordering/invalid logic) issue mentioned here was
 addressed by mlelstv@ in dwc_eqos.c, r. 1.46. (But not pulled up to any
 branches, yet.)

 > Even if it were taken, why do we always set the low 16 bits to be
 > 0x00f2, instead of setting the low 2 bits to be 0x2 (local=3D1,
 > multicast=3D0)?

 I wondered this as well; what I've found so far is that this is
 consistent from when the first example entered our tree in 2014 onward.
 That would be dwc_gmac.c, r. 1.29, though I may have missed an example.
 Apparently no MAC OUI F2:00 assignment exists, so this could be a way
 of making the randomization more obviously such.
 (This is going by
 https://github.com/Ringmast4r/OUI-Master-Database/blob/master/LISTS/kismet_=
 manuf.txt
 .)

 Linux, on the other hand, does it as you describe.
 https://github.com/torvalds/linux/blob/71dfdfb0209b43dfd6f494f84f5548e4cfd1=
 8cb5/include/linux/etherdevice.h#L237

 > Maybe we should have a random_mac_address routine so these magic
 > constants don't get duplicated everywhere.

 I counted seven drivers with code like this, often similar or the same,
 but with some style variances. (When I added it to rtl8169.c, I didn't
 realize there was that much duplication already.)

 Separately, it may also make sense to add something to log that we're
 generating a random MAC, as this may cause unexpected complications for
 someone (IPv6 and SLAAC, network monitoring tools, insufficiently
 random generation if a MAC is calculated before the entropy pool is
 ready).

 Dave

From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/58702: eqos(4) MAC address fallback is busted
Date: Thu, 16 Jul 2026 12:02:12 -0000 (UTC)

 gnats-admin@NetBSD.org ("David H. Gutteridge via gnats") writes:

 >The following reply was made to PR kern/58702; it has been noted by GNATS.

 >From: "David H. Gutteridge" <david@gutteridge.ca>
 >To: gnats-bugs@netbsd.org
 >Cc: 
 >Subject: Re: kern/58702: eqos(4) MAC address fallback is busted
 >Date: Wed, 15 Jul 2026 21:02:44 -0400

 > The main (functional ordering/invalid logic) issue mentioned here was
 > addressed by mlelstv@ in dwc_eqos.c, r. 1.46. (But not pulled up to any
 > branches, yet.)
 > 
 > > Even if it were taken, why do we always set the low 16 bits to be
 > > 0x00f2, instead of setting the low 2 bits to be 0x2 (local=3D1,
 > > multicast=3D0)?


 You may want to use other "locally assigned" prefixes that are not random,
 which would be impossible if you take all the bits. The random value is
 to avoid conflicts within your LAN segment and 32 random bits are good
 enough.

 Of course "good enough" isn't a strong argument nowadays.

Home	PR Database Search