linux-kernel - Exposing nvmem cells to userspace?

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

Date:   Thu, 22 Sep 2022 12:23:47 +0200
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
Cc:     Robert Marko <robert.marko@...tura.hr>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        linux-kernel@...r.kernel.org
Subject: Exposing nvmem cells to userspace?

Hello Srinivas,

I am currently looking at the Open Compute Project ONIE Tlv tables in
modern networking hardware. Thanks to the specification being available
for many years and rather easy to implement, those tables are already
present in many switches. Manufacturers just have to provide a small
storage medium exposing factory-related information (manufacturer, date,
serial#, mac addresses, etc) in Type-Length-Value fields, as well
as their own extensions if they want. These tables are common, but
there is currently no shared decoding logic, each provider maintaining
its own internally.

I am currently looking for upstreaming an nvmem layout driver for
exposing the standard nvmem cells. This way, Ethernet drivers might eg.
take the base MAC address from there. But I feel like there is
something missing, because the vendor name, the device version, the
serial number or any other information available in these tables might
also very well be used by the userspace rather than the kernel drivers
only.

Thus, I was wondering if there was some ongoing work to make these
cells available to userspace (in /sys maybe?) or if this had already
been discussed somewhere. Otherwise, would you be open to such a
contribution? I guess it would also be a useful debug tool anyway (and
might very well be moved somewhere else than in /sys).

Thanks for your time,
Miquèl