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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Tue, 21 Oct 2008 23:55:45 +0200
From:	Martin Capitanio <c4p7n@...itanio.org>
To:	Ivan Vecera <ivecera@...hat.com>
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

On Tue, 2008-10-21 at 19:10 +0200, Ivan Vecera wrote:
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).
>

My current working hypothesis is, that some of the devices due a hw bug
doesn't like a auto-load on the 'pci-hardwired-reset'. So they have the
value (0x8128).

Second thing is, that thru vpd you have full r/w
access to the EEPROM and the difference between read and write
is just flipping 1 bit. Although my brain refuses to parse the related
linux's pci core code, I think the access should be hw disabled
at the driver start and in the read case as soon as possible
to keep the window for the devil tinier ( http://lwn.net/Articles/303390/ ),
i.e. the realtek's code:

	RTL_W8(Cfg9346, Cfg9346_Unlock);
        RTL_W8(Config1, RTL_R8(Config1) | VPDEnable);
        RTL_W8(Cfg9346, Cfg9346_Lock);

        for (i = 0, read_addr = 0; i < eeprom_size / 4; i++)
                *(eeprom_cont + i) = rtl8169_vpd_read(dev, read_addr + i * 4);

        RTL_W8(Cfg9346, Cfg9346_Unlock);
        RTL_W8(Config1, RTL_R8(Config1) & ~VPDEnable);
        RTL_W8(Cfg9346, Cfg9346_Lock);

Martin

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