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
| ||
|
Message-ID: <de684c19-7a84-ac7c-0019-31c253d89a5f@canonical.com> Date: Thu, 13 Jan 2022 11:23:44 +0800 From: Aaron Ma <aaron.ma@...onical.com> To: "Limonciello, Mario" <Mario.Limonciello@....com>, 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>, "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 On 1/13/22 03:27, Limonciello, Mario wrote: > [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. Sorry for my previous patch. Before made that patch I already discussed with Lenovo. And didn't get any other opinion. The solution is from a discussion with them. This info had been forward to them too. Aaron > >> regards, >> Henning
Powered by blists - more mailing lists