linux-kernel - Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree

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: Tue, 9 Jan 2024 15:33:55 +0100
From: Rasmus Villemoes <rasmus.villemoes@...vas.dk>
To: Masahiro Yamada <masahiroy@...nel.org>, Chen-Yu Tsai <wenst@...omium.org>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>,
 Laurent Pinchart <laurent.pinchart@...asonboard.com>,
 Simon Glass <sjg@...omium.org>, linux-arm-kernel@...ts.infradead.org,
 Ahmad Fatoum <a.fatoum@...gutronix.de>,
 U-Boot Mailing List <u-boot@...ts.denx.de>,
 Nicolas Schier <nicolas@...sle.eu>, Tom Rini <trini@...sulko.com>,
 Catalin Marinas <catalin.marinas@....com>, Jonathan Corbet <corbet@....net>,
 Nathan Chancellor <nathan@...nel.org>, Nick Terrell <terrelln@...com>,
 Will Deacon <will@...nel.org>, linux-doc@...r.kernel.org,
 linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org,
 workflows@...r.kernel.org
Subject: Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree

On 14/12/2023 08.33, Masahiro Yamada wrote:
> On Thu, Dec 14, 2023 at 3:12 PM Masahiro Yamada <masahiroy@...nel.org> wrote:
>>

> One more question to confirm if I can use this
> for my practical use-cases.
> 
> Is U-Boot able to handle FIT (includes kernel + DTs)
> and a separate initrd?
> 
>   # bootm  <fit-address>:<conf-name>  <ramdisk-address>
> 
> 
> Presumably, it would be difficult to inject initramdisk
> into image.fit later, so I am hoping bootm would work like that,
> but I did not delve into U-Boot code.

I recently had occasion to use this, and it actually already works
out-of-the-box, but perhaps it could be better documented. Though you
need not only the ramdisk address but also the size, as in
<addr>:<size>, and of course CONFIG_SUPPORT_RAW_INITRD.

My use case is bootstrapping: I have one FIT image (consisting of
kernel, dtbs and an initramfs) which is the one that will be written to
the target. But for bootstrapping, I (obviously) need to boot with a
different initramfs that contains the bootstrap logic. Since this
project uses fastboot, what I do is: upload the alternative initramfs,
move it out of the way ('cause fastboot only supports one single target
buffer), upload the FIT image, and "bootm $fitaddr $initrdaddr:$initrdsize".

> If it works, is it possible to verify the integrity of initrd?

No, I don't think so. In my case the FIT image is signed, and the kernel
and chosen dtb does get verified, but not the contents of the initrd.
I'm not sure how that should happen - in any case, in the fastboot case,
the host can run arbitrary shell commands so not much U-Boot can do.

Rasmus