linux-kernel - Re: 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-prev] [thread-next>] [day] [month] [year] [list]

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



On 22/09/2022 11:23, Miquel Raynal wrote:
> 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.

Could you explain the userspace side use-case?

> 
> 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

we had this discussed this in many instances and this is some thing we 
would desire to have but we never got it moving forward.

> contribution? I guess it would also be a useful debug tool anyway (and
> might very well be moved somewhere else than in /sys).

getting sysfs working correctly in sync with userspace might be tricky 
in this particular case as we will be creating cells after the provider 
driver is created.

debugfs on the other hand is more doable.

--srini
> 
> Thanks for your time,
> Miquèl