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  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 <>
To:     "Limonciello, Mario" <>,
        Henning Schild <>
Cc:     Jakub Kicinski <>,
        Kai-Heng Feng <>,
        Andrew Lunn <>, Oliver Neukum <>,
        "" <>,
        "" <>,
        "" <>,
        "" <>,
        "" <>
Subject: Re: [PATCH 1/3 v3] net: usb: r8152: Check used MAC passthrough

On 1/13/22 03:27, Limonciello, Mario wrote:
> [Public]
>> -----Original Message-----
>> From: Henning Schild <>
>> Sent: Wednesday, January 12, 2022 13:21
>> To: Limonciello, Mario <>
>> Cc: Jakub Kicinski <>; Kai-Heng Feng
>> <>; Andrew Lunn <>; Oliver
>> Neukum <>; Aaron Ma <>; linux-
>> 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" <>:
>>> 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.


>> regards,
>> Henning

Powered by blists - more mailing lists