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

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

[Moiz Imtiaz]

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

Hope you are doing well and everything is going good at your end. I am
using Raspi 4B and Compute Model 4 and trying to configure U-boot with
Verified boot support, *but while booting the signing of the configuration
is not being checked*. I am using the latest master branch from GitHub.
<https://github.com/u-boot/u-boot>

We have checked the signature verification via the *"fit_check_sign"
*utility that
comes with u-boot and it does verify the configuration of the signature so,
I am sure that the image is signed properly and the Control FDT is good as
well.

[image: fit_check_sign.png]

but while booting, it doesn't check the signature of the configuration. It
should be showing "*Verifying Hash Integrity ... sha1,rsa2048:dev+ OK*"
[image: image.png]

*I believe that maybe I am not adding Control FDT in the U-boot binary
properly.* Following is the command that I am using to add control FDT to
U-boot.

$ make EXT_DTB=bcm2711-rpi-4-b-pubkey.dtb -j8
I have also tried
$ make DEV_TREE_BIN=bcm2711-rpi-4-b-pubkey.dtb -j8

The bytes size of the u-boot.bin and u-boot-nodtb.bin after using both the
above commands is the same.

Attached is the FIT source file,  rpi_4_defconfig and the control FDT file.
Also, the following has been added in configs/rpi_4_defconfig.

CONFIG_OF_CONTROL=y
CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_RSA=y

*Can you please help me with how to add Control FDT to the U-boot.bin
binary or what can be the reason that it isn't checking the signature of
the configuration while booting? Any kind of help would be really
appreciated.*

[-- Attachment #2: rpi_4_defconfig --]
[-- Type: application/octet-stream, Size: 1613 bytes --]

CONFIG_ARM=y
CONFIG_ARCH_BCM283X=y
CONFIG_SYS_TEXT_BASE=0x00080000
CONFIG_TARGET_RPI_4=y
CONFIG_SYS_MALLOC_F_LEN=0x2000
CONFIG_ENV_SIZE=0x4000
CONFIG_DISTRO_DEFAULTS=y
CONFIG_OF_BOARD_SETUP=y
CONFIG_USE_PREBOOT=y
CONFIG_PREBOOT="pci enum; usb start;"
# CONFIG_DISPLAY_CPUINFO is not set
# CONFIG_DISPLAY_BOARDINFO is not set
CONFIG_MISC_INIT_R=y
CONFIG_SYS_PROMPT="U-Boot> "
CONFIG_CMD_DFU=y
CONFIG_CMD_GPIO=y
CONFIG_CMD_MMC=y
CONFIG_CMD_PCI=y
CONFIG_CMD_USB=y
CONFIG_CMD_FS_UUID=y
CONFIG_OF_BOARD=y
CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
CONFIG_TFTP_TSIZE=y
CONFIG_DM_DMA=y
CONFIG_DFU_MMC=y
CONFIG_SYS_DFU_DATA_BUF_SIZE=0x100000
CONFIG_SYS_DFU_MAX_FILE_SIZE=0x200000
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_SDMA=y
CONFIG_MMC_SDHCI_BCM2835=y
CONFIG_DM_ETH=y
CONFIG_BCMGENET=y
CONFIG_PCI=y
CONFIG_PCI_BRCMSTB=y
CONFIG_PINCTRL=y
# CONFIG_PINCTRL_GENERIC is not set
CONFIG_DM_RESET=y
CONFIG_DM_RNG=y
CONFIG_RNG_IPROC200=y
# CONFIG_REQUIRE_SERIAL_CONSOLE is not set
CONFIG_USB=y
CONFIG_DM_USB_GADGET=y
CONFIG_USB_XHCI_HCD=y
CONFIG_USB_XHCI_PCI=y
CONFIG_USB_KEYBOARD=y
CONFIG_USB_GADGET=y
CONFIG_USB_GADGET_MANUFACTURER="FSL"
CONFIG_USB_GADGET_VENDOR_NUM=0x0525
CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
CONFIG_USB_GADGET_DWC2_OTG=y
CONFIG_USB_GADGET_DOWNLOAD=y
CONFIG_DM_VIDEO=y
# CONFIG_VIDEO_BPP8 is not set
# CONFIG_VIDEO_BPP16 is not set
CONFIG_SYS_WHITE_ON_BLACK=y
CONFIG_CONSOLE_SCROLL_LINES=10
CONFIG_PHYS_TO_BUS=y
CONFIG_OF_LIBFDT_OVERLAY=y
CONFIG_CMD_BOOTI=y
CONFIG_ENABLE_VBOOT=y
CONFIG_RSA=y
CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_OF_CONTROL=y

[-- Attachment #3: image.its --]
[-- Type: application/octet-stream, Size: 1153 bytes --]

/dts-v1/;
/ {
    description = "RPi FIT Image";
    #address-cells = <1>;
    images {
        kernel-1 {
            description = "default kernel";
            data = /incbin/("/media/dodain/BOOT-A/kernel8.img");
            type = "kernel";
            arch = "arm64";
            os = "linux";
            compression = "none";
            load =  <0x00080000>;
            entry = <0x00080000>;
            hash-1 {
                algo = "sha1";
            };
        };
        fdt-1 {
            description = "device tree";
            data = /incbin/("/media/dodain/BOOT-A/bcm2711-rpi-4-b.dtb");
            type = "flat_dt";
            arch = "arm64";
            compression = "none";
            hash-1 {
                algo = "sha1";
            };
        };
    };
    configurations {
        default = "config-1";
        config-1 {
            description = "default configuration";
            kernel = "kernel-1";
            fdt = "fdt-1";
            signature-1 {
                algo = "sha1,rsa2048";
                key-name-hint = "dev";
                sign-images = "fdt", "kernel";
            };
        };
    };
};

[-- Attachment #4: bcm2711-rpi-4-b-pubkey.dtb --]
[-- Type: application/octet-stream, Size: 50114 bytes --]

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

[Simon Glass]

+Tom Rini

Hi Moiz,

On Thu, 9 Sept 2021 at 14:21, Moiz Imtiaz <moizimtiaz1@gmail.com> wrote:
>
> Hope you are doing well and everything is going good at your end. I am using Raspi 4B and Compute Model 4 and trying to configure U-boot with Verified boot support, but while booting the signing of the configuration is not being checked. I am using the latest master branch from GitHub.
>
> We have checked the signature verification via the "fit_check_sign" utility that comes with u-boot and it does verify the configuration of the signature so, I am sure that the image is signed properly and the Control FDT is good as well.
>
>
>
> but while booting, it doesn't check the signature of the configuration. It should be showing "Verifying Hash Integrity ... sha1,rsa2048:dev+ OK"
>
>
> I believe that maybe I am not adding Control FDT in the U-boot binary properly. Following is the command that I am using to add control FDT to U-boot.
>
> $ make EXT_DTB=bcm2711-rpi-4-b-pubkey.dtb -j8
> I have also tried
> $ make DEV_TREE_BIN=bcm2711-rpi-4-b-pubkey.dtb -j8
>
> The bytes size of the u-boot.bin and u-boot-nodtb.bin after using both the above commands is the same.
>
> Attached is the FIT source file,  rpi_4_defconfig and the control FDT file. Also, the following has been added in configs/rpi_4_defconfig.
>
> CONFIG_OF_CONTROL=y
> CONFIG_FIT=y
> CONFIG_FIT_SIGNATURE=y
> CONFIG_RSA=y
>
> Can you please help me with how to add Control FDT to the U-boot.bin binary or what can be the reason that it isn't checking the signature of the configuration while booting? Any kind of help would be really appreciated.

There is an example of this flow in the sandbox vboot test. There is
also an example for Beaglebone Black in
doc/uImage.FIT/beaglebone_vboot.txt

I wonder if rpi is not using the devicetree compiled with U-Boot, but
instead one provided by the earlier-stage firmware? Can you check that
the required 'signature' node is present? You can use the 'fdt'
command in U-Boot to look at it.

Looking at rpi_4 it uses CONFIG_OF_BOARD which means it has its own
special way of getting the devicetree into U-Boot. The older boards
use CONFIG_OF_EMBED which is actually not even allowed in production
boards....

Also you may need the -r argument to mkimage to mark the key as required.

Regards,
Simon

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

[Moiz Imtiaz]

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

Hi Simon,

Thanks for the reply.  I already followed the steps mentioned in
"doc/uImage.FIT/beaglebone_vboot.txt".

>I wonder if rpi is not using the devicetree compiled with U-Boot, but
instead one provided by the earlier-stage firmware?

Not sure, but seems like this is the case. I checked and there isn't any
dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to
add the dtb and other dts dtsi
<https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom>files
from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and
CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and
it would just give a blank screen*. I wonder why there isn't any device
tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by
RPI4?

and if I tried CONFIG_OF_BOARD (the default rpi_4 configuration), it will
take us back to the initial problem, signature not being checked.

> Can you check that the required 'signature' node is present? You can use
the 'fdt' command in U-Boot to look at it.
I tried the "fdt checksign" but it didn't return anything. Screenshot
inlined, image.itb is the fit image. If I am not doing it wrong, or some
other commands needs to be executed, please let me know.

[image: image.png]

Just for reference, I am inlining the steps I followed:
1. clone the master branch of u-boot.
2. Add FIT, RSA & SIGNATURE support to rpi_4_defconfig
3. Build with 64-bit architecture. (CROSS_COMPILE=aarch64-linux-gnu-)
4. Build U-boot  ($make -j8)
5. copy device tree and make a clone by appending pubkey to it.
$ cp bcm2711-rpi-4-b.dtb bcm2711-rpi-4-b-pubkey.dtb
6. generate the keys and make .its file and sign it with the following
command:
mkdir keys
openssl genrsa -F4 -out keys/dev.key 2048
 openssl req -batch -new -x509 -key keys/dev.key -out keys/dev.crt
mkimage -f image.its -K bcm2711-rpi-4-b-pubkey.dtb -k keys -r image.itb
7. rebuild uboot with control FDT (bcm2711-rpi-4-b-pubkey.dtb)
$make EXT_DTB=bcm2711-rpi-4-b-pubkey.dtb -j8
8. Copy u-boot.bin and image.itb to boot partition.

But since I had CONFIG_OF_BOARD set, I am assuming it didn't add control
FDT into u-boot.bin as byte size for both binaries (u-boot.bin &
u-boot-nodtb.bin) was the same. I tried to concatenate them with cat but
while booting, U-Boot still didn't read the Control FDT.

Can anyone please help with enabling verified boot (signature check)
support for Raspberry Pi4. It's a very mainstream board and support for it
would be great to have. I am willing to contribute, whatever I can.

Best,
Moiz Imtiaz

On Fri, Sep 10, 2021 at 9:37 AM Simon Glass <sjg@chromium.org> wrote:

> +Tom Rini
>
> Hi Moiz,
>
> On Thu, 9 Sept 2021 at 14:21, Moiz Imtiaz <moizimtiaz1@gmail.com> wrote:
> >
> > Hope you are doing well and everything is going good at your end. I am
> using Raspi 4B and Compute Model 4 and trying to configure U-boot with
> Verified boot support, but while booting the signing of the configuration
> is not being checked. I am using the latest master branch from GitHub.
> >
> > We have checked the signature verification via the "fit_check_sign"
> utility that comes with u-boot and it does verify the configuration of the
> signature so, I am sure that the image is signed properly and the Control
> FDT is good as well.
> >
> >
> >
> > but while booting, it doesn't check the signature of the configuration.
> It should be showing "Verifying Hash Integrity ... sha1,rsa2048:dev+ OK"
> >
> >
> > I believe that maybe I am not adding Control FDT in the U-boot binary
> properly. Following is the command that I am using to add control FDT to
> U-boot.
> >
> > $ make EXT_DTB=bcm2711-rpi-4-b-pubkey.dtb -j8
> > I have also tried
> > $ make DEV_TREE_BIN=bcm2711-rpi-4-b-pubkey.dtb -j8
> >
> > The bytes size of the u-boot.bin and u-boot-nodtb.bin after using both
> the above commands is the same.
> >
> > Attached is the FIT source file,  rpi_4_defconfig and the control FDT
> file. Also, the following has been added in configs/rpi_4_defconfig.
> >
> > CONFIG_OF_CONTROL=y
> > CONFIG_FIT=y
> > CONFIG_FIT_SIGNATURE=y
> > CONFIG_RSA=y
> >
> > Can you please help me with how to add Control FDT to the U-boot.bin
> binary or what can be the reason that it isn't checking the signature of
> the configuration while booting? Any kind of help would be really
> appreciated.
>
> There is an example of this flow in the sandbox vboot test. There is
> also an example for Beaglebone Black in
> doc/uImage.FIT/beaglebone_vboot.txt
>
> I wonder if rpi is not using the devicetree compiled with U-Boot, but
> instead one provided by the earlier-stage firmware? Can you check that
> the required 'signature' node is present? You can use the 'fdt'
> command in U-Boot to look at it.
>
> Looking at rpi_4 it uses CONFIG_OF_BOARD which means it has its own
> special way of getting the devicetree into U-Boot. The older boards
> use CONFIG_OF_EMBED which is actually not even allowed in production
> boards....
>
> Also you may need the -r argument to mkimage to mark the key as required.
>
> Regards,
> Simon
>

[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 15099 bytes --]

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

[Mark Kettenis]

> From: Moiz Imtiaz <moizimtiaz1@gmail.com>
> Date: Sat, 11 Sep 2021 23:19:05 +0500
> 
> Hi Simon,
> 
> Thanks for the reply.  I already followed the steps mentioned in
> "doc/uImage.FIT/beaglebone_vboot.txt".
> 
> >I wonder if rpi is not using the devicetree compiled with U-Boot, but
> instead one provided by the earlier-stage firmware?
> 
> Not sure, but seems like this is the case. I checked and there isn't any
> dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to
> add the dtb and other dts dtsi
> <https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom>files
> from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and
> CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and
> it would just give a blank screen*. I wonder why there isn't any device
> tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by
> RPI4?

The issue with the rpi4 is that the addresses of devices move around
based on the version of the Raspberry Pi firmware you're using.  And
possibly on the amount of memory on the board as well.  So U-Boot
pretty much has to use the device tree passed by the firmware since
the device tree in the U-Boot tree would be wrong for many
combinations of firmware and hardware.

Simon, this sort of thing is exactly the reason why I think the idea
of having all U-Boot configuration information in a single device tree
with the hardware description doesn't work everywhere.

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

[Tom Rini]

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

On Sat, Sep 11, 2021 at 09:18:46PM +0200, Mark Kettenis wrote:
> > From: Moiz Imtiaz <moizimtiaz1@gmail.com>
> > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > 
> > Hi Simon,
> > 
> > Thanks for the reply.  I already followed the steps mentioned in
> > "doc/uImage.FIT/beaglebone_vboot.txt".
> > 
> > >I wonder if rpi is not using the devicetree compiled with U-Boot, but
> > instead one provided by the earlier-stage firmware?
> > 
> > Not sure, but seems like this is the case. I checked and there isn't any
> > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to
> > add the dtb and other dts dtsi
> > <https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom>files
> > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and
> > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and
> > it would just give a blank screen*. I wonder why there isn't any device
> > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by
> > RPI4?
> 
> The issue with the rpi4 is that the addresses of devices move around
> based on the version of the Raspberry Pi firmware you're using.  And
> possibly on the amount of memory on the board as well.  So U-Boot
> pretty much has to use the device tree passed by the firmware since
> the device tree in the U-Boot tree would be wrong for many
> combinations of firmware and hardware.
> 
> Simon, this sort of thing is exactly the reason why I think the idea
> of having all U-Boot configuration information in a single device tree
> with the hardware description doesn't work everywhere.

In this case, doesn't the Pi firmware pass along apply overlays and
construct the device tree it's going to pass along, so in this case you
would want to make an "overlay" for the Pi firmware to apply and pass
along to U-Boot, that includes the required information?

-- 
Tom

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

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

[Mark Kettenis]

> Date: Sat, 11 Sep 2021 17:05:45 -0400
> From: Tom Rini <trini@konsulko.com>
> 
> On Sat, Sep 11, 2021 at 09:18:46PM +0200, Mark Kettenis wrote:
> > > From: Moiz Imtiaz <moizimtiaz1@gmail.com>
> > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > > 
> > > Hi Simon,
> > > 
> > > Thanks for the reply.  I already followed the steps mentioned in
> > > "doc/uImage.FIT/beaglebone_vboot.txt".
> > > 
> > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but
> > > instead one provided by the earlier-stage firmware?
> > > 
> > > Not sure, but seems like this is the case. I checked and there isn't any
> > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to
> > > add the dtb and other dts dtsi
> > > <https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom>files
> > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and
> > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and
> > > it would just give a blank screen*. I wonder why there isn't any device
> > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by
> > > RPI4?
> > 
> > The issue with the rpi4 is that the addresses of devices move around
> > based on the version of the Raspberry Pi firmware you're using.  And
> > possibly on the amount of memory on the board as well.  So U-Boot
> > pretty much has to use the device tree passed by the firmware since
> > the device tree in the U-Boot tree would be wrong for many
> > combinations of firmware and hardware.
> > 
> > Simon, this sort of thing is exactly the reason why I think the idea
> > of having all U-Boot configuration information in a single device tree
> > with the hardware description doesn't work everywhere.
> 
> In this case, doesn't the Pi firmware pass along apply overlays and
> construct the device tree it's going to pass along, so in this case you
> would want to make an "overlay" for the Pi firmware to apply and pass
> along to U-Boot, that includes the required information?

yes, that might work.  The overlay can be specified in the config.txt file.

I think truly verified boot is impossible on the Pi though, as u-boot
and the overlay file will need to be stored on the uSD card of the Pi.
But that applies to the scenario where the public key is stored in the
device tree embedded in u-boot itself as well.

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

[Tom Rini]

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

On Sat, Sep 11, 2021 at 11:30:00PM +0200, Mark Kettenis wrote:
> > Date: Sat, 11 Sep 2021 17:05:45 -0400
> > From: Tom Rini <trini@konsulko.com>
> > 
> > On Sat, Sep 11, 2021 at 09:18:46PM +0200, Mark Kettenis wrote:
> > > > From: Moiz Imtiaz <moizimtiaz1@gmail.com>
> > > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > > > 
> > > > Hi Simon,
> > > > 
> > > > Thanks for the reply.  I already followed the steps mentioned in
> > > > "doc/uImage.FIT/beaglebone_vboot.txt".
> > > > 
> > > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but
> > > > instead one provided by the earlier-stage firmware?
> > > > 
> > > > Not sure, but seems like this is the case. I checked and there isn't any
> > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to
> > > > add the dtb and other dts dtsi
> > > > <https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom>files
> > > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and
> > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and
> > > > it would just give a blank screen*. I wonder why there isn't any device
> > > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by
> > > > RPI4?
> > > 
> > > The issue with the rpi4 is that the addresses of devices move around
> > > based on the version of the Raspberry Pi firmware you're using.  And
> > > possibly on the amount of memory on the board as well.  So U-Boot
> > > pretty much has to use the device tree passed by the firmware since
> > > the device tree in the U-Boot tree would be wrong for many
> > > combinations of firmware and hardware.
> > > 
> > > Simon, this sort of thing is exactly the reason why I think the idea
> > > of having all U-Boot configuration information in a single device tree
> > > with the hardware description doesn't work everywhere.
> > 
> > In this case, doesn't the Pi firmware pass along apply overlays and
> > construct the device tree it's going to pass along, so in this case you
> > would want to make an "overlay" for the Pi firmware to apply and pass
> > along to U-Boot, that includes the required information?
> 
> yes, that might work.  The overlay can be specified in the config.txt file.
> 
> I think truly verified boot is impossible on the Pi though, as u-boot
> and the overlay file will need to be stored on the uSD card of the Pi.
> But that applies to the scenario where the public key is stored in the
> device tree embedded in u-boot itself as well.

Yes, a more general problem is that some platforms are really only
proof-of-concept useful.  If you can't start with the ROM, you're going
to be limited.


-- 
Tom

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

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

[Moiz Imtiaz]

Completely agreed, that a fully secure boot on pi won't be achievable
because the Root of Trust (ROT) cant be established from the BOTROM/EEPROM.
Plus Pi doesn't have any High Assurance Boot (HAB).  But given the
scenerio, whatever we can achieve i.e if we can verify the kernel, the
device tree, from the bootloader, (u-boot)  that would be great.

Currently the issue with Pi4 is that , signature verification is not being
done with u-boot, so wondering if that can be made possible.

>But that applies to the scenario where the public key is stored in the
> device tree embedded in u-boot itself as well

Just for the sake of knowledge, Isn't this the case with all u-boot, that
the public key is stored in the device tree (control FDT) and is embedded
in the u-boot.

On Sun, 12 Sep 2021, 02:34 Tom Rini, <trini@konsulko.com> wrote:

> On Sat, Sep 11, 2021 at 11:30:00PM +0200, Mark Kettenis wrote:
> > > Date: Sat, 11 Sep 2021 17:05:45 -0400
> > > From: Tom Rini <trini@konsulko.com>
> > >
> > > On Sat, Sep 11, 2021 at 09:18:46PM +0200, Mark Kettenis wrote:
> > > > > From: Moiz Imtiaz <moizimtiaz1@gmail.com>
> > > > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > Thanks for the reply.  I already followed the steps mentioned in
> > > > > "doc/uImage.FIT/beaglebone_vboot.txt".
> > > > >
> > > > > >I wonder if rpi is not using the devicetree compiled with U-Boot,
> but
> > > > > instead one provided by the earlier-stage firmware?
> > > > >
> > > > > Not sure, but seems like this is the case. I checked and there
> isn't any
> > > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I
> tried to
> > > > > add the dtb and other dts dtsi
> > > > > <
> https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom
> >files
> > > > > from the raspberry pi Linux and compile them with
> CONFIG_OF_SEPARATE and
> > > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the
> U-Boot and
> > > > > it would just give a blank screen*. I wonder why there isn't any
> device
> > > > > tree in the U-boot repo for RPI4. Is U-boot control FDT not
> supported by
> > > > > RPI4?
> > > >
> > > > The issue with the rpi4 is that the addresses of devices move around
> > > > based on the version of the Raspberry Pi firmware you're using.  And
> > > > possibly on the amount of memory on the board as well.  So U-Boot
> > > > pretty much has to use the device tree passed by the firmware since
> > > > the device tree in the U-Boot tree would be wrong for many
> > > > combinations of firmware and hardware.
> > > >
> > > > Simon, this sort of thing is exactly the reason why I think the idea
> > > > of having all U-Boot configuration information in a single device
> tree
> > > > with the hardware description doesn't work everywhere.
> > >
> > > In this case, doesn't the Pi firmware pass along apply overlays and
> > > construct the device tree it's going to pass along, so in this case you
> > > would want to make an "overlay" for the Pi firmware to apply and pass
> > > along to U-Boot, that includes the required information?
> >
> > yes, that might work.  The overlay can be specified in the config.txt
> file.
> >
> > I think truly verified boot is impossible on the Pi though, as u-boot
> > and the overlay file will need to be stored on the uSD card of the Pi.
> > But that applies to the scenario where the public key is stored in the
> > device tree embedded in u-boot itself as well.
>
> Yes, a more general problem is that some platforms are really only
> proof-of-concept useful.  If you can't start with the ROM, you're going
> to be limited.
>
>
> --
> Tom
>

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

[Tom Rini]

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

On Sun, Sep 12, 2021 at 02:58:12AM +0500, Moiz Imtiaz wrote:

> Completely agreed, that a fully secure boot on pi won't be achievable
> because the Root of Trust (ROT) cant be established from the BOTROM/EEPROM.
> Plus Pi doesn't have any High Assurance Boot (HAB).  But given the
> scenerio, whatever we can achieve i.e if we can verify the kernel, the
> device tree, from the bootloader, (u-boot)  that would be great.
> 
> Currently the issue with Pi4 is that , signature verification is not being
> done with u-boot, so wondering if that can be made possible.

Right, OK.  Yes, I think it would be possible, but you'll need to
experiment a bit.  You'll basically want to take the signature
information that the U-Boot docs talk about out of the created device
tree, and put it in its own file, and then have the Pi firmware apply
that as an "overlay", as it assembles the tree to use.  Then the regular
mechanism U-Boot uses to use the passed in device tree should work.

> >But that applies to the scenario where the public key is stored in the
> > device tree embedded in u-boot itself as well
> 
> Just for the sake of knowledge, Isn't this the case with all u-boot, that
> the public key is stored in the device tree (control FDT) and is embedded
> in the u-boot.

You're in experimental territory here, yes.  The existing examples all
are on platforms where a prior stage wouldn't be giving us a device
tree.  U-Boot should not actually care where the device tree comes from
so long as it is correct.

I've only got a Pi 3 in my CI lab, and since it's CI I also really hate
fiddling with it since I then end up spending more time re-setting it
for CI.

-- 
Tom

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

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

[Moiz Imtiaz]

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

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

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.

Best,
Moiz Imtiaz Khan

On Sun, Sep 12, 2021 at 8:02 PM Tom Rini <trini@konsulko.com> wrote:

> On Sun, Sep 12, 2021 at 02:58:12AM +0500, Moiz Imtiaz wrote:
>
> > Completely agreed, that a fully secure boot on pi won't be achievable
> > because the Root of Trust (ROT) cant be established from the
> BOTROM/EEPROM.
> > Plus Pi doesn't have any High Assurance Boot (HAB).  But given the
> > scenerio, whatever we can achieve i.e if we can verify the kernel, the
> > device tree, from the bootloader, (u-boot)  that would be great.
> >
> > Currently the issue with Pi4 is that , signature verification is not
> being
> > done with u-boot, so wondering if that can be made possible.
>
> Right, OK.  Yes, I think it would be possible, but you'll need to
> experiment a bit.  You'll basically want to take the signature
> information that the U-Boot docs talk about out of the created device
> tree, and put it in its own file, and then have the Pi firmware apply
> that as an "overlay", as it assembles the tree to use.  Then the regular
> mechanism U-Boot uses to use the passed in device tree should work.
>
> > >But that applies to the scenario where the public key is stored in the
> > > device tree embedded in u-boot itself as well
> >
> > Just for the sake of knowledge, Isn't this the case with all u-boot, that
> > the public key is stored in the device tree (control FDT) and is embedded
> > in the u-boot.
>
> You're in experimental territory here, yes.  The existing examples all
> are on platforms where a prior stage wouldn't be giving us a device
> tree.  U-Boot should not actually care where the device tree comes from
> so long as it is correct.
>
> I've only got a Pi 3 in my CI lab, and since it's CI I also really hate
> fiddling with it since I then end up spending more time re-setting it
> for CI.
>
> --
> Tom
>

[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 67795 bytes --]

[-- Attachment #3: changing_the_hash_verfication.png --]
[-- Type: image/png, Size: 24777 bytes --]

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

[Tom Rini]

[-- 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 --]

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

[Simon Glass]

Hi Mark,

On Sat, 11 Sept 2021 at 13:18, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>
> > From: Moiz Imtiaz <moizimtiaz1@gmail.com>
> > Date: Sat, 11 Sep 2021 23:19:05 +0500
> >
> > Hi Simon,
> >
> > Thanks for the reply.  I already followed the steps mentioned in
> > "doc/uImage.FIT/beaglebone_vboot.txt".
> >
> > >I wonder if rpi is not using the devicetree compiled with U-Boot, but
> > instead one provided by the earlier-stage firmware?
> >
> > Not sure, but seems like this is the case. I checked and there isn't any
> > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to
> > add the dtb and other dts dtsi
> > <https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom>files
> > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and
> > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and
> > it would just give a blank screen*. I wonder why there isn't any device
> > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by
> > RPI4?
>
> The issue with the rpi4 is that the addresses of devices move around
> based on the version of the Raspberry Pi firmware you're using.  And
> possibly on the amount of memory on the board as well.  So U-Boot
> pretty much has to use the device tree passed by the firmware since
> the device tree in the U-Boot tree would be wrong for many
> combinations of firmware and hardware.
>
> Simon, this sort of thing is exactly the reason why I think the idea
> of having all U-Boot configuration information in a single device tree
> with the hardware description doesn't work everywhere.

From my reading of this thread, it rather reinforces the need to
provide a way to give U-Boot the config it needs, in the devicetree.

It seems that rpi is actually OK in this regard. If you think about
it, it would be pretty hopeless if first-stage firmware assumed that
it could provide a devicetree to whatever is next. For example, if
U-Boot evolves to support more devices, they could not be supported.
If UEFI is used, the devicetree would have no effect, since it doesn't
support devicetree.

So perhaps the only remaining issue is with qemu on ARM / Risc-V?

Regards,
Simon

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

[François Ozog]

Le mer. 15 sept. 2021 à 12:13, Simon Glass <sjg@chromium.org> a écrit :

> Hi Mark,
>
> On Sat, 11 Sept 2021 at 13:18, Mark Kettenis <mark.kettenis@xs4all.nl>
> wrote:
> >
> > > From: Moiz Imtiaz <moizimtiaz1@gmail.com>
> > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > >
> > > Hi Simon,
> > >
> > > Thanks for the reply.  I already followed the steps mentioned in
> > > "doc/uImage.FIT/beaglebone_vboot.txt".
> > >
> > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but
> > > instead one provided by the earlier-stage firmware?
> > >
> > > Not sure, but seems like this is the case. I checked and there isn't
> any
> > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I
> tried to
> > > add the dtb and other dts dtsi
> > > <
> https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom
> >files
> > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE
> and
> > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot
> and
> > > it would just give a blank screen*. I wonder why there isn't any device
> > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported
> by
> > > RPI4?
> >
> > The issue with the rpi4 is that the addresses of devices move around
> > based on the version of the Raspberry Pi firmware you're using.  And
> > possibly on the amount of memory on the board as well.  So U-Boot
> > pretty much has to use the device tree passed by the firmware since
> > the device tree in the U-Boot tree would be wrong for many
> > combinations of firmware and hardware.
> >
> > Simon, this sort of thing is exactly the reason why I think the idea
> > of having all U-Boot configuration information in a single device tree
> > with the hardware description doesn't work everywhere.
>
> From my reading of this thread, it rather reinforces the need to
> provide a way to give U-Boot the config it needs, in the devicetree.
>
> It seems that rpi is actually OK in this regard. If you think about
> it, it would be pretty hopeless if first-stage firmware assumed that
> it could provide a devicetree to whatever is next. For example, if
> U-Boot evolves to support more devices, they could not be supported.
> If UEFI is used, the devicetree would have no effect, since it doesn't
> support devicetree.

Please use EDK2 when you refer to it and not by the interface it
implements. And even if we read “If EDK2 is used” this is false as
Socionext has a platform that can select ACPI or DT for its EDK2
implementation.
TF-A has fat less drivers than U-Boot. There is no problem in having a
“verified” platform DT stored in BL33_CONFIG part of a FIP, verified by TFa
and handed over by U-Boot to OS.
That can be the same thing in RPI4 case or FPGA boards.

>
>
> So perhaps the only remaining issue is with qemu on ARM / Risc-V?
>
> Regards,
> Simon
>
-- 
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog

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

[Simon Glass]

Hi François,

On Wed, 15 Sept 2021 at 04:26, François Ozog <francois.ozog@linaro.org> wrote:
>
>
>
> Le mer. 15 sept. 2021 à 12:13, Simon Glass <sjg@chromium.org> a écrit :
>>
>> Hi Mark,
>>
>> On Sat, 11 Sept 2021 at 13:18, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>> >
>> > > From: Moiz Imtiaz <moizimtiaz1@gmail.com>
>> > > Date: Sat, 11 Sep 2021 23:19:05 +0500
>> > >
>> > > Hi Simon,
>> > >
>> > > Thanks for the reply.  I already followed the steps mentioned in
>> > > "doc/uImage.FIT/beaglebone_vboot.txt".
>> > >
>> > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but
>> > > instead one provided by the earlier-stage firmware?
>> > >
>> > > Not sure, but seems like this is the case. I checked and there isn't any
>> > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to
>> > > add the dtb and other dts dtsi
>> > > <https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom>files
>> > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and
>> > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and
>> > > it would just give a blank screen*. I wonder why there isn't any device
>> > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by
>> > > RPI4?
>> >
>> > The issue with the rpi4 is that the addresses of devices move around
>> > based on the version of the Raspberry Pi firmware you're using.  And
>> > possibly on the amount of memory on the board as well.  So U-Boot
>> > pretty much has to use the device tree passed by the firmware since
>> > the device tree in the U-Boot tree would be wrong for many
>> > combinations of firmware and hardware.
>> >
>> > Simon, this sort of thing is exactly the reason why I think the idea
>> > of having all U-Boot configuration information in a single device tree
>> > with the hardware description doesn't work everywhere.
>>
>> From my reading of this thread, it rather reinforces the need to
>> provide a way to give U-Boot the config it needs, in the devicetree.
>>
>> It seems that rpi is actually OK in this regard. If you think about
>> it, it would be pretty hopeless if first-stage firmware assumed that
>> it could provide a devicetree to whatever is next. For example, if
>> U-Boot evolves to support more devices, they could not be supported.
>> If UEFI is used, the devicetree would have no effect, since it doesn't
>> support devicetree.
>
> Please use EDK2 when you refer to it and not by the interface it implements. And even if we read “If EDK2 is used” this is false as Socionext has a platform that can select ACPI or DT for its EDK2 implementation.

OK I will try to remember to use 'EDK2' to describe a UEFI
implementation. Since all the other UEFI implementations are
closed-source(?) I suppose it is the only one that is relevant here.
Not that EDK2 actually supports very many boards, so far as I can tell
from the source tree.

I recall people complaining about libfdt being needed in EDK2 (I
assume, perhaps it was some other UEFI?) Are you saying that EDK2 can
use devicetree for its configuration? If not, thenI think you
misunderstood my point.

> TF-A has fat less drivers than U-Boot. There is no problem in having a “verified” platform DT stored in BL33_CONFIG part of a FIP, verified by TFa and handed over by U-Boot to OS.
> That can be the same thing in RPI4 case or FPGA boards.
>>

OK. I think you are saying that we can use TF-A on rpi and have it
provide a suitable devicetree for U-Boot. That's fine. However it
happens is fine. It just needs to support the features U-Boot
supports, not provide a partial devicetree forcing U-Boot to put its
config elsewhere.


>>
>>
>> So perhaps the only remaining issue is with qemu on ARM / Risc-V?

Regards,
Simon

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

[François Ozog]

HI Simon,

On Fri, 17 Sept 2021 at 18:21, Simon Glass <sjg@chromium.org> wrote:

> Hi François,
>
> On Wed, 15 Sept 2021 at 04:26, François Ozog <francois.ozog@linaro.org>
> wrote:
> >
> >
> >
> > Le mer. 15 sept. 2021 à 12:13, Simon Glass <sjg@chromium.org> a écrit :
> >>
> >> Hi Mark,
> >>
> >> On Sat, 11 Sept 2021 at 13:18, Mark Kettenis <mark.kettenis@xs4all.nl>
> wrote:
> >> >
> >> > > From: Moiz Imtiaz <moizimtiaz1@gmail.com>
> >> > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> >> > >
> >> > > Hi Simon,
> >> > >
> >> > > Thanks for the reply.  I already followed the steps mentioned in
> >> > > "doc/uImage.FIT/beaglebone_vboot.txt".
> >> > >
> >> > > >I wonder if rpi is not using the devicetree compiled with U-Boot,
> but
> >> > > instead one provided by the earlier-stage firmware?
> >> > >
> >> > > Not sure, but seems like this is the case. I checked and there
> isn't any
> >> > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I
> tried to
> >> > > add the dtb and other dts dtsi
> >> > > <
> https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom
> >files
> >> > > from the raspberry pi Linux and compile them with
> CONFIG_OF_SEPARATE and
> >> > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the
> U-Boot and
> >> > > it would just give a blank screen*. I wonder why there isn't any
> device
> >> > > tree in the U-boot repo for RPI4. Is U-boot control FDT not
> supported by
> >> > > RPI4?
> >> >
> >> > The issue with the rpi4 is that the addresses of devices move around
> >> > based on the version of the Raspberry Pi firmware you're using.  And
> >> > possibly on the amount of memory on the board as well.  So U-Boot
> >> > pretty much has to use the device tree passed by the firmware since
> >> > the device tree in the U-Boot tree would be wrong for many
> >> > combinations of firmware and hardware.
> >> >
> >> > Simon, this sort of thing is exactly the reason why I think the idea
> >> > of having all U-Boot configuration information in a single device tree
> >> > with the hardware description doesn't work everywhere.
> >>
> >> From my reading of this thread, it rather reinforces the need to
> >> provide a way to give U-Boot the config it needs, in the devicetree.
> >>
> >> It seems that rpi is actually OK in this regard. If you think about
> >> it, it would be pretty hopeless if first-stage firmware assumed that
> >> it could provide a devicetree to whatever is next. For example, if
> >> U-Boot evolves to support more devices, they could not be supported.
> >> If UEFI is used, the devicetree would have no effect, since it doesn't
> >> support devicetree.
> >
> > Please use EDK2 when you refer to it and not by the interface it
> implements. And even if we read “If EDK2 is used” this is false as
> Socionext has a platform that can select ACPI or DT for its EDK2
> implementation.
>
> OK I will try to remember to use 'EDK2' to describe a UEFI
> implementation. Since all the other UEFI implementations are
> closed-source(?) I suppose it is the only one that is relevant here.
> Not that EDK2 actually supports very many boards, so far as I can tell
> from the source tree.
>
> I recall people complaining about libfdt being needed in EDK2 (I
> assume, perhaps it was some other UEFI?) Are you saying that EDK2 can
> use devicetree for its configuration? If not, thenI think you
> misunderstood my point.
>
I effectively did misunderstood your point. EDK2 configuration elements
come from very different sources. It consumes HOBs from the pre-EFI world,
has ACPI parameters, and even private storage. UEFI variables are used to
control some functional elements but if you want to talk about PCI
bifurcation control for instance it is not in ACPI, not in UEFI: just
private structures may be stored in an EEPROM or other element.

>
> > TF-A has fat less drivers than U-Boot. There is no problem in having a
> “verified” platform DT stored in BL33_CONFIG part of a FIP, verified by TFa
> and handed over by U-Boot to OS.
> > That can be the same thing in RPI4 case or FPGA boards.
> >>
>
> OK. I think you are saying that we can use TF-A on rpi and have it
> provide a suitable devicetree for U-Boot. That's fine. However it
> happens is fine. It just needs to support the features U-Boot
> supports, not provide a partial devicetree forcing U-Boot to put its
> config elsewhere.
>
> This is how I implemented LinuxBoot on MacchiatoBin: DT for the platform
in the FIP.
For the RPI, I would just consume what has been assembled through
config.txt overlays and other adjustments.
But again, TFA shall ignore the exact nature of the BL33 (U-Boot,
LinuxBoot, Xen...).
That said I agree there is a need of a clearer/richer contract at the entry
of BL33 (the HOBs/bloblist proposal by Harb is part of this extended
contract discussion).  The DT that TFA passes to BL33, may list a
restricted set of devices because BL33 may not need all devices, or it may
contain the same list of devices but with different bindings (I remember ST
suggesting a display may need 4 parameters for BL33 while it may be
thousands of bytes long for the full OS). This aspect is still open on the
DT technical report from Linaro DTE project (Device Tree Evolution).
U-Boot has a nice "environment" that can host parameters, it can even
include a base64'ified DT. As I said earlier, any program can use DT to
store self describing data. U-Boot can be one of them and use the FDT
format to store its configuration data. It will not be visible by upstream
or downstream firmware component. It is not an overlay of any sort.
It feels an elegant way to store program specific configuration data. Let's
just not make it a global thing on the platform.

>
> >>
> >>
> >> So perhaps the only remaining issue is with qemu on ARM / Risc-V?
>
> Regards,
> Simon
>


-- 
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog

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

[Tom Rini]

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

On Fri, Sep 17, 2021 at 10:21:38AM -0600, Simon Glass wrote:
> Hi François,
> 
> On Wed, 15 Sept 2021 at 04:26, François Ozog <francois.ozog@linaro.org> wrote:
> >
> >
> >
> > Le mer. 15 sept. 2021 à 12:13, Simon Glass <sjg@chromium.org> a écrit :
> >>
> >> Hi Mark,
> >>
> >> On Sat, 11 Sept 2021 at 13:18, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> >> >
> >> > > From: Moiz Imtiaz <moizimtiaz1@gmail.com>
> >> > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> >> > >
> >> > > Hi Simon,
> >> > >
> >> > > Thanks for the reply.  I already followed the steps mentioned in
> >> > > "doc/uImage.FIT/beaglebone_vboot.txt".
> >> > >
> >> > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but
> >> > > instead one provided by the earlier-stage firmware?
> >> > >
> >> > > Not sure, but seems like this is the case. I checked and there isn't any
> >> > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to
> >> > > add the dtb and other dts dtsi
> >> > > <https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom>files
> >> > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and
> >> > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and
> >> > > it would just give a blank screen*. I wonder why there isn't any device
> >> > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by
> >> > > RPI4?
> >> >
> >> > The issue with the rpi4 is that the addresses of devices move around
> >> > based on the version of the Raspberry Pi firmware you're using.  And
> >> > possibly on the amount of memory on the board as well.  So U-Boot
> >> > pretty much has to use the device tree passed by the firmware since
> >> > the device tree in the U-Boot tree would be wrong for many
> >> > combinations of firmware and hardware.
> >> >
> >> > Simon, this sort of thing is exactly the reason why I think the idea
> >> > of having all U-Boot configuration information in a single device tree
> >> > with the hardware description doesn't work everywhere.
> >>
> >> From my reading of this thread, it rather reinforces the need to
> >> provide a way to give U-Boot the config it needs, in the devicetree.
> >>
> >> It seems that rpi is actually OK in this regard. If you think about
> >> it, it would be pretty hopeless if first-stage firmware assumed that
> >> it could provide a devicetree to whatever is next. For example, if
> >> U-Boot evolves to support more devices, they could not be supported.
> >> If UEFI is used, the devicetree would have no effect, since it doesn't
> >> support devicetree.
> >
> > Please use EDK2 when you refer to it and not by the interface it implements. And even if we read “If EDK2 is used” this is false as Socionext has a platform that can select ACPI or DT for its EDK2 implementation.
> 
> OK I will try to remember to use 'EDK2' to describe a UEFI
> implementation. Since all the other UEFI implementations are
> closed-source(?) I suppose it is the only one that is relevant here.

Just for the record, AMI recently announced they will be supporting
aarch64, and yes with ACPI.

-- 
Tom

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

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

[Mark Kettenis]

> From: Simon Glass <sjg@chromium.org>
> Date: Wed, 15 Sep 2021 04:13:24 -0600

Hi Simon,

> Hi Mark,
> 
> On Sat, 11 Sept 2021 at 13:18, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> >
> > > From: Moiz Imtiaz <moizimtiaz1@gmail.com>
> > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > >
> > > Hi Simon,
> > >
> > > Thanks for the reply.  I already followed the steps mentioned in
> > > "doc/uImage.FIT/beaglebone_vboot.txt".
> > >
> > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but
> > > instead one provided by the earlier-stage firmware?
> > >
> > > Not sure, but seems like this is the case. I checked and there isn't any
> > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to
> > > add the dtb and other dts dtsi
> > > <https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom>files
> > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and
> > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and
> > > it would just give a blank screen*. I wonder why there isn't any device
> > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by
> > > RPI4?
> >
> > The issue with the rpi4 is that the addresses of devices move around
> > based on the version of the Raspberry Pi firmware you're using.  And
> > possibly on the amount of memory on the board as well.  So U-Boot
> > pretty much has to use the device tree passed by the firmware since
> > the device tree in the U-Boot tree would be wrong for many
> > combinations of firmware and hardware.
> >
> > Simon, this sort of thing is exactly the reason why I think the idea
> > of having all U-Boot configuration information in a single device tree
> > with the hardware description doesn't work everywhere.
> 
> >From my reading of this thread, it rather reinforces the need to
> provide a way to give U-Boot the config it needs, in the devicetree.

As long as that configuration is optional, yes, maybe.

> It seems that rpi is actually OK in this regard. If you think about
> it, it would be pretty hopeless if first-stage firmware assumed that
> it could provide a devicetree to whatever is next.

Not hopeless.  If that device tree provides a hardware description
that is complete enough to boot Linux, it should be good enough to run
U-Boot.

And yes, the Raspberry Pi has a nice way to load overlays to do
additional hardware configuration and support add-on hardware that
connects to the GPIO header on the Pi.  Replicating all this in U-Boot
would make very little sense.

> For example, if U-Boot evolves to support more devices, they could
> not be supported.

Unless the device in question has a mechanism to load device tree
overlays like the Pi, this would require a firmware update.

In practice, the device tree provided by the firmware will have more
stuff than U-Boot will ever need though.  Unless you're advocating
that U-Boot evolves into a full-fledged OS ;).

> If UEFI is used, the devicetree would have no effect, since it doesn't
> support devicetree.

That is not true.  UEFI supports device trees just fine.  All the
arm64 and riscv64 boards supported by U-Boot that include EFI_LOADER
support use device trees.  The idea that UEFI implies ACPI is a
misconception.

> So perhaps the only remaining issue is with qemu on ARM / Risc-V?

Maybe somebody can add device tree overlay support to QEMU?

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

[Tom Rini]

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

On Wed, Sep 15, 2021 at 01:51:51PM +0200, Mark Kettenis wrote:
> > From: Simon Glass <sjg@chromium.org>
> > Date: Wed, 15 Sep 2021 04:13:24 -0600
> 
> Hi Simon,
> 
> > Hi Mark,
> > 
> > On Sat, 11 Sept 2021 at 13:18, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > >
> > > > From: Moiz Imtiaz <moizimtiaz1@gmail.com>
> > > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > > >
> > > > Hi Simon,
> > > >
> > > > Thanks for the reply.  I already followed the steps mentioned in
> > > > "doc/uImage.FIT/beaglebone_vboot.txt".
> > > >
> > > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but
> > > > instead one provided by the earlier-stage firmware?
> > > >
> > > > Not sure, but seems like this is the case. I checked and there isn't any
> > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to
> > > > add the dtb and other dts dtsi
> > > > <https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom>files
> > > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and
> > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and
> > > > it would just give a blank screen*. I wonder why there isn't any device
> > > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by
> > > > RPI4?
> > >
> > > The issue with the rpi4 is that the addresses of devices move around
> > > based on the version of the Raspberry Pi firmware you're using.  And
> > > possibly on the amount of memory on the board as well.  So U-Boot
> > > pretty much has to use the device tree passed by the firmware since
> > > the device tree in the U-Boot tree would be wrong for many
> > > combinations of firmware and hardware.
> > >
> > > Simon, this sort of thing is exactly the reason why I think the idea
> > > of having all U-Boot configuration information in a single device tree
> > > with the hardware description doesn't work everywhere.
> > 
> > >From my reading of this thread, it rather reinforces the need to
> > provide a way to give U-Boot the config it needs, in the devicetree.
> 
> As long as that configuration is optional, yes, maybe.

Lets be a little careful.  We don't want to have two ways to provide the
information for a given feature.  But some configuration properties are
certainly optional.

> > It seems that rpi is actually OK in this regard. If you think about
> > it, it would be pretty hopeless if first-stage firmware assumed that
> > it could provide a devicetree to whatever is next.
> 
> Not hopeless.  If that device tree provides a hardware description
> that is complete enough to boot Linux, it should be good enough to run
> U-Boot.

And keep in mind that one of those long stated goals is that the device
tree for a platform lives physically on the platform and doesn't require
being replaced entirely at run-time with a new/different device tree.

> And yes, the Raspberry Pi has a nice way to load overlays to do
> additional hardware configuration and support add-on hardware that
> connects to the GPIO header on the Pi.  Replicating all this in U-Boot
> would make very little sense.

Note that in U-Boot we do have functionality to figure out and apply DT
overlays for a platform, and it's generic enough that platforms can
plugin their logic to detect what overlays are appropriate.  This is
under CMD_EXTENSION.  It's not appropriate for Pi as they did all of
this in their in-house firmware instead of using U-Boot.

> > For example, if U-Boot evolves to support more devices, they could
> > not be supported.
> 
> Unless the device in question has a mechanism to load device tree
> overlays like the Pi, this would require a firmware update.

In that CMD_EXTENSION is about updating the tree for the next stage, and
not ourself, yes.  But this is also the same problem that OSes have that
lead to overlays, at least in part.  But also why it's so hard to
support a static device tree on hardware, and have an evolving kernel.
I'm not sure there's many / any good examples of wholly static and also
feature complete device trees and OSes today, on a recent / semi-recent
piece of hardware.

> In practice, the device tree provided by the firmware will have more
> stuff than U-Boot will ever need though.  Unless you're advocating
> that U-Boot evolves into a full-fledged OS ;).
> 
> > If UEFI is used, the devicetree would have no effect, since it doesn't
> > support devicetree.
> 
> That is not true.  UEFI supports device trees just fine.  All the
> arm64 and riscv64 boards supported by U-Boot that include EFI_LOADER
> support use device trees.  The idea that UEFI implies ACPI is a
> misconception.
> 
> > So perhaps the only remaining issue is with qemu on ARM / Risc-V?
> 
> Maybe somebody can add device tree overlay support to QEMU?

Having gone through this thread, I wonder if U-Boot generating a device
tree overlay (and also the keeping the source of it, before
preprocessing if we can) isn't part of the solution here.  Heinrich had
suggested in another thread, and Simon had strongly disagreed with
overlays being how we perhaps solve some portions of the overall "what
should U-Boot require of the DT?" problem.  I'm thinking that might be
the right answer, in some cases.

-- 
Tom

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

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

[François Ozog]

On Wed, 15 Sept 2021 at 15:36, Tom Rini <trini@konsulko.com> wrote:

> On Wed, Sep 15, 2021 at 01:51:51PM +0200, Mark Kettenis wrote:
> > > From: Simon Glass <sjg@chromium.org>
> > > Date: Wed, 15 Sep 2021 04:13:24 -0600
> >
> > Hi Simon,
> >
> > > Hi Mark,
> > >
> > > On Sat, 11 Sept 2021 at 13:18, Mark Kettenis <mark.kettenis@xs4all.nl>
> wrote:
> > > >
> > > > > From: Moiz Imtiaz <moizimtiaz1@gmail.com>
> > > > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > Thanks for the reply.  I already followed the steps mentioned in
> > > > > "doc/uImage.FIT/beaglebone_vboot.txt".
> > > > >
> > > > > >I wonder if rpi is not using the devicetree compiled with U-Boot,
> but
> > > > > instead one provided by the earlier-stage firmware?
> > > > >
> > > > > Not sure, but seems like this is the case. I checked and there
> isn't any
> > > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I
> tried to
> > > > > add the dtb and other dts dtsi
> > > > > <
> https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom
> >files
> > > > > from the raspberry pi Linux and compile them with
> CONFIG_OF_SEPARATE and
> > > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the
> U-Boot and
> > > > > it would just give a blank screen*. I wonder why there isn't any
> device
> > > > > tree in the U-boot repo for RPI4. Is U-boot control FDT not
> supported by
> > > > > RPI4?
> > > >
> > > > The issue with the rpi4 is that the addresses of devices move around
> > > > based on the version of the Raspberry Pi firmware you're using.  And
> > > > possibly on the amount of memory on the board as well.  So U-Boot
> > > > pretty much has to use the device tree passed by the firmware since
> > > > the device tree in the U-Boot tree would be wrong for many
> > > > combinations of firmware and hardware.
> > > >
> > > > Simon, this sort of thing is exactly the reason why I think the idea
> > > > of having all U-Boot configuration information in a single device
> tree
> > > > with the hardware description doesn't work everywhere.
> > >
> > > >From my reading of this thread, it rather reinforces the need to
> > > provide a way to give U-Boot the config it needs, in the devicetree.
> >
> > As long as that configuration is optional, yes, maybe.
>
> Lets be a little careful.  We don't want to have two ways to provide the
> information for a given feature.  But some configuration properties are
> certainly optional.
>
> > > It seems that rpi is actually OK in this regard. If you think about
> > > it, it would be pretty hopeless if first-stage firmware assumed that
> > > it could provide a devicetree to whatever is next.
> >
> > Not hopeless.  If that device tree provides a hardware description
> > that is complete enough to boot Linux, it should be good enough to run
> > U-Boot.
>
> And keep in mind that one of those long stated goals is that the device
> tree for a platform lives physically on the platform and doesn't require
> being replaced entirely at run-time with a new/different device tree.
>
> > And yes, the Raspberry Pi has a nice way to load overlays to do
> > additional hardware configuration and support add-on hardware that
> > connects to the GPIO header on the Pi.  Replicating all this in U-Boot
> > would make very little sense.
>
> Note that in U-Boot we do have functionality to figure out and apply DT
> overlays for a platform, and it's generic enough that platforms can
> plugin their logic to detect what overlays are appropriate.  This is
> under CMD_EXTENSION.  It's not appropriate for Pi as they did all of
> this in their in-house firmware instead of using U-Boot.
>
> > > For example, if U-Boot evolves to support more devices, they could
> > > not be supported.
> >
> > Unless the device in question has a mechanism to load device tree
> > overlays like the Pi, this would require a firmware update.
>
> In that CMD_EXTENSION is about updating the tree for the next stage, and
> not ourself, yes.  But this is also the same problem that OSes have that
> lead to overlays, at least in part.  But also why it's so hard to
> support a static device tree on hardware, and have an evolving kernel.
> I'm not sure there's many / any good examples of wholly static and also
> feature complete device trees and OSes today, on a recent / semi-recent
> piece of hardware.
>
> > In practice, the device tree provided by the firmware will have more
> > stuff than U-Boot will ever need though.  Unless you're advocating
> > that U-Boot evolves into a full-fledged OS ;).
> >
> > > If UEFI is used, the devicetree would have no effect, since it doesn't
> > > support devicetree.
> >
> > That is not true.  UEFI supports device trees just fine.  All the
> > arm64 and riscv64 boards supported by U-Boot that include EFI_LOADER
> > support use device trees.  The idea that UEFI implies ACPI is a
> > misconception.
> >
> > > So perhaps the only remaining issue is with qemu on ARM / Risc-V?
> >
> > Maybe somebody can add device tree overlay support to QEMU?
>
> Having gone through this thread, I wonder if U-Boot generating a device
> tree overlay (and also the keeping the source of it, before
> preprocessing if we can) isn't part of the solution here.  Heinrich had
> suggested in another thread, and Simon had strongly disagreed with
> overlays being how we perhaps solve some portions of the overall "what
> should U-Boot require of the DT?" problem.  I'm thinking that might be
> the right answer, in some cases.
>
+1
U-Boot is best placed to deal with hats, capes among other things.

>
> --
> Tom
>


-- 
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog

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

[Simon Glass]

Hi Tom,

On Wed, 15 Sept 2021 at 07:35, Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, Sep 15, 2021 at 01:51:51PM +0200, Mark Kettenis wrote:
> > > From: Simon Glass <sjg@chromium.org>
> > > Date: Wed, 15 Sep 2021 04:13:24 -0600
> >
> > Hi Simon,
> >
> > > Hi Mark,
> > >
> > > On Sat, 11 Sept 2021 at 13:18, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > > >
> > > > > From: Moiz Imtiaz <moizimtiaz1@gmail.com>
> > > > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > Thanks for the reply.  I already followed the steps mentioned in
> > > > > "doc/uImage.FIT/beaglebone_vboot.txt".
> > > > >
> > > > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but
> > > > > instead one provided by the earlier-stage firmware?
> > > > >
> > > > > Not sure, but seems like this is the case. I checked and there isn't any
> > > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to
> > > > > add the dtb and other dts dtsi
> > > > > <https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom>files
> > > > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and
> > > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and
> > > > > it would just give a blank screen*. I wonder why there isn't any device
> > > > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by
> > > > > RPI4?
> > > >
> > > > The issue with the rpi4 is that the addresses of devices move around
> > > > based on the version of the Raspberry Pi firmware you're using.  And
> > > > possibly on the amount of memory on the board as well.  So U-Boot
> > > > pretty much has to use the device tree passed by the firmware since
> > > > the device tree in the U-Boot tree would be wrong for many
> > > > combinations of firmware and hardware.
> > > >
> > > > Simon, this sort of thing is exactly the reason why I think the idea
> > > > of having all U-Boot configuration information in a single device tree
> > > > with the hardware description doesn't work everywhere.
> > >
> > > >From my reading of this thread, it rather reinforces the need to
> > > provide a way to give U-Boot the config it needs, in the devicetree.
> >
> > As long as that configuration is optional, yes, maybe.
>
> Lets be a little careful.  We don't want to have two ways to provide the
> information for a given feature.  But some configuration properties are
> certainly optional.
>
> > > It seems that rpi is actually OK in this regard. If you think about
> > > it, it would be pretty hopeless if first-stage firmware assumed that
> > > it could provide a devicetree to whatever is next.
> >
> > Not hopeless.  If that device tree provides a hardware description
> > that is complete enough to boot Linux, it should be good enough to run
> > U-Boot.
>
> And keep in mind that one of those long stated goals is that the device
> tree for a platform lives physically on the platform and doesn't require
> being replaced entirely at run-time with a new/different device tree.
>
> > And yes, the Raspberry Pi has a nice way to load overlays to do
> > additional hardware configuration and support add-on hardware that
> > connects to the GPIO header on the Pi.  Replicating all this in U-Boot
> > would make very little sense.
>
> Note that in U-Boot we do have functionality to figure out and apply DT
> overlays for a platform, and it's generic enough that platforms can
> plugin their logic to detect what overlays are appropriate.  This is
> under CMD_EXTENSION.  It's not appropriate for Pi as they did all of
> this in their in-house firmware instead of using U-Boot.
>
> > > For example, if U-Boot evolves to support more devices, they could
> > > not be supported.
> >
> > Unless the device in question has a mechanism to load device tree
> > overlays like the Pi, this would require a firmware update.
>
> In that CMD_EXTENSION is about updating the tree for the next stage, and
> not ourself, yes.  But this is also the same problem that OSes have that
> lead to overlays, at least in part.  But also why it's so hard to
> support a static device tree on hardware, and have an evolving kernel.
> I'm not sure there's many / any good examples of wholly static and also
> feature complete device trees and OSes today, on a recent / semi-recent
> piece of hardware.
>
> > In practice, the device tree provided by the firmware will have more
> > stuff than U-Boot will ever need though.  Unless you're advocating
> > that U-Boot evolves into a full-fledged OS ;).
> >
> > > If UEFI is used, the devicetree would have no effect, since it doesn't
> > > support devicetree.
> >
> > That is not true.  UEFI supports device trees just fine.  All the
> > arm64 and riscv64 boards supported by U-Boot that include EFI_LOADER
> > support use device trees.  The idea that UEFI implies ACPI is a
> > misconception.
> >
> > > So perhaps the only remaining issue is with qemu on ARM / Risc-V?
> >
> > Maybe somebody can add device tree overlay support to QEMU?
>
> Having gone through this thread, I wonder if U-Boot generating a device
> tree overlay (and also the keeping the source of it, before
> preprocessing if we can) isn't part of the solution here.  Heinrich had
> suggested in another thread, and Simon had strongly disagreed with
> overlays being how we perhaps solve some portions of the overall "what
> should U-Boot require of the DT?" problem.  I'm thinking that might be
> the right answer, in some cases.

