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