linux-kernel - Re: [RFC PATCH 1/4] init: move block device helpers from init/do

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:   Mon, 12 Dec 2022 22:48:12 -0800
From:   Christoph Hellwig <hch@...radead.org>
To:     Daniel Golle <daniel@...rotopia.org>
Cc:     Christoph Hellwig <hch@...radead.org>,
        Richard Weinberger <richard@....at>,
        Matthew Wilcox <willy@...radead.org>,
        Jens Axboe <axboe@...nel.dk>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        Chaitanya Kulkarni <kch@...dia.com>,
        Wolfram Sang <wsa+renesas@...g-engineering.com>,
        linux-block@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 1/4] init: move block device helpers from
 init/do_mounts.c

On Mon, Dec 12, 2022 at 11:02:33AM +0000, Daniel Golle wrote:
> The thing is that there isn't anything extraordinarily complex here,
> just dynamically partitioning a block device based on a well-known
> format.

Yes, but a completely non-standard format that nests inside an
partition.

> Using initramfs implies that we would need a 2nd copy of the standard C
> library and libfdt, both alone will already occupy more than just a
> single 64kB block of flash.

Why do you need libfdt?  And with a simple statically linked kpartx
you won't pull in much of libc either.

> I understand that from the point of view of
> classic x86 servers or even embedded devices with eMMC this seems
> negligible. However, keep in mind that a huge number of existing
> devices and also new designs of embedded devices often boot from just a
> few megabytes of NOR flash, and there every byte counts.

So I've worked quite a bit on really small deeply embedded systems,
and for those I wouldn't even think of using strange image formats
or the rather wasteful GPT partition format.
There we wouldn't dare to use paritions or weird image formats, but

> > What is the point of the uImage.FIT?
> 
> It is the format used by Das U-Boot, which is by far the most common
> bootloader found on small embedded devices running Linux.
> Is is already used by Das U-Boot to validate and load kernel,
> devicetree, initramfs, ... to RAM before launching Linux.
> I've included a link to the documentation[1] which gives insights
> regarding the motivation to create such a format.

That doesn't explain why you'd want to use it.  Nor how people
came up with it.

> In fact, that's only one out of three possible uses in which parsing
> the contained sub-image boundaries can be useful:
>  * On devices with NOR flash uImage.FIT is stored in an MTD partition,
>    hence the uImage.FIT partition parser (or small stackable block
>    driver) would then operate on top of /dev/mtdblockX.
> 
>  * On devices with NAND flash uImage.FIT is stored in a UBI volume,
>    hence in this case /dev/ubiblockX needs to be processed.

And all the mtdblock / ubiblock is due to the lack of a native
mtd/ubi backend for squashfs?  Why can't we take the block layer
out of the loop entirely?

> I hope this explains my motivation. Please ask should there by any
> doubts or if any of my explainations above are not clear.

None of this explains the silly nesting inside the GPT partition.
It is not needed for the any use cases and the root probem here.
Without that you could simply implement a parition format, with that
you get into crazy nesting behavior.  Note that it would have
any benefit over just not doing this silly image.

Maybe someone just needs to go back and come up wit ha scheme that
actually works and implement that in uboot as well.