Note that my objection here is adding runtime to U-Boot. If the prior
stage wants to arrange things that way, it seems OK to me. In
particular for QEMU arm, we could add a -dtsi arg to provide a U-Boot
tree to merge with what it generates.

Regards,
Simon

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

[Tom Rini]

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

On Fri, Sep 17, 2021 at 10:21:15AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Wed, 15 Sept 2021 at 07:35, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Wed, Sep 15, 2021 at 01:51:51PM +0200, Mark Kettenis wrote:
> > > > From: Simon Glass <sjg@chromium.org>
> > > > Date: Wed, 15 Sep 2021 04:13:24 -0600
> > >
> > > Hi Simon,
> > >
> > > > Hi Mark,
> > > >
> > > > On Sat, 11 Sept 2021 at 13:18, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > > > >
> > > > > > From: Moiz Imtiaz <moizimtiaz1@gmail.com>
> > > > > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > > > > >
> > > > > > Hi Simon,
> > > > > >
> > > > > > Thanks for the reply.  I already followed the steps mentioned in
> > > > > > "doc/uImage.FIT/beaglebone_vboot.txt".
> > > > > >
> > > > > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but
> > > > > > instead one provided by the earlier-stage firmware?
> > > > > >
> > > > > > Not sure, but seems like this is the case. I checked and there isn't any
> > > > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to
> > > > > > add the dtb and other dts dtsi
> > > > > > <https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom>files
> > > > > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and
> > > > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and
> > > > > > it would just give a blank screen*. I wonder why there isn't any device
> > > > > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by
> > > > > > RPI4?
> > > > >
> > > > > The issue with the rpi4 is that the addresses of devices move around
> > > > > based on the version of the Raspberry Pi firmware you're using.  And
> > > > > possibly on the amount of memory on the board as well.  So U-Boot
> > > > > pretty much has to use the device tree passed by the firmware since
> > > > > the device tree in the U-Boot tree would be wrong for many
> > > > > combinations of firmware and hardware.
> > > > >
> > > > > Simon, this sort of thing is exactly the reason why I think the idea
> > > > > of having all U-Boot configuration information in a single device tree
> > > > > with the hardware description doesn't work everywhere.
> > > >
> > > > >From my reading of this thread, it rather reinforces the need to
> > > > provide a way to give U-Boot the config it needs, in the devicetree.
> > >
> > > As long as that configuration is optional, yes, maybe.
> >
> > Lets be a little careful.  We don't want to have two ways to provide the
> > information for a given feature.  But some configuration properties are
> > certainly optional.
> >
> > > > It seems that rpi is actually OK in this regard. If you think about
> > > > it, it would be pretty hopeless if first-stage firmware assumed that
> > > > it could provide a devicetree to whatever is next.
> > >
> > > Not hopeless.  If that device tree provides a hardware description
> > > that is complete enough to boot Linux, it should be good enough to run
> > > U-Boot.
> >
> > And keep in mind that one of those long stated goals is that the device
> > tree for a platform lives physically on the platform and doesn't require
> > being replaced entirely at run-time with a new/different device tree.
> >
> > > And yes, the Raspberry Pi has a nice way to load overlays to do
> > > additional hardware configuration and support add-on hardware that
> > > connects to the GPIO header on the Pi.  Replicating all this in U-Boot
> > > would make very little sense.
> >
> > Note that in U-Boot we do have functionality to figure out and apply DT
> > overlays for a platform, and it's generic enough that platforms can
> > plugin their logic to detect what overlays are appropriate.  This is
> > under CMD_EXTENSION.  It's not appropriate for Pi as they did all of
> > this in their in-house firmware instead of using U-Boot.
> >
> > > > For example, if U-Boot evolves to support more devices, they could
> > > > not be supported.
> > >
> > > Unless the device in question has a mechanism to load device tree
> > > overlays like the Pi, this would require a firmware update.
> >
> > In that CMD_EXTENSION is about updating the tree for the next stage, and
> > not ourself, yes.  But this is also the same problem that OSes have that
> > lead to overlays, at least in part.  But also why it's so hard to
> > support a static device tree on hardware, and have an evolving kernel.
> > I'm not sure there's many / any good examples of wholly static and also
> > feature complete device trees and OSes today, on a recent / semi-recent
> > piece of hardware.
> >
> > > In practice, the device tree provided by the firmware will have more
> > > stuff than U-Boot will ever need though.  Unless you're advocating
> > > that U-Boot evolves into a full-fledged OS ;).
> > >
> > > > If UEFI is used, the devicetree would have no effect, since it doesn't
> > > > support devicetree.
> > >
> > > That is not true.  UEFI supports device trees just fine.  All the
> > > arm64 and riscv64 boards supported by U-Boot that include EFI_LOADER
> > > support use device trees.  The idea that UEFI implies ACPI is a
> > > misconception.
> > >
> > > > So perhaps the only remaining issue is with qemu on ARM / Risc-V?
> > >
> > > Maybe somebody can add device tree overlay support to QEMU?
> >
> > Having gone through this thread, I wonder if U-Boot generating a device
> > tree overlay (and also the keeping the source of it, before
> > preprocessing if we can) isn't part of the solution here.  Heinrich had
> > suggested in another thread, and Simon had strongly disagreed with
> > overlays being how we perhaps solve some portions of the overall "what
> > should U-Boot require of the DT?" problem.  I'm thinking that might be
> > the right answer, in some cases.
> 
> Note that my objection here is adding runtime to U-Boot. If the prior
> stage wants to arrange things that way, it seems OK to me. In
> particular for QEMU arm, we could add a -dtsi arg to provide a U-Boot
> tree to merge with what it generates.

