svn commit: r346052 - head/sys/dev/usb/net

[John Baldwin]

On 4/9/19 12:48 PM, Rodney W. Grimes wrote:
>> On 4/9/19 9:59 AM, Ian Lepore wrote:
>>> On Tue, 2019-04-09 at 09:33 -0700, John Baldwin wrote:
>>>> On 4/9/19 9:17 AM, Ian Lepore wrote:
>>>>> On Tue, 2019-04-09 at 09:11 -0700, John Baldwin wrote:
>>>>>> On 4/9/19 6:54 AM, Ganbold Tsagaankhuu wrote:
>>>>>>> Author: ganbold
>>>>>>> Date: Tue Apr  9 13:54:08 2019
>>>>>>> New Revision: 346052
>>>>>>> URL: https://svnweb.freebsd.org/changeset/base/346052
>>>>>>>
>>>>>>> Log:
>>>>>>>   In some cases like NanoPI R1, its second USB ethernet
>>>>>>>   RTL8152 (chip version URE_CHIP_VER_4C10) doesn't
>>>>>>>   have hardwired MAC address, in other words, it is all zeros.
>>>>>>>   This commit fixes it by setting random MAC address
>>>>>>>   when MAC address is all zeros.
>>>>>>>   
>>>>>>>   Reviewed by:	kevlo
>>>>>>>   Differential Revision:	
>>>>>>> https://reviews.freebsd.org/D19856
>>>>>>
>>>>>> It would be best to not use a purely random mac address and to
>>>>>> use
>>>>>> the
>>>>>> function kevans@ added recently.  That function generates a MAC
>>>>>> address
>>>>>> from the FreeBSD OUI using a cryptographic hash so you get a
>>>>>> stable address across boots on a given host.
>>>>>>
>>>>>
>>>>> How could that possibly work?  If it's not random, you can't have
>>>>> two
>>>>> such devices on the same network.  If it is random, it's not stable
>>>>> from one boot to the next.
>>>>
>>>> It uses the UUID and interface name as input into the hash.  
>>>
>>>> The UUID is per-host.
>>>
>>> Oh, so it only works on x86 (or I guess any system that has something
>>> like a bios that can provide you with a uuid that doesn't change from
>>> one boot to the next).
>>
>> The function is in one centralized place where you are free to add other
>> data as input into the hash.  We do always generate a uuid that we save
>> on boot if we aren't seeded with one by firmware, though that is probably
>> too late for this driver (so +1 may in fact be a better route).  It should
>> be fine for psuedo interfaces created post-boot though even on non-x86 due
>> to /etc/rc.d/hostid.  Pure random MAC's are not really great either.
> 
> Cant the loader load /etc/rc.d/hostid and put it in something that
> the kernel could get at, or a module written that handles this?

It's a different file, and yes in theory the loader could look at the file
and set UUID and hostid env vars.  However, that's a no-op for most use
cases.  If other platforms have some kind of firmware-provided thing that
isn't a UUID, it would be good to teach the centralized function about
those as an input to the hash, but at least that can be done in place
rather than having open-coded MAC generators in various drivers.

-- 
John Baldwin