netdev - Re: [PATCH netdev-2.6] jme: JMicron Gigabit Ethernet Driver

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:	Sun, 24 Aug 2008 00:04:50 +0800
From:	Guo-Fu Tseng <cooldavid@...ldavid.org>
To:	Jeff Garzik <jgarzik@...ox.com>
CC:	Ethan <ethanhsiao@...cron.com>, akeemting <akeem@...cron.com>,
	netdev@...r.kernel.org
Subject: Re: [PATCH netdev-2.6] jme: JMicron Gigabit Ethernet Driver

Jeff Garzik wrote:
> Guo-Fu Tseng wrote:
>> Hi, Jeff:
>>
>> Here is the full patch of JMicron Gigabit Ethernet driver.
>> Supporting JMC250, and JMC260.
>>
>> I'm new in this submitting system, I've tried hard not to done silly 
>> errors.
>> Comments, and corrections are welcome from anyone. Thank you for 
>> reviewing it.
>>
>> The patch is also available at:
>> http://cooldavid.org/download/jme.netdev-2.6.20080823.patch
>>
>> Signed-off-by: Guo-Fu Tseng <cooldavid@...ldavid.org>
>
> Very nice and clean and feature-complete!  Comments:
>
Thank you! You are so kind. :-)
> * the definition of jwrite32() and jread32():  writel() and readl() 
> are defined in terms of the little-endian PCI bus, and therefore 
> automatically handle byteswapping (or not) as defined by the platform 
> API.
>
> You should be able to just remove those le32_to_cpu() and the reverse, 
> to obtain proper behavior.
>
Removed it.
> * The atomic values rx_cleaning and tx_cleaning look problematic and 
> potentially racy, though I admit not having completely evaluated its 
> usage.
>
Re-writing it.
> * we prefer not to add custom ioctls, but rather add functionality to 
> ethtool.  in particular, JMESPIIOCTL does not appear to have any 
> security checks, and is a potential security hole that permits an 
> unpriveleged user direct access to hardware
>

Should I add privilege check, or should(could?) I send a patch that add 
ethtool interface for flash(For storing PXE code) read/write?


Thank you for super-fast reply.

--
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