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: <20220104120027.611f8830@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
Date:   Tue, 4 Jan 2022 12:00:27 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Henning Schild <henning.schild@...mens.com>
Cc:     Aaron Ma <aaron.ma@...onical.com>, <davem@...emloft.net>,
        <hayeswang@...ltek.com>, <tiwai@...e.de>,
        <linux-usb@...r.kernel.org>, <netdev@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] net: usb: r8152: Add MAC passthrough support for more
 Lenovo Docks

On Tue, 4 Jan 2022 19:34:55 +0100 Henning Schild wrote:
> Am Wed, 5 Jan 2022 01:40:42 +0800
> schrieb Aaron Ma <aaron.ma@...onical.com>:
> > Yes, it's expected to be a mess if multiple r8152 are attached to
> > Lenovo USB-C/TBT docks. The issue had been discussed for several
> > times in LKML. Either lose this feature or add potential risk for
> > multiple r8152.
> > 
> > The idea is to make the Dock work which only ship with one r8152.
> > It's really hard to say r8152 is from dock or another plugin one.
> > 
> > If revert this patch, then most users with the original shipped dock
> > may lose this feature. That's the problem this patch try to fix.  
> 
> I understand that. But i would say people can not expect such a crap
> feature on Linux, or we really need very good reasoning to cause MAC
> collisions with the real PHY and on top claim ETOOMANY of the dongles.
> 
> The other vendors seem to check bits of the "golden" dongle. At least
> that is how i understand BD/AD/BND_MASK
> 
> How about making it a module param and default to off, and dev_warn if
> BIOS has it turned on. That sounds like a reasonable compromise and
> whoever turns it on twice probably really wants it. (note that BIOS
> defaults to on ... so that was never intended by users, and corporate
> users might not be allowed/able to turn that off)
> 
> MACs change ... all the time, people should use radius x509. The
> request is probably coming from corporate users, and they are all on a
> zero trust journey and will eventually stop relying on MACs anyways.
> 
> And if ubuntu wants to cater by default, there can always be an udev
> rule or setting that module param to "on".

Let's split the problem into the clear regression caused by the patch
and support of the feature on newer docks. I think we should fix the
regression ASAP (the patch has also been backported to 5.15, so it's
going to get more and more widely deployed). Then we can worry about
the MAC addr copy on newer docks and the feature in a wider context.
Is there really nothing in the usb info of the r8152 instance to
indicate that it's part of the dock? Does the device have EEPROM which
could contain useful info, maybe?

> > For now I suggest to disable it in BIOS if you got multiple r8152.
> > 
> > Let me try to make some changes to limit this feature in one r8152.  
> 
> Which one? ;) And how to deal with the real NIC once you picked one?
> Looking forward, please Cc me.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