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: <20220112202125.105d4c58@md1za8fc.ad001.siemens.net>
Date:   Wed, 12 Jan 2022 20:21:25 +0100
From:   Henning Schild <henning.schild@...mens.com>
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?)

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.

regards,
Henning