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
| ||
|
Date: Sat, 14 Jan 2012 07:54:27 -0800 From: Darren Hart <dvhart@...ux.intel.com> To: David Miller <davem@...emloft.net> CC: linux-kernel@...r.kernel.org, arjan@...ux.intel.com, alan@...ux.intel.com, tomoya.rohm@...il.com, jeffrey.t.kirsher@...el.com, paul.gortmaker@...driver.com, jdmason@...zu.us, netdev@...r.kernel.org Subject: Re: [PATCH] pch_gbe: Use a randomly generated MAC instead of failing probe On 01/14/2012 12:14 AM, David Miller wrote: > From: Darren Hart <dvhart@...ux.intel.com> > 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 <dvhart@...ux.intel.com> > > 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 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/
Powered by blists - more mailing lists