Right.  I am talking about U-Boot applying an overlay to a provided by
prior stage device tree.  In the above example of Pi, the prior stage
has an option already to apply an overlay before-hand, yes.  But that's
not going to be the case for all platforms.

-- 
Tom

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

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

[Simon Glass]

Hi Tom,

On Fri, 17 Sept 2021 at 11:42, Tom Rini <trini@konsulko.com> wrote:
>
> On Fri, Sep 17, 2021 at 10:21:15AM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Wed, 15 Sept 2021 at 07:35, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Wed, Sep 15, 2021 at 01:51:51PM +0200, Mark Kettenis wrote:
> > > > > From: Simon Glass <sjg@chromium.org>
> > > > > Date: Wed, 15 Sep 2021 04:13:24 -0600
> > > >
> > > > Hi Simon,
> > > >
> > > > > Hi Mark,
> > > > >
> > > > > On Sat, 11 Sept 2021 at 13:18, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > > > > >
> > > > > > > From: Moiz Imtiaz <moizimtiaz1@gmail.com>
> > > > > > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > > > > > >
> > > > > > > Hi Simon,
> > > > > > >
> > > > > > > Thanks for the reply.  I already followed the steps mentioned in
> > > > > > > "doc/uImage.FIT/beaglebone_vboot.txt".
> > > > > > >
> > > > > > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but
> > > > > > > instead one provided by the earlier-stage firmware?
> > > > > > >
> > > > > > > Not sure, but seems like this is the case. I checked and there isn't any
> > > > > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to
> > > > > > > add the dtb and other dts dtsi
> > > > > > > <https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom>files
> > > > > > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and
> > > > > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and
> > > > > > > it would just give a blank screen*. I wonder why there isn't any device
> > > > > > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by
> > > > > > > RPI4?
> > > > > >
> > > > > > The issue with the rpi4 is that the addresses of devices move around
> > > > > > based on the version of the Raspberry Pi firmware you're using.  And
> > > > > > possibly on the amount of memory on the board as well.  So U-Boot
> > > > > > pretty much has to use the device tree passed by the firmware since
> > > > > > the device tree in the U-Boot tree would be wrong for many
> > > > > > combinations of firmware and hardware.
> > > > > >
> > > > > > Simon, this sort of thing is exactly the reason why I think the idea
> > > > > > of having all U-Boot configuration information in a single device tree
> > > > > > with the hardware description doesn't work everywhere.
> > > > >
> > > > > >From my reading of this thread, it rather reinforces the need to
> > > > > provide a way to give U-Boot the config it needs, in the devicetree.
> > > >
> > > > As long as that configuration is optional, yes, maybe.
> > >
> > > Lets be a little careful.  We don't want to have two ways to provide the
> > > information for a given feature.  But some configuration properties are
> > > certainly optional.
> > >
> > > > > It seems that rpi is actually OK in this regard. If you think about
> > > > > it, it would be pretty hopeless if first-stage firmware assumed that
> > > > > it could provide a devicetree to whatever is next.
> > > >
> > > > Not hopeless.  If that device tree provides a hardware description
> > > > that is complete enough to boot Linux, it should be good enough to run
> > > > U-Boot.
> > >
> > > And keep in mind that one of those long stated goals is that the device
> > > tree for a platform lives physically on the platform and doesn't require
> > > being replaced entirely at run-time with a new/different device tree.
> > >
> > > > And yes, the Raspberry Pi has a nice way to load overlays to do
> > > > additional hardware configuration and support add-on hardware that
> > > > connects to the GPIO header on the Pi.  Replicating all this in U-Boot
> > > > would make very little sense.
> > >
> > > Note that in U-Boot we do have functionality to figure out and apply DT
> > > overlays for a platform, and it's generic enough that platforms can
> > > plugin their logic to detect what overlays are appropriate.  This is
> > > under CMD_EXTENSION.  It's not appropriate for Pi as they did all of
> > > this in their in-house firmware instead of using U-Boot.
> > >
> > > > > For example, if U-Boot evolves to support more devices, they could
> > > > > not be supported.
> > > >
> > > > Unless the device in question has a mechanism to load device tree
> > > > overlays like the Pi, this would require a firmware update.
> > >
> > > In that CMD_EXTENSION is about updating the tree for the next stage, and
> > > not ourself, yes.  But this is also the same problem that OSes have that
> > > lead to overlays, at least in part.  But also why it's so hard to
> > > support a static device tree on hardware, and have an evolving kernel.
> > > I'm not sure there's many / any good examples of wholly static and also
> > > feature complete device trees and OSes today, on a recent / semi-recent
> > > piece of hardware.
> > >
> > > > In practice, the device tree provided by the firmware will have more
> > > > stuff than U-Boot will ever need though.  Unless you're advocating
> > > > that U-Boot evolves into a full-fledged OS ;).
> > > >
> > > > > If UEFI is used, the devicetree would have no effect, since it doesn't
> > > > > support devicetree.
> > > >
> > > > That is not true.  UEFI supports device trees just fine.  All the
> > > > arm64 and riscv64 boards supported by U-Boot that include EFI_LOADER
> > > > support use device trees.  The idea that UEFI implies ACPI is a
> > > > misconception.
> > > >
> > > > > So perhaps the only remaining issue is with qemu on ARM / Risc-V?
> > > >
> > > > Maybe somebody can add device tree overlay support to QEMU?
> > >
> > > Having gone through this thread, I wonder if U-Boot generating a device
> > > tree overlay (and also the keeping the source of it, before
> > > preprocessing if we can) isn't part of the solution here.  Heinrich had
> > > suggested in another thread, and Simon had strongly disagreed with
> > > overlays being how we perhaps solve some portions of the overall "what
> > > should U-Boot require of the DT?" problem.  I'm thinking that might be
> > > the right answer, in some cases.
> >
> > Note that my objection here is adding runtime to U-Boot. If the prior
> > stage wants to arrange things that way, it seems OK to me. In
> > particular for QEMU arm, we could add a -dtsi arg to provide a U-Boot
> > tree to merge with what it generates.
>
> Right.  I am talking about U-Boot applying an overlay to a provided by
> prior stage device tree.  In the above example of Pi, the prior stage
> has an option already to apply an overlay before-hand, yes.  But that's
> not going to be the case for all platforms.

