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:   Wed, 19 Jan 2022 07:39:02 -0800
From:   Jakub Kicinski <>
To:     Ido Schimmel <>
Cc:     Michal Kubecek <>,
        "" <>,,, Andrew Lunn <>
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) {
> 	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.

Powered by blists - more mailing lists