Re: Problem with U-boot | Configuration Signature not being checked while booting

From: Tom Rini <trini@konsulko.com>
To: Moiz Imtiaz <moizimtiaz1@gmail.com>
Cc: Simon Glass <sjg@chromium.org>,
	Mark Kettenis <mark.kettenis@xs4all.nl>,
	U-Boot Mailing List <u-boot@lists.denx.de>,
	moiz.imtiaz@skyelectric.com,
	Jehannaz Khan <jehannazkhan@skyelectric.com>
Subject: Re: Problem with U-boot | Configuration Signature not being checked while booting
Date: Wed, 15 Sep 2021 09:02:53 -0400	[thread overview]
Message-ID: <20210915130253.GT12964@bill-the-cat> (raw)
In-Reply-To: <CAMHoVnqEZOdtmD_RoGuf4UjEuY79qMA46yMHEN+NPE7ihWJptA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2358 bytes --]

On Mon, Sep 13, 2021 at 01:45:56AM +0500, Moiz Imtiaz wrote:

> Thanks a lot Tom and U-boot Team,
> 
> What I did is that I made a control FDT (with Public_key and
> signature_node) and replaced the default dtb (bcm2711-rpi-4-b.dtb) in the
> boot directory of rpi_4-b(the board I am using) with the Control FDT
> 
> I compiled U-boot with "Config_OF_BOARD" and thought that since the pi
> second stage bootloader is gonna decide what dtb to use, how about
> replacing the default with our Contro FDT and it worked :)
> 
> [image: image.png]
> 
> It's like when I will be copying u-boot.bin in the /boot directory I will
> replace the default dtb with the Control FDT. If there is any concern with
> the above implementation from a security perspective (i.e manually
> replacing the default dtb of pi with control FDT), please let me know so
> that I can improve it. I am completely open to suggestions.
> 
> I also checked by modifying the config kernel hash and it throw rejection
> and didn't boot up.
> [image: changing_the_hash_verfication.png]
> 
> Kudos on the awesome writeup
> <https://github.com/u-boot/u-boot/blob/master/doc/uImage.FIT/beaglebone_vboot.txt>
> of
> manual verification by modifying the hash, saved me a couple of hours of
> googling :D

Nice!  If you want to write something up extending the documentation on
how you made this work for Pi it would be much appreciated.

> Also, one quick question, why do we not accept boot scripts with FIT
> enabled? I really like the idea of disabling legacy image support with FIT
> enabled but what is the recommended way of achieving boot scripts action
> then, if we won't allow boot script for e.g loading the FIT image in memory
> and then booting it up with bootm?
> Currently, I am using the following in my boot script.
> 
> setenv bootargs 8250.nr_uarts=1 console=ttyS0,115200 root=/dev/mmcblk0p2
> > rootwait rw;
> > fatload mmc 0:1 0x20000000 image.itb;
> > bootm 0x20000000;
> 
> 
> Again, thanks a lot and appreciate your input and suggestions.

I believe the general reason is that we want to have the vboot build as
locked down as possible.  You should be able to embed the bootargs in to
the FIT image, if you don't need to support some sort of A/B rootfs
scheme, or in to the default U-Boot environment otherwise.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]