There is no need for the prior stage to apply an overlay though. It
just needs to provide the correct devicetree with the U-Boot
properties.

I'm going to send a binding for the config node upstream and see what happens.

Regards,
Simon

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

[Tom Rini]

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

On Sat, Sep 18, 2021 at 03:27:40AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, 17 Sept 2021 at 11:42, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Fri, Sep 17, 2021 at 10:21:15AM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Wed, 15 Sept 2021 at 07:35, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Wed, Sep 15, 2021 at 01:51:51PM +0200, Mark Kettenis wrote:
> > > > > > From: Simon Glass <sjg@chromium.org>
> > > > > > Date: Wed, 15 Sep 2021 04:13:24 -0600
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > > Hi Mark,
> > > > > >
> > > > > > On Sat, 11 Sept 2021 at 13:18, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > > > > > >
> > > > > > > > From: Moiz Imtiaz <moizimtiaz1@gmail.com>
> > > > > > > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > > > > > > >
> > > > > > > > Hi Simon,
> > > > > > > >
> > > > > > > > Thanks for the reply.  I already followed the steps mentioned in
> > > > > > > > "doc/uImage.FIT/beaglebone_vboot.txt".
> > > > > > > >
> > > > > > > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but
> > > > > > > > instead one provided by the earlier-stage firmware?
> > > > > > > >
> > > > > > > > Not sure, but seems like this is the case. I checked and there isn't any
> > > > > > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to
> > > > > > > > add the dtb and other dts dtsi
> > > > > > > > <https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom>files
> > > > > > > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and
> > > > > > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and
> > > > > > > > it would just give a blank screen*. I wonder why there isn't any device
> > > > > > > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by
> > > > > > > > RPI4?
> > > > > > >
> > > > > > > The issue with the rpi4 is that the addresses of devices move around
> > > > > > > based on the version of the Raspberry Pi firmware you're using.  And
> > > > > > > possibly on the amount of memory on the board as well.  So U-Boot
> > > > > > > pretty much has to use the device tree passed by the firmware since
> > > > > > > the device tree in the U-Boot tree would be wrong for many
> > > > > > > combinations of firmware and hardware.
> > > > > > >
> > > > > > > Simon, this sort of thing is exactly the reason why I think the idea
> > > > > > > of having all U-Boot configuration information in a single device tree
> > > > > > > with the hardware description doesn't work everywhere.
> > > > > >
> > > > > > >From my reading of this thread, it rather reinforces the need to
> > > > > > provide a way to give U-Boot the config it needs, in the devicetree.
> > > > >
> > > > > As long as that configuration is optional, yes, maybe.
> > > >
> > > > Lets be a little careful.  We don't want to have two ways to provide the
> > > > information for a given feature.  But some configuration properties are
> > > > certainly optional.
> > > >
> > > > > > It seems that rpi is actually OK in this regard. If you think about
> > > > > > it, it would be pretty hopeless if first-stage firmware assumed that
> > > > > > it could provide a devicetree to whatever is next.
> > > > >
> > > > > Not hopeless.  If that device tree provides a hardware description
> > > > > that is complete enough to boot Linux, it should be good enough to run
> > > > > U-Boot.
> > > >
> > > > And keep in mind that one of those long stated goals is that the device
> > > > tree for a platform lives physically on the platform and doesn't require
> > > > being replaced entirely at run-time with a new/different device tree.
> > > >
> > > > > And yes, the Raspberry Pi has a nice way to load overlays to do
> > > > > additional hardware configuration and support add-on hardware that
> > > > > connects to the GPIO header on the Pi.  Replicating all this in U-Boot
> > > > > would make very little sense.
> > > >
> > > > Note that in U-Boot we do have functionality to figure out and apply DT
> > > > overlays for a platform, and it's generic enough that platforms can
> > > > plugin their logic to detect what overlays are appropriate.  This is
> > > > under CMD_EXTENSION.  It's not appropriate for Pi as they did all of
> > > > this in their in-house firmware instead of using U-Boot.
> > > >
> > > > > > For example, if U-Boot evolves to support more devices, they could
> > > > > > not be supported.
> > > > >
> > > > > Unless the device in question has a mechanism to load device tree
> > > > > overlays like the Pi, this would require a firmware update.
> > > >
> > > > In that CMD_EXTENSION is about updating the tree for the next stage, and
> > > > not ourself, yes.  But this is also the same problem that OSes have that
> > > > lead to overlays, at least in part.  But also why it's so hard to
> > > > support a static device tree on hardware, and have an evolving kernel.
> > > > I'm not sure there's many / any good examples of wholly static and also
> > > > feature complete device trees and OSes today, on a recent / semi-recent
> > > > piece of hardware.
> > > >
> > > > > In practice, the device tree provided by the firmware will have more
> > > > > stuff than U-Boot will ever need though.  Unless you're advocating
> > > > > that U-Boot evolves into a full-fledged OS ;).
> > > > >
> > > > > > If UEFI is used, the devicetree would have no effect, since it doesn't
> > > > > > support devicetree.
> > > > >
> > > > > That is not true.  UEFI supports device trees just fine.  All the
> > > > > arm64 and riscv64 boards supported by U-Boot that include EFI_LOADER
> > > > > support use device trees.  The idea that UEFI implies ACPI is a
> > > > > misconception.
> > > > >
> > > > > > So perhaps the only remaining issue is with qemu on ARM / Risc-V?
> > > > >
> > > > > Maybe somebody can add device tree overlay support to QEMU?
> > > >
> > > > Having gone through this thread, I wonder if U-Boot generating a device
> > > > tree overlay (and also the keeping the source of it, before
> > > > preprocessing if we can) isn't part of the solution here.  Heinrich had
> > > > suggested in another thread, and Simon had strongly disagreed with
> > > > overlays being how we perhaps solve some portions of the overall "what
> > > > should U-Boot require of the DT?" problem.  I'm thinking that might be
> > > > the right answer, in some cases.
> > >
> > > Note that my objection here is adding runtime to U-Boot. If the prior
> > > stage wants to arrange things that way, it seems OK to me. In
> > > particular for QEMU arm, we could add a -dtsi arg to provide a U-Boot
> > > tree to merge with what it generates.
> >
> > Right.  I am talking about U-Boot applying an overlay to a provided by
> > prior stage device tree.  In the above example of Pi, the prior stage
> > has an option already to apply an overlay before-hand, yes.  But that's
> > not going to be the case for all platforms.
> 
> There is no need for the prior stage to apply an overlay though. It
> just needs to provide the correct devicetree with the U-Boot
> properties.

Well, it depends on what upstream is and how it handles things.  The
case where U-Boot is optional in the boot chain, like Pi, is perhaps
more common than we would like to admit, and at least Pi, and possibly
other cases also have a mechanism for applying overlays to the generated
device tree, in order to pass it to the kernel (or, U-Boot).

I'd almost say that if for no reason other than to make examples for
vboot, and other things too, available on Pi (as nearly everyone has one
in/on their desk), it's important to do so.  It's the most common
reference platform.

> I'm going to send a binding for the config node upstream and see what happens.

OK, please make sure to CC me, thanks!

-- 
Tom

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

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

[Simon Glass]

Hi Mark,

On Wed, 15 Sept 2021 at 05:52, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>
> > From: Simon Glass <sjg@chromium.org>
> > Date: Wed, 15 Sep 2021 04:13:24 -0600
>
> Hi Simon,
>
> > Hi Mark,
> >
> > On Sat, 11 Sept 2021 at 13:18, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > >
> > > > From: Moiz Imtiaz <moizimtiaz1@gmail.com>
> > > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > > >
> > > > Hi Simon,
> > > >
> > > > Thanks for the reply.  I already followed the steps mentioned in
> > > > "doc/uImage.FIT/beaglebone_vboot.txt".
> > > >
> > > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but
> > > > instead one provided by the earlier-stage firmware?
> > > >
> > > > Not sure, but seems like this is the case. I checked and there isn't any
> > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to
> > > > add the dtb and other dts dtsi
> > > > <https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom>files
> > > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and
> > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and
> > > > it would just give a blank screen*. I wonder why there isn't any device
> > > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by
> > > > RPI4?
> > >
> > > The issue with the rpi4 is that the addresses of devices move around
> > > based on the version of the Raspberry Pi firmware you're using.  And
> > > possibly on the amount of memory on the board as well.  So U-Boot
> > > pretty much has to use the device tree passed by the firmware since
> > > the device tree in the U-Boot tree would be wrong for many
> > > combinations of firmware and hardware.
> > >
> > > Simon, this sort of thing is exactly the reason why I think the idea
> > > of having all U-Boot configuration information in a single device tree
> > > with the hardware description doesn't work everywhere.
> >
> > >From my reading of this thread, it rather reinforces the need to
> > provide a way to give U-Boot the config it needs, in the devicetree.
>
> As long as that configuration is optional, yes, maybe.
>
> > It seems that rpi is actually OK in this regard. If you think about
> > it, it would be pretty hopeless if first-stage firmware assumed that
> > it could provide a devicetree to whatever is next.
>
> Not hopeless.  If that device tree provides a hardware description
> that is complete enough to boot Linux, it should be good enough to run
> U-Boot.

Not in general. I hope I have covered this in enormous detail in the
devicetree patch. But if you don't need verified boot, SPL or some
other feature that needs config, then perhaps you will get away with
it.

>
> And yes, the Raspberry Pi has a nice way to load overlays to do
> additional hardware configuration and support add-on hardware that
> connects to the GPIO header on the Pi.  Replicating all this in U-Boot
> would make very little sense.

Indeed, since AFAIK there is no way to use U-Boot as a first-stage
bootloader on rpi.

>
> > For example, if U-Boot evolves to support more devices, they could
> > not be supported.
>
> Unless the device in question has a mechanism to load device tree
> overlays like the Pi, this would require a firmware update.
>
> In practice, the device tree provided by the firmware will have more
> stuff than U-Boot will ever need though.  Unless you're advocating
> that U-Boot evolves into a full-fledged OS ;).

It is a constant risk.

>
> > If UEFI is used, the devicetree would have no effect, since it doesn't
> > support devicetree.
>
> That is not true.  UEFI supports device trees just fine.  All the
> arm64 and riscv64 boards supported by U-Boot that include EFI_LOADER
> support use device trees.  The idea that UEFI implies ACPI is a
> misconception.

François made the same point and I'm pretty sure you are talking about
booting a kernel using devicetree. Here, we are talking about setting
up the U-Boot control dtb correctly and my point was that UEFI does
not use a control dtb, so far as I know.

>
> > So perhaps the only remaining issue is with qemu on ARM / Risc-V?
>
> Maybe somebody can add device tree overlay support to QEMU?

Yes. I'm actually willing to do this once we get the UEFI embedded
signature reverted. I think it is pretty clear now that it is a dead
end.

Regards,
Simon

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

[Tom Rini]

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

On Fri, Sep 17, 2021 at 10:19:18AM -0600, Simon Glass wrote:
> Hi Mark,
> 
> On Wed, 15 Sept 2021 at 05:52, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> >
> > > From: Simon Glass <sjg@chromium.org>
> > > Date: Wed, 15 Sep 2021 04:13:24 -0600
> >
> > Hi Simon,
> >
> > > Hi Mark,
> > >
> > > On Sat, 11 Sept 2021 at 13:18, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > > >
> > > > > From: Moiz Imtiaz <moizimtiaz1@gmail.com>
> > > > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > Thanks for the reply.  I already followed the steps mentioned in
> > > > > "doc/uImage.FIT/beaglebone_vboot.txt".
> > > > >
> > > > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but
> > > > > instead one provided by the earlier-stage firmware?
> > > > >
> > > > > Not sure, but seems like this is the case. I checked and there isn't any
> > > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to
> > > > > add the dtb and other dts dtsi
> > > > > <https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom>files
> > > > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and
> > > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and
> > > > > it would just give a blank screen*. I wonder why there isn't any device
> > > > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by
> > > > > RPI4?
> > > >
> > > > The issue with the rpi4 is that the addresses of devices move around
> > > > based on the version of the Raspberry Pi firmware you're using.  And
> > > > possibly on the amount of memory on the board as well.  So U-Boot
> > > > pretty much has to use the device tree passed by the firmware since
> > > > the device tree in the U-Boot tree would be wrong for many
> > > > combinations of firmware and hardware.
> > > >
> > > > Simon, this sort of thing is exactly the reason why I think the idea
> > > > of having all U-Boot configuration information in a single device tree
> > > > with the hardware description doesn't work everywhere.
> > >
> > > >From my reading of this thread, it rather reinforces the need to
> > > provide a way to give U-Boot the config it needs, in the devicetree.
> >
> > As long as that configuration is optional, yes, maybe.
> >
> > > It seems that rpi is actually OK in this regard. If you think about
> > > it, it would be pretty hopeless if first-stage firmware assumed that
> > > it could provide a devicetree to whatever is next.
> >
> > Not hopeless.  If that device tree provides a hardware description
> > that is complete enough to boot Linux, it should be good enough to run
> > U-Boot.
> 
> Not in general. I hope I have covered this in enormous detail in the
> devicetree patch. But if you don't need verified boot, SPL or some
> other feature that needs config, then perhaps you will get away with
> it.

Wait, why does SPL _need_ it?  If something provides us with a device
tree, we don't need u-boot,dm-spl as that's used to filter nodes in to a
smaller DT to use.  Dealing with u-boot,dm-pre-reloc could be trickier,
but means whatever loaded us needs to have enabled any early clocks we
need.  But even then, it's just going to be output related?  And some
"was already configured" path could be used.

-- 
Tom

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

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

[Simon Glass]

Hi Tom,

On Fri, 17 Sept 2021 at 11:26, Tom Rini <trini@konsulko.com> wrote:
>
> On Fri, Sep 17, 2021 at 10:19:18AM -0600, Simon Glass wrote:
> > Hi Mark,
> >
> > On Wed, 15 Sept 2021 at 05:52, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > >
> > > > From: Simon Glass <sjg@chromium.org>
> > > > Date: Wed, 15 Sep 2021 04:13:24 -0600
> > >
> > > Hi Simon,
> > >
> > > > Hi Mark,
> > > >
> > > > On Sat, 11 Sept 2021 at 13:18, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > > > >
> > > > > > From: Moiz Imtiaz <moizimtiaz1@gmail.com>
> > > > > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > > > > >
> > > > > > Hi Simon,
> > > > > >
> > > > > > Thanks for the reply.  I already followed the steps mentioned in
> > > > > > "doc/uImage.FIT/beaglebone_vboot.txt".
> > > > > >
> > > > > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but
> > > > > > instead one provided by the earlier-stage firmware?
> > > > > >
> > > > > > Not sure, but seems like this is the case. I checked and there isn't any
> > > > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to
> > > > > > add the dtb and other dts dtsi
> > > > > > <https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom>files
> > > > > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and
> > > > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and
> > > > > > it would just give a blank screen*. I wonder why there isn't any device
> > > > > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by
> > > > > > RPI4?
> > > > >
> > > > > The issue with the rpi4 is that the addresses of devices move around
> > > > > based on the version of the Raspberry Pi firmware you're using.  And
> > > > > possibly on the amount of memory on the board as well.  So U-Boot
> > > > > pretty much has to use the device tree passed by the firmware since
> > > > > the device tree in the U-Boot tree would be wrong for many
> > > > > combinations of firmware and hardware.
> > > > >
> > > > > Simon, this sort of thing is exactly the reason why I think the idea
> > > > > of having all U-Boot configuration information in a single device tree
> > > > > with the hardware description doesn't work everywhere.
> > > >
> > > > >From my reading of this thread, it rather reinforces the need to
> > > > provide a way to give U-Boot the config it needs, in the devicetree.
> > >
> > > As long as that configuration is optional, yes, maybe.
> > >
> > > > It seems that rpi is actually OK in this regard. If you think about
> > > > it, it would be pretty hopeless if first-stage firmware assumed that
> > > > it could provide a devicetree to whatever is next.
> > >
> > > Not hopeless.  If that device tree provides a hardware description
> > > that is complete enough to boot Linux, it should be good enough to run
> > > U-Boot.
> >
> > Not in general. I hope I have covered this in enormous detail in the
> > devicetree patch. But if you don't need verified boot, SPL or some
> > other feature that needs config, then perhaps you will get away with
> > it.
>
> Wait, why does SPL _need_ it?  If something provides us with a device
> tree, we don't need u-boot,dm-spl as that's used to filter nodes in to a
> smaller DT to use.

Yes, although if the filtering is not done I am not sure what SPL
would do. In fact we don't have a way to provide two DTs (SPL, U-Boot
proper) from a prior boot stage at present.

>  Dealing with u-boot,dm-pre-reloc could be trickier,
> but means whatever loaded us needs to have enabled any early clocks we
> need.  But even then, it's just going to be output related?  And some
> "was already configured" path could be used.

My point is that ignoring U-Boot's devicetree requirements doesn't
work in general. It may work in specific cases. It cannot work for
verified boot of course.

Regards,
Simon

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

[Moiz Imtiaz]

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

Sure, would love to do a PR.

I basically replaced the dtb that pi loads with control Dtb of uboot, but
will do a PR of documentation addition in respect to pi_4, detailing
everything shortly :)

It does verifies the kernel, and other loadables, except (Dtb) because this
is what Pi is giving to Uboot , not sure whether at "starting kernel" stage
Uboot passes its own Dtb (verified one) or  the one passed by pi
(unverified/ can't be verified, as it gets passed to Uboot by pi). So in
true sense it's not a complete secure boot. Plus Pi_4 doesn't implement the
trustzone that Armv8 provides (Cortex A-72 ) so I am not sure how difficult
it would be for someone to change the config.txt(kernel=u-boot.bin) in
memory (from attackers perspective), resulting in normal pi bootloader to
be loaded rather  Uboot on next reboot.

If pi can make the config.txt immutable from memory , have kind of secure
world, than it would be great. Not sure, if pi has something as of this in
mind in near future implementation either.

On Sat, 18 Sep 2021, 14:28 Simon Glass, <sjg@chromium.org> wrote:

> Hi Tom,
>
> On Fri, 17 Sept 2021 at 11:26, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Fri, Sep 17, 2021 at 10:19:18AM -0600, Simon Glass wrote:
> > > Hi Mark,
> > >
> > > On Wed, 15 Sept 2021 at 05:52, Mark Kettenis <mark.kettenis@xs4all.nl>
> wrote:
> > > >
> > > > > From: Simon Glass <sjg@chromium.org>
> > > > > Date: Wed, 15 Sep 2021 04:13:24 -0600
> > > >
> > > > Hi Simon,
> > > >
> > > > > Hi Mark,
> > > > >
> > > > > On Sat, 11 Sept 2021 at 13:18, Mark Kettenis <
> mark.kettenis@xs4all.nl> wrote:
> > > > > >
> > > > > > > From: Moiz Imtiaz <moizimtiaz1@gmail.com>
> > > > > > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > > > > > >
> > > > > > > Hi Simon,
> > > > > > >
> > > > > > > Thanks for the reply.  I already followed the steps mentioned
> in
> > > > > > > "doc/uImage.FIT/beaglebone_vboot.txt".
> > > > > > >
> > > > > > > >I wonder if rpi is not using the devicetree compiled with
> U-Boot, but
> > > > > > > instead one provided by the earlier-stage firmware?
> > > > > > >
> > > > > > > Not sure, but seems like this is the case. I checked and there
> isn't any
> > > > > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in
> u-boot. I tried to
> > > > > > > add the dtb and other dts dtsi
> > > > > > > <
> https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom
> >files
> > > > > > > from the raspberry pi Linux and compile them with
> CONFIG_OF_SEPARATE and
> > > > > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the
> U-Boot and
> > > > > > > it would just give a blank screen*. I wonder why there isn't
> any device
> > > > > > > tree in the U-boot repo for RPI4. Is U-boot control FDT not
> supported by
> > > > > > > RPI4?
> > > > > >
> > > > > > The issue with the rpi4 is that the addresses of devices move
> around
> > > > > > based on the version of the Raspberry Pi firmware you're using.
> And
> > > > > > possibly on the amount of memory on the board as well.  So U-Boot
> > > > > > pretty much has to use the device tree passed by the firmware
> since
> > > > > > the device tree in the U-Boot tree would be wrong for many
> > > > > > combinations of firmware and hardware.
> > > > > >
> > > > > > Simon, this sort of thing is exactly the reason why I think the
> idea
> > > > > > of having all U-Boot configuration information in a single
> device tree
> > > > > > with the hardware description doesn't work everywhere.
> > > > >
> > > > > >From my reading of this thread, it rather reinforces the need to
> > > > > provide a way to give U-Boot the config it needs, in the
> devicetree.
> > > >
> > > > As long as that configuration is optional, yes, maybe.
> > > >
> > > > > It seems that rpi is actually OK in this regard. If you think about
> > > > > it, it would be pretty hopeless if first-stage firmware assumed
> that
> > > > > it could provide a devicetree to whatever is next.
> > > >
> > > > Not hopeless.  If that device tree provides a hardware description
> > > > that is complete enough to boot Linux, it should be good enough to
> run
> > > > U-Boot.
> > >
> > > Not in general. I hope I have covered this in enormous detail in the
> > > devicetree patch. But if you don't need verified boot, SPL or some
> > > other feature that needs config, then perhaps you will get away with
> > > it.
> >
> > Wait, why does SPL _need_ it?  If something provides us with a device
> > tree, we don't need u-boot,dm-spl as that's used to filter nodes in to a
> > smaller DT to use.
>
> Yes, although if the filtering is not done I am not sure what SPL
> would do. In fact we don't have a way to provide two DTs (SPL, U-Boot
> proper) from a prior boot stage at present.
>
> >  Dealing with u-boot,dm-pre-reloc could be trickier,
> > but means whatever loaded us needs to have enabled any early clocks we
> > need.  But even then, it's just going to be output related?  And some
> > "was already configured" path could be used.
>
> My point is that ignoring U-Boot's devicetree requirements doesn't
> work in general. It may work in specific cases. It cannot work for
> verified boot of course.
>
> Regards,
> Simon
>

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

[Mark Kettenis]

> From: Moiz Imtiaz <moizimtiaz1@gmail.com>
> Date: Sat, 18 Sep 2021 14:47:51 +0500
> 
> >Nice!  If you want to write something up extending the >documentation on
> >how you made this work for Pi it would be much appreciated.
> 
> Sure, would love to do a PR.  
> 
> I basically replaced the dtb that pi loads with control Dtb of uboot, but
> will do a PR of documentation addition in respect to pi_4, detailing
> everything shortly :)

Sorry, but I don't think this is safe.  The Raspberry Pi firmware
makes changes to the device tree and it is unclear what requirements
it has in terms of names of nodes and compatible strings since the
firmware is closed source.  It should be fine to add stuff to the DTB
that came with the firmware, but replacing it altogether is probably
going to break things in subtle ways.  So I don't think that is
something we should advocate by documenting it in U-Boot.

Creating a DT overlay and specifying it in config.txt should be much
more robust than doing a wholesale replacement of the firmware DT.

> It does verifies the kernel, and other loadables, except (Dtb) because this
> is what Pi is giving to Uboot , not sure whether at "starting kernel" stage
> Uboot passes its own Dtb (verified one) or  the one passed by pi
> (unverified/ can't be verified, as it gets passed to Uboot by pi). So in
> true sense it's not a complete secure boot. Plus Pi_4 doesn't implement the
> trustzone that Armv8 provides (Cortex A-72 ) so I am not sure how difficult
> it would be for someone to change the config.txt(kernel=u-boot.bin) in
> memory (from attackers perspective), resulting in normal pi bootloader to be
> loaded rather  Uboot on next reboot. 
> 
> If pi can make the config.txt immutable from memory , have kind of secure
> world, than it would be great. Not sure, if pi has something as of this in
> mind in near future implementation either. 
> 
> On Sat, 18 Sep 2021, 14:28 Simon Glass, <sjg@chromium.org> wrote:
> 
>  Hi Tom,
> 
>  On Fri, 17 Sept 2021 at 11:26, Tom Rini <trini@konsulko.com> wrote:
>  >
>  > On Fri, Sep 17, 2021 at 10:19:18AM -0600, Simon Glass wrote:
>  > > Hi Mark,
>  > >
>  > > On Wed, 15 Sept 2021 at 05:52, Mark Kettenis
>  <mark.kettenis@xs4all.nl> wrote:
>  > > >
>  > > > > From: Simon Glass <sjg@chromium.org>
>  > > > > Date: Wed, 15 Sep 2021 04:13:24 -0600
>  > > >
>  > > > Hi Simon,
>  > > >
>  > > > > Hi Mark,
>  > > > >
>  > > > > On Sat, 11 Sept 2021 at 13:18, Mark Kettenis
>  <mark.kettenis@xs4all.nl> wrote:
>  > > > > >
>  > > > > > > From: Moiz Imtiaz <moizimtiaz1@gmail.com>
>  > > > > > > Date: Sat, 11 Sep 2021 23:19:05 +0500
>  > > > > > >
>  > > > > > > Hi Simon,
>  > > > > > >
>  > > > > > > Thanks for the reply.  I already followed the steps
>  mentioned in
>  > > > > > > "doc/uImage.FIT/beaglebone_vboot.txt".
>  > > > > > >
>  > > > > > > >I wonder if rpi is not using the devicetree compiled with
>  U-Boot, but
>  > > > > > > instead one provided by the earlier-stage firmware?
>  > > > > > >
>  > > > > > > Not sure, but seems like this is the case. I checked and
>  there isn't any
>  > > > > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in
>  u-boot. I tried to
>  > > > > > > add the dtb and other dts dtsi
>  > > > > > >
>  <https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom>files
>  
>  > > > > > > from the raspberry pi Linux and compile them with
>  CONFIG_OF_SEPARATE and
>  > > > > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot
>  the U-Boot and
>  > > > > > > it would just give a blank screen*. I wonder why there isn't
>  any device
>  > > > > > > tree in the U-boot repo for RPI4. Is U-boot control FDT not
>  supported by
>  > > > > > > RPI4?
>  > > > > >
>  > > > > > The issue with the rpi4 is that the addresses of devices move
>  around
>  > > > > > based on the version of the Raspberry Pi firmware you're
>  using.  And
>  > > > > > possibly on the amount of memory on the board as well.  So
>  U-Boot
>  > > > > > pretty much has to use the device tree passed by the firmware
>  since
>  > > > > > the device tree in the U-Boot tree would be wrong for many
>  > > > > > combinations of firmware and hardware.
>  > > > > >
>  > > > > > Simon, this sort of thing is exactly the reason why I think
>  the idea
>  > > > > > of having all U-Boot configuration information in a single
>  device tree
>  > > > > > with the hardware description doesn't work everywhere.
>  > > > >
>  > > > > >From my reading of this thread, it rather reinforces the need
>  to
>  > > > > provide a way to give U-Boot the config it needs, in the
>  devicetree.
>  > > >
>  > > > As long as that configuration is optional, yes, maybe.
>  > > >
>  > > > > It seems that rpi is actually OK in this regard. If you think
>  about
>  > > > > it, it would be pretty hopeless if first-stage firmware assumed
>  that
>  > > > > it could provide a devicetree to whatever is next.
>  > > >
>  > > > Not hopeless.  If that device tree provides a hardware description
>  > > > that is complete enough to boot Linux, it should be good enough to
>  run
>  > > > U-Boot.
>  > >
>  > > Not in general. I hope I have covered this in enormous detail in the
>  > > devicetree patch. But if you don't need verified boot, SPL or some
>  > > other feature that needs config, then perhaps you will get away with
>  > > it.
>  >
>  > Wait, why does SPL _need_ it?  If something provides us with a device
>  > tree, we don't need u-boot,dm-spl as that's used to filter nodes in to
>  a
>  > smaller DT to use.
> 
>  Yes, although if the filtering is not done I am not sure what SPL
>  would do. In fact we don't have a way to provide two DTs (SPL, U-Boot
>  proper) from a prior boot stage at present.
> 
>  >  Dealing with u-boot,dm-pre-reloc could be trickier,
>  > but means whatever loaded us needs to have enabled any early clocks we
>  > need.  But even then, it's just going to be output related?  And some
>  > "was already configured" path could be used.
> 
>  My point is that ignoring U-Boot's devicetree requirements doesn't
>  work in general. It may work in specific cases. It cannot work for
>  verified boot of course.
> 
>  Regards,
>  Simon

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

[François Ozog]

Le sam. 18 sept. 2021 à 12:10, Mark Kettenis <mark.kettenis@xs4all.nl> a
écrit :

> > From: Moiz Imtiaz <moizimtiaz1@gmail.com>
> > Date: Sat, 18 Sep 2021 14:47:51 +0500
> >
> > >Nice!  If you want to write something up extending the >documentation on
> > >how you made this work for Pi it would be much appreciated.
> >
> > Sure, would love to do a PR.
> >
> > I basically replaced the dtb that pi loads with control Dtb of uboot, but
> > will do a PR of documentation addition in respect to pi_4, detailing
> > everything shortly :)
>
> Sorry, but I don't think this is safe.  The Raspberry Pi firmware
> makes changes to the device tree and it is unclear what requirements
> it has in terms of names of nodes and compatible strings since the
> firmware is closed source.  It should be fine to add stuff to the DTB
> that came with the firmware, but replacing it altogether is probably
> going to break things in subtle ways.  So I don't think that is
> something we should advocate by documenting it in U-Boot.
>
The way I see the chain of trust is: I don’t know how the GPU firmware is
checked (or even if it is checked), The GPU firmware does not check or
measure the booted kernel from kernel=xyz that it gets from the unverified
config.txt which have been building a hardware description from unverified
files from the file system.

Bottom line, trying to create a secure boot flow on RPI4 may lead into
impression of security while it is not supported at hardware level.
Impression of security can be worse than no security at all.

