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  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:	Sat, 14 Jan 2012 07:54:27 -0800
From:	Darren Hart <>
To:	David Miller <>
Subject: Re: [PATCH] pch_gbe: Use a randomly generated MAC instead of failing

On 01/14/2012 12:14 AM, David Miller wrote:
> From: Darren Hart <>
> Date: Fri, 13 Jan 2012 22:44:55 -0800
>> If the MAC is invalid or not implemented, use a randomly generated one rather
>> than failing the probe. Store the generated addr in a new sw_mac array in the
>> pch_gbe_mac_info structure. Take care to allow for assigning the MAC via
>> ifconfig by reusing sw_addr to store an assigned mac if probe populated it with
>> a random one (otherwise the assignment would rely on the ROM and the reset would
>> fail to write a valid MAC to the rx filter).
>> Tested on two platforms, one with a valid MAC, the other without a MAC. The
>> real MAC is used if present, a randomly generated one otherwise. Both are
>> capable of changing the MAC with ifconfig. They successfully get an IP over
>> DHCP and pass a simple ping and login over ssh test.
>> This does not make any attempt to address a missing or invalid MAC for the
>> pch_phub driver.
>> Signed-off-by: Darren Hart <>
> I don't want to see code like this added if it's "just in case."

I don't disagree, unfortunately it is not "just in case". The Inforce
Goldstein QSeven Module on the Portwell PQ7-C100XL carrier board are
already available and do not implement the MAC EEPROM in hardware.

> Please correct any hardware that hasn't shipped yet or is alpha/beta
> hardware in testing, so that we don't need stuff like this.

I saw that the use of random_ether_addr is fairly prevalent, and
attempted a roughly similar sort of approach to others I had seen. Do
you consider all of those to be "necessary evils" or are there
legitimate situations for its use?

In any case, with existing hardware out there that is unusable with the
current pch_gbe driver, can we consider this workaround for inclusion?

Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists