netdev - Re: [PATCH 1/1] r8169: revert "read MAC address from EEPROM on 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-next>] [day] [month] [year] [list]

Message-ID: <20081026222224.GC24790@electric-eye.fr.zoreil.com>
Date:	Sun, 26 Oct 2008 23:22:24 +0100
From:	Francois Romieu <romieu@...zoreil.com>
To:	Krzysztof Halasa <khc@...waw.pl>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>, jgarzik@...ox.com,
	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Alistair John Strachan <alistair@...zero.co.uk>,
	Ivan Vecera <ivecera@...hat.com>,
	Chuck Ebbert <cebbert@...hat.com>,
	Petr Vandrovec <petr@...drovec.name>,
	Plamen Petrov <pvp-lsts@...ru.acad.bg>,
	Ilpo J?rvinen <ilpo.jarvinen@...sinki.fi>,
	"J.A. Magall?n" <jamagallon@....com>,
	Jiri Slaby <jirislaby@...il.com>,
	Simon Arlott <simon@...e.lp0.eu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Edward Hsu <edward_hsu@...ltek.com.tw>
Subject: Re: [PATCH 1/1] r8169: revert "read MAC address from EEPROM on
	init"

Krzysztof Halasa <khc@...waw.pl> :
[...]
> Ahh, just PCI VPD.
> 
> IMHO the above shouldn't hurt anyone, in theory. You only write to
> VPD_ADDR, and to change actual VPD data (i.e., EEPROM), you need to
> write to VPD_DATA.
> 
> Anyone should be allowed to do that even for unknown PCI devices
> without a problem.

Theorically, yes.

In practice I noticed rather different behaviors between a 8168b and
a 8110s when I tried accessing the eeprom through plain old bitbang
a few months ago (i.e. ok on the 8110, lots of zero on the 8168b).

> > -static void rtl_init_mac_address(struct rtl8169_private *tp,
> 
> > -	if (!(cfg1  & VPD)) {
> > -		if (netif_msg_probe(tp))
> > -			dev_info(&pdev->dev, "VPD access disabled, enabling\n");
> > -		RTL_W8(Cfg9346, Cfg9346_Unlock);
> > -		RTL_W8(Config1, cfg1 | VPD);
> > -		RTL_W8(Cfg9346, Cfg9346_Lock);
> 
> Now I wonder what do they say the above does exactly.
> Unfortunately the docs don't seem to be public.

Realtek's legal department has changed his mind :o(

>From what I had received beforehand:

RTL8169:  R/W Set to enable Vital Product Data. The VPD data is stored in
          93C46 or 93c56 from within offset 40h-7fh.

RTL8168C: R (huh ?) Set to enable Vital Product Data. Always 1.

[...]
> > -	if (netif_msg_probe(tp)) {
> > -		DECLARE_MAC_BUF(buf);
> > -
> > -		dev_info(&pdev->dev, "MAC address found in EEPROM: %s\n",
> > -			 print_mac(buf, mac));
> > -	}
> > -
> > -	if (is_valid_ether_addr(mac))
> > -		rtl_rar_set(tp, mac);
> > -}
> 
> No RTL_W8(Config1, cfg1 | ~VPD) to disable (perhaps R/W) access?

Apparently not. See above.

> Though obviously first reading a good address from the EEPROM and then
> erasing first 32 bits is a different story.

Yes.

> I wonder if changing the MAC address by hand works (using ifconfig, to
> arbitrary address).

It does. It can be quite sticky. That was the whole point of the
patch.

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