Creating a DT overlay and specifying it in config.txt should be much
> more robust than doing a wholesale replacement of the firmware DT.
>
> > It does verifies the kernel, and other loadables, except (Dtb) because
> this
> > is what Pi is giving to Uboot , not sure whether at "starting kernel"
> stage
> > Uboot passes its own Dtb (verified one) or  the one passed by pi
> > (unverified/ can't be verified, as it gets passed to Uboot by pi). So in
> > true sense it's not a complete secure boot. Plus Pi_4 doesn't implement
> the
> > trustzone that Armv8 provides (Cortex A-72 ) so I am not sure how
> difficult
> > it would be for someone to change the config.txt(kernel=u-boot.bin) in
> > memory (from attackers perspective), resulting in normal pi bootloader
> to be
> > loaded rather  Uboot on next reboot.
> >
> > If pi can make the config.txt immutable from memory , have kind of secure
> > world, than it would be great. Not sure, if pi has something as of this
> in
> > mind in near future implementation either.
> >
> > On Sat, 18 Sep 2021, 14:28 Simon Glass, <sjg@chromium.org> wrote:
> >
> >  Hi Tom,
> >
> >  On Fri, 17 Sept 2021 at 11:26, Tom Rini <trini@konsulko.com> wrote:
> >  >
> >  > On Fri, Sep 17, 2021 at 10:19:18AM -0600, Simon Glass wrote:
> >  > > Hi Mark,
> >  > >
> >  > > On Wed, 15 Sept 2021 at 05:52, Mark Kettenis
> >  <mark.kettenis@xs4all.nl> wrote:
> >  > > >
> >  > > > > From: Simon Glass <sjg@chromium.org>
> >  > > > > Date: Wed, 15 Sep 2021 04:13:24 -0600
> >  > > >
> >  > > > Hi Simon,
> >  > > >
> >  > > > > Hi Mark,
> >  > > > >
> >  > > > > On Sat, 11 Sept 2021 at 13:18, Mark Kettenis
> >  <mark.kettenis@xs4all.nl> wrote:
> >  > > > > >
> >  > > > > > > From: Moiz Imtiaz <moizimtiaz1@gmail.com>
> >  > > > > > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> >  > > > > > >
> >  > > > > > > Hi Simon,
> >  > > > > > >
> >  > > > > > > Thanks for the reply.  I already followed the steps
> >  mentioned in
> >  > > > > > > "doc/uImage.FIT/beaglebone_vboot.txt".
> >  > > > > > >
> >  > > > > > > >I wonder if rpi is not using the devicetree compiled with
> >  U-Boot, but
> >  > > > > > > instead one provided by the earlier-stage firmware?
> >  > > > > > >
> >  > > > > > > Not sure, but seems like this is the case. I checked and
> >  there isn't any
> >  > > > > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in
> >  u-boot. I tried to
> >  > > > > > > add the dtb and other dts dtsi
> >  > > > > > >
> >  <
> https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom
> >files
> >
> >  > > > > > > from the raspberry pi Linux and compile them with
> >  CONFIG_OF_SEPARATE and
> >  > > > > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot
> >  the U-Boot and
> >  > > > > > > it would just give a blank screen*. I wonder why there isn't
> >  any device
> >  > > > > > > tree in the U-boot repo for RPI4. Is U-boot control FDT not
> >  supported by
> >  > > > > > > RPI4?
> >  > > > > >
> >  > > > > > The issue with the rpi4 is that the addresses of devices move
> >  around
> >  > > > > > based on the version of the Raspberry Pi firmware you're
> >  using.  And
> >  > > > > > possibly on the amount of memory on the board as well.  So
> >  U-Boot
> >  > > > > > pretty much has to use the device tree passed by the firmware
> >  since
> >  > > > > > the device tree in the U-Boot tree would be wrong for many
> >  > > > > > combinations of firmware and hardware.
> >  > > > > >
> >  > > > > > Simon, this sort of thing is exactly the reason why I think
> >  the idea
> >  > > > > > of having all U-Boot configuration information in a single
> >  device tree
> >  > > > > > with the hardware description doesn't work everywhere.
> >  > > > >
> >  > > > > >From my reading of this thread, it rather reinforces the need
> >  to
> >  > > > > provide a way to give U-Boot the config it needs, in the
> >  devicetree.
> >  > > >
> >  > > > As long as that configuration is optional, yes, maybe.
> >  > > >
> >  > > > > It seems that rpi is actually OK in this regard. If you think
> >  about
> >  > > > > it, it would be pretty hopeless if first-stage firmware assumed
> >  that
> >  > > > > it could provide a devicetree to whatever is next.
> >  > > >
> >  > > > Not hopeless.  If that device tree provides a hardware description
> >  > > > that is complete enough to boot Linux, it should be good enough to
> >  run
> >  > > > U-Boot.
> >  > >
> >  > > Not in general. I hope I have covered this in enormous detail in the
> >  > > devicetree patch. But if you don't need verified boot, SPL or some
> >  > > other feature that needs config, then perhaps you will get away with
> >  > > it.
> >  >
> >  > Wait, why does SPL _need_ it?  If something provides us with a device
> >  > tree, we don't need u-boot,dm-spl as that's used to filter nodes in to
> >  a
> >  > smaller DT to use.
> >
> >  Yes, although if the filtering is not done I am not sure what SPL
> >  would do. In fact we don't have a way to provide two DTs (SPL, U-Boot
> >  proper) from a prior boot stage at present.
> >
> >  >  Dealing with u-boot,dm-pre-reloc could be trickier,
> >  > but means whatever loaded us needs to have enabled any early clocks we
> >  > need.  But even then, it's just going to be output related?  And some
> >  > "was already configured" path could be used.
> >
> >  My point is that ignoring U-Boot's devicetree requirements doesn't
> >  work in general. It may work in specific cases. It cannot work for
> >  verified boot of course.
> >
> >  Regards,
> >  Simon
>
-- 
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog

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

[Moiz Imtiaz]

Tbh, the reason why I didn't do overlay is that I am not comfortable with
it. I still have to learn how to do dtbo, and that is why I didn't add a PR
to the documentation. I understand adding a dtbo is more robust and better
way.

What I replaced with was a copy of the original device tree that came with
the firmware or one can get it from pi's GitHub and using mkimage added the
public key to it.

I completely agree that achieving a complete secure boot in pi is not
possible and I have mentioned few reasons in the initial thread as well.
One reason being that the Root of Trust can't be achieved in its true way.
The pi loads from GPU and we get control at 3rd stage of the pi bootloader
from where, our U-boot comes, what happens before it, can't be verified
because the (bootloader.bin) and (start.elf) are both closed source and PI
doesn't offer any HAB either.

Secondly, relying on an unverified config.txt which theoretically speaking
can be replaced by an attacker having shell access is not a secure way. as
in PI, AFAIK, it's flat memory and there isn't any Arm trustzone or TF-A
implemented, so one would be relying completely on an unverified congif.txt
file.

Other than that, since there isn't any HAB, or efuses, the physcial attack
vector is always there. Anyone with physical access can flash the emmc or
sdcard and replace it with their own FIT (having kernel) and Control FDT or
just replace the u-boot.bin with their own u-boot.

I guess, pi wanted to reduce the cost and compensated on the security
features.

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

[Moiz Imtiaz]

I will try to learn how to create a dtbo, and do a PR to documentation. I
ain't an embedded or kernel guru like you guys.

I have a complete security background with primarily appsec :)

But I agree that we should have some documentation because
1. It's a common reference platform
2. At the moment we don't have any public doc on how to achieve signature
validation on Pi-4.

I know it won't be a complete secure boot, but will do a PR nonetheless. :)

We can then improve the writeup, with the passage of time,if needs
required.

On Sat, 18 Sep 2021, 18:24 Moiz Imtiaz, <moizimtiaz1@gmail.com> wrote:

> Tbh, the reason why I didn't do overlay is that I am not comfortable with
> it. I still have to learn how to do dtbo, and that is why I didn't add a PR
> to the documentation. I understand adding a dtbo is more robust and better
> way.
>
> What I replaced with was a copy of the original device tree that came with
> the firmware or one can get it from pi's GitHub and using mkimage added the
> public key to it.
>
> I completely agree that achieving a complete secure boot in pi is not
> possible and I have mentioned few reasons in the initial thread as well.
> One reason being that the Root of Trust can't be achieved in its true way.
> The pi loads from GPU and we get control at 3rd stage of the pi bootloader
> from where, our U-boot comes, what happens before it, can't be verified
> because the (bootloader.bin) and (start.elf) are both closed source and PI
> doesn't offer any HAB either.
>
> Secondly, relying on an unverified config.txt which theoretically speaking
> can be replaced by an attacker having shell access is not a secure way. as
> in PI, AFAIK, it's flat memory and there isn't any Arm trustzone or TF-A
> implemented, so one would be relying completely on an unverified congif.txt
> file.
>
> Other than that, since there isn't any HAB, or efuses, the physcial attack
> vector is always there. Anyone with physical access can flash the emmc or
> sdcard and replace it with their own FIT (having kernel) and Control FDT or
> just replace the u-boot.bin with their own u-boot.
>
> I guess, pi wanted to reduce the cost and compensated on the security
> features.
>

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

[Tom Rini]

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

On Sat, Sep 18, 2021 at 12:26:00PM +0200, François Ozog wrote:
> Le sam. 18 sept. 2021 à 12:10, Mark Kettenis <mark.kettenis@xs4all.nl> a
> écrit :
> 
> > > From: Moiz Imtiaz <moizimtiaz1@gmail.com>
> > > Date: Sat, 18 Sep 2021 14:47:51 +0500
> > >
> > > >Nice!  If you want to write something up extending the >documentation on
> > > >how you made this work for Pi it would be much appreciated.
> > >
> > > Sure, would love to do a PR.
> > >
> > > I basically replaced the dtb that pi loads with control Dtb of uboot, but
> > > will do a PR of documentation addition in respect to pi_4, detailing
> > > everything shortly :)
> >
> > Sorry, but I don't think this is safe.  The Raspberry Pi firmware
> > makes changes to the device tree and it is unclear what requirements
> > it has in terms of names of nodes and compatible strings since the
> > firmware is closed source.  It should be fine to add stuff to the DTB
> > that came with the firmware, but replacing it altogether is probably
> > going to break things in subtle ways.  So I don't think that is
> > something we should advocate by documenting it in U-Boot.
>
> The way I see the chain of trust is: I don’t know how the GPU firmware is
> checked (or even if it is checked), The GPU firmware does not check or
> measure the booted kernel from kernel=xyz that it gets from the unverified
> config.txt which have been building a hardware description from unverified
> files from the file system.
> 
> Bottom line, trying to create a secure boot flow on RPI4 may lead into
> impression of security while it is not supported at hardware level.
> Impression of security can be worse than no security at all.

In general, there's always the questionable value of enabling some level
of "secure" boot on platforms where we don't have a root of trust
starting from the hardware, nor hardware assist later on.  But there is
some value in documenting how to enable the commodity (versus
SoC-specific) functionality on very common reference platforms.
Sometimes even more so even on platforms you can't otherwise potentially
lock yourself out of.

-- 
Tom

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

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

[Mark Kettenis]

> From: Simon Glass <sjg@chromium.org>
> Date: Sat, 18 Sep 2021 03:27:48 -0600
> 
> Hi Tom,
> 
> On Fri, 17 Sept 2021 at 11:26, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Fri, Sep 17, 2021 at 10:19:18AM -0600, Simon Glass wrote:
> > > Hi Mark,
> > >
> > > On Wed, 15 Sept 2021 at 05:52, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > > >
> > > > > From: Simon Glass <sjg@chromium.org>
> > > > > Date: Wed, 15 Sep 2021 04:13:24 -0600
> > > >
> > > > Hi Simon,
> > > >
> > > > > Hi Mark,
> > > > >
> > > > > On Sat, 11 Sept 2021 at 13:18, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > > > > >
> > > > > > > From: Moiz Imtiaz <moizimtiaz1@gmail.com>
> > > > > > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > > > > > >
> > > > > > > Hi Simon,
> > > > > > >
> > > > > > > Thanks for the reply.  I already followed the steps mentioned in
> > > > > > > "doc/uImage.FIT/beaglebone_vboot.txt".
> > > > > > >
> > > > > > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but
> > > > > > > instead one provided by the earlier-stage firmware?
> > > > > > >
> > > > > > > Not sure, but seems like this is the case. I checked and there isn't any
> > > > > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to
> > > > > > > add the dtb and other dts dtsi
> > > > > > > <https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom>files
> > > > > > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and
> > > > > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and
> > > > > > > it would just give a blank screen*. I wonder why there isn't any device
> > > > > > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by
> > > > > > > RPI4?
> > > > > >
> > > > > > The issue with the rpi4 is that the addresses of devices move around
> > > > > > based on the version of the Raspberry Pi firmware you're using.  And
> > > > > > possibly on the amount of memory on the board as well.  So U-Boot
> > > > > > pretty much has to use the device tree passed by the firmware since
> > > > > > the device tree in the U-Boot tree would be wrong for many
> > > > > > combinations of firmware and hardware.
> > > > > >
> > > > > > Simon, this sort of thing is exactly the reason why I think the idea
> > > > > > of having all U-Boot configuration information in a single device tree
> > > > > > with the hardware description doesn't work everywhere.
> > > > >
> > > > > >From my reading of this thread, it rather reinforces the need to
> > > > > provide a way to give U-Boot the config it needs, in the devicetree.
> > > >
> > > > As long as that configuration is optional, yes, maybe.
> > > >
> > > > > It seems that rpi is actually OK in this regard. If you think about
> > > > > it, it would be pretty hopeless if first-stage firmware assumed that
> > > > > it could provide a devicetree to whatever is next.
> > > >
> > > > Not hopeless.  If that device tree provides a hardware description
> > > > that is complete enough to boot Linux, it should be good enough to run
> > > > U-Boot.
> > >
> > > Not in general. I hope I have covered this in enormous detail in the
> > > devicetree patch. But if you don't need verified boot, SPL or some
> > > other feature that needs config, then perhaps you will get away with
> > > it.
> >
> > Wait, why does SPL _need_ it?  If something provides us with a device
> > tree, we don't need u-boot,dm-spl as that's used to filter nodes in to a
> > smaller DT to use.
> 
> Yes, although if the filtering is not done I am not sure what SPL
> would do. In fact we don't have a way to provide two DTs (SPL, U-Boot
> proper) from a prior boot stage at present.

I still think that if there is some sort of prior stage firmware,
there typically is no need for SPL.  And if there is, DRAM is probably
set up already and there are no space constraints so using the full DT
isn't an issue.

> >  Dealing with u-boot,dm-pre-reloc could be trickier,
> > but means whatever loaded us needs to have enabled any early clocks we
> > need.  But even then, it's just going to be output related?  And some
> > "was already configured" path could be used.
> 
> My point is that ignoring U-Boot's devicetree requirements doesn't
> work in general. It may work in specific cases. It cannot work for
> verified boot of course.

And this is I think the root of the controversy.  IMHO, U-Boot should
have no "hard" devicetree requirements other than the requirement that
the device tree provides a complete enough description of the hardware
using standardized DT bindings.

That doesn't mean you can't have something like a /config node with
U-Boot specific options.  I'd say that would be a great way for prior
stage firmware to control U-Boot behaviour.

But what it does mean is that none of those options can be a "hard"
requirement in the sense that in order to have a functioning U-Boot on
a platform you absolutely have to have U-Boot specific nodes and/or
properties in your DT.

I guess what I'm saying/asking is, why can't we have some sort of
middle ground here?

If there is no prior-stage firmware to speak of and U-Boot is entirely
responsible for bootstrapping a board (the typical scenario where you
need SPL/TPL) I don't see a problem with having a control DT that
specifies everything.

If there is prior-stage firmware, and U-Boot proper is the canonical
payload for that firmware on a board, adding U-Boot specific stuff to
the DT should be no issue.  There are some obvious issues here in
keeping DT bindings in synch between the prior-stage firmware and
U-Boot in that case, so standardizing/upstreaming the U-Boot DT
bindings would be helpful in this scenario.

If U-Boot is just one of many choices for the payload having U-Boot
specific stuff in the DT may not make sense.  In that scenario you'd
just get reasonable default behaviour (and potentially no verified
boot).  But it should be possible to change the default behaviour
using the U-Boot environment variables in cases where it makes sense.

I'm not yet sure where my Apple M1 work is going to land on this
spectrum.  I think doing verified boot here is doable when using
u-boot as a payload.  Currently the m1n1 bootloader, the DTB and
U-Boot are combined into a single Mach-O binary and there is a special
procedure that requires username/password verification to "enroll"
that binary as a bootable "kernel" for Apple's bootloader.  I believe
that means that it can't be tampered with without physical access to
the machine and providing the password of the "owner" of the machine.
So embedding the public key that verifies subsequent stages (e.g. a
FIT image or an EFI binary) should work just fine.

Cheers,

Mark

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

[Simon Glass]

Hi Mark,

