netdev - Re: [PATCH 2/2] r8169: checks against wrong mac addresse init

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <48FE0D0F.7020300@redhat.com>
Date:	Tue, 21 Oct 2008 19:10:39 +0200
From:	Ivan Vecera <ivecera@...hat.com>
To:	Martin Capitanio <c4p7n@...itanio.org>
CC:	Francois Romieu <romieu@...zoreil.com>,
	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	jeff@...zik.org, Edward Hsu <edward_hsu@...ltek.com.tw>,
	Petr Vandrovec <petr@...drovec.name>,
	Plamen Petrov <pvp-lsts@...ru.acad.bg>,
	"\"J.A.\" Magallón" 
	<jamagallon@....com>
Subject: Re: [PATCH 2/2] r8169: checks against wrong mac addresse init

Martin Capitanio wrote:
> Please take a look at the realtek r8101_n aka RealTek RTL8101E,
> RTL8102E(L) code. Only CFG_METHOD_1, CFG_METHOD_2
> and #(ioaddr, 0x00) == 0x8128 are here allowed to EEPROM access.
> 
> ...
> 	rtl_eeprom_write_sc(ioaddr, 0x00, 0x8129);
> 
> 	RTL_W8(Cfg9346, Cfg9346_EEM0);
> 	mdelay(15);
> 	rtl_eeprom_write_sc(ioaddr, 0x00, 0x8128);

1) According specification when EEM0 is set to 1 and EEM1 is set to 0
then adapter enters "auto load" mode. Entering this mode will make the
adapter load the contents of the 93C46 (93C56) as when the PCI RSTB
signal is asserted. This auto-load operation will take about 2 ms.
Upon completion, the it automatically returns to normal mode
(EEM1 = EEM0 = 0) and all of the other registers are reset to default
values.
2) First 2 bytes of the EEPROM contain ID code words for the adapter.
It will load the contents of the EEPROM into the corresponding location
if the ID word (0x8129) is correct.

So the Realtek's driver at first sets these bytes to value 0x8129 to ensure
that auto-load will be a success. Then it initiates auto-load (EMM0 = 1 and
EMM1 = 0) then wait some time and finally writes back original value (0x8128).

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