linux-kernel - Re: [RFC PATCH 6/6] 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: <ZLqIvuK2EX2hROJo@makrotopia.org>
Date:   Fri, 21 Jul 2023 14:31:42 +0100
From:   Daniel Golle <daniel@...rotopia.org>
To:     Christoph Hellwig <hch@...radead.org>
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>,
        Ming Lei <ming.lei@...hat.com>, 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 6/6] block: implement NVMEM provider

On Thu, Jul 20, 2023 at 11:35:55PM -0700, Christoph Hellwig wrote:
> > +static int blk_nvmem_reg_read(void *priv, unsigned int from,
> > +			      void *val, size_t bytes)
> > +{
> > +	pgoff_t f_index = from >> PAGE_SHIFT;
> > +	struct address_space *mapping;
> > +	struct blk_nvmem *bnv = priv;
> > +	size_t bytes_left = bytes;
> > +	struct folio *folio;
> > +	unsigned long offs, to_read;
> > +	void *p;
> 
> Btw, this function really should be using kern_read on a file
> using filp_open instead of poking into block device internals.

Unfortunately filp_open requires a device inode on a filesystem to be
able to open a block device. What if the root filesystem has not yet
been mounted, or even requires NVMEM (let's say for the Ethernet MAC
address to be known for a nfsroot, nbd or iSCSI to work) to be
available first?

Can you imagine we could implement something like filp_open_bdev which
takes a (struct block_device *) as parameter instead of (const char *)?

That would allow the driver to open and read from the block device
before any filesystems (incl. /dev) become ready.

> That way you can even have a generic file provider that works
> on anything that can be read from.
> 

While this could also be useful, it doesn't fulfil the requirement of
making NVMEM available as early as possible for other drivers to use,
e.g. for the Ethernet MAC address.

And it would also heavily deviate from how things work with other types
of flash storage typically used in embedded Linux devices such as SPI
NOR or NAND flash which is represented as MTD device.

Sidenote: block2mtd is also not an option because one cannot reference
block2mtd devices in device tree, hence they cannot serve as NVMEM
providers.