On Sat, 18 Sept 2021 at 05:15, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>
> > From: Simon Glass <sjg@chromium.org>
> > Date: Sat, 18 Sep 2021 03:27:48 -0600
> >
> > Hi Tom,
> >
> > On Fri, 17 Sept 2021 at 11:26, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Fri, Sep 17, 2021 at 10:19:18AM -0600, Simon Glass wrote:
> > > > Hi Mark,
> > > >
> > > > On Wed, 15 Sept 2021 at 05:52, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > > > >
> > > > > > From: Simon Glass <sjg@chromium.org>
> > > > > > Date: Wed, 15 Sep 2021 04:13:24 -0600
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > > Hi Mark,
> > > > > >
> > > > > > On Sat, 11 Sept 2021 at 13:18, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > > > > > >
> > > > > > > > From: Moiz Imtiaz <moizimtiaz1@gmail.com>
> > > > > > > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > > > > > > >
> > > > > > > > Hi Simon,
> > > > > > > >
> > > > > > > > Thanks for the reply.  I already followed the steps mentioned in
> > > > > > > > "doc/uImage.FIT/beaglebone_vboot.txt".
> > > > > > > >
> > > > > > > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but
> > > > > > > > instead one provided by the earlier-stage firmware?
> > > > > > > >
> > > > > > > > Not sure, but seems like this is the case. I checked and there isn't any
> > > > > > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to
> > > > > > > > add the dtb and other dts dtsi
> > > > > > > > <https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom>files
> > > > > > > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and
> > > > > > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and
> > > > > > > > it would just give a blank screen*. I wonder why there isn't any device
> > > > > > > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by
> > > > > > > > RPI4?
> > > > > > >
> > > > > > > The issue with the rpi4 is that the addresses of devices move around
> > > > > > > based on the version of the Raspberry Pi firmware you're using.  And
> > > > > > > possibly on the amount of memory on the board as well.  So U-Boot
> > > > > > > pretty much has to use the device tree passed by the firmware since
> > > > > > > the device tree in the U-Boot tree would be wrong for many
> > > > > > > combinations of firmware and hardware.
> > > > > > >
> > > > > > > Simon, this sort of thing is exactly the reason why I think the idea
> > > > > > > of having all U-Boot configuration information in a single device tree
> > > > > > > with the hardware description doesn't work everywhere.
> > > > > >
> > > > > > >From my reading of this thread, it rather reinforces the need to
> > > > > > provide a way to give U-Boot the config it needs, in the devicetree.
> > > > >
> > > > > As long as that configuration is optional, yes, maybe.
> > > > >
> > > > > > It seems that rpi is actually OK in this regard. If you think about
> > > > > > it, it would be pretty hopeless if first-stage firmware assumed that
> > > > > > it could provide a devicetree to whatever is next.
> > > > >
> > > > > Not hopeless.  If that device tree provides a hardware description
> > > > > that is complete enough to boot Linux, it should be good enough to run
> > > > > U-Boot.
> > > >
> > > > Not in general. I hope I have covered this in enormous detail in the
> > > > devicetree patch. But if you don't need verified boot, SPL or some
> > > > other feature that needs config, then perhaps you will get away with
> > > > it.
> > >
> > > Wait, why does SPL _need_ it?  If something provides us with a device
> > > tree, we don't need u-boot,dm-spl as that's used to filter nodes in to a
> > > smaller DT to use.
> >
> > Yes, although if the filtering is not done I am not sure what SPL
> > would do. In fact we don't have a way to provide two DTs (SPL, U-Boot
> > proper) from a prior boot stage at present.
>
> I still think that if there is some sort of prior stage firmware,
> there typically is no need for SPL.  And if there is, DRAM is probably
> set up already and there are no space constraints so using the full DT
> isn't an issue.

The DT does need to be paired with U-Boot, I think. For example, if
the DT adds new devices then the pre-reloc malloc size may need to be
increased as well.

For the SPL case, we may have enough memory to init devices, but it
may not be configured that way. Typically SPL uses a small RAM size
even if it is not initing the SDRAM. SPL does not relocate.

For the non-SPL case we still need to consider pre-reloc, where boot
time could be adversely affected by initing devices that are not
needed.

So I thnk we should say that if you are using a particular U-Boot
version, you should provide U-Boot with the DT from that version too.

>
> > >  Dealing with u-boot,dm-pre-reloc could be trickier,
> > > but means whatever loaded us needs to have enabled any early clocks we
> > > need.  But even then, it's just going to be output related?  And some
> > > "was already configured" path could be used.
> >
> > My point is that ignoring U-Boot's devicetree requirements doesn't
> > work in general. It may work in specific cases. It cannot work for
> > verified boot of course.
>
> And this is I think the root of the controversy.  IMHO, U-Boot should
> have no "hard" devicetree requirements other than the requirement that
> the device tree provides a complete enough description of the hardware
> using standardized DT bindings.
>
> That doesn't mean you can't have something like a /config node with
> U-Boot specific options.  I'd say that would be a great way for prior
> stage firmware to control U-Boot behaviour.
>
> But what it does mean is that none of those options can be a "hard"
> requirement in the sense that in order to have a functioning U-Boot on
> a platform you absolutely have to have U-Boot specific nodes and/or
> properties in your DT.
>
> I guess what I'm saying/asking is, why can't we have some sort of
> middle ground here?
>
> If there is no prior-stage firmware to speak of and U-Boot is entirely
> responsible for bootstrapping a board (the typical scenario where you
> need SPL/TPL) I don't see a problem with having a control DT that
> specifies everything.
>
> If there is prior-stage firmware, and U-Boot proper is the canonical
> payload for that firmware on a board, adding U-Boot specific stuff to
> the DT should be no issue.  There are some obvious issues here in
> keeping DT bindings in synch between the prior-stage firmware and
> U-Boot in that case, so standardizing/upstreaming the U-Boot DT
> bindings would be helpful in this scenario.
>
> If U-Boot is just one of many choices for the payload having U-Boot
> specific stuff in the DT may not make sense.  In that scenario you'd
> just get reasonable default behaviour (and potentially no verified
> boot).  But it should be possible to change the default behaviour
> using the U-Boot environment variables in cases where it makes sense.

I think we are saying the same thing. If you don't need U-Boot
features which rely on config, and you have a tail wind, then you
should be able to boot with whatever DT there is.

But I don't think we should recommend this. It is a 'fallback' case
when (for whatever reason) the U-Boot DT for that board is not
provided. You are 'on your own' and things may or may not work,
depending on memory requirements, what features are used, etc.

Note that verified boot will actually boot (without verifying) when
the U-Boot devicetree is not provided.

>
> I'm not yet sure where my Apple M1 work is going to land on this
> spectrum.  I think doing verified boot here is doable when using
> u-boot as a payload.  Currently the m1n1 bootloader, the DTB and
> U-Boot are combined into a single Mach-O binary and there is a special
> procedure that requires username/password verification to "enroll"
> that binary as a bootable "kernel" for Apple's bootloader.  I believe
> that means that it can't be tampered with without physical access to
> the machine and providing the password of the "owner" of the machine.
> So embedding the public key that verifies subsequent stages (e.g. a
> FIT image or an EFI binary) should work just fine.

Sounds right to me.

Regards,
Simon

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

[Tom Rini]

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

On Sat, Sep 18, 2021 at 01:15:07PM +0200, Mark Kettenis wrote:
> > From: Simon Glass <sjg@chromium.org>
> > Date: Sat, 18 Sep 2021 03:27:48 -0600
> > 
> > Hi Tom,
> > 
> > On Fri, 17 Sept 2021 at 11:26, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Fri, Sep 17, 2021 at 10:19:18AM -0600, Simon Glass wrote:
> > > > Hi Mark,
> > > >
> > > > On Wed, 15 Sept 2021 at 05:52, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > > > >
> > > > > > From: Simon Glass <sjg@chromium.org>
> > > > > > Date: Wed, 15 Sep 2021 04:13:24 -0600
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > > Hi Mark,
> > > > > >
> > > > > > On Sat, 11 Sept 2021 at 13:18, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > > > > > >
> > > > > > > > From: Moiz Imtiaz <moizimtiaz1@gmail.com>
> > > > > > > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > > > > > > >
> > > > > > > > Hi Simon,
> > > > > > > >
> > > > > > > > Thanks for the reply.  I already followed the steps mentioned in
> > > > > > > > "doc/uImage.FIT/beaglebone_vboot.txt".
> > > > > > > >
> > > > > > > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but
> > > > > > > > instead one provided by the earlier-stage firmware?
> > > > > > > >
> > > > > > > > Not sure, but seems like this is the case. I checked and there isn't any
> > > > > > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to
> > > > > > > > add the dtb and other dts dtsi
> > > > > > > > <https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom>files
> > > > > > > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and
> > > > > > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and
> > > > > > > > it would just give a blank screen*. I wonder why there isn't any device
> > > > > > > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by
> > > > > > > > RPI4?
> > > > > > >
> > > > > > > The issue with the rpi4 is that the addresses of devices move around
> > > > > > > based on the version of the Raspberry Pi firmware you're using.  And
> > > > > > > possibly on the amount of memory on the board as well.  So U-Boot
> > > > > > > pretty much has to use the device tree passed by the firmware since
> > > > > > > the device tree in the U-Boot tree would be wrong for many
> > > > > > > combinations of firmware and hardware.
> > > > > > >
> > > > > > > Simon, this sort of thing is exactly the reason why I think the idea
> > > > > > > of having all U-Boot configuration information in a single device tree
> > > > > > > with the hardware description doesn't work everywhere.
> > > > > >
> > > > > > >From my reading of this thread, it rather reinforces the need to
> > > > > > provide a way to give U-Boot the config it needs, in the devicetree.
> > > > >
> > > > > As long as that configuration is optional, yes, maybe.
> > > > >
> > > > > > It seems that rpi is actually OK in this regard. If you think about
> > > > > > it, it would be pretty hopeless if first-stage firmware assumed that
> > > > > > it could provide a devicetree to whatever is next.
> > > > >
> > > > > Not hopeless.  If that device tree provides a hardware description
> > > > > that is complete enough to boot Linux, it should be good enough to run
> > > > > U-Boot.
> > > >
> > > > Not in general. I hope I have covered this in enormous detail in the
> > > > devicetree patch. But if you don't need verified boot, SPL or some
> > > > other feature that needs config, then perhaps you will get away with
> > > > it.
> > >
> > > Wait, why does SPL _need_ it?  If something provides us with a device
> > > tree, we don't need u-boot,dm-spl as that's used to filter nodes in to a
> > > smaller DT to use.
> > 
> > Yes, although if the filtering is not done I am not sure what SPL
> > would do. In fact we don't have a way to provide two DTs (SPL, U-Boot
> > proper) from a prior boot stage at present.
> 
> I still think that if there is some sort of prior stage firmware,
> there typically is no need for SPL.  And if there is, DRAM is probably
> set up already and there are no space constraints so using the full DT
> isn't an issue.

This isn't strictly true.  You can look at the TI Keystone 3 platforms
where there's both R5 and A72 cores and it's still an intentional
software design to use SPL at the A72 stage.  I think this is explained
in the U-Boot docs, but if not I think it has been on the mailing list,
perhaps?  But that's just an FYI really.

> > >  Dealing with u-boot,dm-pre-reloc could be trickier,
> > > but means whatever loaded us needs to have enabled any early clocks we
> > > need.  But even then, it's just going to be output related?  And some
> > > "was already configured" path could be used.
> > 
> > My point is that ignoring U-Boot's devicetree requirements doesn't
> > work in general. It may work in specific cases. It cannot work for
> > verified boot of course.
> 
> And this is I think the root of the controversy.  IMHO, U-Boot should
> have no "hard" devicetree requirements other than the requirement that
> the device tree provides a complete enough description of the hardware
> using standardized DT bindings.
> 
> That doesn't mean you can't have something like a /config node with
> U-Boot specific options.  I'd say that would be a great way for prior
> stage firmware to control U-Boot behaviour.
> 
> But what it does mean is that none of those options can be a "hard"
> requirement in the sense that in order to have a functioning U-Boot on
> a platform you absolutely have to have U-Boot specific nodes and/or
> properties in your DT.
> 
> I guess what I'm saying/asking is, why can't we have some sort of
> middle ground here?
> 
> If there is no prior-stage firmware to speak of and U-Boot is entirely
> responsible for bootstrapping a board (the typical scenario where you
> need SPL/TPL) I don't see a problem with having a control DT that
> specifies everything.
> 
> If there is prior-stage firmware, and U-Boot proper is the canonical
> payload for that firmware on a board, adding U-Boot specific stuff to
> the DT should be no issue.  There are some obvious issues here in
> keeping DT bindings in synch between the prior-stage firmware and
> U-Boot in that case, so standardizing/upstreaming the U-Boot DT
> bindings would be helpful in this scenario.
> 
> If U-Boot is just one of many choices for the payload having U-Boot
> specific stuff in the DT may not make sense.  In that scenario you'd
> just get reasonable default behaviour (and potentially no verified
> boot).  But it should be possible to change the default behaviour
> using the U-Boot environment variables in cases where it makes sense.

I concur.  And I would just note that everyone using DT is supposed to
be using the same bindings, so the in-sync part shouldn't be a big
issue.

-- 
Tom

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

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

[Tom Rini]

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

On Sat, Sep 18, 2021 at 03:27:48AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, 17 Sept 2021 at 11:26, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Fri, Sep 17, 2021 at 10:19:18AM -0600, Simon Glass wrote:
> > > Hi Mark,
> > >
> > > On Wed, 15 Sept 2021 at 05:52, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > > >
> > > > > From: Simon Glass <sjg@chromium.org>
> > > > > Date: Wed, 15 Sep 2021 04:13:24 -0600
> > > >
> > > > Hi Simon,
> > > >
> > > > > Hi Mark,
> > > > >
> > > > > On Sat, 11 Sept 2021 at 13:18, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > > > > >
> > > > > > > From: Moiz Imtiaz <moizimtiaz1@gmail.com>
> > > > > > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > > > > > >
> > > > > > > Hi Simon,
> > > > > > >
> > > > > > > Thanks for the reply.  I already followed the steps mentioned in
> > > > > > > "doc/uImage.FIT/beaglebone_vboot.txt".
> > > > > > >
> > > > > > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but
> > > > > > > instead one provided by the earlier-stage firmware?
> > > > > > >
> > > > > > > Not sure, but seems like this is the case. I checked and there isn't any
> > > > > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to
> > > > > > > add the dtb and other dts dtsi
> > > > > > > <https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom>files
> > > > > > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and
> > > > > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and
> > > > > > > it would just give a blank screen*. I wonder why there isn't any device
> > > > > > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by
> > > > > > > RPI4?
> > > > > >
> > > > > > The issue with the rpi4 is that the addresses of devices move around
> > > > > > based on the version of the Raspberry Pi firmware you're using.  And
> > > > > > possibly on the amount of memory on the board as well.  So U-Boot
> > > > > > pretty much has to use the device tree passed by the firmware since
> > > > > > the device tree in the U-Boot tree would be wrong for many
> > > > > > combinations of firmware and hardware.
> > > > > >
> > > > > > Simon, this sort of thing is exactly the reason why I think the idea
> > > > > > of having all U-Boot configuration information in a single device tree
> > > > > > with the hardware description doesn't work everywhere.
> > > > >
> > > > > >From my reading of this thread, it rather reinforces the need to
> > > > > provide a way to give U-Boot the config it needs, in the devicetree.
> > > >
> > > > As long as that configuration is optional, yes, maybe.
> > > >
> > > > > It seems that rpi is actually OK in this regard. If you think about
> > > > > it, it would be pretty hopeless if first-stage firmware assumed that
> > > > > it could provide a devicetree to whatever is next.
> > > >
> > > > Not hopeless.  If that device tree provides a hardware description
> > > > that is complete enough to boot Linux, it should be good enough to run
> > > > U-Boot.
> > >
> > > Not in general. I hope I have covered this in enormous detail in the
> > > devicetree patch. But if you don't need verified boot, SPL or some
> > > other feature that needs config, then perhaps you will get away with
> > > it.
> >
> > Wait, why does SPL _need_ it?  If something provides us with a device
> > tree, we don't need u-boot,dm-spl as that's used to filter nodes in to a
> > smaller DT to use.
> 
> Yes, although if the filtering is not done I am not sure what SPL
> would do. In fact we don't have a way to provide two DTs (SPL, U-Boot
> proper) from a prior boot stage at present.

The need to filter the DT down for SPL tends to be because we don't
otherwise have enough initialized memory to retrieve / work with / etc
the DT.  That can't be true if some other stage is handing us something.

> >  Dealing with u-boot,dm-pre-reloc could be trickier,
> > but means whatever loaded us needs to have enabled any early clocks we
> > need.  But even then, it's just going to be output related?  And some
> > "was already configured" path could be used.
> 
> My point is that ignoring U-Boot's devicetree requirements doesn't
> work in general. It may work in specific cases. It cannot work for
> verified boot of course.

I'm trying to not belabor the point here, since you've said you'll post
some bindings for review, but it's not _our_ device tree.  That breaks
the whole blasted point of having "a" device tree, rather than everyone
having their own device tree.  So figuring out a good path forward for
verified boot is something that'll require a little more thinking quite
possibly and explaining how you do it on something again modern and
potentially hardware-assisted.

-- 
Tom

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