linux-kernel - Re: [PATCH 0/8] block: implement NVMEM provider

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]

Message-ID: <6a59ac6e-cc1f-46de-92d7-f017082d99d2@acm.org>
Date: Fri, 22 Mar 2024 12:19:47 -0700
From: Bart Van Assche <bvanassche@....org>
To: Daniel Golle <daniel@...rotopia.org>
Cc: Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>, Ulf Hansson <ulf.hansson@...aro.org>,
 Jens Axboe <axboe@...nel.dk>, Dave Chinner <dchinner@...hat.com>,
 Jan Kara <jack@...e.cz>, Thomas Weißschuh
 <linux@...ssschuh.net>, Damien Le Moal <dlemoal@...nel.org>,
 Li Lingfeng <lilingfeng3@...wei.com>, Christian Brauner
 <brauner@...nel.org>, Christian Heusel <christian@...sel.eu>,
 Min Li <min15.li@...sung.com>, Adrian Hunter <adrian.hunter@...el.com>,
 Avri Altman <avri.altman@....com>, Hannes Reinecke <hare@...e.de>,
 Christian Loehle <CLoehle@...erstone.com>, Bean Huo <beanhuo@...ron.com>,
 Yeqi Fu <asuk4.q@...il.com>, Victor Shih <victor.shih@...esyslogic.com.tw>,
 Christophe JAILLET <christophe.jaillet@...adoo.fr>,
 Dominique Martinet <dominique.martinet@...ark-techno.com>,
 "Ricardo B. Marliere" <ricardo@...liere.net>, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-mmc@...r.kernel.org,
 linux-block@...r.kernel.org
Subject: Re: [PATCH 0/8] block: implement NVMEM provider

On 3/22/24 11:02, Daniel Golle wrote:
> On Fri, Mar 22, 2024 at 10:52:17AM -0700, Bart Van Assche wrote:
>> On 3/21/24 12:31, Daniel Golle wrote:
>>> On embedded devices using an eMMC it is common that one or more (hw/sw)
>>> partitions on the eMMC are used to store MAC addresses and Wi-Fi
>>> calibration EEPROM data.
>>>
>>> Implement an NVMEM provider backed by a block device as typically the
>>> NVMEM framework is used to have kernel drivers read and use binary data
>>> from EEPROMs, efuses, flash memory (MTD), ...
>>>
>>> In order to be able to reference hardware partitions on an eMMC, add code
>>> to bind each hardware partition to a specific firmware subnode.
>>>
>>> Overall, this enables uniform handling across practially all flash
>>> storage types used for this purpose (MTD, UBI, and now also MMC).
>>>
>>> As part of this series it was necessary to define a device tree schema
>>> for block devices and partitions on them, which (similar to how it now
>>> works also for UBI volumes) can be matched by one or more properties.
>>
>> Since this patch series adds code that opens partitions and reads
>> from partitions, can that part of the functionality be implemented in
>> user space? There is already a mechanism for notifying user space about
>> block device changes, namely udev.
> 
> No. Because it has to happen (e.g. for nfsroot to work) before
> userland gets initiated: Without Ethernet MAC address (which if often
> stored at some raw offset on a partition or hw-partition of an eMMC),
> we don't have a way to use nfsroot (because that requires functional
> Ethernet), hence userland won't come up. It's a circular dependency
> problem which can only be addressed by making sure that everything
> needed for Ethernet to come up is provided by the kernel **before**
> rootfs (which can be nfsroot) is mounted.

How about the initial RAM disk? I think that's where code should occur
that reads calibration data from local storage.

Thanks,

Bart.