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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 15 Dec 2022 07:49:59 -0800 From: Alexander H Duyck <alexander.duyck@...il.com> To: 梁礼学 <lianglixuehao@....com> Cc: Heiner Kallweit <hkallweit1@...il.com>, Jakub Kicinski <kuba@...nel.org>, Leon Romanovsky <leon@...nel.org>, Tony Nguyen <anthony.l.nguyen@...el.com>, linux-kernel@...r.kernel.org, Jesse Brandeburg <jesse.brandeburg@...el.com>, David Miller <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Netdev <netdev@...r.kernel.org> Subject: Re: [PATCH v7] igb: Assign random MAC address instead of fail in case of invalid one On Thu, 2022-12-15 at 11:24 +0800, 梁礼学 wrote: > The module parameter method does bring some inconvenience to the user, > especially the parameter needs to be specified when the module is loaded. > But as alexander said, if the net device is not successfully registered, > the user has no chance to modify the invalid MAC address in the current EEPROM. > At present, the read/write of EEPROM is bundled with the net driver. > I am not sure if there is any other way to complete the modification of EEPROM > independently of the network driver; > > Is it necessary to bind the registration of net device to the judgment of invalid MAC? > I personally think that MAC configuration is not the capability or function of the device, > this should not affect the registration of the device; > Can the invalid MAC be judged in the up stage of the network device? > In this way, the net driver can continue to be loaded successfully, > and the MAC can be changed using ethtool, and it will not increase the difficulty of debugging for users. > > Thanks The problem is that the decision all depends on use case. For a small embedded device or desktop system it probably doesn't care as it will always just default to DHCP most likely anyway so it doesn't really care about maintaining a static MAC configuration. However the igb device covers a range of products including workstation and some server. The issue is that changing the MAC address on server setups can trigger significant issues depending on the setup as things like static IP reservations can be lost due to either a static DHCP reservation or sysconfig potentially being lost. I know on older redhat systems random MACs would lead to a buildup up sysconfig files as it would generate a new one every time the MAC changed. It is one of the reasons why Intel stopped using random MAC on VFs if I recall correctly. Lastly one thing that occurs to me is that there is support for providing a MAC address via eth_platform_get_mac_address() as some of the smaller embedded parts have an option to run without an EEPROM. I wonder if there isn't a way to work around this by providing a devicetree overlay on problematic systems.
Powered by blists - more mailing lists