netdev - Re: [PATCH] pch_gbe: Use a randomly generated MAC instead of failing probe

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:	Sat, 14 Jan 2012 14:36:07 -0800
From:	Darren Hart <dvhart@...ux.intel.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	David Miller <davem@...emloft.net>, 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 01:46 PM, Alan Cox wrote:
>> I fear that people are just going to add this random MAC stuff way too
>> easily, it's a spreading disease.
>>
>> Ship functional hardware instead.
> 
> See "choir, preaching to the".
> 
> The stuff is out there and it's not Darren's fault !
> 
> Alan

So perhaps I should provide some more context into why I'm sending these
patches. The following hardware is currently available and the existing
Linux support is confined to a Timesys Fedora-Based pre-installed image
which requires user intervention to write a MAC using an old, not
upstreamed, modified ioh_gbe_mac driver.

The board documentation is available here:
http://www.inforcecomputing.com/SYS940X_ECX.html

In particular, see:
http://www.inforcecomputing.com/proddls/SYS940X-01_UserGuide_001329.pdf
and:
http://www.inforcecomputing.com/proddls/BLDK2_Kern_2.6.29-10_and_2.6.29-12_for_SYS940X-1_1304.pdf

I felt this patch made this hardware more accessible by allowing it to
work with current kernels without ugly userspace hacks. It is also
following precedent set by existing drivers.

So while I completely agree with the sentiment "Ship functional
hardware", this wasn't a product I was involved with, I'm just trying to
make a bad situation better. As Alan alludes to above, I do actually
spend a good deal of time trying to improve hardware to avoid this kind
of thing (it's an amazingly difficult task).

-- 
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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html