netdev - RE: [PATCH 1/3 v3] net: usb: r8152: Check used MAC passthrough address

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]
Message-ID: <DM4PR12MB516889A458A16D89D4562CA7E2529@DM4PR12MB5168.namprd12.prod.outlook.com>
Date:   Wed, 12 Jan 2022 19:27:50 +0000
From:   "Limonciello, Mario" <Mario.Limonciello@....com>
To:     Henning Schild <henning.schild@...mens.com>
CC:     Jakub Kicinski <kuba@...nel.org>,
        Kai-Heng Feng <kai.heng.feng@...onical.com>,
        Andrew Lunn <andrew@...n.ch>, Oliver Neukum <oneukum@...e.com>,
        Aaron Ma <aaron.ma@...onical.com>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "hayeswang@...ltek.com" <hayeswang@...ltek.com>,
        "tiwai@...e.de" <tiwai@...e.de>
Subject: RE: [PATCH 1/3 v3] net: usb: r8152: Check used MAC passthrough
 address

[Public]

> -----Original Message-----
> From: Henning Schild <henning.schild@...mens.com>
> Sent: Wednesday, January 12, 2022 13:21
> To: Limonciello, Mario <Mario.Limonciello@....com>
> Cc: Jakub Kicinski <kuba@...nel.org>; Kai-Heng Feng
> <kai.heng.feng@...onical.com>; Andrew Lunn <andrew@...n.ch>; Oliver
> Neukum <oneukum@...e.com>; Aaron Ma <aaron.ma@...onical.com>; linux-
> usb@...r.kernel.org; netdev@...r.kernel.org; davem@...emloft.net;
> hayeswang@...ltek.com; tiwai@...e.de
> Subject: Re: [PATCH 1/3 v3] net: usb: r8152: Check used MAC passthrough
> address
> 
> Am Tue, 11 Jan 2022 11:10:52 -0600
> schrieb "Limonciello, Mario" <mario.limonciello@....com>:
> 
> > On 1/11/2022 11:06, Jakub Kicinski wrote:
> > > On Tue, 11 Jan 2022 10:54:50 -0600 Limonciello, Mario wrote:
> > >>> Also knowing how those OSes handle the new docks which don't have
> > >>> unique device IDs would obviously be great..
> > >>
> > >> I'm sorry, can you give me some more context on this?  What unique
> > >> device IDs?
> > >
> > > We used to match the NICs based on their device ID. The USB NICs
> > > present in docks had lenovo as manufacturer and a unique device ID.
> > > Now reportedly the new docks are using generic realtek IDs so we
> > > have no way to differentiate "blessed" dock NICs from random USB
> > > dongles, and inheriting the address to all devices with the generic
> > > relatek IDs breaks setups with multiple dongles, e.g. Henning's
> > > setup. > If we know of a fuse that can be read on new docks that'd
> > > put us back in more comfortable position. If we need to execute
> > > random heuristics to find the "right NIC" we'd much rather have
> > > udev or NetworkManager or some other user space do that according
> > > to whatever policy it chooses.
> >
> > I agree - this stuff in the kernel isn't supposed to be applying to
> > anything other than the OEM dongles or docks.  If you can't identify
> > them they shouldn't be in here.
> 
> Not sure we can really get to a proper solution here. The one revert
> for Lenovo will solve my very issue. And on top i was lucky enough to
> being able to disable pass-thru in the BIOS.
> 
> From what the Lenovo vendor docs seem to suggest it is about PXE ...
> meaning the BIOS will do the spoofing, how it does that is unclear. Now
> an OS can try to keep it up but probably should not try to do anything
> on its own ... or do the additional bits in user-space and not the
> kernel.
> 
> Thinking about PXE we do not just have the kernel, but also multiple
> potential bootloaders. All would need to inherit the spoofed MAC from a
> potential predecessor having applied spoofing, and support USB and
> network ... that is not realistic!
> 
> Going back to PXE ... says nothing about OS operation really. Say a
> BIOS decides to spoof when booting ... that say nothing on how to deal
> with hot-plugged devices which die BIOS did not even see. But we have
> code for such hot-plug spoofing in the kernel .. where vendors like
> Lenovo talk about PXE (only?)

Something that would probably be interesting to check is whether the
BIOS uses pass through MAC on anything as well or it has some criteria
that decides to apply it that the kernel doesn't know about.

> 
> The whole story seems too complicated and not really explained or
> throught through. If the vendors can explain stuff the kernel can
> probably cater ... but user-land would still be the better place.
> 
> I will not push for more reverts. But more patches in the direction
> should be questioned really hard! And even if we get "proper device
> matching" we will only cater for "vendor lock-in". It is not clear why
> that strange feature will only apply if the dock if from the same
> vendor as the laptop. Applying it on all USB NICs is clearly going too
> far, that will only work with IT department highlander policies like
> "there must only be one NIC".
> 
> So from my point it is solved with the one Lenovo-related revert. Any
> future pass-thru patches get a NACK and any reverts targeting other
> vendors get an ACK. But feel free to Cc me when such things happen in
> the future.
> 

KH & Aaron - can you please talk to Lenovo about making sure that there
is a way to distinguish between devices that should get pass through or
shouldn't and to document that?  

I think that a policy that it should be a NACK for anything else general
makes sense.

> regards,
> Henning