[yocto] Understanding dtb generation wrt uboot (with signing)

[Rick Altherr]

I'm not sure what you mean by fitImage dtb.  Do you mean a dtb
encapsulated in the fitImage for use by the kernel, the quasi-dtb that
describes the fitImage components, or something else?

For U-Boot verified boot to work, U-Boot needs the public key that
matches the private key used to sign the components in the fitImage.
This public key must be stored independently of the fitImage otherwise
anyone could just sign the fitImage with whatever key they want and
then include the corresponding public key as well.  Instead, the
public key is stored in U-Boot's control dtb.  For modern U-Boot
targets, this dtb already exists to describe the hardware to U-Boot
(see firefly or ast2500 targets) so storing the public keys there is
just leveraging an existing data storage mechanism.  This control dtb
is baked into the U-Boot binary that gets flashed onto the target.

This gets a bit more complicated when you notice that fitImage
components are signed individually.  Each image (kernel, dtb, ramdisk)
is signed separately as are configurations described in the fitImage.
Further, each of those components can be signed with different and/or
multiple keys.  Maybe you use different keys for each product but use
a single fitImage across them all.  All of the public keys used need
to be included in the U-Boot control dtb.

Yocto uses this process adapted from the U-Boot examples:
  * build U-Boot with control dtb as provided in source
  * generate unsigned FIT
  * sign the FIT and update the control dtb with the public keys used
  * rebuild U-Boot with the updated control dtb

If your target doesn't require a control dtb for boot, you can create
a very simple one that just contains the empty key-related nodes.

On Mon, Jul 31, 2017 at 7:10 AM, Colin Helliwell
<colin.helliwell at ln-systems.com> wrote:
>
>> On 27 July 2017 at 17:48 colin.helliwell at ln-systems.com wrote:
>>
>> I'm working on 2.2/Morty, with a custom board.
>> Ultimate goal is to create a FIT image with a signed configuration. But I'm
>> trying to just work through step by step and understand the relationships
>> between u-boot, kernel, dtb, and the fit image - would appreciate any
>> guidance!
>> So far, I've built and booted a fitImage.
>>
> ...
>>
>> First thing I'm puzzled by is that the dtb *is* in
>> tmp/deploy/images/mymachine/ , but is called
>> "zImage--4.4-r0-mymachine-20170727160613.dtb". Also with a symlink
>> "zImage-mymachine.dtb". (If I'm understanding things right, this is because
>> the fitImage contains a compressed kernel...?)
>>
>> Then I set UBOOT_SIGN_ENABLE = "1", and re-bitbake the u-boot target. It
>> only gets as far as re-building the kernel, which fails on the
>> do_assemble_fitimage stage because uboot-mkimage is being told to use
>> "u-boot.dtb"
>>
>
> After studying things in more depth, I've now grasped that the relationships with the uboot-sign class are, not circular, but a bit to-and-fro between kernel and u-boot. Please correct me if I've got any of this wrong:
> The 'final' signed dtb, for use by U-Boot, consists of the U-Boot dtb (i.e. the traditional U-Boot hardware blob) plus the fitimage dtb tree;
> The latter encompasses the kernel and the hardware blob from the *kernel*.
> It seems a bit tortured to have two hardware device blobs involved in this, but I kinda get the issues of keeping sync between two (https://stackoverflow.com/questions/30711327/why-device-tree-structure-dts-file-is-needed-both-in-bootloader-and-kernel-sou).
>
> The first complication I have is that my [manufacturer-dervied] U-Boot doesn't seem to compile a dtb - instead the manufacturer just uses the one built with the kernel. I don't mind this too much - I don't particularly need a separate dtb to be built within U-Boot, and its arguably easier to *not* have to maintain two sets of sources.
> However this does aggravate the uboot-sign'ing, since there's no .dtb for kernel-fitimage.bbclass to use ("Step #7").
>
> Is there some means already hooked into the class(es) whereby I can easily have the kernel dtb used in 'Step #7' instead?
> I thought I might be able to do this by setting UBOOT_DTB_IMAGE but it looks like the kernel's dtb hasn't yet, at this point in the build sequence, been installed into ${DEPLOYDIR}. Should I be aiming to make use of 'EXT_DTB'?
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto