netdev - Re: [PATCH net-next] ethtool: Macro definition for SFF-8436/8636 Memory map max sizes

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]

Date:	Sat, 11 Jun 2016 19:26:48 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	vidya@...ulusnetworks.com
Cc:	bwh@...nel.org, netdev@...r.kernel.org, roopa@...ulusnetworks.com
Subject: Re: [PATCH net-next] ethtool: Macro definition for SFF-8436/8636
 Memory map max sizes

From: Vidya Sagar Ravipati <vidya@...ulusnetworks.com>
Date: Sat, 11 Jun 2016 16:22:38 -0700

> As part of ethtool application, application is requesting  the drivers
> to provide the supported eeprom size to allocate memory buffer for
> getting complete dump.

And the right way to do that is the driver requests the eeprom info
with a buffer size of zero, then the driver fills in the size field
for what the size actually is.

Then the application can allocate the proper buffer size and rerun
the eeprom request.

Putting endless values for each and every eeprom type a device has is
just rediculous.

I'm not going to continue promoting this broken and unscalable scheme,
we have to fix this.