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] [day] [month] [year] [list]

Message-ID: <20220120093051.70845141@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
Date:   Thu, 20 Jan 2022 09:30:51 -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 Thu, 20 Jan 2022 09:54:21 +0200 Ido Schimmel wrote:
> > 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?  
> 
> Not sure what you mean by that (I believe they are already doing the
> right thing). Life is much easier for drivers that implement
> get_module_eeprom_by_page() because they only need to fetch the
> information user space is asking for. They need not perform any parsing
> of the data, unlike in the legacy callbacks.

I see, my concern was that overzealous driver or FW may try to validate
the page number rather than just performing the read.