linux-kernel - Re: [RFC PATCH 0/6] nvmem: add block device 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]

Date:   Fri, 21 Jul 2023 12:08:56 +0100
From:   Daniel Golle <daniel@...rotopia.org>
To:     Ming Lei <ming.lei@...hat.com>
Cc:     Jens Axboe <axboe@...nel.dk>, Ulf Hansson <ulf.hansson@...aro.org>,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        Richard Weinberger <richard@....at>,
        Vignesh Raghavendra <vigneshr@...com>,
        Dave Chinner <dchinner@...hat.com>,
        Matthew Wilcox <willy@...radead.org>,
        Thomas Weißschuh <linux@...ssschuh.net>,
        Jan Kara <jack@...e.cz>, Damien Le Moal <dlemoal@...nel.org>,
        Min Li <min15.li@...sung.com>,
        Christian Loehle <CLoehle@...erstone.com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Hannes Reinecke <hare@...e.de>,
        Jack Wang <jinpu.wang@...os.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Yeqi Fu <asuk4.q@...il.com>, Avri Altman <avri.altman@....com>,
        Hans de Goede <hdegoede@...hat.com>,
        Ye Bin <yebin10@...wei.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Rafał Miłecki <rafal@...ecki.pl>,
        linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-mmc@...r.kernel.org, linux-mtd@...ts.infradead.org
Subject: Re: [RFC PATCH 0/6] nvmem: add block device NVMEM provider

On Fri, Jul 21, 2023 at 04:32:49PM +0800, Ming Lei wrote:
> On Wed, Jul 19, 2023 at 11:01:14PM +0100, 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 block devices 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.
> > 
> > This series is meant to open the discussion on how exactly the device tree
> > schema for block devices and partitions may look like, and even if using
> > the block layer to back the NVMEM device is at all the way to go -- to me
> > it seemed to be a good solution because it will be reuable e.g. for NVMe.
> 
> Just wondering why you don't use request_firmware() in drivers which consume
> the data, then the logic can be moved out of kernel, and you needn't to deal
> with device tree & block device.

The thing is: Why should the OS need to know about how to read
calibration to be fed into a wireless driver on a specific
hardware/firmware?

Or even worse: The MAC address of the main Ethernet interface? What if
for one of many possible reasons the extraction script in userland gets
broken and you would need to recover the system via SSH (because it's a
router or switch and doesn't even have any local console)?

Having information about the location of firmware artifacts be supplied
by the firmware (via device tree) seems to be the natural choice, and
also how it is done for devices booting off NOR or NAND flash by using
the NVMEM framework. Why should eMMC be the exception?

> 
> Or Android doesn't support udev and initrd?

Yes, sure, but then the OS ROM needs to know about and handle a lot of
very device-specific details in userland and if (unlike Android) the
same OS ROM should run on many devices that would mean it will have to
ship all of them in a huge initrd or root filesystem.

Also using userspace mechanics to acquire things as basic as a MAC
address seems overly complex and much more fragile than having the
firmware instruct the kernel via device tree to do so.

Hence, within the OpenWrt project, we've been working for years now to
push for Device Tree and lately for use of the NVMEM framework, exactly
to **reduce** the amount of hardware-specific knowledge in userland and
get rid of shell scripts acting as hotplug handlers for firmware
requests and such.