[U-Boot] Complete verified uboot example

Thu Feb 23 05:23:54 UTC 2017

On Wed, 22 Feb 2017 10:51:22 -0800
Rick Altherr <raltherr at google.com> wrote:

> On Tue, Feb 21, 2017 at 10:08 AM, Ron Brash <ron.brash at gmail.com>
> wrote:
> 
> > Hello all,
> >
> > I am adding verified kernel support on a board we are using and I am
> > struggling to fully understand all of the concepts and steps
> > required to pull everything together (on ARM, using ZImages and
> > booting with a working DTB on 4.4.3x).  I also looked at the test
> > script inside of examples, but it left me with more questions than
> > understanding.
> >
> > Please correct me where appropriate in my understanding, but if I am
> > confused, likely others are too and I hope this helps everyone
> > involved overall.
> >
> 
> You've asked some really good questions.  Hopefully this discussion
> will end up with patches to clarify the docs.
> 
> 
> >
> > Steps:
> > ---------------------------------------------------------------
> >
> > First, u-boot needs to have the appropriate features enabled and to
> > be built using them.  At a minimum, I suspect:
> >
> > CONFIG_RSA=y
> > CONFIG_FIT=y
> > CONFIG_FIT_SIGNATURE=y
> > CONFIG_OF_CONTROL=y
> >
> >
> Yup.  That looks right.
> 
> 
> > Next, we need to derive the appropriate cryptographic
> > primitives/keys.
> >
> > #Generate a private signing key (RSA2048):
> > openssl genrsa -F4 -out \
> > "${key_dir}"/"${key_name}".key 2048
> >
> > # Generate a public key:
> > openssl req -batch -new -x509 \
> > -key "${key_dir}"/"${key_name}".key \
> > -out "${key_dir}"/"${key_name}".crt
> >
> >
> So far so good.  In general, I suggest having multiple signing keys.
> You can put all the public keys in your u-boot so an image signed
> with any of those keys will be accepted.  If you happen to have a
> signing key compromised, you can switch to one of the other ones.
> With that other key, you can sign an update the removes the
> compromised public key from future images.
> 
> 
> > Then we derive the ITS or image source file - a file that
> > hints/describes the elements that will be verified and/or inside of
> > the FIT image?  Lets call this $FIT_ITS
> >
> > FIT is a container format.  Generally, you'll create a FIT that
> > contains
> the zImage, dtb, initramfs, etc.  With FIT support enabled in u-boot,
> you only need to provide the single FIT image address to 'bootm'.
> u-boot will use the config section to find the individual elements,
> load them into RAM as needed, and boot.
> 
> 
> > / dts - v1 /;
> > / {
> > description = "Configuration to load a Xen Kernel";
> > #address-cells = <1>;
> > images {
> > linux_kernel @ 1 {
> > description = "Linux zImage";
> > data = /incbin / ("pathToImage/zImage");
> > type = "kernel";
> > arch = "arm";
> > os = "linux";
> > compression = "none";
> > load = <0xaf600000 >;
> > entry = <0xaf600000 >;
> > hash @ 1 {
> > algo = "sha1";
> > };
> > };
> > fdt @ 1 {
> > description = "FDT blob";
> > data = /incbin / ("PathToDTBUsedByBootingKernel/ex.dtb");
> > type = "flat_dt";
> > arch = "arm";
> > compression = "none";
> > load = <0xaec00000 >;
> >
> 
> You generally don't need a 'load' property for the FDT or an
> initramfs. Without one, U-Boot will allocate RAM dynamically, if
> needed, and pass the relocated address to the kernel.
> 
> hash @ 1 {
> > algo = "sha1";
> > };
> > };
> > };
> > configurations {
> > default = "config at 1";
> > config @ 1 {
> > description = "Plain Linux";
> > kernel = "linux_kernel at 1";
> > fdt = "fdt at 1";
> > loadables = "linux_kernel at 1";
> >
> 
> 'loadables' is for other types of firmware.  You only need the
> 'kernel' property for loading and booting the kernel.
> 
> 
> > };
> > };
> > };
> >
> > Question: Does a signature section go into this as well? underneath
> > the hash node for each value?
> 
> 
> > signature at 1 {
> >      algo = "sha1,rsa2048";
> >      value = <...kernel signature 1...>
> >  };
> >
> 
> You add a signature section to each image you want signed within the
> FIT. In your case, add one for both the kernel and FDT images.
> Signatures go _next_ to the hash section, not in it.  Omit the
> 'value' property as it will be generated for you later.
> 
> 
> >
> > Then using the device-tree-compiler (dtc), I create a DTB for
> > u-boot.  This is the control FDT and this defines what keys are
> > used etc..
> >
> 
> The control FDT is used for U-Boot's driver model _as well as_
> providing public keys for verifying images.  Your board may not
> currently use a control FDT in which case you create one from scratch.
> 
> 
> >
> > #Assemble control FDT for U-Boot with space for public key:
> > $DTC -p 0x1000 u-boot.dts -O dtb -o u-boot.dtb
> >
> > Question: What is required inside of the u-boot.dts for u-boot?  Is
> > it simply the same .dts used by the booting kernel, but with a
> > section proclaiming the keys?
> >
> 
> This depends on the board you are using.  For example, an AST2500
> requires a DTB for U-Boot to load the right drivers.  The DTB used by
> U-Boot is slightly different from that used by Linux as the Linux DTB
> often includes addition configuration information.  When using
> verified boot, the U-Boot DTB includes the public keys whereas the
> FDT/DTB stored in the FIT does not as Linux doesn't need them.
> 
> 
> >
> > Question:  Where will the compiled u-boot.dtb eventually go?  Is
> > this put into a FIT image, or flashed onto the board alongside the
> > u-boot bootloader itself?
> >
> 
> The U-Boot control FDT is compiled into the U-Boot binary.  The FDT
> in the FIT is the FDT that is provided to Linux.
> 
> 
> >
> > Next, given that the above steps are completed, I need to create a
> > FIT image with space for the signature.
> >
> > # Generate fitImage with space for signature:
> > $MKIMG -D "-I dts -O dtb -p 2000" \
> > -f f$FIT_ITS $FIT_IMG
> >
> > Question: Is the FIT_IMAGE the actual zimage or is it an output
> > image that contains all of the values contained within the ITS?
> >
> 
> The latter.  It will have a compiled version of the ITS as well as the
> actual images specified in the ITS (kernel, fdt).
> 
> 
> >
> > Next this FIT_IMAGE (assuming that this is the final FIT image that
> > contains the FDT and zImage) needs to be signed and the public key
> > added to it; given that that the key information is in the uboot.
> >
> 
> You sign the FIT_IMAGE and put the public keys in the control DTB.
> 
> 
> >
> > # Sign fitImage and add public key into u-boot.dtb:
> > $MKIMG -D "-I dts -O dtb -p 2000" -F \
> > -k "${key dir}" -K u-boot.dtb -r $FIT_IMG
> >
> 
> This is putting the public keys used by the FIT image into the
> control DTB
> 
> 
> >
> > Then, we sign the subsequent fitImage again - correct?
> >
> > # Signing subsequent fitImage:
> > $MKIMG -D "-I dts -O dtb -p 2000" \
> > -k "${key dir}" -f $FIT_ITS -r $FIT_IMG
> >
> 
> This is generating signatures for the images in the FIT and storing
> those signatures in the FIT.
> 
> 
> >
> > Now that all of the above is done - we need to:
> > 1. Write our uboot to the flash
> > 2. Write our FIT_IMAGE to flash
> >
> > Question: Do we write anything else to persistent storage? The ITS?
> > etc..
> >
> 
> No.  Everything is contained in the U-Boot binary (control FDT
> including public keys) and the FIT (images, signatures)
> 
> >
> > Question: Do we just boot using anything else or just bootm
> > 0xLocationOfTheFitImageInRAM
> >
> 
> The latter.  bootm will check the config section in the FIT and use
> the kernel, fdt, etc specified there.
> 
> 
> >
> > Greatly appreciate any assistance to all of these questions and I'm
> > sure this threat will be of interest to anyone else too.
> >
> > Thanks!
> 
> _______________________________________________
> > U-Boot mailing list
> > U-Boot at lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
> >
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

It would be valuable to have this thread formalized to some ./doc
entry ..., IMHO.

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de