linux-kernel - Re: RFC: Platform data for onboard USB assets

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, 18 Mar 2011 10:09:46 +0000
From:	Andy Green <andy@...mcat.com>
To:	Roger Quadros <roger.quadros@...ia.com>
CC:	ext Arnd Bergmann <arnd@...db.de>, Greg KH <greg@...ah.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Nicolas Pitre <nicolas.pitre@...aro.org>,
	Linux USB list <linux-usb@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: RFC: Platform data for onboard USB assets

On 03/18/2011 09:55 AM, Somebody in the thread at some point said:

>>> So how does the Host LAN driver know what MAC address it should use?
>>
>> This is the problem we're trying to work out. The EEPROM is not
>> present, and user space has no way of knowing which MAC address
>> to set to which device. Note that there might be multiple
>> USB devices of the same type that are indistinguishable to user
>> space, so setting the MAC address there would not be completely
>> safe.
>>
>
> And what happens if you need to use u-boot or some bootloader with
> ethernet network support?
>
> Wouldn't it be better to have the MAC address programmed at the
> bootloader level?

Generally trying to have stuff half done in bootloader and half in Linux 
makes things fragile and makes another place for trouble to hide (in 
addition to bootloader state such as U-Boot env or boot.scr or 
what-have-you needing distro control for updates).

If your bootloader is bloated enough to target network operations under 
its own steam, it's bloated enough to set a random MAC or use the same 
CPU ID scheme.  But it doesn't mean that Linux should not assert the 
state it wants when it runs.

-Andy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/