linux-kernel - Re: [PATCH v7] igb: Assign random MAC address instead of fail in case of invalid one

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: <72641fb1-f547-197b-b319-ce3b943b192d@intel.com>
Date:   Mon, 19 Dec 2022 10:25:27 -0800
From:   Jacob Keller <jacob.e.keller@...el.com>
To:     Alexander Duyck <alexander.duyck@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>
CC:     Jakub Kicinski <kuba@...nel.org>,
        Leon Romanovsky <leon@...nel.org>,
        "Lixue Liang" <lianglixuehao@....com>,
        <anthony.l.nguyen@...el.com>, <linux-kernel@...r.kernel.org>,
        <jesse.brandeburg@...el.com>, <davem@...emloft.net>,
        <edumazet@...gle.com>, <pabeni@...hat.com>,
        <netdev@...r.kernel.org>, <lianglixue@...atwall.com.cn>
Subject: Re: [PATCH v7] igb: Assign random MAC address instead of fail in case
 of invalid one

On 12/14/2022 3:17 PM, Alexander Duyck wrote:
> On Wed, Dec 14, 2022 at 1:43 PM Heiner Kallweit <hkallweit1@...il.com> wrote:
> As far as the discussion for module parameter vs something else. The
> problem with the driver is that it is monolithic so it isn't as if
> there is a devlink interface to configure a per-network parameter
> before the network portion is loaded. The module parameter is a
> compromise that should only be used to enable the workaround so that
> the driver can be loaded so that the EEPROM can then be edited. If
> anything, tying the EEPROM to ethtool is the issue. If somebody wants
> to look at providing an option to edit the EEPROM via devlink that
> would solve the issue as then the driver could expose the devlink
> interface to edit the EEPROM without having to allocate and register a
> netdev.

Right. Since igb only has netdev as the way to change the MAC or edit
the EEPROM, there is no way to fix this if the driver doesn't load.

Ideally the driver would instead still be able to register and expose an
interface (devlink?) that does not depend on the MAC, and when the MAC
is invalid it just would not register a netdevice. Another option might
me some method of a netdev to say "I don't have a valid MAC, so don't
allow me to do traffic"?

A global sysctl policy as discussed elsewhere in the thread also seems
reasonable to me, given that modifying the driver to expose devlink is a
lot more work. Of course we'd also need to check and get other drivers
to use the same global policy as well.

Thanks,
Jake