netdev - Re: ethtool 5.16 release / ethtool -m bug fix

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: <20220119073902.507f568c@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
Date:   Wed, 19 Jan 2022 07:39:02 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Ido Schimmel <idosch@...sch.org>
Cc:     Michal Kubecek <mkubecek@...e.cz>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>, michel@...com,
        dcavalca@...com, Andrew Lunn <andrew@...n.ch>
Subject: Re: ethtool 5.16 release / ethtool -m bug fix

On Wed, 19 Jan 2022 11:45:41 +0200 Ido Schimmel wrote:
> On Tue, Jan 18, 2022 at 02:51:59PM -0800, Jakub Kicinski wrote:
> > Hi Michal!
> > 
> > Sorry to hasten but I'm wondering if there is a plan to cut the 5.16
> > ethtool release? Looks like there is a problem in SFP EEPROM parsing
> > code, at least with QSFP28s, user space always requests page 3 now.
> > This ends in an -EINVAL (at least for drivers not supporting the paged
> > mode).  
> 
> Jakub, are you sure you are dealing with QSFP and not SFP? I'm asking
> because I assume the driver in question is mlx5 that has this code in
> its implementation of get_module_eeprom_by_page():
> 
> ```
> switch (module_id) {
> case MLX5_MODULE_ID_SFP:
> 	if (params->page > 0)
> 		return -EINVAL;
> 	break;
> ```

Yup, it's a QSFP28 / SFF-8636, the report was with a different NIC.

> And indeed, ethtool(8) commit fc47fdb7c364 ("ethtool: Refactor
> human-readable module EEPROM output for new API") always asks for Upper
> Page 03h, regardless of the module type.
> 
> It is not optimal for ethtool(8) to ask for unsupported pages and I made
> sure it's not doing it anymore, but I believe it's wrong for the kernel
> to return an error. All the specifications that I'm aware of mandate
> that when an unsupported page is requested, the Page Select byte will
> revert to 0. That is why Upper Page 00h is always read-only.
> 
> For reference, see section 10.3 in SFF-8472, section 6.2.11 in SFF-8636
> and section 8.2.13 in CMIS.
> 
> Also, the entire point of the netlink interface is that the kernel can
> remain ignorant of the EEPROM layout and keep all the logic in user
> space.

The EINVAL came from fallback_set_params().

As far as I can see user space will call sff8636_show_dom() regardless
of what we return from the kernel, so returning first page again should
not confuse anything.. as long as the fields read from page 3 happen to
be 0 in page 0?

What about drivers which do implement get_module_eeprom_by_page? Can we
somehow ensure they DTRT and are consistent with the legacy / flat API?

> > By the looks of it - Ido fixed this in 6e2b32a0d0ea ("sff-8636: Request
> > specific pages for parsing in netlink path") but it may be too much code 
> > to backport so I'm thinking it's easiest for distros to move to v5.16.  
> 
> I did target fixes at 'ethtool' and features at 'ethtool-next', but I
> wasn't aware of this bug.