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, 10 Feb 2023 15:28:14 -0600
From:   Dan Williams <dcbw@...hat.com>
To:     Ajay.Kathat@...rochip.com, kvalo@...nel.org, heiko.thiery@...il.com
Cc:     michael@...le.cc, kuba@...nel.org, Claudiu.Beznea@...rochip.com,
        linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
        Amisha.Patel@...rochip.com, thaller@...hat.com,
        bgalvani@...hat.com, Sripad.Balwadgi@...rochip.com
Subject: Re: wilc1000 MAC address is 00:00:00:00:00:00

On Fri, 2023-02-10 at 19:12 +0000, Ajay.Kathat@...rochip.com wrote:
> Hi Kalle,
> 
> On 2/10/23 02:25, Kalle Valo wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you
> > know the content is safe
> > 
> > Heiko Thiery <heiko.thiery@...il.com> writes:
> > 
> > > HI,
> > > 
> > > Am Do., 9. Feb. 2023 um 22:19 Uhr schrieb Michael Walle
> > > <michael@...le.cc>:
> > > > 
> > > > Am 2023-02-09 22:07, schrieb Jakub Kicinski:
> > > > > On Thu, 9 Feb 2023 18:51:58 +0000
> > > > > Ajay.Kathat@...rochip.com wrote:
> > > > > > > netdev should be created with a valid lladdr, is there
> > > > > > > something
> > > > > > > wifi-specific here that'd prevalent that? The canonical
> > > > > > > flow is
> > > > > > > to this before registering the netdev:
> > > > > > 
> > > > > > Here it's the timing in wilc1000 by when the MAC address is
> > > > > > available
> > > > > > to
> > > > > > read from NV. NV read is available in "mac_open"
> > > > > > net_device_ops
> > > > > > instead
> > > > > > of bus probe function. I think, mostly the operations on
> > > > > > netdev which
> > > > > > make use of mac address are performed after the "mac_open"
> > > > > > (I may be
> > > > > > missing something).
> > > > > > 
> > > > > > Does it make sense to assign a random address in probe and
> > > > > > later read
> > > > > > back from NV in mac_open to make use of stored value?
> > > > > 
> > > > > Hard to say, I'd suspect that may be even more confusing than
> > > > > starting with zeroes. There aren't any hard rules around the
> > > > > addresses AFAIK, but addrs are visible to user space. So user
> > > > > space will likely make assumptions based on the most commonly
> > > > > observed sequence (reading real addr at probe).
> > > > 
> > > > Maybe we should also ask the NetworkManager guys. IMHO random
> > > > MAC address sounds bogus.
> > > 
> > > Maybe it would be a "workaround" with loading the firmware while
> > > probing the device to set the real hw address.
> > > 
> > > probe()
> > >   load_fw()
> > >   read_hw_addr_from_nv()
> > >   eth_hw_addr_set(ndev, addr)
> > >   unload_fw()
> > > 
> > > mac_open()
> > >   load_fw()
> > > 
> > > mac_close()
> > >   unload_fw()
> > 
> > This is exactly what many wireless drivers already do and I
> > recommend
> > that wilc1000 would do the same.
> > 
> 
> In wilc1000, the bus interface is up in probe but we don't have
> access
> to mac address via register until the driver starts the wilc firmware
> because of design limitation. This information is only available
> after
> the MAC layer is initialized.

So... initialize the MAC layer and read the address, then stop the card
until dev open which reloads and reinits? That's what eg Atmel does
(though it has a special "read the MAC only" firmware to do that):

	/* No stored firmware so load a small stub which just
	   tells us the MAC address */
	int i;
	priv->card_type = CARD_TYPE_EEPROM;
	atmel_write16(dev, BSR, BSS_IRAM);
	atmel_copy_to_card(dev, 0, mac_reader, sizeof(mac_reader));
	atmel_set_gcr(dev, GCR_REMAP);
	atmel_clear_gcr(priv->dev, 0x0040);
	atmel_write16(dev, BSR, BSS_SRAM);
	for (i = LOOP_RETRY_LIMIT; i; i--)
		if (atmel_read16(dev, MR3) & MAC_BOOT_COMPLETE)
			break;
	if (i == 0) {
		printk(KERN_ALERT "%s: MAC failed to boot MAC address reader.\n", dev->name);
	} else {

		atmel_copy_to_host(dev, addr, atmel_read16(dev, MR2), 6);
		eth_hw_addr_set(dev, addr);
		/* got address, now squash it again until the network
		   interface is opened */
		if (priv->bus_type == BUS_TYPE_PCCARD)
			atmel_write16(dev, GCR, 0x0060);
		atmel_write16(dev, GCR, 0x0040);
		rc = 1;
	}

Dan

> 
> 
> Regards,
> Ajay

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