netdev - Re: [PATCH] net: usb: r8152: Add MAC passthrough support for more Lenovo Docks

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:   Tue, 4 Jan 2022 18:07:15 +0100
From:   Henning Schild <henning.schild@...mens.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     Aaron Ma <aaron.ma@...onical.com>, <davem@...emloft.net>,
        <hayeswang@...ltek.com>, <tiwai@...e.de>,
        <linux-usb@...r.kernel.org>, <netdev@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] net: usb: r8152: Add MAC passthrough support for more
 Lenovo Docks

Am Tue, 4 Jan 2022 06:53:26 -0800
schrieb Jakub Kicinski <kuba@...nel.org>:

> On Tue, 4 Jan 2022 12:38:14 +0100 Henning Schild wrote:
> > This patch is wrong and taking the MAC inheritance way too far. Now
> > any USB Ethernet dongle connected to a Lenovo USB Hub will go into
> > inheritance (which is meant for docks).
> > 
> > It means that such dongles plugged directly into the laptop will do
> > that, or travel adaptors/hubs which are not "active docks".
> > 
> > I have USB-Ethernet dongles on two desks and both stopped working as
> > expected because they took the main MAC, even with it being used at
> > the same time. The inheritance should (if at all) only be done for
> > clearly identified docks and only for one r8152 instance ... not
> > all. Maybe even double checking if that main PHY is "plugged" and
> > monitoring it to back off as soon as it is.
> > 
> > With this patch applied users can not use multiple ethernet devices
> > anymore ... if some of them are r8152 and connected to "Lenovo" ...
> > which is more than likely!
> > 
> > Reverting that patch solved my problem, but i later went to
> > disabling that very questionable BIOS feature to disable things for
> > good without having to patch my kernel.
> > 
> > I strongly suggest to revert that. And if not please drop the
> > defines of 
> > > -		case DEVICE_ID_THINKPAD_THUNDERBOLT3_DOCK_GEN2:
> > > -		case DEVICE_ID_THINKPAD_USB_C_DOCK_GEN2:    
> > 
> > And instead of crapping out with "(unnamed net_device)
> > (uninitialized): Invalid header when reading pass-thru MAC addr"
> > when the BIOS feature is turned off, one might want to check
> > DSDT/WMT1/ITEM/"MACAddressPassThrough" which is my best for asking
> > the BIOS if the feature is wanted.  
> 
> Thank you for the report!
> 
> Aaron, will you be able to fix this quickly? 5.16 is about to be
> released.

If you guys agree with a revert and potentially other actions, i would
be willing to help. In any case it is not super-urgent since we can
maybe agree an regression and push it back into stable kernels.

I first wanted to place the report and see how people would react ...
if you guys agree that this is a bug and the inheritance is going "way
too far".

But i would only do some repairs on the surface, the feature itself is
horrific to say the least and i am very happy with that BIOS switch to
ditch it for good. Giving the MAC out is something a dock physically
blocking the original PHY could do ... but year ... only once and it
might be pretty hard to say which r8152 is built-in from the hub and
which is plugged in additionally in that very hub.
Not to mention multiple hubs of the same type ... in a nice USB-C chain.

MAC spoofing is something NetworkManager and others can take care of,
or udev ... doing that in the driver is ... spooky.

regards,
Henning