[U-Boot] Complete verified uboot example

[U-Boot] Complete verified uboot example

[Ron Brash]

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.

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

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

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

/ 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 >;
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";
};
};
};

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...>
 };

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..

#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?

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?

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?

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.

# 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

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

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..

Question: Do we just boot using anything else or just bootm
0xLocationOfTheFitImageInRAM

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] Complete verified uboot example

[Lukasz Majewski]

On Tue, 21 Feb 2017 13:08:19 -0500
Ron Brash <ron.brash@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.

Some time ago I've gave a try to verified boot on BBB (beagle bone
black).

Please refer to:
/home/lukma/work/embedded/u-boot-denx/doc/uImage.FIT/beaglebone_vboot.txt

It should shed some more light to your problem and provide reference.

> 
> 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
> 
> 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
> 
> 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
> 
> / 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 >;
> 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";
> };
> };
> };
> 
> 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...>
>  };
> 
> 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..
> 
> #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?

u-boot dts is not 100% compatible with Linux kernel, but does the
same job.

Yes, you put your public key to it IIRC.

> 
> 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 dtb will be packed into FIT image, which comprise u-boot and
several dtb's. This image is not the one, which kernel uses to boot the
kernel.

(There is a switch CONFIG_SPL_LOAD_FIT in spl.c, so please look for a
reference).

> 
> 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?
> 
> 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.
> 
> # 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
> 
> 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
> 
> 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..
> 
> Question: Do we just boot using anything else or just bootm
> 0xLocationOfTheFitImageInRAM
> 
> 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




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

[U-Boot] Complete verified uboot example

[Rick Altherr]

On Tue, Feb 21, 2017 at 10:08 AM, Ron Brash <ron.brash@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] Complete verified uboot example

[Lukasz Majewski]

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

> On Tue, Feb 21, 2017 at 10:08 AM, Ron Brash <ron.brash@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

[U-Boot] Complete verified uboot example

[Ron Brash]

Hello all (and thanks Mr. Altherr for this insight),

Excellent feedback and I agree that all of this needs to find a home either
on the global docs on the website and/or the text-only documentation.
Regardless, this leads me to a few questions.

NOTE: the use of a uboot control DTS, control DTB and control FTD even in
Mr. Altherr's email is confusion provoking.  One term to rule them all is
needed ;)

1.)  What if a board doesn't have OR has ever been configured to use u-boot
DTS (could we call this a UDTS or something friendly to differentiate that
fact?); this was a point of misunderstanding until I started scampering
around into arch/arm/dts/?

* For example, my board is a derivative of an Atmel at91sam9g20.  It had a
very generic implementation of a DTS that covered reference boards in the
Linux kernel, but required a fair bit of modification to make it work.  As
the at91sam(legacy platform) isn't in u-boot's source tree for a DTS - what
would someone like me need to do - do we have a barebones tutorial (again I
don't mind publishing such with proofing)?  Is it even required if we have
a platform/board already working in the traditional u-boot way?

2.)  Just to summarise - everything winds up in two binaries: u-boot and
the FIT image.  So the partition scheme would more or less would look like:

/-----------------
* Bootstrap/ROM (optional)
/----------------
* U-boot
*    Control DTB
*         Has keys
*         Driver loadout/init
/----------------
* U-boot env
*----------------
* FIT image
*    ITS
*    Kernel
*    DTS
*    ....
/---------------
* Rootfs etc...
* ...
/---------------


3.)  What people used to use to load X address into Z location in memory is
now removed by the usage of a DTB in u-boot correct?  I assume that the
u-boot DTB now does this and bootarg/bootcmd is partially done away with -
as its arguments are augmented by said file.

Anybody have the spare cycles to organise a
web-tutorial/presentation/recording with me on a play-by-play to make all
of this make sense?  I'm aiming to be in Prague for the 2017 conference in
October, might be a good place to showcase this fine-tuning.

Ron

On 22 February 2017 at 13:51, Rick Altherr <raltherr@google.com> wrote:

>
> On Tue, Feb 21, 2017 at 10:08 AM, Ron Brash <ron.brash@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] Complete verified uboot example

[Rick Altherr]

On Thu, Feb 23, 2017 at 7:48 AM, Ron Brash <ron.brash@gmail.com> wrote:

> Hello all (and thanks Mr. Altherr for this insight),
>
> Excellent feedback and I agree that all of this needs to find a home
> either on the global docs on the website and/or the text-only
> documentation.  Regardless, this leads me to a few questions.
>
> NOTE: the use of a uboot control DTS, control DTB and control FTD even in
> Mr. Altherr's email is confusion provoking.  One term to rule them all is
> needed ;)
>

Agreed.  Technically a flattened device tree (FDT) can be described in an
ASCII form (dts) or binary form (dtb).


>
> 1.)  What if a board doesn't have OR has ever been configured to use
> u-boot DTS (could we call this a UDTS or something friendly to
> differentiate that fact?); this was a point of misunderstanding until I
> started scampering around into arch/arm/dts/?
>
> * For example, my board is a derivative of an Atmel at91sam9g20.  It had a
> very generic implementation of a DTS that covered reference boards in the
> Linux kernel, but required a fair bit of modification to make it work.  As
> the at91sam(legacy platform) isn't in u-boot's source tree for a DTS - what
> would someone like me need to do - do we have a barebones tutorial (again I
> don't mind publishing such with proofing)?  Is it even required if we have
> a platform/board already working in the traditional u-boot way?
>
> I believe (but have no verified) that if your board is supported by U-Boot
without a control FDT today, you can just create one that contains only the
public keys.  I've gathered from the mailing list that using a control FDT
and the driver model is how all new boards should be implemented.


> 2.)  Just to summarise - everything winds up in two binaries: u-boot and
> the FIT image.  So the partition scheme would more or less would look like:
>
> /-----------------
> * Bootstrap/ROM (optional)
> /----------------
> * U-boot
> *    Control DTB
> *         Has keys
>

Only the public keys.  The private keys are never stored on the target
device.


> *         Driver loadout/init
>
The control FDT only describes the hardware (see
https://www.devicetree.org/ and
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/usage-model.txt).
U-Boot's driver model matches device drivers against nodes in the FDT and
starts them.


> /----------------
> * U-boot env
> *----------------
> * FIT image
>
The FIT shouldn't be in the U-Boot env section.  That's used by U-Boot to
store its persistent environment.  The FIT is a replacement for the kernel
image.  Keep a separate place allocated in the flash for kernel but store
the FIT there.


> *    ITS
>
I never really thought of it this way, but yes, that's true.  The ITS is
itself written in device tree syntax and gets compiled to binary form.  dtb
tends to get used only to describe device trees in binary form that
describe hardware.  Maybe we need to introduce ITB to clarify this is the
device tree in binary form describing the image.


> *    Kernel
> *    DTS
>

Prefer the terms FDT or DTB.  Only the compiled form is stored in the FIT.


> *    ....
> /---------------
> * Rootfs etc...
> * ...
> /---------------
>
>
> 3.)  What people used to use to load X address into Z location in memory
> is now removed by the usage of a DTB in u-boot correct?  I assume that the
> u-boot DTB now does this and bootarg/bootcmd is partially done away with -
> as its arguments are augmented by said file.
>

Not quite.  bootarg/bootcmd is still used.  What is different is that
booting linux with a FDT with legacy images required multiple arguments to
bootm.  In that case, bootarg would be 'bootm <zimage_addr> - <fdt_addr>'.
With a FIT, you only provide the address of the FIT itself to bootm so
bootarg is set to 'bootm <fit_addr>'.


>
> Anybody have the spare cycles to organise a web-tutorial/presentation/recording
> with me on a play-by-play to make all of this make sense?  I'm aiming to be
> in Prague for the 2017 conference in October, might be a good place to
> showcase this fine-tuning.
>
>
I'm not clear on what you are asking.  I probably have time to review docs
and presentations and maybe a few phone or video conference meetings.


> Ron
>
> On 22 February 2017 at 13:51, Rick Altherr <raltherr@google.com> wrote:
>
>>
>> On Tue, Feb 21, 2017 at 10:08 AM, Ron Brash <ron.brash@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] Complete verified uboot example

[Ron Brash]

Hi Mr. Altherr,

I don't have time today to re-clarify everything mentioned  in this stream,
but I will begin to reformat my initial inquiries given all of the provided
information and provide them again.

From my last point:

Anybody have the spare cycles to organise a web-tutorial/presentation/recording
with me on a play-by-play to make all of this make sense?  I'm aiming to be
in Prague for the 2017 conference in October, might be a good place to
showcase this fine-tuning.

I was referring to the process to make this entire document with all of
your help.  Secondly, if we(the community) want more people to add verified
boot to their systems, this information needs to be accessible.  It can
come in a number of forms: text-only doc, a webpage, slide-deck, and/or
complete tutorials from A-Z.  I only mentioned the fall conference as
potential avenue for delivery - I watched a recent presentation from last
October and noticed a mediocre number of people attending this session even
use verified u-boot;  this conference, even if bird-of-a-feather could be a
good delivery mechanism.


On 23 February 2017 at 12:27, Rick Altherr <raltherr@google.com> wrote:

>
>
> On Thu, Feb 23, 2017 at 7:48 AM, Ron Brash <ron.brash@gmail.com> wrote:
>
>> Hello all (and thanks Mr. Altherr for this insight),
>>
>> Excellent feedback and I agree that all of this needs to find a home
>> either on the global docs on the website and/or the text-only
>> documentation.  Regardless, this leads me to a few questions.
>>
>> NOTE: the use of a uboot control DTS, control DTB and control FTD even in
>> Mr. Altherr's email is confusion provoking.  One term to rule them all is
>> needed ;)
>>
>
> Agreed.  Technically a flattened device tree (FDT) can be described in an
> ASCII form (dts) or binary form (dtb).
>
>
>>
>> 1.)  What if a board doesn't have OR has ever been configured to use
>> u-boot DTS (could we call this a UDTS or something friendly to
>> differentiate that fact?); this was a point of misunderstanding until I
>> started scampering around into arch/arm/dts/?
>>
>> * For example, my board is a derivative of an Atmel at91sam9g20.  It had
>> a very generic implementation of a DTS that covered reference boards in the
>> Linux kernel, but required a fair bit of modification to make it work.  As
>> the at91sam(legacy platform) isn't in u-boot's source tree for a DTS - what
>> would someone like me need to do - do we have a barebones tutorial (again I
>> don't mind publishing such with proofing)?  Is it even required if we have
>> a platform/board already working in the traditional u-boot way?
>>
>> I believe (but have no verified) that if your board is supported by
> U-Boot without a control FDT today, you can just create one that contains
> only the public keys.  I've gathered from the mailing list that using a
> control FDT and the driver model is how all new boards should be
> implemented.
>
>
>> 2.)  Just to summarise - everything winds up in two binaries: u-boot and
>> the FIT image.  So the partition scheme would more or less would look like:
>>
>> /-----------------
>> * Bootstrap/ROM (optional)
>> /----------------
>> * U-boot
>> *    Control DTB
>> *         Has keys
>>
>
> Only the public keys.  The private keys are never stored on the target
> device.
>
>
>> *         Driver loadout/init
>>
> The control FDT only describes the hardware (see
> https://www.devicetree.org/ and http://git.kernel.org/cgit/
> linux/kernel/git/torvalds/linux.git/tree/Documentation/
> devicetree/usage-model.txt).  U-Boot's driver model matches device
> drivers against nodes in the FDT and starts them.
>
>
>> /----------------
>> * U-boot env
>> *----------------
>> * FIT image
>>
> The FIT shouldn't be in the U-Boot env section.  That's used by U-Boot to
> store its persistent environment.  The FIT is a replacement for the kernel
> image.  Keep a separate place allocated in the flash for kernel but store
> the FIT there.
>
>
>> *    ITS
>>
> I never really thought of it this way, but yes, that's true.  The ITS is
> itself written in device tree syntax and gets compiled to binary form.  dtb
> tends to get used only to describe device trees in binary form that
> describe hardware.  Maybe we need to introduce ITB to clarify this is the
> device tree in binary form describing the image.
>
>
>> *    Kernel
>> *    DTS
>>
>
> Prefer the terms FDT or DTB.  Only the compiled form is stored in the FIT.
>
>
>> *    ....
>> /---------------
>> * Rootfs etc...
>> * ...
>> /---------------
>>
>>
>> 3.)  What people used to use to load X address into Z location in memory
>> is now removed by the usage of a DTB in u-boot correct?  I assume that the
>> u-boot DTB now does this and bootarg/bootcmd is partially done away with -
>> as its arguments are augmented by said file.
>>
>
> Not quite.  bootarg/bootcmd is still used.  What is different is that
> booting linux with a FDT with legacy images required multiple arguments to
> bootm.  In that case, bootarg would be 'bootm <zimage_addr> - <fdt_addr>'.
> With a FIT, you only provide the address of the FIT itself to bootm so
> bootarg is set to 'bootm <fit_addr>'.
>
>
>>
>> Anybody have the spare cycles to organise a web-tutorial/presentation/recording
>> with me on a play-by-play to make all of this make sense?  I'm aiming to be
>> in Prague for the 2017 conference in October, might be a good place to
>> showcase this fine-tuning.
>>
>>
> I'm not clear on what you are asking.  I probably have time to review docs
> and presentations and maybe a few phone or video conference meetings.
>
>
>> Ron
>>
>> On 22 February 2017 at 13:51, Rick Altherr <raltherr@google.com> wrote:
>>
>>>
>>> On Tue, Feb 21, 2017 at 10:08 AM, Ron Brash <ron.brash@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
>>>>
>>>
>>>
>>
>


-- 


Ron Brash
CTO  & Co-founder of Atlants Embedded Inc.
www.atlantsembedded.com
------------------------------------------------------------------

Cell +1 438 880 6441
Email  ron.brash at gmail.com
Blog www.pacificsimplicity.ca
LinkedIn ca.linkedin.com/in/ronbrash/



This communication is intended for the use of the recipient to which it is
addressed, and may contain confidential, personal, and or privileged
information. Please contact the sender immediately if you are not the
intended recipient of this communication, and do not copy, distribute, or
take action relying on it. Any communication received in error, or
subsequent reply, should be deleted or destroyed.

[U-Boot] Complete verified uboot example

[Rick Altherr]

On Thu, Feb 23, 2017 at 10:06 AM, Ron Brash <ron.brash@gmail.com> wrote:

> Hi Mr. Altherr,
>
> I don't have time today to re-clarify everything mentioned  in this
> stream, but I will begin to reformat my initial inquiries given all of the
> provided information and provide them again.
>
> From my last point:
>
> Anybody have the spare cycles to organise a web-tutorial/presentation/recording
> with me on a play-by-play to make all of this make sense?  I'm aiming to be
> in Prague for the 2017 conference in October, might be a good place to
> showcase this fine-tuning.
>
> I was referring to the process to make this entire document with all of
> your help.  Secondly, if we(the community) want more people to add verified
> boot to their systems, this information needs to be accessible.  It can
> come in a number of forms: text-only doc, a webpage, slide-deck, and/or
> complete tutorials from A-Z.  I only mentioned the fall conference as
> potential avenue for delivery - I watched a recent presentation from last
> October and noticed a mediocre number of people attending this session even
> use verified u-boot;  this conference, even if bird-of-a-feather could be a
> good delivery mechanism.
>
>
I'm interested in helping put this together.  I'm unclear on how much time
I can commit to it though.

[U-Boot] Complete verified uboot example

[Ron Brash]

Okay - it seems, after working my way through a bunch of the documentation
and examples in /doc/uImage.FIT - I noticed a discrepancy

/dts-v1/;
/{
description = "Configuration to load a Basic Kernel";
#address-cells = <1>;
images {
linux_kernel at 1 {
description = "Linux zImage";
data = /incbin/("zImage");
type = "kernel";
arch = "arm";
os = "linux";
compression = "none";
load =  <0x20000000>;
entry = <0x20008000>;
kernel-version = <1>;
hash at 1 {
algo = "sha256";
};
};
fdt at 1 {
description = "FDT blob";
data = /incbin/("myboard.dtn");
type = "flat_dt";
arch = "arm";
compression = "none";
fdt-version = <1>;
hash at 1{
algo = "sha256";
};
};
};
configurations {
default = "config at 1";
config at 1{
description = "Plain Linux";
kernel = "linux_kernel at 1";
fdt = "fdt at 1";
signature at 1{
algo = "sha256,rsa2048";
key-name-hint = "dev_key";
sign-images = "fdt", "kernel";
};
};
};
};

Does NOT equal (for brevity - I just used the node)

fdt at 1 {
description = "FDT blob";
data = /incbin/("myboard.dtn");
type = "flat_dt";
arch = "arm";
compression = "none";
fdt-version = <1>;
hash at 1{
algo = "sha256";
};
signature at 1{
algo = "sha256,rsa2048";
key-name-hint = "dev_key";
};
};

Apparently, this causes the mkimage tooling in my particular instance to
explain invalid blob messages.  The large example above indeed does work
once this nuance was noticed.

Next,  once the final CTRL FDT is created, how does one get it back into
the actual u-boot binary.  Does/can mkimage insert it into the binary image
at a particular offset?  What is the command to do so?





On 23 February 2017 at 12:27, Rick Altherr <raltherr@google.com> wrote:

>
>
> On Thu, Feb 23, 2017 at 7:48 AM, Ron Brash <ron.brash@gmail.com> wrote:
>
>> Hello all (and thanks Mr. Altherr for this insight),
>>
>> Excellent feedback and I agree that all of this needs to find a home
>> either on the global docs on the website and/or the text-only
>> documentation.  Regardless, this leads me to a few questions.
>>
>> NOTE: the use of a uboot control DTS, control DTB and control FTD even in
>> Mr. Altherr's email is confusion provoking.  One term to rule them all is
>> needed ;)
>>
>
> Agreed.  Technically a flattened device tree (FDT) can be described in an
> ASCII form (dts) or binary form (dtb).
>
>
>>
>> 1.)  What if a board doesn't have OR has ever been configured to use
>> u-boot DTS (could we call this a UDTS or something friendly to
>> differentiate that fact?); this was a point of misunderstanding until I
>> started scampering around into arch/arm/dts/?
>>
>> * For example, my board is a derivative of an Atmel at91sam9g20.  It had
>> a very generic implementation of a DTS that covered reference boards in the
>> Linux kernel, but required a fair bit of modification to make it work.  As
>> the at91sam(legacy platform) isn't in u-boot's source tree for a DTS - what
>> would someone like me need to do - do we have a barebones tutorial (again I
>> don't mind publishing such with proofing)?  Is it even required if we have
>> a platform/board already working in the traditional u-boot way?
>>
>> I believe (but have no verified) that if your board is supported by
> U-Boot without a control FDT today, you can just create one that contains
> only the public keys.  I've gathered from the mailing list that using a
> control FDT and the driver model is how all new boards should be
> implemented.
>
>
>> 2.)  Just to summarise - everything winds up in two binaries: u-boot and
>> the FIT image.  So the partition scheme would more or less would look like:
>>
>> /-----------------
>> * Bootstrap/ROM (optional)
>> /----------------
>> * U-boot
>> *    Control DTB
>> *         Has keys
>>
>
> Only the public keys.  The private keys are never stored on the target
> device.
>
>
>> *         Driver loadout/init
>>
> The control FDT only describes the hardware (see
> https://www.devicetree.org/ and http://git.kernel.org/cgit/
> linux/kernel/git/torvalds/linux.git/tree/Documentation/
> devicetree/usage-model.txt).  U-Boot's driver model matches device
> drivers against nodes in the FDT and starts them.
>
>
>> /----------------
>> * U-boot env
>> *----------------
>> * FIT image
>>
> The FIT shouldn't be in the U-Boot env section.  That's used by U-Boot to
> store its persistent environment.  The FIT is a replacement for the kernel
> image.  Keep a separate place allocated in the flash for kernel but store
> the FIT there.
>
>
>> *    ITS
>>
> I never really thought of it this way, but yes, that's true.  The ITS is
> itself written in device tree syntax and gets compiled to binary form.  dtb
> tends to get used only to describe device trees in binary form that
> describe hardware.  Maybe we need to introduce ITB to clarify this is the
> device tree in binary form describing the image.
>
>
>> *    Kernel
>> *    DTS
>>
>
> Prefer the terms FDT or DTB.  Only the compiled form is stored in the FIT.
>
>
>> *    ....
>> /---------------
>> * Rootfs etc...
>> * ...
>> /---------------
>>
>>
>> 3.)  What people used to use to load X address into Z location in memory
>> is now removed by the usage of a DTB in u-boot correct?  I assume that the
>> u-boot DTB now does this and bootarg/bootcmd is partially done away with -
>> as its arguments are augmented by said file.
>>
>
> Not quite.  bootarg/bootcmd is still used.  What is different is that
> booting linux with a FDT with legacy images required multiple arguments to
> bootm.  In that case, bootarg would be 'bootm <zimage_addr> - <fdt_addr>'.
> With a FIT, you only provide the address of the FIT itself to bootm so
> bootarg is set to 'bootm <fit_addr>'.
>
>
>>
>> Anybody have the spare cycles to organise a web-tutorial/presentation/recording
>> with me on a play-by-play to make all of this make sense?  I'm aiming to be
>> in Prague for the 2017 conference in October, might be a good place to
>> showcase this fine-tuning.
>>
>>
> I'm not clear on what you are asking.  I probably have time to review docs
> and presentations and maybe a few phone or video conference meetings.
>
>
>> Ron
>>
>> On 22 February 2017 at 13:51, Rick Altherr <raltherr@google.com> wrote:
>>
>>>
>>> On Tue, Feb 21, 2017 at 10:08 AM, Ron Brash <ron.brash@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
>>>>
>>>
>>>
>>
>


-- 


Ron Brash
CTO  & Co-founder of Atlants Embedded Inc.
www.atlantsembedded.com
------------------------------------------------------------------

Cell +1 438 880 6441
Email  ron.brash at gmail.com
Blog www.pacificsimplicity.ca
LinkedIn ca.linkedin.com/in/ronbrash/



This communication is intended for the use of the recipient to which it is
addressed, and may contain confidential, personal, and or privileged
information. Please contact the sender immediately if you are not the
intended recipient of this communication, and do not copy, distribute, or
take action relying on it. Any communication received in error, or
subsequent reply, should be deleted or destroyed.

[U-Boot] Complete verified uboot example

[Rick Altherr]

The projects I'm working on are based on Yocto so I've been using the
u-boot signing support that is built in there.  I believe the magic you are
looking for is in
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/uboot-sign.bbclass.
Specifically, when you run 'mkimage -F -k <key-name> -K <control-dtb> -r
<fit>', the public keys will be inserted into the control dtb.  You can
then rebuild u-boot with 'make EXT_DTB=<control-dtb>' which will use the
dtb that includes the keys.

On Mon, Feb 27, 2017 at 7:34 AM, Ron Brash <ron.brash@gmail.com> wrote:

> Okay - it seems, after working my way through a bunch of the documentation
> and examples in /doc/uImage.FIT - I noticed a discrepancy
>
> /dts-v1/;
> /{
> description = "Configuration to load a Basic Kernel";
> #address-cells = <1>;
> images {
> linux_kernel at 1 {
> description = "Linux zImage";
> data = /incbin/("zImage");
> type = "kernel";
> arch = "arm";
> os = "linux";
> compression = "none";
> load =  <0x20000000>;
> entry = <0x20008000>;
> kernel-version = <1>;
> hash at 1 {
> algo = "sha256";
> };
> };
> fdt at 1 {
> description = "FDT blob";
> data = /incbin/("myboard.dtn");
> type = "flat_dt";
> arch = "arm";
> compression = "none";
> fdt-version = <1>;
> hash at 1{
> algo = "sha256";
> };
> };
> };
> configurations {
> default = "config at 1";
> config at 1{
> description = "Plain Linux";
> kernel = "linux_kernel at 1";
> fdt = "fdt at 1";
> signature at 1{
> algo = "sha256,rsa2048";
> key-name-hint = "dev_key";
> sign-images = "fdt", "kernel";
> };
> };
> };
> };
>
> Does NOT equal (for brevity - I just used the node)
>
> fdt at 1 {
> description = "FDT blob";
> data = /incbin/("myboard.dtn");
> type = "flat_dt";
> arch = "arm";
> compression = "none";
> fdt-version = <1>;
> hash at 1{
> algo = "sha256";
> };
> signature at 1{
> algo = "sha256,rsa2048";
> key-name-hint = "dev_key";
> };
> };
>
> Apparently, this causes the mkimage tooling in my particular instance to
> explain invalid blob messages.  The large example above indeed does work
> once this nuance was noticed.
>
> Next,  once the final CTRL FDT is created, how does one get it back into
> the actual u-boot binary.  Does/can mkimage insert it into the binary image
> at a particular offset?  What is the command to do so?
>
>
>
>
>
> On 23 February 2017 at 12:27, Rick Altherr <raltherr@google.com> wrote:
>
>>
>>
>> On Thu, Feb 23, 2017 at 7:48 AM, Ron Brash <ron.brash@gmail.com> wrote:
>>
>>> Hello all (and thanks Mr. Altherr for this insight),
>>>
>>> Excellent feedback and I agree that all of this needs to find a home
>>> either on the global docs on the website and/or the text-only
>>> documentation.  Regardless, this leads me to a few questions.
>>>
>>> NOTE: the use of a uboot control DTS, control DTB and control FTD even
>>> in Mr. Altherr's email is confusion provoking.  One term to rule them all
>>> is needed ;)
>>>
>>
>> Agreed.  Technically a flattened device tree (FDT) can be described in an
>> ASCII form (dts) or binary form (dtb).
>>
>>
>>>
>>> 1.)  What if a board doesn't have OR has ever been configured to use
>>> u-boot DTS (could we call this a UDTS or something friendly to
>>> differentiate that fact?); this was a point of misunderstanding until I
>>> started scampering around into arch/arm/dts/?
>>>
>>> * For example, my board is a derivative of an Atmel at91sam9g20.  It had
>>> a very generic implementation of a DTS that covered reference boards in the
>>> Linux kernel, but required a fair bit of modification to make it work.  As
>>> the at91sam(legacy platform) isn't in u-boot's source tree for a DTS - what
>>> would someone like me need to do - do we have a barebones tutorial (again I
>>> don't mind publishing such with proofing)?  Is it even required if we have
>>> a platform/board already working in the traditional u-boot way?
>>>
>>> I believe (but have no verified) that if your board is supported by
>> U-Boot without a control FDT today, you can just create one that contains
>> only the public keys.  I've gathered from the mailing list that using a
>> control FDT and the driver model is how all new boards should be
>> implemented.
>>
>>
>>> 2.)  Just to summarise - everything winds up in two binaries: u-boot and
>>> the FIT image.  So the partition scheme would more or less would look like:
>>>
>>> /-----------------
>>> * Bootstrap/ROM (optional)
>>> /----------------
>>> * U-boot
>>> *    Control DTB
>>> *         Has keys
>>>
>>
>> Only the public keys.  The private keys are never stored on the target
>> device.
>>
>>
>>> *         Driver loadout/init
>>>
>> The control FDT only describes the hardware (see
>> https://www.devicetree.org/ and http://git.kernel.org/cgit/lin
>> ux/kernel/git/torvalds/linux.git/tree/Documentation/devicet
>> ree/usage-model.txt).  U-Boot's driver model matches device drivers
>> against nodes in the FDT and starts them.
>>
>>
>>> /----------------
>>> * U-boot env
>>> *----------------
>>> * FIT image
>>>
>> The FIT shouldn't be in the U-Boot env section.  That's used by U-Boot to
>> store its persistent environment.  The FIT is a replacement for the kernel
>> image.  Keep a separate place allocated in the flash for kernel but store
>> the FIT there.
>>
>>
>>> *    ITS
>>>
>> I never really thought of it this way, but yes, that's true.  The ITS is
>> itself written in device tree syntax and gets compiled to binary form.  dtb
>> tends to get used only to describe device trees in binary form that
>> describe hardware.  Maybe we need to introduce ITB to clarify this is the
>> device tree in binary form describing the image.
>>
>>
>>> *    Kernel
>>> *    DTS
>>>
>>
>> Prefer the terms FDT or DTB.  Only the compiled form is stored in the FIT.
>>
>>
>>> *    ....
>>> /---------------
>>> * Rootfs etc...
>>> * ...
>>> /---------------
>>>
>>>
>>> 3.)  What people used to use to load X address into Z location in memory
>>> is now removed by the usage of a DTB in u-boot correct?  I assume that the
>>> u-boot DTB now does this and bootarg/bootcmd is partially done away with -
>>> as its arguments are augmented by said file.
>>>
>>
>> Not quite.  bootarg/bootcmd is still used.  What is different is that
>> booting linux with a FDT with legacy images required multiple arguments to
>> bootm.  In that case, bootarg would be 'bootm <zimage_addr> - <fdt_addr>'.
>> With a FIT, you only provide the address of the FIT itself to bootm so
>> bootarg is set to 'bootm <fit_addr>'.
>>
>>
>>>
>>> Anybody have the spare cycles to organise a
>>> web-tutorial/presentation/recording with me on a play-by-play to make
>>> all of this make sense?  I'm aiming to be in Prague for the 2017 conference
>>> in October, might be a good place to showcase this fine-tuning.
>>>
>>>
>> I'm not clear on what you are asking.  I probably have time to review
>> docs and presentations and maybe a few phone or video conference meetings.
>>
>>
>>> Ron
>>>
>>> On 22 February 2017 at 13:51, Rick Altherr <raltherr@google.com> wrote:
>>>
>>>>
>>>> On Tue, Feb 21, 2017 at 10:08 AM, Ron Brash <ron.brash@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
>>>>>
>>>>
>>>>
>>>
>>
>
>
> --
>
>
> Ron Brash
> CTO  & Co-founder of Atlants Embedded Inc.
> www.atlantsembedded.com
> ------------------------------------------------------------------
>
> Cell +1 438 880 6441 <(438)%20880-6441>
> Email  ron.brash at gmail.com
> Blog www.pacificsimplicity.ca
> LinkedIn ca.linkedin.com/in/ronbrash/
>
>
>
> This communication is intended for the use of the recipient to which it is
> addressed, and may contain confidential, personal, and or privileged
> information. Please contact the sender immediately if you are not the
> intended recipient of this communication, and do not copy, distribute, or
> take action relying on it. Any communication received in error, or
> subsequent reply, should be deleted or destroyed.
>

[U-Boot] Complete verified uboot example

[Ron Brash]

Looks like far more progress:

#> setenv my_bootcount 0; bootm 0xD0084000
Initial value for argc=3
Final value for argc=3
## Current stack ends at 0x23f11db8 *  kernel: cmdline image address =
0xd0084000
   Reading image header from dataflash address d0084000 to RAM address
22000000
   FIT/FDT format image found at 0x22000000, size 0x0016c0b1
   Reading image remaining data from dataflash address d0084040 to RAM
address 22000040
## Loading kernel from FIT Image at 22000000 ...
No configuration specified, trying default...
Found default configuration: 'config at 1'
   Using 'config at 1' configuration
   Trying 'linux_kernel at 1' kernel subimage
     Description:  Linux zImage
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x220000dc
     Data Size:    1465544 Bytes = 1.4 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: 0x22000000
     Entry Point:  0x22008000
     Hash node:    'hash at 1'
     Hash algo:    sha256
     Hash value:
5dcf9a4328bca6fe5c3405e03b9a58402dce36f3a4f0c757e52091b050d2bcb2
     Hash len:     32
   Verifying Hash Integrity ... sha256+ OK
   kernel data at 0x220000dc, len = 0x00165cc8 (1465544)
*  ramdisk: using config 'config at 1' from image at 0x22000000
*  ramdisk: no 'ramdisk' in config
*  fdt: using config 'config at 1' from image at 0x22000000
## Checking for 'FDT'/'FDT Image' at 22000000
## Loading fdt from FIT Image at 22000000 ...
   Using 'config at 1' configuration
   Trying 'fdt at 1' fdt subimage
     Description:  FDT blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x22165ea4
     Data Size:    21681 Bytes = 21.2 KiB
     Architecture: ARM
     Hash node:    'hash at 1'
     Hash algo:    sha256
     Hash value:
c7f32d039871d858dda8d397c3b6a685bc914c78cf70f03d1860f61ecfe9c689
     Hash len:     32
   Verifying Hash Integrity ... sha256+ OK
   Loading fdt from 0x22165ea4 to 0x28000000
   Booting using the fdt blob at 0x28000000
   of_flat_tree at 0x28000000 size 0x000054b1
Initial value for argc=3
Final value for argc=3
   Loading Kernel Image ... OK
CACHE: Misaligned operation at range [22000000, 22165cc8]
   kernel loaded at 0x22000000, end = 0x22165cc8
images.os.start = 0x22000000, images.os.end = 0x2216c0f1
images.os.load = 0x22000000, load_end = 0x22165cc8
ERROR: new format image overwritten - must RESET the board to recover
resetting ...

This appears to be an addressing issue.  Anyone care to comment?

I'll put up how I got to this point after, but I am curious on how all of
the addresses are leveraged, is there an order they follow and more?



On 27 February 2017 at 15:58, Rick Altherr <raltherr@google.com> wrote:

> The projects I'm working on are based on Yocto so I've been using the
> u-boot signing support that is built in there.  I believe the magic you are
> looking for is in http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/
> meta/classes/uboot-sign.bbclass.  Specifically, when you run 'mkimage -F
> -k <key-name> -K <control-dtb> -r <fit>', the public keys will be inserted
> into the control dtb.  You can then rebuild u-boot with 'make
> EXT_DTB=<control-dtb>' which will use the dtb that includes the keys.
>
> On Mon, Feb 27, 2017 at 7:34 AM, Ron Brash <ron.brash@gmail.com> wrote:
>
>> Okay - it seems, after working my way through a bunch of the
>> documentation and examples in /doc/uImage.FIT - I noticed a discrepancy
>>
>> /dts-v1/;
>> /{
>> description = "Configuration to load a Basic Kernel";
>> #address-cells = <1>;
>> images {
>> linux_kernel at 1 {
>> description = "Linux zImage";
>> data = /incbin/("zImage");
>> type = "kernel";
>> arch = "arm";
>> os = "linux";
>> compression = "none";
>> load =  <0x20000000>;
>> entry = <0x20008000>;
>> kernel-version = <1>;
>> hash at 1 {
>> algo = "sha256";
>> };
>> };
>> fdt at 1 {
>> description = "FDT blob";
>> data = /incbin/("myboard.dtn");
>> type = "flat_dt";
>> arch = "arm";
>> compression = "none";
>> fdt-version = <1>;
>> hash at 1{
>> algo = "sha256";
>> };
>> };
>> };
>> configurations {
>> default = "config at 1";
>> config at 1{
>> description = "Plain Linux";
>> kernel = "linux_kernel at 1";
>> fdt = "fdt at 1";
>> signature at 1{
>> algo = "sha256,rsa2048";
>> key-name-hint = "dev_key";
>> sign-images = "fdt", "kernel";
>> };
>> };
>> };
>> };
>>
>> Does NOT equal (for brevity - I just used the node)
>>
>> fdt at 1 {
>> description = "FDT blob";
>> data = /incbin/("myboard.dtn");
>> type = "flat_dt";
>> arch = "arm";
>> compression = "none";
>> fdt-version = <1>;
>> hash at 1{
>> algo = "sha256";
>> };
>> signature at 1{
>> algo = "sha256,rsa2048";
>> key-name-hint = "dev_key";
>> };
>> };
>>
>> Apparently, this causes the mkimage tooling in my particular instance to
>> explain invalid blob messages.  The large example above indeed does work
>> once this nuance was noticed.
>>
>> Next,  once the final CTRL FDT is created, how does one get it back into
>> the actual u-boot binary.  Does/can mkimage insert it into the binary image
>> at a particular offset?  What is the command to do so?
>>
>>
>>
>>
>>
>> On 23 February 2017 at 12:27, Rick Altherr <raltherr@google.com> wrote:
>>
>>>
>>>
>>> On Thu, Feb 23, 2017 at 7:48 AM, Ron Brash <ron.brash@gmail.com> wrote:
>>>
>>>> Hello all (and thanks Mr. Altherr for this insight),
>>>>
>>>> Excellent feedback and I agree that all of this needs to find a home
>>>> either on the global docs on the website and/or the text-only
>>>> documentation.  Regardless, this leads me to a few questions.
>>>>
>>>> NOTE: the use of a uboot control DTS, control DTB and control FTD even
>>>> in Mr. Altherr's email is confusion provoking.  One term to rule them all
>>>> is needed ;)
>>>>
>>>
>>> Agreed.  Technically a flattened device tree (FDT) can be described in
>>> an ASCII form (dts) or binary form (dtb).
>>>
>>>
>>>>
>>>> 1.)  What if a board doesn't have OR has ever been configured to use
>>>> u-boot DTS (could we call this a UDTS or something friendly to
>>>> differentiate that fact?); this was a point of misunderstanding until I
>>>> started scampering around into arch/arm/dts/?
>>>>
>>>> * For example, my board is a derivative of an Atmel at91sam9g20.  It
>>>> had a very generic implementation of a DTS that covered reference boards in
>>>> the Linux kernel, but required a fair bit of modification to make it work.
>>>> As the at91sam(legacy platform) isn't in u-boot's source tree for a DTS -
>>>> what would someone like me need to do - do we have a barebones tutorial
>>>> (again I don't mind publishing such with proofing)?  Is it even required if
>>>> we have a platform/board already working in the traditional u-boot way?
>>>>
>>>> I believe (but have no verified) that if your board is supported by
>>> U-Boot without a control FDT today, you can just create one that contains
>>> only the public keys.  I've gathered from the mailing list that using a
>>> control FDT and the driver model is how all new boards should be
>>> implemented.
>>>
>>>
>>>> 2.)  Just to summarise - everything winds up in two binaries: u-boot
>>>> and the FIT image.  So the partition scheme would more or less would look
>>>> like:
>>>>
>>>> /-----------------
>>>> * Bootstrap/ROM (optional)
>>>> /----------------
>>>> * U-boot
>>>> *    Control DTB
>>>> *         Has keys
>>>>
>>>
>>> Only the public keys.  The private keys are never stored on the target
>>> device.
>>>
>>>
>>>> *         Driver loadout/init
>>>>
>>> The control FDT only describes the hardware (see
>>> https://www.devicetree.org/ and http://git.kernel.org/cgit/lin
>>> ux/kernel/git/torvalds/linux.git/tree/Documentation/devicetr
>>> ee/usage-model.txt).  U-Boot's driver model matches device drivers
>>> against nodes in the FDT and starts them.
>>>
>>>
>>>> /----------------
>>>> * U-boot env
>>>> *----------------
>>>> * FIT image
>>>>
>>> The FIT shouldn't be in the U-Boot env section.  That's used by U-Boot
>>> to store its persistent environment.  The FIT is a replacement for the
>>> kernel image.  Keep a separate place allocated in the flash for kernel but
>>> store the FIT there.
>>>
>>>
>>>> *    ITS
>>>>
>>> I never really thought of it this way, but yes, that's true.  The ITS is
>>> itself written in device tree syntax and gets compiled to binary form.  dtb
>>> tends to get used only to describe device trees in binary form that
>>> describe hardware.  Maybe we need to introduce ITB to clarify this is the
>>> device tree in binary form describing the image.
>>>
>>>
>>>> *    Kernel
>>>> *    DTS
>>>>
>>>
>>> Prefer the terms FDT or DTB.  Only the compiled form is stored in the
>>> FIT.
>>>
>>>
>>>> *    ....
>>>> /---------------
>>>> * Rootfs etc...
>>>> * ...
>>>> /---------------
>>>>
>>>>
>>>> 3.)  What people used to use to load X address into Z location in
>>>> memory is now removed by the usage of a DTB in u-boot correct?  I assume
>>>> that the u-boot DTB now does this and bootarg/bootcmd is partially done
>>>> away with - as its arguments are augmented by said file.
>>>>
>>>
>>> Not quite.  bootarg/bootcmd is still used.  What is different is that
>>> booting linux with a FDT with legacy images required multiple arguments to
>>> bootm.  In that case, bootarg would be 'bootm <zimage_addr> - <fdt_addr>'.
>>> With a FIT, you only provide the address of the FIT itself to bootm so
>>> bootarg is set to 'bootm <fit_addr>'.
>>>
>>>
>>>>
>>>> Anybody have the spare cycles to organise a
>>>> web-tutorial/presentation/recording with me on a play-by-play to make
>>>> all of this make sense?  I'm aiming to be in Prague for the 2017 conference
>>>> in October, might be a good place to showcase this fine-tuning.
>>>>
>>>>
>>> I'm not clear on what you are asking.  I probably have time to review
>>> docs and presentations and maybe a few phone or video conference meetings.
>>>
>>>
>>>> Ron
>>>>
>>>> On 22 February 2017 at 13:51, Rick Altherr <raltherr@google.com> wrote:
>>>>
>>>>>
>>>>> On Tue, Feb 21, 2017 at 10:08 AM, Ron Brash <ron.brash@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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>> --
>>
>>
>> Ron Brash
>> CTO  & Co-founder of Atlants Embedded Inc.
>> www.atlantsembedded.com
>> ------------------------------------------------------------------
>>
>> Cell +1 438 880 6441 <(438)%20880-6441>
>> Email  ron.brash at gmail.com
>> Blog www.pacificsimplicity.ca
>> LinkedIn ca.linkedin.com/in/ronbrash/
>>
>>
>>
>> This communication is intended for the use of the recipient to which it is
>> addressed, and may contain confidential, personal, and or privileged
>> information. Please contact the sender immediately if you are not the
>> intended recipient of this communication, and do not copy, distribute, or
>> take action relying on it. Any communication received in error, or
>> subsequent reply, should be deleted or destroyed.
>>
>
>


-- 


Ron Brash
CTO  & Co-founder of Atlants Embedded Inc.
www.atlantsembedded.com
------------------------------------------------------------------

Cell +1 438 880 6441
Email  ron.brash at gmail.com
Blog www.pacificsimplicity.ca
LinkedIn ca.linkedin.com/in/ronbrash/



This communication is intended for the use of the recipient to which it is
addressed, and may contain confidential, personal, and or privileged
information. Please contact the sender immediately if you are not the
intended recipient of this communication, and do not copy, distribute, or
take action relying on it. Any communication received in error, or
subsequent reply, should be deleted or destroyed.

[U-Boot] Complete verified uboot example

[Rick Altherr]

You set the load address for the linux image to the same location as the
FIT.  U-Boot verified the hashes on the FIT and then tried to copy the
kernel over top the FIT.  I assume you put the FIT in flash.  Pick a
location in RAM for the kernel's load address.

On Mon, Feb 27, 2017 at 1:49 PM, Ron Brash <ron.brash@gmail.com> wrote:

> Looks like far more progress:
>
> #> setenv my_bootcount 0; bootm 0xD0084000
> Initial value for argc=3
> Final value for argc=3
> ## Current stack ends at 0x23f11db8 *  kernel: cmdline image address =
> 0xd0084000
>    Reading image header from dataflash address d0084000 to RAM address
> 22000000
>    FIT/FDT format image found at 0x22000000, size 0x0016c0b1
>    Reading image remaining data from dataflash address d0084040 to RAM
> address 22000040
> ## Loading kernel from FIT Image at 22000000 ...
> No configuration specified, trying default...
> Found default configuration: 'config at 1'
>    Using 'config at 1' configuration
>    Trying 'linux_kernel at 1' kernel subimage
>      Description:  Linux zImage
>      Type:         Kernel Image
>      Compression:  uncompressed
>      Data Start:   0x220000dc
>      Data Size:    1465544 Bytes = 1.4 MiB
>      Architecture: ARM
>      OS:           Linux
>      Load Address: 0x22000000
>      Entry Point:  0x22008000
>      Hash node:    'hash at 1'
>      Hash algo:    sha256
>      Hash value:   5dcf9a4328bca6fe5c3405e03b9a58
> 402dce36f3a4f0c757e52091b050d2bcb2
>      Hash len:     32
>    Verifying Hash Integrity ... sha256+ OK
>    kernel data at 0x220000dc, len = 0x00165cc8 (1465544)
> *  ramdisk: using config 'config at 1' from image at 0x22000000
> *  ramdisk: no 'ramdisk' in config
> *  fdt: using config 'config at 1' from image at 0x22000000
> ## Checking for 'FDT'/'FDT Image' at 22000000
> ## Loading fdt from FIT Image at 22000000 ...
>    Using 'config at 1' configuration
>    Trying 'fdt at 1' fdt subimage
>      Description:  FDT blob
>      Type:         Flat Device Tree
>      Compression:  uncompressed
>      Data Start:   0x22165ea4
>      Data Size:    21681 Bytes = 21.2 KiB
>      Architecture: ARM
>      Hash node:    'hash at 1'
>      Hash algo:    sha256
>      Hash value:   c7f32d039871d858dda8d397c3b6a6
> 85bc914c78cf70f03d1860f61ecfe9c689
>      Hash len:     32
>    Verifying Hash Integrity ... sha256+ OK
>    Loading fdt from 0x22165ea4 to 0x28000000
>    Booting using the fdt blob at 0x28000000
>    of_flat_tree at 0x28000000 size 0x000054b1
> Initial value for argc=3
> Final value for argc=3
>    Loading Kernel Image ... OK
> CACHE: Misaligned operation at range [22000000, 22165cc8]
>    kernel loaded at 0x22000000, end = 0x22165cc8
> images.os.start = 0x22000000, images.os.end = 0x2216c0f1
> images.os.load = 0x22000000, load_end = 0x22165cc8
> ERROR: new format image overwritten - must RESET the board to recover
> resetting ...
>
> This appears to be an addressing issue.  Anyone care to comment?
>
> I'll put up how I got to this point after, but I am curious on how all of
> the addresses are leveraged, is there an order they follow and more?
>
>
>
> On 27 February 2017 at 15:58, Rick Altherr <raltherr@google.com> wrote:
>
>> The projects I'm working on are based on Yocto so I've been using the
>> u-boot signing support that is built in there.  I believe the magic you are
>> looking for is in http://git.yoctoproject.org
>> /cgit/cgit.cgi/poky/tree/meta/classes/uboot-sign.bbclass.  Specifically,
>> when you run 'mkimage -F -k <key-name> -K <control-dtb> -r <fit>', the
>> public keys will be inserted into the control dtb.  You can then rebuild
>> u-boot with 'make EXT_DTB=<control-dtb>' which will use the dtb that
>> includes the keys.
>>
>> On Mon, Feb 27, 2017 at 7:34 AM, Ron Brash <ron.brash@gmail.com> wrote:
>>
>>> Okay - it seems, after working my way through a bunch of the
>>> documentation and examples in /doc/uImage.FIT - I noticed a discrepancy
>>>
>>> /dts-v1/;
>>> /{
>>> description = "Configuration to load a Basic Kernel";
>>> #address-cells = <1>;
>>> images {
>>> linux_kernel at 1 {
>>> description = "Linux zImage";
>>> data = /incbin/("zImage");
>>> type = "kernel";
>>> arch = "arm";
>>> os = "linux";
>>> compression = "none";
>>> load =  <0x20000000>;
>>> entry = <0x20008000>;
>>> kernel-version = <1>;
>>> hash at 1 {
>>> algo = "sha256";
>>> };
>>> };
>>> fdt at 1 {
>>> description = "FDT blob";
>>> data = /incbin/("myboard.dtn");
>>> type = "flat_dt";
>>> arch = "arm";
>>> compression = "none";
>>> fdt-version = <1>;
>>> hash at 1{
>>> algo = "sha256";
>>> };
>>> };
>>> };
>>> configurations {
>>> default = "config at 1";
>>> config at 1{
>>> description = "Plain Linux";
>>> kernel = "linux_kernel at 1";
>>> fdt = "fdt at 1";
>>> signature at 1{
>>> algo = "sha256,rsa2048";
>>> key-name-hint = "dev_key";
>>> sign-images = "fdt", "kernel";
>>> };
>>> };
>>> };
>>> };
>>>
>>> Does NOT equal (for brevity - I just used the node)
>>>
>>> fdt at 1 {
>>> description = "FDT blob";
>>> data = /incbin/("myboard.dtn");
>>> type = "flat_dt";
>>> arch = "arm";
>>> compression = "none";
>>> fdt-version = <1>;
>>> hash at 1{
>>> algo = "sha256";
>>> };
>>> signature at 1{
>>> algo = "sha256,rsa2048";
>>> key-name-hint = "dev_key";
>>> };
>>> };
>>>
>>> Apparently, this causes the mkimage tooling in my particular instance to
>>> explain invalid blob messages.  The large example above indeed does work
>>> once this nuance was noticed.
>>>
>>> Next,  once the final CTRL FDT is created, how does one get it back into
>>> the actual u-boot binary.  Does/can mkimage insert it into the binary image
>>> at a particular offset?  What is the command to do so?
>>>
>>>
>>>
>>>
>>>
>>> On 23 February 2017 at 12:27, Rick Altherr <raltherr@google.com> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Feb 23, 2017 at 7:48 AM, Ron Brash <ron.brash@gmail.com> wrote:
>>>>
>>>>> Hello all (and thanks Mr. Altherr for this insight),
>>>>>
>>>>> Excellent feedback and I agree that all of this needs to find a home
>>>>> either on the global docs on the website and/or the text-only
>>>>> documentation.  Regardless, this leads me to a few questions.
>>>>>
>>>>> NOTE: the use of a uboot control DTS, control DTB and control FTD even
>>>>> in Mr. Altherr's email is confusion provoking.  One term to rule them all
>>>>> is needed ;)
>>>>>
>>>>
>>>> Agreed.  Technically a flattened device tree (FDT) can be described in
>>>> an ASCII form (dts) or binary form (dtb).
>>>>
>>>>
>>>>>
>>>>> 1.)  What if a board doesn't have OR has ever been configured to use
>>>>> u-boot DTS (could we call this a UDTS or something friendly to
>>>>> differentiate that fact?); this was a point of misunderstanding until I
>>>>> started scampering around into arch/arm/dts/?
>>>>>
>>>>> * For example, my board is a derivative of an Atmel at91sam9g20.  It
>>>>> had a very generic implementation of a DTS that covered reference boards in
>>>>> the Linux kernel, but required a fair bit of modification to make it work.
>>>>> As the at91sam(legacy platform) isn't in u-boot's source tree for a DTS -
>>>>> what would someone like me need to do - do we have a barebones tutorial
>>>>> (again I don't mind publishing such with proofing)?  Is it even required if
>>>>> we have a platform/board already working in the traditional u-boot way?
>>>>>
>>>>> I believe (but have no verified) that if your board is supported by
>>>> U-Boot without a control FDT today, you can just create one that contains
>>>> only the public keys.  I've gathered from the mailing list that using a
>>>> control FDT and the driver model is how all new boards should be
>>>> implemented.
>>>>
>>>>
>>>>> 2.)  Just to summarise - everything winds up in two binaries: u-boot
>>>>> and the FIT image.  So the partition scheme would more or less would look
>>>>> like:
>>>>>
>>>>> /-----------------
>>>>> * Bootstrap/ROM (optional)
>>>>> /----------------
>>>>> * U-boot
>>>>> *    Control DTB
>>>>> *         Has keys
>>>>>
>>>>
>>>> Only the public keys.  The private keys are never stored on the target
>>>> device.
>>>>
>>>>
>>>>> *         Driver loadout/init
>>>>>
>>>> The control FDT only describes the hardware (see
>>>> https://www.devicetree.org/ and http://git.kernel.org/cgit/lin
>>>> ux/kernel/git/torvalds/linux.git/tree/Documentation/devicetr
>>>> ee/usage-model.txt).  U-Boot's driver model matches device drivers
>>>> against nodes in the FDT and starts them.
>>>>
>>>>
>>>>> /----------------
>>>>> * U-boot env
>>>>> *----------------
>>>>> * FIT image
>>>>>
>>>> The FIT shouldn't be in the U-Boot env section.  That's used by U-Boot
>>>> to store its persistent environment.  The FIT is a replacement for the
>>>> kernel image.  Keep a separate place allocated in the flash for kernel but
>>>> store the FIT there.
>>>>
>>>>
>>>>> *    ITS
>>>>>
>>>> I never really thought of it this way, but yes, that's true.  The ITS
>>>> is itself written in device tree syntax and gets compiled to binary form.
>>>>  dtb tends to get used only to describe device trees in binary form that
>>>> describe hardware.  Maybe we need to introduce ITB to clarify this is the
>>>> device tree in binary form describing the image.
>>>>
>>>>
>>>>> *    Kernel
>>>>> *    DTS
>>>>>
>>>>
>>>> Prefer the terms FDT or DTB.  Only the compiled form is stored in the
>>>> FIT.
>>>>
>>>>
>>>>> *    ....
>>>>> /---------------
>>>>> * Rootfs etc...
>>>>> * ...
>>>>> /---------------
>>>>>
>>>>>
>>>>> 3.)  What people used to use to load X address into Z location in
>>>>> memory is now removed by the usage of a DTB in u-boot correct?  I assume
>>>>> that the u-boot DTB now does this and bootarg/bootcmd is partially done
>>>>> away with - as its arguments are augmented by said file.
>>>>>
>>>>
>>>> Not quite.  bootarg/bootcmd is still used.  What is different is that
>>>> booting linux with a FDT with legacy images required multiple arguments to
>>>> bootm.  In that case, bootarg would be 'bootm <zimage_addr> - <fdt_addr>'.
>>>> With a FIT, you only provide the address of the FIT itself to bootm so
>>>> bootarg is set to 'bootm <fit_addr>'.
>>>>
>>>>
>>>>>
>>>>> Anybody have the spare cycles to organise a
>>>>> web-tutorial/presentation/recording with me on a play-by-play to make
>>>>> all of this make sense?  I'm aiming to be in Prague for the 2017 conference
>>>>> in October, might be a good place to showcase this fine-tuning.
>>>>>
>>>>>
>>>> I'm not clear on what you are asking.  I probably have time to review
>>>> docs and presentations and maybe a few phone or video conference meetings.
>>>>
>>>>
>>>>> Ron
>>>>>
>>>>> On 22 February 2017 at 13:51, Rick Altherr <raltherr@google.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> On Tue, Feb 21, 2017 at 10:08 AM, Ron Brash <ron.brash@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
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>>
>>>
>>> Ron Brash
>>> CTO  & Co-founder of Atlants Embedded Inc.
>>> www.atlantsembedded.com
>>> ------------------------------------------------------------------
>>>
>>> Cell +1 438 880 6441 <(438)%20880-6441>
>>> Email  ron.brash at gmail.com
>>> Blog www.pacificsimplicity.ca
>>> LinkedIn ca.linkedin.com/in/ronbrash/
>>>
>>>
>>>
>>> This communication is intended for the use of the recipient to which it
>>> is
>>> addressed, and may contain confidential, personal, and or privileged
>>> information. Please contact the sender immediately if you are not the
>>> intended recipient of this communication, and do not copy, distribute, or
>>> take action relying on it. Any communication received in error, or
>>> subsequent reply, should be deleted or destroyed.
>>>
>>
>>
>
>
> --
>
>
> Ron Brash
> CTO  & Co-founder of Atlants Embedded Inc.
> www.atlantsembedded.com
> ------------------------------------------------------------------
>
> Cell +1 438 880 6441 <(438)%20880-6441>
> Email  ron.brash at gmail.com
> Blog www.pacificsimplicity.ca
> LinkedIn ca.linkedin.com/in/ronbrash/
>
>
>
> This communication is intended for the use of the recipient to which it is
> addressed, and may contain confidential, personal, and or privileged
> information. Please contact the sender immediately if you are not the
> intended recipient of this communication, and do not copy, distribute, or
> take action relying on it. Any communication received in error, or
> subsequent reply, should be deleted or destroyed.
>

[U-Boot] Complete verified uboot example

[Ron Brash]

Hello,

Still for some reason - there is an issue with booting from the FIT.  With
a version of Uboot without the FIT related CONFIGs enabled; everything
works.

Here is me taking my zImage and converting it to a u-image ( I am not sure
on the addresses)

mkimage -A arm -O linux -C none -T kernel -a 0x23008000 -e 0x23008000 -n
linux-4.4.36b \
-d $(KDIR)/zImage $(BIN_DIR)/$(IMG_PREFIX)-zImage-nDTB2


My .its:

/dts-v1/;
/{
description = "Configuration to load a Basic Kernel";
#address-cells = <1>;
images {
linux_kernel at 1 {
description = "Linux zImage";
data =
/incbin/("../../../../bin/targets/myboard/legacy/myboard-legacy-zImage-nDTB2");
type = "kernel";
arch = "arm";
os = "linux";
compression = "none";
load =  <0x23008000>;
entry = <0x23008000>;
kernel-version = <1>;
hash at 1 {
algo = "sha256";
};
};
fdt at 1 {
description = "FDT blob";
data = /incbin/("../../../../bin/targets/myboard/legacy/myboard.dtb");
type = "flat_dt";
arch = "arm";
compression = "none";
load =  <0x28000000>;
fdt-version = <1>;
hash at 1{
algo = "sha256";
};
};
};
configurations {
default = "config at 1";
config at 1{
description = "Plain Linux";
kernel = "linux_kernel at 1";
fdt = "fdt at 1";
signature at 1{
algo = "sha256,rsa2048";
key-name-hint = "dev_key";
sign-images = "fdt", "kernel";
};
};
};
};


Then


set -ex
key_dir="/tmp/keys"
key_name="dev_key"

rm -rf ${FIT_IMG}
rm -rf ${key_dir}
mkdir ${key_dir}
rootdir="/home/dev/usr"

MKIMG="${rootdir}/lede/staging_dir/host/bin/mkimage"
DTC="/usr/bin/dtc"
CPP="/usr/bin/cpp"
OPENSSL="/usr/bin/openssl"

#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

# Control FDT (u-boot.dts) - hits uboot to have keys etc...
BD_NAME="at91sam9260-plx35"
PATH_TO_BIN="${rootdir}/lede/bin/targets/myboard/legacy"

#
# This is the uboot-nodtb.bin (just renamed)
#
UBOOT_NAME="lede-myboard.bin"
UBOOT_WITH_DTB="${PATH_TO_BIN}/${UBOOT_NAME}"

PATH_TO_CTRL_FDT="${rootdir}/lede/build_dir/target-arm_arm926ej-s_musl-1.1.15_eabi/linux-myboard/myboard-uboot-2016.05/arch/arm/dts/"

CTRL_FDT="${PATH_TO_CTRL_FDT}${BD_NAME}"

FIT_ITS="at91sam9260"
FIT_IMG="${rootdir}/lede/bin/targets/myboard/legacy/lede-at91-image.fit"

DOPTS="-I dts -O dtb -p 2000"

# Generate fitImage with space for signature:
echo "create FIT with space - no signing"
echo " --------------------------------"
$MKIMG -D "${DOPTS}" \
 -f "${FIT_ITS}".its "${FIT_IMG}"

echo ""
echo ""

# Now add them and sign them
echo "Sign images with our keys"
echo " --------------------------------"
$MKIMG -D "${DOPTS}" -F \
-k "${key_dir}" -K "${CTRL_FDT}".dtb -r "${FIT_IMG}"

echo ""
echo ""

# Add FDT to image
cp ${UBOOT_WITH_DTB} ${UBOOT_WITH_DTB}-wDTB
cat ${PATH_TO_CTRL_FDT}/${BD_NAME}.dtb >> ${UBOOT_WITH_DTB}-wDTB


Then I flash the uboot-WDTB to the board and also the FIT image.  Following
that, then I load the FIT into RAM and execute it with the command:


cp.b 0xD0084000 0x22000000 0x186A00;setenv my_bootcount 0; bootm 0x22000000

Initial value for argc=3
Final value for argc=3
## Current stack ends at 0x23f119b8 *  kernel: cmdline image address =
0x22000000
## Loading kernel from FIT Image at 22000000 ...
No configuration specified, trying default...
Found default configuration: 'config at 1'
   Using 'config at 1' configuration
   Trying 'linux_kernel at 1' kernel subimage
     Description:  Linux zImage
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x220000dc
     Data Size:    1465544 Bytes = 1.4 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: 0x23008000
     Entry Point:  0x23008000
     Hash node:    'hash at 1'
     Hash algo:    sha256
     Hash value:
52f8048436c3f62d9108957cb4f6f7d4e58c8c9931d68ea6f0121f4c661c7ffe
     Hash len:     32
   Verifying Hash Integrity ... sha256+ OK
   kernel data at 0x220000dc, len = 0x00165cc8 (1465544)
*  ramdisk: using config 'config at 1' from image at 0x22000000
*  ramdisk: no 'ramdisk' in config
*  fdt: using config 'config at 1' from image at 0x22000000
## Checking for 'FDT'/'FDT Image' at 22000000
## Loading fdt from FIT Image at 22000000 ...
   Using 'config at 1' configuration
   Trying 'fdt at 1' fdt subimage
     Description:  FDT blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x22165ea4
     Data Size:    21681 Bytes = 21.2 KiB
     Architecture: ARM
     Hash node:    'hash at 1'
     Hash algo:    sha256
     Hash value:
c7f32d039871d858dda8d397c3b6a685bc914c78cf70f03d1860f61ecfe9c689
     Hash len:     32
   Verifying Hash Integrity ... sha256+ OK
   Loading fdt from 0x22165ea4 to 0x28000000
   Booting using the fdt blob at 0x28000000
   of_flat_tree at 0x28000000 size 0x000054b1
Initial value for argc=3
Final value for argc=3
   Loading Kernel Image ... OK
CACHE: Misaligned operation at range [23008000, 2316dcc8]
   kernel loaded at 0x23008000, end = 0x2316dcc8
using: FDT
## initrd_high = 0x24000000, copy_to_ram = 1
   ramdisk load start = 0x00000000, ramdisk load end = 0x00000000
## device tree at 28000000 ... 280054b0 (len=33969 [0x84B1])
   Loading Device Tree to 23f08000, end 23f104b0 ... OK
Initial value for argc=3
Final value for argc=3
## Transferring control to Linux (at address 23008000)...

Starting kernel ...

undefined instruction
pc : [<23008028>]          lr : [<23f44ca4>]
reloc pc : [<20fc3028>]    lr : [<21effca4>]
sp : 23f11980  ip : 23f9472c     fp : 00000000
r10: 23f1e61c  r9 : 23f17ef0     r8 : 23f4585c
r7 : 00000000  r6 : 23008000     r5 : 23f9b0f4  r4 : 00000081
r3 : 000054b1  r2 : 23f08000     r1 : 00000658  r0 : 23900000
Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

With iminfo:

#> cp.b 0xD0084000 0x22000000 0x186A00
#> iminfo

## Checking Image at 22000000 ...
   FIT image found
   FIT description: Configuration to load a Basic Kernel
    Image 0 (linux_kernel at 1)
     Description:  Linux zImage
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x220000dc
     Data Size:    1465544 Bytes = 1.4 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: 0x23008000
     Entry Point:  0x23008000
     Hash node:    'hash at 1'
     Hash algo:    sha256
     Hash value:
52f8048436c3f62d9108957cb4f6f7d4e58c8c9931d68ea6f0121f4c661c7ffe
     Hash len:     32
    Image 1 (fdt at 1)
     Description:  FDT blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x22165ea4
     Data Size:    21681 Bytes = 21.2 KiB
     Architecture: ARM
     Hash node:    'hash at 1'
     Hash algo:    sha256
     Hash value:
c7f32d039871d858dda8d397c3b6a685bc914c78cf70f03d1860f61ecfe9c689
     Hash len:     32
    Default Configuration: 'config at 1'
    Configuration 0 (config at 1)
     Description:  Plain Linux
     Kernel:       linux_kernel at 1
     FDT:          fdt at 1
## Checking hash(es) for FIT Image at 22000000 ...
   Hash(es) for Image 0 (linux_kernel at 1): sha256+
   Hash(es) for Image 1 (fdt at 1): sha256+


Any input?  This seems like offsets and not knowing where various
components need to be looking.






On 27 February 2017 at 16:53, Rick Altherr <raltherr@google.com> wrote:

> You set the load address for the linux image to the same location as the
> FIT.  U-Boot verified the hashes on the FIT and then tried to copy the
> kernel over top the FIT.  I assume you put the FIT in flash.  Pick a
> location in RAM for the kernel's load address.
>
> On Mon, Feb 27, 2017 at 1:49 PM, Ron Brash <ron.brash@gmail.com> wrote:
>
>> Looks like far more progress:
>>
>> #> setenv my_bootcount 0; bootm 0xD0084000
>> Initial value for argc=3
>> Final value for argc=3
>> ## Current stack ends at 0x23f11db8 *  kernel: cmdline image address =
>> 0xd0084000
>>    Reading image header from dataflash address d0084000 to RAM address
>> 22000000
>>    FIT/FDT format image found at 0x22000000, size 0x0016c0b1
>>    Reading image remaining data from dataflash address d0084040 to RAM
>> address 22000040
>> ## Loading kernel from FIT Image at 22000000 ...
>> No configuration specified, trying default...
>> Found default configuration: 'config at 1'
>>    Using 'config at 1' configuration
>>    Trying 'linux_kernel at 1' kernel subimage
>>      Description:  Linux zImage
>>      Type:         Kernel Image
>>      Compression:  uncompressed
>>      Data Start:   0x220000dc
>>      Data Size:    1465544 Bytes = 1.4 MiB
>>      Architecture: ARM
>>      OS:           Linux
>>      Load Address: 0x22000000
>>      Entry Point:  0x22008000
>>      Hash node:    'hash at 1'
>>      Hash algo:    sha256
>>      Hash value:   5dcf9a4328bca6fe5c3405e03b9a58
>> 402dce36f3a4f0c757e52091b050d2bcb2
>>      Hash len:     32
>>    Verifying Hash Integrity ... sha256+ OK
>>    kernel data at 0x220000dc, len = 0x00165cc8 (1465544)
>> *  ramdisk: using config 'config at 1' from image at 0x22000000
>> *  ramdisk: no 'ramdisk' in config
>> *  fdt: using config 'config at 1' from image at 0x22000000
>> ## Checking for 'FDT'/'FDT Image' at 22000000
>> ## Loading fdt from FIT Image at 22000000 ...
>>    Using 'config at 1' configuration
>>    Trying 'fdt at 1' fdt subimage
>>      Description:  FDT blob
>>      Type:         Flat Device Tree
>>      Compression:  uncompressed
>>      Data Start:   0x22165ea4
>>      Data Size:    21681 Bytes = 21.2 KiB
>>      Architecture: ARM
>>      Hash node:    'hash at 1'
>>      Hash algo:    sha256
>>      Hash value:   c7f32d039871d858dda8d397c3b6a6
>> 85bc914c78cf70f03d1860f61ecfe9c689
>>      Hash len:     32
>>    Verifying Hash Integrity ... sha256+ OK
>>    Loading fdt from 0x22165ea4 to 0x28000000
>>    Booting using the fdt blob at 0x28000000
>>    of_flat_tree at 0x28000000 size 0x000054b1
>> Initial value for argc=3
>> Final value for argc=3
>>    Loading Kernel Image ... OK
>> CACHE: Misaligned operation at range [22000000, 22165cc8]
>>    kernel loaded at 0x22000000, end = 0x22165cc8
>> images.os.start = 0x22000000, images.os.end = 0x2216c0f1
>> images.os.load = 0x22000000, load_end = 0x22165cc8
>> ERROR: new format image overwritten - must RESET the board to recover
>> resetting ...
>>
>> This appears to be an addressing issue.  Anyone care to comment?
>>
>> I'll put up how I got to this point after, but I am curious on how all of
>> the addresses are leveraged, is there an order they follow and more?
>>
>>
>>
>> On 27 February 2017 at 15:58, Rick Altherr <raltherr@google.com> wrote:
>>
>>> The projects I'm working on are based on Yocto so I've been using the
>>> u-boot signing support that is built in there.  I believe the magic you are
>>> looking for is in http://git.yoctoproject.org
>>> /cgit/cgit.cgi/poky/tree/meta/classes/uboot-sign.bbclass.
>>> Specifically, when you run 'mkimage -F -k <key-name> -K <control-dtb> -r
>>> <fit>', the public keys will be inserted into the control dtb.  You can
>>> then rebuild u-boot with 'make EXT_DTB=<control-dtb>' which will use the
>>> dtb that includes the keys.
>>>
>>> On Mon, Feb 27, 2017 at 7:34 AM, Ron Brash <ron.brash@gmail.com> wrote:
>>>
>>>> Okay - it seems, after working my way through a bunch of the
>>>> documentation and examples in /doc/uImage.FIT - I noticed a discrepancy
>>>>
>>>> /dts-v1/;
>>>> /{
>>>> description = "Configuration to load a Basic Kernel";
>>>> #address-cells = <1>;
>>>> images {
>>>> linux_kernel at 1 {
>>>> description = "Linux zImage";
>>>> data = /incbin/("zImage");
>>>> type = "kernel";
>>>> arch = "arm";
>>>> os = "linux";
>>>> compression = "none";
>>>> load =  <0x20000000>;
>>>> entry = <0x20008000>;
>>>> kernel-version = <1>;
>>>> hash at 1 {
>>>> algo = "sha256";
>>>> };
>>>> };
>>>> fdt at 1 {
>>>> description = "FDT blob";
>>>> data = /incbin/("myboard.dtn");
>>>> type = "flat_dt";
>>>> arch = "arm";
>>>> compression = "none";
>>>> fdt-version = <1>;
>>>> hash at 1{
>>>> algo = "sha256";
>>>> };
>>>> };
>>>> };
>>>> configurations {
>>>> default = "config at 1";
>>>> config at 1{
>>>> description = "Plain Linux";
>>>> kernel = "linux_kernel at 1";
>>>> fdt = "fdt at 1";
>>>> signature at 1{
>>>> algo = "sha256,rsa2048";
>>>> key-name-hint = "dev_key";
>>>> sign-images = "fdt", "kernel";
>>>> };
>>>> };
>>>> };
>>>> };
>>>>
>>>> Does NOT equal (for brevity - I just used the node)
>>>>
>>>> fdt at 1 {
>>>> description = "FDT blob";
>>>> data = /incbin/("myboard.dtn");
>>>> type = "flat_dt";
>>>> arch = "arm";
>>>> compression = "none";
>>>> fdt-version = <1>;
>>>> hash at 1{
>>>> algo = "sha256";
>>>> };
>>>> signature at 1{
>>>> algo = "sha256,rsa2048";
>>>> key-name-hint = "dev_key";
>>>> };
>>>> };
>>>>
>>>> Apparently, this causes the mkimage tooling in my particular instance
>>>> to explain invalid blob messages.  The large example above indeed does work
>>>> once this nuance was noticed.
>>>>
>>>> Next,  once the final CTRL FDT is created, how does one get it back
>>>> into the actual u-boot binary.  Does/can mkimage insert it into the binary
>>>> image at a particular offset?  What is the command to do so?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 23 February 2017 at 12:27, Rick Altherr <raltherr@google.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Feb 23, 2017 at 7:48 AM, Ron Brash <ron.brash@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hello all (and thanks Mr. Altherr for this insight),
>>>>>>
>>>>>> Excellent feedback and I agree that all of this needs to find a home
>>>>>> either on the global docs on the website and/or the text-only
>>>>>> documentation.  Regardless, this leads me to a few questions.
>>>>>>
>>>>>> NOTE: the use of a uboot control DTS, control DTB and control FTD
>>>>>> even in Mr. Altherr's email is confusion provoking.  One term to rule them
>>>>>> all is needed ;)
>>>>>>
>>>>>
>>>>> Agreed.  Technically a flattened device tree (FDT) can be described in
>>>>> an ASCII form (dts) or binary form (dtb).
>>>>>
>>>>>
>>>>>>
>>>>>> 1.)  What if a board doesn't have OR has ever been configured to use
>>>>>> u-boot DTS (could we call this a UDTS or something friendly to
>>>>>> differentiate that fact?); this was a point of misunderstanding until I
>>>>>> started scampering around into arch/arm/dts/?
>>>>>>
>>>>>> * For example, my board is a derivative of an Atmel at91sam9g20.  It
>>>>>> had a very generic implementation of a DTS that covered reference boards in
>>>>>> the Linux kernel, but required a fair bit of modification to make it work.
>>>>>> As the at91sam(legacy platform) isn't in u-boot's source tree for a DTS -
>>>>>> what would someone like me need to do - do we have a barebones tutorial
>>>>>> (again I don't mind publishing such with proofing)?  Is it even required if
>>>>>> we have a platform/board already working in the traditional u-boot way?
>>>>>>
>>>>>> I believe (but have no verified) that if your board is supported by
>>>>> U-Boot without a control FDT today, you can just create one that contains
>>>>> only the public keys.  I've gathered from the mailing list that using a
>>>>> control FDT and the driver model is how all new boards should be
>>>>> implemented.
>>>>>
>>>>>
>>>>>> 2.)  Just to summarise - everything winds up in two binaries: u-boot
>>>>>> and the FIT image.  So the partition scheme would more or less would look
>>>>>> like:
>>>>>>
>>>>>> /-----------------
>>>>>> * Bootstrap/ROM (optional)
>>>>>> /----------------
>>>>>> * U-boot
>>>>>> *    Control DTB
>>>>>> *         Has keys
>>>>>>
>>>>>
>>>>> Only the public keys.  The private keys are never stored on the target
>>>>> device.
>>>>>
>>>>>
>>>>>> *         Driver loadout/init
>>>>>>
>>>>> The control FDT only describes the hardware (see
>>>>> https://www.devicetree.org/ and http://git.kernel.org/cgit/lin
>>>>> ux/kernel/git/torvalds/linux.git/tree/Documentation/devicetr
>>>>> ee/usage-model.txt).  U-Boot's driver model matches device drivers
>>>>> against nodes in the FDT and starts them.
>>>>>
>>>>>
>>>>>> /----------------
>>>>>> * U-boot env
>>>>>> *----------------
>>>>>> * FIT image
>>>>>>
>>>>> The FIT shouldn't be in the U-Boot env section.  That's used by U-Boot
>>>>> to store its persistent environment.  The FIT is a replacement for the
>>>>> kernel image.  Keep a separate place allocated in the flash for kernel but
>>>>> store the FIT there.
>>>>>
>>>>>
>>>>>> *    ITS
>>>>>>
>>>>> I never really thought of it this way, but yes, that's true.  The ITS
>>>>> is itself written in device tree syntax and gets compiled to binary form.
>>>>>  dtb tends to get used only to describe device trees in binary form that
>>>>> describe hardware.  Maybe we need to introduce ITB to clarify this is the
>>>>> device tree in binary form describing the image.
>>>>>
>>>>>
>>>>>> *    Kernel
>>>>>> *    DTS
>>>>>>
>>>>>
>>>>> Prefer the terms FDT or DTB.  Only the compiled form is stored in the
>>>>> FIT.
>>>>>
>>>>>
>>>>>> *    ....
>>>>>> /---------------
>>>>>> * Rootfs etc...
>>>>>> * ...
>>>>>> /---------------
>>>>>>
>>>>>>
>>>>>> 3.)  What people used to use to load X address into Z location in
>>>>>> memory is now removed by the usage of a DTB in u-boot correct?  I assume
>>>>>> that the u-boot DTB now does this and bootarg/bootcmd is partially done
>>>>>> away with - as its arguments are augmented by said file.
>>>>>>
>>>>>
>>>>> Not quite.  bootarg/bootcmd is still used.  What is different is that
>>>>> booting linux with a FDT with legacy images required multiple arguments to
>>>>> bootm.  In that case, bootarg would be 'bootm <zimage_addr> - <fdt_addr>'.
>>>>> With a FIT, you only provide the address of the FIT itself to bootm so
>>>>> bootarg is set to 'bootm <fit_addr>'.
>>>>>
>>>>>
>>>>>>
>>>>>> Anybody have the spare cycles to organise a
>>>>>> web-tutorial/presentation/recording with me on a play-by-play to
>>>>>> make all of this make sense?  I'm aiming to be in Prague for the 2017
>>>>>> conference in October, might be a good place to showcase this fine-tuning.
>>>>>>
>>>>>>
>>>>> I'm not clear on what you are asking.  I probably have time to review
>>>>> docs and presentations and maybe a few phone or video conference meetings.
>>>>>
>>>>>
>>>>>> Ron
>>>>>>
>>>>>> On 22 February 2017 at 13:51, Rick Altherr <raltherr@google.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> On Tue, Feb 21, 2017 at 10:08 AM, Ron Brash <ron.brash@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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>> Ron Brash
>>>> CTO  & Co-founder of Atlants Embedded Inc.
>>>> www.atlantsembedded.com
>>>> ------------------------------------------------------------------
>>>>
>>>> Cell +1 438 880 6441 <(438)%20880-6441>
>>>> Email  ron.brash at gmail.com
>>>> Blog www.pacificsimplicity.ca
>>>> LinkedIn ca.linkedin.com/in/ronbrash/
>>>>
>>>>
>>>>
>>>> This communication is intended for the use of the recipient to which it
>>>> is
>>>> addressed, and may contain confidential, personal, and or privileged
>>>> information. Please contact the sender immediately if you are not the
>>>> intended recipient of this communication, and do not copy, distribute,
>>>> or
>>>> take action relying on it. Any communication received in error, or
>>>> subsequent reply, should be deleted or destroyed.
>>>>
>>>
>>>
>>
>>
>> --
>>
>>
>> Ron Brash
>> CTO  & Co-founder of Atlants Embedded Inc.
>> www.atlantsembedded.com
>> ------------------------------------------------------------------
>>
>> Cell +1 438 880 6441 <(438)%20880-6441>
>> Email  ron.brash at gmail.com
>> Blog www.pacificsimplicity.ca
>> LinkedIn ca.linkedin.com/in/ronbrash/
>>
>>
>>
>> This communication is intended for the use of the recipient to which it is
>> addressed, and may contain confidential, personal, and or privileged
>> information. Please contact the sender immediately if you are not the
>> intended recipient of this communication, and do not copy, distribute, or
>> take action relying on it. Any communication received in error, or
>> subsequent reply, should be deleted or destroyed.
>>
>
>


-- 


Ron Brash
CTO  & Co-founder of Atlants Embedded Inc.
www.atlantsembedded.com
------------------------------------------------------------------

Cell +1 438 880 6441
Email  ron.brash at gmail.com
Blog www.pacificsimplicity.ca
LinkedIn ca.linkedin.com/in/ronbrash/



This communication is intended for the use of the recipient to which it is
addressed, and may contain confidential, personal, and or privileged
information. Please contact the sender immediately if you are not the
intended recipient of this communication, and do not copy, distribute, or
take action relying on it. Any communication received in error, or
subsequent reply, should be deleted or destroyed.

[U-Boot] Complete verified uboot example

[Rick Altherr]

I've never seen the kernel load address (the start address for copying
the kernel image into RAM) being the same as the entrypoint address
(where U-Boot jumps to begin executing the kernel).  I'd expect the
load address to be 0x23000000.

It looks like you are converting the zImage into a U-Boot legacy image
and then storing the legacy image in the FIT.  Don't do that.  Store
the zImage in the FIT directly.

On Tue, Feb 28, 2017 at 11:09 AM, Ron Brash <ron.brash@gmail.com> wrote:
> Hello,
>
> Still for some reason - there is an issue with booting from the FIT.  With a
> version of Uboot without the FIT related CONFIGs enabled; everything works.
>
> Here is me taking my zImage and converting it to a u-image ( I am not sure
> on the addresses)
>
> mkimage -A arm -O linux -C none -T kernel -a 0x23008000 -e 0x23008000 -n
> linux-4.4.36b \
> -d $(KDIR)/zImage $(BIN_DIR)/$(IMG_PREFIX)-zImage-nDTB2
>
>
> My .its:
>
> /dts-v1/;
> /{
> description = "Configuration to load a Basic Kernel";
> #address-cells = <1>;
> images {
> linux_kernel at 1 {
> description = "Linux zImage";
> data =
> /incbin/("../../../../bin/targets/myboard/legacy/myboard-legacy-zImage-nDTB2");
> type = "kernel";
> arch = "arm";
> os = "linux";
> compression = "none";
> load =  <0x23008000>;
> entry = <0x23008000>;
> kernel-version = <1>;
> hash at 1 {
> algo = "sha256";
> };
> };
> fdt at 1 {
> description = "FDT blob";
> data = /incbin/("../../../../bin/targets/myboard/legacy/myboard.dtb");
> type = "flat_dt";
> arch = "arm";
> compression = "none";
> load =  <0x28000000>;
> fdt-version = <1>;
> hash at 1{
> algo = "sha256";
> };
> };
> };
> configurations {
> default = "config at 1";
> config at 1{
> description = "Plain Linux";
> kernel = "linux_kernel at 1";
> fdt = "fdt at 1";
> signature at 1{
> algo = "sha256,rsa2048";
> key-name-hint = "dev_key";
> sign-images = "fdt", "kernel";
> };
> };
> };
> };
>
>
> Then
>
>
> set -ex
> key_dir="/tmp/keys"
> key_name="dev_key"
>
> rm -rf ${FIT_IMG}
> rm -rf ${key_dir}
> mkdir ${key_dir}
> rootdir="/home/dev/usr"
>
> MKIMG="${rootdir}/lede/staging_dir/host/bin/mkimage"
> DTC="/usr/bin/dtc"
> CPP="/usr/bin/cpp"
> OPENSSL="/usr/bin/openssl"
>
> #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
>
> # Control FDT (u-boot.dts) - hits uboot to have keys etc...
> BD_NAME="at91sam9260-plx35"
> PATH_TO_BIN="${rootdir}/lede/bin/targets/myboard/legacy"
>
> #
> # This is the uboot-nodtb.bin (just renamed)
> #
> UBOOT_NAME="lede-myboard.bin"
> UBOOT_WITH_DTB="${PATH_TO_BIN}/${UBOOT_NAME}"
>
> PATH_TO_CTRL_FDT="${rootdir}/lede/build_dir/target-arm_arm926ej-s_musl-1.1.15_eabi/linux-myboard/myboard-uboot-2016.05/arch/arm/dts/"
>
> CTRL_FDT="${PATH_TO_CTRL_FDT}${BD_NAME}"
>
> FIT_ITS="at91sam9260"
> FIT_IMG="${rootdir}/lede/bin/targets/myboard/legacy/lede-at91-image.fit"
>
> DOPTS="-I dts -O dtb -p 2000"
>
> # Generate fitImage with space for signature:
> echo "create FIT with space - no signing"
> echo " --------------------------------"
> $MKIMG -D "${DOPTS}" \
>  -f "${FIT_ITS}".its "${FIT_IMG}"
>
> echo ""
> echo ""
>
> # Now add them and sign them
> echo "Sign images with our keys"
> echo " --------------------------------"
> $MKIMG -D "${DOPTS}" -F \
> -k "${key_dir}" -K "${CTRL_FDT}".dtb -r "${FIT_IMG}"
>
> echo ""
> echo ""
>
> # Add FDT to image
> cp ${UBOOT_WITH_DTB} ${UBOOT_WITH_DTB}-wDTB
> cat ${PATH_TO_CTRL_FDT}/${BD_NAME}.dtb >> ${UBOOT_WITH_DTB}-wDTB
>
>
> Then I flash the uboot-WDTB to the board and also the FIT image.  Following
> that, then I load the FIT into RAM and execute it with the command:
>
>
> cp.b 0xD0084000 0x22000000 0x186A00;setenv my_bootcount 0; bootm 0x22000000
>
> Initial value for argc=3
> Final value for argc=3
> ## Current stack ends at 0x23f119b8 *  kernel: cmdline image address =
> 0x22000000
> ## Loading kernel from FIT Image at 22000000 ...
> No configuration specified, trying default...
> Found default configuration: 'config at 1'
>    Using 'config at 1' configuration
>    Trying 'linux_kernel at 1' kernel subimage
>      Description:  Linux zImage
>      Type:         Kernel Image
>      Compression:  uncompressed
>      Data Start:   0x220000dc
>      Data Size:    1465544 Bytes = 1.4 MiB
>      Architecture: ARM
>      OS:           Linux
>      Load Address: 0x23008000
>      Entry Point:  0x23008000
>      Hash node:    'hash at 1'
>      Hash algo:    sha256
>      Hash value:
> 52f8048436c3f62d9108957cb4f6f7d4e58c8c9931d68ea6f0121f4c661c7ffe
>      Hash len:     32
>    Verifying Hash Integrity ... sha256+ OK
>    kernel data at 0x220000dc, len = 0x00165cc8 (1465544)
> *  ramdisk: using config 'config at 1' from image at 0x22000000
> *  ramdisk: no 'ramdisk' in config
> *  fdt: using config 'config at 1' from image at 0x22000000
> ## Checking for 'FDT'/'FDT Image' at 22000000
> ## Loading fdt from FIT Image at 22000000 ...
>    Using 'config at 1' configuration
>    Trying 'fdt at 1' fdt subimage
>      Description:  FDT blob
>      Type:         Flat Device Tree
>      Compression:  uncompressed
>      Data Start:   0x22165ea4
>      Data Size:    21681 Bytes = 21.2 KiB
>      Architecture: ARM
>      Hash node:    'hash at 1'
>      Hash algo:    sha256
>      Hash value:
> c7f32d039871d858dda8d397c3b6a685bc914c78cf70f03d1860f61ecfe9c689
>      Hash len:     32
>    Verifying Hash Integrity ... sha256+ OK
>    Loading fdt from 0x22165ea4 to 0x28000000
>    Booting using the fdt blob at 0x28000000
>    of_flat_tree at 0x28000000 size 0x000054b1
> Initial value for argc=3
> Final value for argc=3
>    Loading Kernel Image ... OK
> CACHE: Misaligned operation at range [23008000, 2316dcc8]
>    kernel loaded at 0x23008000, end = 0x2316dcc8
> using: FDT
> ## initrd_high = 0x24000000, copy_to_ram = 1
>    ramdisk load start = 0x00000000, ramdisk load end = 0x00000000
> ## device tree at 28000000 ... 280054b0 (len=33969 [0x84B1])
>    Loading Device Tree to 23f08000, end 23f104b0 ... OK
> Initial value for argc=3
> Final value for argc=3
> ## Transferring control to Linux (at address 23008000)...
>
> Starting kernel ...
>
> undefined instruction
> pc : [<23008028>]          lr : [<23f44ca4>]
> reloc pc : [<20fc3028>]    lr : [<21effca4>]
> sp : 23f11980  ip : 23f9472c     fp : 00000000
> r10: 23f1e61c  r9 : 23f17ef0     r8 : 23f4585c
> r7 : 00000000  r6 : 23008000     r5 : 23f9b0f4  r4 : 00000081
> r3 : 000054b1  r2 : 23f08000     r1 : 00000658  r0 : 23900000
> Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
> Resetting CPU ...
>
> With iminfo:
>
> #> cp.b 0xD0084000 0x22000000 0x186A00
> #> iminfo
>
> ## Checking Image at 22000000 ...
>    FIT image found
>    FIT description: Configuration to load a Basic Kernel
>     Image 0 (linux_kernel at 1)
>      Description:  Linux zImage
>      Type:         Kernel Image
>      Compression:  uncompressed
>      Data Start:   0x220000dc
>      Data Size:    1465544 Bytes = 1.4 MiB
>      Architecture: ARM
>      OS:           Linux
>      Load Address: 0x23008000
>      Entry Point:  0x23008000
>      Hash node:    'hash at 1'
>      Hash algo:    sha256
>      Hash value:
> 52f8048436c3f62d9108957cb4f6f7d4e58c8c9931d68ea6f0121f4c661c7ffe
>      Hash len:     32
>     Image 1 (fdt at 1)
>      Description:  FDT blob
>      Type:         Flat Device Tree
>      Compression:  uncompressed
>      Data Start:   0x22165ea4
>      Data Size:    21681 Bytes = 21.2 KiB
>      Architecture: ARM
>      Hash node:    'hash at 1'
>      Hash algo:    sha256
>      Hash value:
> c7f32d039871d858dda8d397c3b6a685bc914c78cf70f03d1860f61ecfe9c689
>      Hash len:     32
>     Default Configuration: 'config at 1'
>     Configuration 0 (config at 1)
>      Description:  Plain Linux
>      Kernel:       linux_kernel at 1
>      FDT:          fdt at 1
> ## Checking hash(es) for FIT Image at 22000000 ...
>    Hash(es) for Image 0 (linux_kernel at 1): sha256+
>    Hash(es) for Image 1 (fdt at 1): sha256+
>
>
> Any input?  This seems like offsets and not knowing where various components
> need to be looking.
>
>
>
>
>
>
> On 27 February 2017 at 16:53, Rick Altherr <raltherr@google.com> wrote:
>>
>> You set the load address for the linux image to the same location as the
>> FIT.  U-Boot verified the hashes on the FIT and then tried to copy the
>> kernel over top the FIT.  I assume you put the FIT in flash.  Pick a
>> location in RAM for the kernel's load address.
>>
>> On Mon, Feb 27, 2017 at 1:49 PM, Ron Brash <ron.brash@gmail.com> wrote:
>>>
>>> Looks like far more progress:
>>>
>>> #> setenv my_bootcount 0; bootm 0xD0084000
>>> Initial value for argc=3
>>> Final value for argc=3
>>> ## Current stack ends at 0x23f11db8 *  kernel: cmdline image address =
>>> 0xd0084000
>>>    Reading image header from dataflash address d0084000 to RAM address
>>> 22000000
>>>    FIT/FDT format image found at 0x22000000, size 0x0016c0b1
>>>    Reading image remaining data from dataflash address d0084040 to RAM
>>> address 22000040
>>> ## Loading kernel from FIT Image at 22000000 ...
>>> No configuration specified, trying default...
>>> Found default configuration: 'config at 1'
>>>    Using 'config at 1' configuration
>>>    Trying 'linux_kernel at 1' kernel subimage
>>>      Description:  Linux zImage
>>>      Type:         Kernel Image
>>>      Compression:  uncompressed
>>>      Data Start:   0x220000dc
>>>      Data Size:    1465544 Bytes = 1.4 MiB
>>>      Architecture: ARM
>>>      OS:           Linux
>>>      Load Address: 0x22000000
>>>      Entry Point:  0x22008000
>>>      Hash node:    'hash at 1'
>>>      Hash algo:    sha256
>>>      Hash value:
>>> 5dcf9a4328bca6fe5c3405e03b9a58402dce36f3a4f0c757e52091b050d2bcb2
>>>      Hash len:     32
>>>    Verifying Hash Integrity ... sha256+ OK
>>>    kernel data at 0x220000dc, len = 0x00165cc8 (1465544)
>>> *  ramdisk: using config 'config at 1' from image at 0x22000000
>>> *  ramdisk: no 'ramdisk' in config
>>> *  fdt: using config 'config at 1' from image at 0x22000000
>>> ## Checking for 'FDT'/'FDT Image' at 22000000
>>> ## Loading fdt from FIT Image at 22000000 ...
>>>    Using 'config at 1' configuration
>>>    Trying 'fdt at 1' fdt subimage
>>>      Description:  FDT blob
>>>      Type:         Flat Device Tree
>>>      Compression:  uncompressed
>>>      Data Start:   0x22165ea4
>>>      Data Size:    21681 Bytes = 21.2 KiB
>>>      Architecture: ARM
>>>      Hash node:    'hash at 1'
>>>      Hash algo:    sha256
>>>      Hash value:
>>> c7f32d039871d858dda8d397c3b6a685bc914c78cf70f03d1860f61ecfe9c689
>>>      Hash len:     32
>>>    Verifying Hash Integrity ... sha256+ OK
>>>    Loading fdt from 0x22165ea4 to 0x28000000
>>>    Booting using the fdt blob at 0x28000000
>>>    of_flat_tree at 0x28000000 size 0x000054b1
>>> Initial value for argc=3
>>> Final value for argc=3
>>>    Loading Kernel Image ... OK
>>> CACHE: Misaligned operation at range [22000000, 22165cc8]
>>>    kernel loaded at 0x22000000, end = 0x22165cc8
>>> images.os.start = 0x22000000, images.os.end = 0x2216c0f1
>>> images.os.load = 0x22000000, load_end = 0x22165cc8
>>> ERROR: new format image overwritten - must RESET the board to recover
>>> resetting ...
>>>
>>> This appears to be an addressing issue.  Anyone care to comment?
>>>
>>> I'll put up how I got to this point after, but I am curious on how all of
>>> the addresses are leveraged, is there an order they follow and more?
>>>
>>>
>>>
>>> On 27 February 2017 at 15:58, Rick Altherr <raltherr@google.com> wrote:
>>>>
>>>> The projects I'm working on are based on Yocto so I've been using the
>>>> u-boot signing support that is built in there.  I believe the magic you are
>>>> looking for is in
>>>> http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/uboot-sign.bbclass.
>>>> Specifically, when you run 'mkimage -F -k <key-name> -K <control-dtb> -r
>>>> <fit>', the public keys will be inserted into the control dtb.  You can then
>>>> rebuild u-boot with 'make EXT_DTB=<control-dtb>' which will use the dtb that
>>>> includes the keys.
>>>>
>>>> On Mon, Feb 27, 2017 at 7:34 AM, Ron Brash <ron.brash@gmail.com> wrote:
>>>>>
>>>>> Okay - it seems, after working my way through a bunch of the
>>>>> documentation and examples in /doc/uImage.FIT - I noticed a discrepancy
>>>>>
>>>>> /dts-v1/;
>>>>> /{
>>>>> description = "Configuration to load a Basic Kernel";
>>>>> #address-cells = <1>;
>>>>> images {
>>>>> linux_kernel at 1 {
>>>>> description = "Linux zImage";
>>>>> data = /incbin/("zImage");
>>>>> type = "kernel";
>>>>> arch = "arm";
>>>>> os = "linux";
>>>>> compression = "none";
>>>>> load =  <0x20000000>;
>>>>> entry = <0x20008000>;
>>>>> kernel-version = <1>;
>>>>> hash at 1 {
>>>>> algo = "sha256";
>>>>> };
>>>>> };
>>>>> fdt at 1 {
>>>>> description = "FDT blob";
>>>>> data = /incbin/("myboard.dtn");
>>>>> type = "flat_dt";
>>>>> arch = "arm";
>>>>> compression = "none";
>>>>> fdt-version = <1>;
>>>>> hash at 1{
>>>>> algo = "sha256";
>>>>> };
>>>>> };
>>>>> };
>>>>> configurations {
>>>>> default = "config at 1";
>>>>> config at 1{
>>>>> description = "Plain Linux";
>>>>> kernel = "linux_kernel at 1";
>>>>> fdt = "fdt at 1";
>>>>> signature at 1{
>>>>> algo = "sha256,rsa2048";
>>>>> key-name-hint = "dev_key";
>>>>> sign-images = "fdt", "kernel";
>>>>> };
>>>>> };
>>>>> };
>>>>> };
>>>>>
>>>>> Does NOT equal (for brevity - I just used the node)
>>>>>
>>>>> fdt at 1 {
>>>>> description = "FDT blob";
>>>>> data = /incbin/("myboard.dtn");
>>>>> type = "flat_dt";
>>>>> arch = "arm";
>>>>> compression = "none";
>>>>> fdt-version = <1>;
>>>>> hash at 1{
>>>>> algo = "sha256";
>>>>> };
>>>>> signature at 1{
>>>>> algo = "sha256,rsa2048";
>>>>> key-name-hint = "dev_key";
>>>>> };
>>>>> };
>>>>>
>>>>> Apparently, this causes the mkimage tooling in my particular instance
>>>>> to explain invalid blob messages.  The large example above indeed does work
>>>>> once this nuance was noticed.
>>>>>
>>>>> Next,  once the final CTRL FDT is created, how does one get it back
>>>>> into the actual u-boot binary.  Does/can mkimage insert it into the binary
>>>>> image at a particular offset?  What is the command to do so?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 23 February 2017 at 12:27, Rick Altherr <raltherr@google.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Feb 23, 2017 at 7:48 AM, Ron Brash <ron.brash@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hello all (and thanks Mr. Altherr for this insight),
>>>>>>>
>>>>>>> Excellent feedback and I agree that all of this needs to find a home
>>>>>>> either on the global docs on the website and/or the text-only documentation.
>>>>>>> Regardless, this leads me to a few questions.
>>>>>>>
>>>>>>> NOTE: the use of a uboot control DTS, control DTB and control FTD
>>>>>>> even in Mr. Altherr's email is confusion provoking.  One term to rule them
>>>>>>> all is needed ;)
>>>>>>
>>>>>>
>>>>>> Agreed.  Technically a flattened device tree (FDT) can be described in
>>>>>> an ASCII form (dts) or binary form (dtb).
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 1.)  What if a board doesn't have OR has ever been configured to use
>>>>>>> u-boot DTS (could we call this a UDTS or something friendly to differentiate
>>>>>>> that fact?); this was a point of misunderstanding until I started scampering
>>>>>>> around into arch/arm/dts/?
>>>>>>>
>>>>>>> * For example, my board is a derivative of an Atmel at91sam9g20.  It
>>>>>>> had a very generic implementation of a DTS that covered reference boards in
>>>>>>> the Linux kernel, but required a fair bit of modification to make it work.
>>>>>>> As the at91sam(legacy platform) isn't in u-boot's source tree for a DTS -
>>>>>>> what would someone like me need to do - do we have a barebones tutorial
>>>>>>> (again I don't mind publishing such with proofing)?  Is it even required if
>>>>>>> we have a platform/board already working in the traditional u-boot way?
>>>>>>>
>>>>>> I believe (but have no verified) that if your board is supported by
>>>>>> U-Boot without a control FDT today, you can just create one that contains
>>>>>> only the public keys.  I've gathered from the mailing list that using a
>>>>>> control FDT and the driver model is how all new boards should be
>>>>>> implemented.
>>>>>>
>>>>>>>
>>>>>>> 2.)  Just to summarise - everything winds up in two binaries: u-boot
>>>>>>> and the FIT image.  So the partition scheme would more or less would look
>>>>>>> like:
>>>>>>>
>>>>>>> /-----------------
>>>>>>> * Bootstrap/ROM (optional)
>>>>>>> /----------------
>>>>>>> * U-boot
>>>>>>> *    Control DTB
>>>>>>> *         Has keys
>>>>>>
>>>>>>
>>>>>> Only the public keys.  The private keys are never stored on the target
>>>>>> device.
>>>>>>
>>>>>>>
>>>>>>> *         Driver loadout/init
>>>>>>
>>>>>> The control FDT only describes the hardware (see
>>>>>> https://www.devicetree.org/ and
>>>>>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/usage-model.txt).
>>>>>> U-Boot's driver model matches device drivers against nodes in the FDT and
>>>>>> starts them.
>>>>>>
>>>>>>>
>>>>>>> /----------------
>>>>>>> * U-boot env
>>>>>>> *----------------
>>>>>>> * FIT image
>>>>>>
>>>>>> The FIT shouldn't be in the U-Boot env section.  That's used by U-Boot
>>>>>> to store its persistent environment.  The FIT is a replacement for the
>>>>>> kernel image.  Keep a separate place allocated in the flash for kernel but
>>>>>> store the FIT there.
>>>>>>
>>>>>>>
>>>>>>> *    ITS
>>>>>>
>>>>>> I never really thought of it this way, but yes, that's true.  The ITS
>>>>>> is itself written in device tree syntax and gets compiled to binary form.
>>>>>> dtb tends to get used only to describe device trees in binary form that
>>>>>> describe hardware.  Maybe we need to introduce ITB to clarify this is the
>>>>>> device tree in binary form describing the image.
>>>>>>
>>>>>>>
>>>>>>> *    Kernel
>>>>>>> *    DTS
>>>>>>
>>>>>>
>>>>>> Prefer the terms FDT or DTB.  Only the compiled form is stored in the
>>>>>> FIT.
>>>>>>
>>>>>>>
>>>>>>> *    ....
>>>>>>> /---------------
>>>>>>> * Rootfs etc...
>>>>>>> * ...
>>>>>>> /---------------
>>>>>>>
>>>>>>>
>>>>>>> 3.)  What people used to use to load X address into Z location in
>>>>>>> memory is now removed by the usage of a DTB in u-boot correct?  I assume
>>>>>>> that the u-boot DTB now does this and bootarg/bootcmd is partially done away
>>>>>>> with - as its arguments are augmented by said file.
>>>>>>
>>>>>>
>>>>>> Not quite.  bootarg/bootcmd is still used.  What is different is that
>>>>>> booting linux with a FDT with legacy images required multiple arguments to
>>>>>> bootm.  In that case, bootarg would be 'bootm <zimage_addr> - <fdt_addr>'.
>>>>>> With a FIT, you only provide the address of the FIT itself to bootm so
>>>>>> bootarg is set to 'bootm <fit_addr>'.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Anybody have the spare cycles to organise a
>>>>>>> web-tutorial/presentation/recording with me on a play-by-play to make all of
>>>>>>> this make sense?  I'm aiming to be in Prague for the 2017 conference in
>>>>>>> October, might be a good place to showcase this fine-tuning.
>>>>>>>
>>>>>>
>>>>>> I'm not clear on what you are asking.  I probably have time to review
>>>>>> docs and presentations and maybe a few phone or video conference meetings.
>>>>>>
>>>>>>>
>>>>>>> Ron
>>>>>>>
>>>>>>> On 22 February 2017 at 13:51, Rick Altherr <raltherr@google.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Feb 21, 2017 at 10:08 AM, Ron Brash <ron.brash@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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>>
>>>>> Ron Brash
>>>>> CTO  & Co-founder of Atlants Embedded Inc.
>>>>> www.atlantsembedded.com
>>>>> ------------------------------------------------------------------
>>>>>
>>>>> Cell +1 438 880 6441
>>>>> Email  ron.brash at gmail.com
>>>>> Blog www.pacificsimplicity.ca
>>>>> LinkedIn ca.linkedin.com/in/ronbrash/
>>>>>
>>>>>
>>>>>
>>>>> This communication is intended for the use of the recipient to which it
>>>>> is
>>>>> addressed, and may contain confidential, personal, and or privileged
>>>>> information. Please contact the sender immediately if you are not the
>>>>> intended recipient of this communication, and do not copy, distribute,
>>>>> or
>>>>> take action relying on it. Any communication received in error, or
>>>>> subsequent reply, should be deleted or destroyed.
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>>
>>>
>>> Ron Brash
>>> CTO  & Co-founder of Atlants Embedded Inc.
>>> www.atlantsembedded.com
>>> ------------------------------------------------------------------
>>>
>>> Cell +1 438 880 6441
>>> Email  ron.brash at gmail.com
>>> Blog www.pacificsimplicity.ca
>>> LinkedIn ca.linkedin.com/in/ronbrash/
>>>
>>>
>>>
>>> This communication is intended for the use of the recipient to which it
>>> is
>>> addressed, and may contain confidential, personal, and or privileged
>>> information. Please contact the sender immediately if you are not the
>>> intended recipient of this communication, and do not copy, distribute, or
>>> take action relying on it. Any communication received in error, or
>>> subsequent reply, should be deleted or destroyed.
>>
>>
>
>
>
> --
>
>
> Ron Brash
> CTO  & Co-founder of Atlants Embedded Inc.
> www.atlantsembedded.com
> ------------------------------------------------------------------
>
> Cell +1 438 880 6441
> Email  ron.brash at gmail.com
> Blog www.pacificsimplicity.ca
> LinkedIn ca.linkedin.com/in/ronbrash/
>
>
>
> This communication is intended for the use of the recipient to which it is
> addressed, and may contain confidential, personal, and or privileged
> information. Please contact the sender immediately if you are not the
> intended recipient of this communication, and do not copy, distribute, or
> take action relying on it. Any communication received in error, or
> subsequent reply, should be deleted or destroyed.

[U-Boot] Complete verified uboot example

[Ron Brash]

Hello,

Here is a list of things I have tried:  The raw zImage (which is compressed
with XZ), various addresses from indeed load address 0x23000000, entry
at 0x23008000
(and the same), I've tried setting the FTD address since it sets itself
neatly at 0x22f and change, which will probably get itself clobbered.

I've tried playing with the "magic" variables of ftdaddr, loadaddr, and
verify.  No luck other than a few loops, hangs and
illegitimate instructions being executed.

Something is missing from my system, documentation or more and it appears
to be uboot and/or the fit format + FDT/DTBs.

Is there a magic formula?  Before FIT I could just copy my kernel to
0x22... and my DTB to another address that wouldn't be clobbered, use bootm
and everything would work given I set it to a uImage.

Question, does the FDT need a load address specified as well?  Why does the
documentation use all 0's?  Usually, all zeros is either an example, or
will be inherit some address from a variable? (perhaps this is not
obviously documented).




On 28 February 2017 at 16:51, Rick Altherr <raltherr@google.com> wrote:

> I've never seen the kernel load address (the start address for copying
> the kernel image into RAM) being the same as the entrypoint address
> (where U-Boot jumps to begin executing the kernel).  I'd expect the
> load address to be 0x23000000.
>
> It looks like you are converting the zImage into a U-Boot legacy image
> and then storing the legacy image in the FIT.  Don't do that.  Store
> the zImage in the FIT directly.
>
> On Tue, Feb 28, 2017 at 11:09 AM, Ron Brash <ron.brash@gmail.com> wrote:
> > Hello,
> >
> > Still for some reason - there is an issue with booting from the FIT.
> With a
> > version of Uboot without the FIT related CONFIGs enabled; everything
> works.
> >
> > Here is me taking my zImage and converting it to a u-image ( I am not
> sure
> > on the addresses)
> >
> > mkimage -A arm -O linux -C none -T kernel -a 0x23008000 -e 0x23008000 -n
> > linux-4.4.36b \
> > -d $(KDIR)/zImage $(BIN_DIR)/$(IMG_PREFIX)-zImage-nDTB2
> >
> >
> > My .its:
> >
> > /dts-v1/;
> > /{
> > description = "Configuration to load a Basic Kernel";
> > #address-cells = <1>;
> > images {
> > linux_kernel at 1 {
> > description = "Linux zImage";
> > data =
> > /incbin/("../../../../bin/targets/myboard/legacy/
> myboard-legacy-zImage-nDTB2");
> > type = "kernel";
> > arch = "arm";
> > os = "linux";
> > compression = "none";
> > load =  <0x23008000>;
> > entry = <0x23008000>;
> > kernel-version = <1>;
> > hash at 1 {
> > algo = "sha256";
> > };
> > };
> > fdt at 1 {
> > description = "FDT blob";
> > data = /incbin/("../../../../bin/targets/myboard/legacy/myboard.dtb");
> > type = "flat_dt";
> > arch = "arm";
> > compression = "none";
> > load =  <0x28000000>;
> > fdt-version = <1>;
> > hash at 1{
> > algo = "sha256";
> > };
> > };
> > };
> > configurations {
> > default = "config at 1";
> > config at 1{
> > description = "Plain Linux";
> > kernel = "linux_kernel at 1";
> > fdt = "fdt at 1";
> > signature at 1{
> > algo = "sha256,rsa2048";
> > key-name-hint = "dev_key";
> > sign-images = "fdt", "kernel";
> > };
> > };
> > };
> > };
> >
> >
> > Then
> >
> >
> > set -ex
> > key_dir="/tmp/keys"
> > key_name="dev_key"
> >
> > rm -rf ${FIT_IMG}
> > rm -rf ${key_dir}
> > mkdir ${key_dir}
> > rootdir="/home/dev/usr"
> >
> > MKIMG="${rootdir}/lede/staging_dir/host/bin/mkimage"
> > DTC="/usr/bin/dtc"
> > CPP="/usr/bin/cpp"
> > OPENSSL="/usr/bin/openssl"
> >
> > #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
> >
> > # Control FDT (u-boot.dts) - hits uboot to have keys etc...
> > BD_NAME="at91sam9260-plx35"
> > PATH_TO_BIN="${rootdir}/lede/bin/targets/myboard/legacy"
> >
> > #
> > # This is the uboot-nodtb.bin (just renamed)
> > #
> > UBOOT_NAME="lede-myboard.bin"
> > UBOOT_WITH_DTB="${PATH_TO_BIN}/${UBOOT_NAME}"
> >
> > PATH_TO_CTRL_FDT="${rootdir}/lede/build_dir/target-arm_
> arm926ej-s_musl-1.1.15_eabi/linux-myboard/myboard-uboot-
> 2016.05/arch/arm/dts/"
> >
> > CTRL_FDT="${PATH_TO_CTRL_FDT}${BD_NAME}"
> >
> > FIT_ITS="at91sam9260"
> > FIT_IMG="${rootdir}/lede/bin/targets/myboard/legacy/lede-at91-image.fit"
> >
> > DOPTS="-I dts -O dtb -p 2000"
> >
> > # Generate fitImage with space for signature:
> > echo "create FIT with space - no signing"
> > echo " --------------------------------"
> > $MKIMG -D "${DOPTS}" \
> >  -f "${FIT_ITS}".its "${FIT_IMG}"
> >
> > echo ""
> > echo ""
> >
> > # Now add them and sign them
> > echo "Sign images with our keys"
> > echo " --------------------------------"
> > $MKIMG -D "${DOPTS}" -F \
> > -k "${key_dir}" -K "${CTRL_FDT}".dtb -r "${FIT_IMG}"
> >
> > echo ""
> > echo ""
> >
> > # Add FDT to image
> > cp ${UBOOT_WITH_DTB} ${UBOOT_WITH_DTB}-wDTB
> > cat ${PATH_TO_CTRL_FDT}/${BD_NAME}.dtb >> ${UBOOT_WITH_DTB}-wDTB
> >
> >
> > Then I flash the uboot-WDTB to the board and also the FIT image.
> Following
> > that, then I load the FIT into RAM and execute it with the command:
> >
> >
> > cp.b 0xD0084000 0x22000000 0x186A00;setenv my_bootcount 0; bootm
> 0x22000000
> >
> > Initial value for argc=3
> > Final value for argc=3
> > ## Current stack ends at 0x23f119b8 *  kernel: cmdline image address =
> > 0x22000000
> > ## Loading kernel from FIT Image at 22000000 ...
> > No configuration specified, trying default...
> > Found default configuration: 'config at 1'
> >    Using 'config at 1' configuration
> >    Trying 'linux_kernel at 1' kernel subimage
> >      Description:  Linux zImage
> >      Type:         Kernel Image
> >      Compression:  uncompressed
> >      Data Start:   0x220000dc
> >      Data Size:    1465544 Bytes = 1.4 MiB
> >      Architecture: ARM
> >      OS:           Linux
> >      Load Address: 0x23008000
> >      Entry Point:  0x23008000
> >      Hash node:    'hash at 1'
> >      Hash algo:    sha256
> >      Hash value:
> > 52f8048436c3f62d9108957cb4f6f7d4e58c8c9931d68ea6f0121f4c661c7ffe
> >      Hash len:     32
> >    Verifying Hash Integrity ... sha256+ OK
> >    kernel data at 0x220000dc, len = 0x00165cc8 (1465544)
> > *  ramdisk: using config 'config at 1' from image at 0x22000000
> > *  ramdisk: no 'ramdisk' in config
> > *  fdt: using config 'config at 1' from image at 0x22000000
> > ## Checking for 'FDT'/'FDT Image' at 22000000
> > ## Loading fdt from FIT Image at 22000000 ...
> >    Using 'config at 1' configuration
> >    Trying 'fdt at 1' fdt subimage
> >      Description:  FDT blob
> >      Type:         Flat Device Tree
> >      Compression:  uncompressed
> >      Data Start:   0x22165ea4
> >      Data Size:    21681 Bytes = 21.2 KiB
> >      Architecture: ARM
> >      Hash node:    'hash at 1'
> >      Hash algo:    sha256
> >      Hash value:
> > c7f32d039871d858dda8d397c3b6a685bc914c78cf70f03d1860f61ecfe9c689
> >      Hash len:     32
> >    Verifying Hash Integrity ... sha256+ OK
> >    Loading fdt from 0x22165ea4 to 0x28000000
> >    Booting using the fdt blob at 0x28000000
> >    of_flat_tree at 0x28000000 size 0x000054b1
> > Initial value for argc=3
> > Final value for argc=3
> >    Loading Kernel Image ... OK
> > CACHE: Misaligned operation at range [23008000, 2316dcc8]
> >    kernel loaded at 0x23008000, end = 0x2316dcc8
> > using: FDT
> > ## initrd_high = 0x24000000, copy_to_ram = 1
> >    ramdisk load start = 0x00000000, ramdisk load end = 0x00000000
> > ## device tree at 28000000 ... 280054b0 (len=33969 [0x84B1])
> >    Loading Device Tree to 23f08000, end 23f104b0 ... OK
> > Initial value for argc=3
> > Final value for argc=3
> > ## Transferring control to Linux (at address 23008000)...
> >
> > Starting kernel ...
> >
> > undefined instruction
> > pc : [<23008028>]          lr : [<23f44ca4>]
> > reloc pc : [<20fc3028>]    lr : [<21effca4>]
> > sp : 23f11980  ip : 23f9472c     fp : 00000000
> > r10: 23f1e61c  r9 : 23f17ef0     r8 : 23f4585c
> > r7 : 00000000  r6 : 23008000     r5 : 23f9b0f4  r4 : 00000081
> > r3 : 000054b1  r2 : 23f08000     r1 : 00000658  r0 : 23900000
> > Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
> > Resetting CPU ...
> >
> > With iminfo:
> >
> > #> cp.b 0xD0084000 0x22000000 0x186A00
> > #> iminfo
> >
> > ## Checking Image at 22000000 ...
> >    FIT image found
> >    FIT description: Configuration to load a Basic Kernel
> >     Image 0 (linux_kernel at 1)
> >      Description:  Linux zImage
> >      Type:         Kernel Image
> >      Compression:  uncompressed
> >      Data Start:   0x220000dc
> >      Data Size:    1465544 Bytes = 1.4 MiB
> >      Architecture: ARM
> >      OS:           Linux
> >      Load Address: 0x23008000
> >      Entry Point:  0x23008000
> >      Hash node:    'hash at 1'
> >      Hash algo:    sha256
> >      Hash value:
> > 52f8048436c3f62d9108957cb4f6f7d4e58c8c9931d68ea6f0121f4c661c7ffe
> >      Hash len:     32
> >     Image 1 (fdt at 1)
> >      Description:  FDT blob
> >      Type:         Flat Device Tree
> >      Compression:  uncompressed
> >      Data Start:   0x22165ea4
> >      Data Size:    21681 Bytes = 21.2 KiB
> >      Architecture: ARM
> >      Hash node:    'hash at 1'
> >      Hash algo:    sha256
> >      Hash value:
> > c7f32d039871d858dda8d397c3b6a685bc914c78cf70f03d1860f61ecfe9c689
> >      Hash len:     32
> >     Default Configuration: 'config at 1'
> >     Configuration 0 (config at 1)
> >      Description:  Plain Linux
> >      Kernel:       linux_kernel at 1
> >      FDT:          fdt at 1
> > ## Checking hash(es) for FIT Image at 22000000 ...
> >    Hash(es) for Image 0 (linux_kernel at 1): sha256+
> >    Hash(es) for Image 1 (fdt at 1): sha256+
> >
> >
> > Any input?  This seems like offsets and not knowing where various
> components
> > need to be looking.
> >
> >
> >
> >
> >
> >
> > On 27 February 2017 at 16:53, Rick Altherr <raltherr@google.com> wrote:
> >>
> >> You set the load address for the linux image to the same location as the
> >> FIT.  U-Boot verified the hashes on the FIT and then tried to copy the
> >> kernel over top the FIT.  I assume you put the FIT in flash.  Pick a
> >> location in RAM for the kernel's load address.
> >>
> >> On Mon, Feb 27, 2017 at 1:49 PM, Ron Brash <ron.brash@gmail.com> wrote:
> >>>
> >>> Looks like far more progress:
> >>>
> >>> #> setenv my_bootcount 0; bootm 0xD0084000
> >>> Initial value for argc=3
> >>> Final value for argc=3
> >>> ## Current stack ends at 0x23f11db8 *  kernel: cmdline image address =
> >>> 0xd0084000
> >>>    Reading image header from dataflash address d0084000 to RAM address
> >>> 22000000
> >>>    FIT/FDT format image found at 0x22000000, size 0x0016c0b1
> >>>    Reading image remaining data from dataflash address d0084040 to RAM
> >>> address 22000040
> >>> ## Loading kernel from FIT Image at 22000000 ...
> >>> No configuration specified, trying default...
> >>> Found default configuration: 'config at 1'
> >>>    Using 'config at 1' configuration
> >>>    Trying 'linux_kernel at 1' kernel subimage
> >>>      Description:  Linux zImage
> >>>      Type:         Kernel Image
> >>>      Compression:  uncompressed
> >>>      Data Start:   0x220000dc
> >>>      Data Size:    1465544 Bytes = 1.4 MiB
> >>>      Architecture: ARM
> >>>      OS:           Linux
> >>>      Load Address: 0x22000000
> >>>      Entry Point:  0x22008000
> >>>      Hash node:    'hash at 1'
> >>>      Hash algo:    sha256
> >>>      Hash value:
> >>> 5dcf9a4328bca6fe5c3405e03b9a58402dce36f3a4f0c757e52091b050d2bcb2
> >>>      Hash len:     32
> >>>    Verifying Hash Integrity ... sha256+ OK
> >>>    kernel data at 0x220000dc, len = 0x00165cc8 (1465544)
> >>> *  ramdisk: using config 'config at 1' from image at 0x22000000
> >>> *  ramdisk: no 'ramdisk' in config
> >>> *  fdt: using config 'config at 1' from image at 0x22000000
> >>> ## Checking for 'FDT'/'FDT Image' at 22000000
> >>> ## Loading fdt from FIT Image at 22000000 ...
> >>>    Using 'config at 1' configuration
> >>>    Trying 'fdt at 1' fdt subimage
> >>>      Description:  FDT blob
> >>>      Type:         Flat Device Tree
> >>>      Compression:  uncompressed
> >>>      Data Start:   0x22165ea4
> >>>      Data Size:    21681 Bytes = 21.2 KiB
> >>>      Architecture: ARM
> >>>      Hash node:    'hash at 1'
> >>>      Hash algo:    sha256
> >>>      Hash value:
> >>> c7f32d039871d858dda8d397c3b6a685bc914c78cf70f03d1860f61ecfe9c689
> >>>      Hash len:     32
> >>>    Verifying Hash Integrity ... sha256+ OK
> >>>    Loading fdt from 0x22165ea4 to 0x28000000
> >>>    Booting using the fdt blob at 0x28000000
> >>>    of_flat_tree at 0x28000000 size 0x000054b1
> >>> Initial value for argc=3
> >>> Final value for argc=3
> >>>    Loading Kernel Image ... OK
> >>> CACHE: Misaligned operation at range [22000000, 22165cc8]
> >>>    kernel loaded at 0x22000000, end = 0x22165cc8
> >>> images.os.start = 0x22000000, images.os.end = 0x2216c0f1
> >>> images.os.load = 0x22000000, load_end = 0x22165cc8
> >>> ERROR: new format image overwritten - must RESET the board to recover
> >>> resetting ...
> >>>
> >>> This appears to be an addressing issue.  Anyone care to comment?
> >>>
> >>> I'll put up how I got to this point after, but I am curious on how all
> of
> >>> the addresses are leveraged, is there an order they follow and more?
> >>>
> >>>
> >>>
> >>> On 27 February 2017 at 15:58, Rick Altherr <raltherr@google.com>
> wrote:
> >>>>
> >>>> The projects I'm working on are based on Yocto so I've been using the
> >>>> u-boot signing support that is built in there.  I believe the magic
> you are
> >>>> looking for is in
> >>>> http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/
> classes/uboot-sign.bbclass.
> >>>> Specifically, when you run 'mkimage -F -k <key-name> -K <control-dtb>
> -r
> >>>> <fit>', the public keys will be inserted into the control dtb.  You
> can then
> >>>> rebuild u-boot with 'make EXT_DTB=<control-dtb>' which will use the
> dtb that
> >>>> includes the keys.
> >>>>
> >>>> On Mon, Feb 27, 2017 at 7:34 AM, Ron Brash <ron.brash@gmail.com>
> wrote:
> >>>>>
> >>>>> Okay - it seems, after working my way through a bunch of the
> >>>>> documentation and examples in /doc/uImage.FIT - I noticed a
> discrepancy
> >>>>>
> >>>>> /dts-v1/;
> >>>>> /{
> >>>>> description = "Configuration to load a Basic Kernel";
> >>>>> #address-cells = <1>;
> >>>>> images {
> >>>>> linux_kernel at 1 {
> >>>>> description = "Linux zImage";
> >>>>> data = /incbin/("zImage");
> >>>>> type = "kernel";
> >>>>> arch = "arm";
> >>>>> os = "linux";
> >>>>> compression = "none";
> >>>>> load =  <0x20000000>;
> >>>>> entry = <0x20008000>;
> >>>>> kernel-version = <1>;
> >>>>> hash at 1 {
> >>>>> algo = "sha256";
> >>>>> };
> >>>>> };
> >>>>> fdt at 1 {
> >>>>> description = "FDT blob";
> >>>>> data = /incbin/("myboard.dtn");
> >>>>> type = "flat_dt";
> >>>>> arch = "arm";
> >>>>> compression = "none";
> >>>>> fdt-version = <1>;
> >>>>> hash at 1{
> >>>>> algo = "sha256";
> >>>>> };
> >>>>> };
> >>>>> };
> >>>>> configurations {
> >>>>> default = "config at 1";
> >>>>> config at 1{
> >>>>> description = "Plain Linux";
> >>>>> kernel = "linux_kernel at 1";
> >>>>> fdt = "fdt at 1";
> >>>>> signature at 1{
> >>>>> algo = "sha256,rsa2048";
> >>>>> key-name-hint = "dev_key";
> >>>>> sign-images = "fdt", "kernel";
> >>>>> };
> >>>>> };
> >>>>> };
> >>>>> };
> >>>>>
> >>>>> Does NOT equal (for brevity - I just used the node)
> >>>>>
> >>>>> fdt at 1 {
> >>>>> description = "FDT blob";
> >>>>> data = /incbin/("myboard.dtn");
> >>>>> type = "flat_dt";
> >>>>> arch = "arm";
> >>>>> compression = "none";
> >>>>> fdt-version = <1>;
> >>>>> hash at 1{
> >>>>> algo = "sha256";
> >>>>> };
> >>>>> signature at 1{
> >>>>> algo = "sha256,rsa2048";
> >>>>> key-name-hint = "dev_key";
> >>>>> };
> >>>>> };
> >>>>>
> >>>>> Apparently, this causes the mkimage tooling in my particular instance
> >>>>> to explain invalid blob messages.  The large example above indeed
> does work
> >>>>> once this nuance was noticed.
> >>>>>
> >>>>> Next,  once the final CTRL FDT is created, how does one get it back
> >>>>> into the actual u-boot binary.  Does/can mkimage insert it into the
> binary
> >>>>> image at a particular offset?  What is the command to do so?
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 23 February 2017 at 12:27, Rick Altherr <raltherr@google.com>
> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Feb 23, 2017 at 7:48 AM, Ron Brash <ron.brash@gmail.com>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Hello all (and thanks Mr. Altherr for this insight),
> >>>>>>>
> >>>>>>> Excellent feedback and I agree that all of this needs to find a
> home
> >>>>>>> either on the global docs on the website and/or the text-only
> documentation.
> >>>>>>> Regardless, this leads me to a few questions.
> >>>>>>>
> >>>>>>> NOTE: the use of a uboot control DTS, control DTB and control FTD
> >>>>>>> even in Mr. Altherr's email is confusion provoking.  One term to
> rule them
> >>>>>>> all is needed ;)
> >>>>>>
> >>>>>>
> >>>>>> Agreed.  Technically a flattened device tree (FDT) can be described
> in
> >>>>>> an ASCII form (dts) or binary form (dtb).
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> 1.)  What if a board doesn't have OR has ever been configured to
> use
> >>>>>>> u-boot DTS (could we call this a UDTS or something friendly to
> differentiate
> >>>>>>> that fact?); this was a point of misunderstanding until I started
> scampering
> >>>>>>> around into arch/arm/dts/?
> >>>>>>>
> >>>>>>> * For example, my board is a derivative of an Atmel at91sam9g20.
> It
> >>>>>>> had a very generic implementation of a DTS that covered reference
> boards in
> >>>>>>> the Linux kernel, but required a fair bit of modification to make
> it work.
> >>>>>>> As the at91sam(legacy platform) isn't in u-boot's source tree for
> a DTS -
> >>>>>>> what would someone like me need to do - do we have a barebones
> tutorial
> >>>>>>> (again I don't mind publishing such with proofing)?  Is it even
> required if
> >>>>>>> we have a platform/board already working in the traditional u-boot
> way?
> >>>>>>>
> >>>>>> I believe (but have no verified) that if your board is supported by
> >>>>>> U-Boot without a control FDT today, you can just create one that
> contains
> >>>>>> only the public keys.  I've gathered from the mailing list that
> using a
> >>>>>> control FDT and the driver model is how all new boards should be
> >>>>>> implemented.
> >>>>>>
> >>>>>>>
> >>>>>>> 2.)  Just to summarise - everything winds up in two binaries:
> u-boot
> >>>>>>> and the FIT image.  So the partition scheme would more or less
> would look
> >>>>>>> like:
> >>>>>>>
> >>>>>>> /-----------------
> >>>>>>> * Bootstrap/ROM (optional)
> >>>>>>> /----------------
> >>>>>>> * U-boot
> >>>>>>> *    Control DTB
> >>>>>>> *         Has keys
> >>>>>>
> >>>>>>
> >>>>>> Only the public keys.  The private keys are never stored on the
> target
> >>>>>> device.
> >>>>>>
> >>>>>>>
> >>>>>>> *         Driver loadout/init
> >>>>>>
> >>>>>> The control FDT only describes the hardware (see
> >>>>>> https://www.devicetree.org/ and
> >>>>>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/
> linux.git/tree/Documentation/devicetree/usage-model.txt).
> >>>>>> U-Boot's driver model matches device drivers against nodes in the
> FDT and
> >>>>>> starts them.
> >>>>>>
> >>>>>>>
> >>>>>>> /----------------
> >>>>>>> * U-boot env
> >>>>>>> *----------------
> >>>>>>> * FIT image
> >>>>>>
> >>>>>> The FIT shouldn't be in the U-Boot env section.  That's used by
> U-Boot
> >>>>>> to store its persistent environment.  The FIT is a replacement for
> the
> >>>>>> kernel image.  Keep a separate place allocated in the flash for
> kernel but
> >>>>>> store the FIT there.
> >>>>>>
> >>>>>>>
> >>>>>>> *    ITS
> >>>>>>
> >>>>>> I never really thought of it this way, but yes, that's true.  The
> ITS
> >>>>>> is itself written in device tree syntax and gets compiled to binary
> form.
> >>>>>> dtb tends to get used only to describe device trees in binary form
> that
> >>>>>> describe hardware.  Maybe we need to introduce ITB to clarify this
> is the
> >>>>>> device tree in binary form describing the image.
> >>>>>>
> >>>>>>>
> >>>>>>> *    Kernel
> >>>>>>> *    DTS
> >>>>>>
> >>>>>>
> >>>>>> Prefer the terms FDT or DTB.  Only the compiled form is stored in
> the
> >>>>>> FIT.
> >>>>>>
> >>>>>>>
> >>>>>>> *    ....
> >>>>>>> /---------------
> >>>>>>> * Rootfs etc...
> >>>>>>> * ...
> >>>>>>> /---------------
> >>>>>>>
> >>>>>>>
> >>>>>>> 3.)  What people used to use to load X address into Z location in
> >>>>>>> memory is now removed by the usage of a DTB in u-boot correct?  I
> assume
> >>>>>>> that the u-boot DTB now does this and bootarg/bootcmd is partially
> done away
> >>>>>>> with - as its arguments are augmented by said file.
> >>>>>>
> >>>>>>
> >>>>>> Not quite.  bootarg/bootcmd is still used.  What is different is
> that
> >>>>>> booting linux with a FDT with legacy images required multiple
> arguments to
> >>>>>> bootm.  In that case, bootarg would be 'bootm <zimage_addr> -
> <fdt_addr>'.
> >>>>>> With a FIT, you only provide the address of the FIT itself to bootm
> so
> >>>>>> bootarg is set to 'bootm <fit_addr>'.
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Anybody have the spare cycles to organise a
> >>>>>>> web-tutorial/presentation/recording with me on a play-by-play to
> make all of
> >>>>>>> this make sense?  I'm aiming to be in Prague for the 2017
> conference in
> >>>>>>> October, might be a good place to showcase this fine-tuning.
> >>>>>>>
> >>>>>>
> >>>>>> I'm not clear on what you are asking.  I probably have time to
> review
> >>>>>> docs and presentations and maybe a few phone or video conference
> meetings.
> >>>>>>
> >>>>>>>
> >>>>>>> Ron
> >>>>>>>
> >>>>>>> On 22 February 2017 at 13:51, Rick Altherr <raltherr@google.com>
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Tue, Feb 21, 2017 at 10:08 AM, Ron Brash <ron.brash@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
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>>
> >>>>> Ron Brash
> >>>>> CTO  & Co-founder of Atlants Embedded Inc.
> >>>>> www.atlantsembedded.com
> >>>>> ------------------------------------------------------------------
> >>>>>
> >>>>> Cell +1 438 880 6441
> >>>>> Email  ron.brash at gmail.com
> >>>>> Blog www.pacificsimplicity.ca
> >>>>> LinkedIn ca.linkedin.com/in/ronbrash/
> >>>>>
> >>>>>
> >>>>>
> >>>>> This communication is intended for the use of the recipient to which
> it
> >>>>> is
> >>>>> addressed, and may contain confidential, personal, and or privileged
> >>>>> information. Please contact the sender immediately if you are not the
> >>>>> intended recipient of this communication, and do not copy,
> distribute,
> >>>>> or
> >>>>> take action relying on it. Any communication received in error, or
> >>>>> subsequent reply, should be deleted or destroyed.
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>>
> >>> Ron Brash
> >>> CTO  & Co-founder of Atlants Embedded Inc.
> >>> www.atlantsembedded.com
> >>> ------------------------------------------------------------------
> >>>
> >>> Cell +1 438 880 6441
> >>> Email  ron.brash at gmail.com
> >>> Blog www.pacificsimplicity.ca
> >>> LinkedIn ca.linkedin.com/in/ronbrash/
> >>>
> >>>
> >>>
> >>> This communication is intended for the use of the recipient to which it
> >>> is
> >>> addressed, and may contain confidential, personal, and or privileged
> >>> information. Please contact the sender immediately if you are not the
> >>> intended recipient of this communication, and do not copy, distribute,
> or
> >>> take action relying on it. Any communication received in error, or
> >>> subsequent reply, should be deleted or destroyed.
> >>
> >>
> >
> >
> >
> > --
> >
> >
> > Ron Brash
> > CTO  & Co-founder of Atlants Embedded Inc.
> > www.atlantsembedded.com
> > ------------------------------------------------------------------
> >
> > Cell +1 438 880 6441
> > Email  ron.brash at gmail.com
> > Blog www.pacificsimplicity.ca
> > LinkedIn ca.linkedin.com/in/ronbrash/
> >
> >
> >
> > This communication is intended for the use of the recipient to which it
> is
> > addressed, and may contain confidential, personal, and or privileged
> > information. Please contact the sender immediately if you are not the
> > intended recipient of this communication, and do not copy, distribute, or
> > take action relying on it. Any communication received in error, or
> > subsequent reply, should be deleted or destroyed.
>



-- 


Ron Brash
CTO  & Co-founder of Atlants Embedded Inc.
www.atlantsembedded.com
------------------------------------------------------------------

Cell +1 438 880 6441
Email  ron.brash at gmail.com
Blog www.pacificsimplicity.ca
LinkedIn ca.linkedin.com/in/ronbrash/



This communication is intended for the use of the recipient to which it is
addressed, and may contain confidential, personal, and or privileged
information. Please contact the sender immediately if you are not the
intended recipient of this communication, and do not copy, distribute, or
take action relying on it. Any communication received in error, or
subsequent reply, should be deleted or destroyed.

[U-Boot] Complete verified uboot example

[Rick Altherr]

I've been swamped this week.  I hope to pick this up with you next week.

On Tue, Feb 28, 2017 at 4:06 PM, Ron Brash <ron.brash@gmail.com> wrote:
> Hello,
>
> Here is a list of things I have tried:  The raw zImage (which is compressed
> with XZ), various addresses from indeed load address 0x23000000, entry at
> 0x23008000 (and the same), I've tried setting the FTD address since it sets
> itself neatly at 0x22f and change, which will probably get itself clobbered.
>
> I've tried playing with the "magic" variables of ftdaddr, loadaddr, and
> verify.  No luck other than a few loops, hangs and illegitimate instructions
> being executed.
>
> Something is missing from my system, documentation or more and it appears to
> be uboot and/or the fit format + FDT/DTBs.
>
> Is there a magic formula?  Before FIT I could just copy my kernel to 0x22...
> and my DTB to another address that wouldn't be clobbered, use bootm and
> everything would work given I set it to a uImage.
>
> Question, does the FDT need a load address specified as well?  Why does the
> documentation use all 0's?  Usually, all zeros is either an example, or will
> be inherit some address from a variable? (perhaps this is not obviously
> documented).
>
>
>
>
> On 28 February 2017 at 16:51, Rick Altherr <raltherr@google.com> wrote:
>>
>> I've never seen the kernel load address (the start address for copying
>> the kernel image into RAM) being the same as the entrypoint address
>> (where U-Boot jumps to begin executing the kernel).  I'd expect the
>> load address to be 0x23000000.
>>
>> It looks like you are converting the zImage into a U-Boot legacy image
>> and then storing the legacy image in the FIT.  Don't do that.  Store
>> the zImage in the FIT directly.
>>
>> On Tue, Feb 28, 2017 at 11:09 AM, Ron Brash <ron.brash@gmail.com> wrote:
>> > Hello,
>> >
>> > Still for some reason - there is an issue with booting from the FIT.
>> > With a
>> > version of Uboot without the FIT related CONFIGs enabled; everything
>> > works.
>> >
>> > Here is me taking my zImage and converting it to a u-image ( I am not
>> > sure
>> > on the addresses)
>> >
>> > mkimage -A arm -O linux -C none -T kernel -a 0x23008000 -e 0x23008000 -n
>> > linux-4.4.36b \
>> > -d $(KDIR)/zImage $(BIN_DIR)/$(IMG_PREFIX)-zImage-nDTB2
>> >
>> >
>> > My .its:
>> >
>> > /dts-v1/;
>> > /{
>> > description = "Configuration to load a Basic Kernel";
>> > #address-cells = <1>;
>> > images {
>> > linux_kernel at 1 {
>> > description = "Linux zImage";
>> > data =
>> >
>> > /incbin/("../../../../bin/targets/myboard/legacy/myboard-legacy-zImage-nDTB2");
>> > type = "kernel";
>> > arch = "arm";
>> > os = "linux";
>> > compression = "none";
>> > load =  <0x23008000>;
>> > entry = <0x23008000>;
>> > kernel-version = <1>;
>> > hash at 1 {
>> > algo = "sha256";
>> > };
>> > };
>> > fdt at 1 {
>> > description = "FDT blob";
>> > data = /incbin/("../../../../bin/targets/myboard/legacy/myboard.dtb");
>> > type = "flat_dt";
>> > arch = "arm";
>> > compression = "none";
>> > load =  <0x28000000>;
>> > fdt-version = <1>;
>> > hash at 1{
>> > algo = "sha256";
>> > };
>> > };
>> > };
>> > configurations {
>> > default = "config at 1";
>> > config at 1{
>> > description = "Plain Linux";
>> > kernel = "linux_kernel at 1";
>> > fdt = "fdt at 1";
>> > signature at 1{
>> > algo = "sha256,rsa2048";
>> > key-name-hint = "dev_key";
>> > sign-images = "fdt", "kernel";
>> > };
>> > };
>> > };
>> > };
>> >
>> >
>> > Then
>> >
>> >
>> > set -ex
>> > key_dir="/tmp/keys"
>> > key_name="dev_key"
>> >
>> > rm -rf ${FIT_IMG}
>> > rm -rf ${key_dir}
>> > mkdir ${key_dir}
>> > rootdir="/home/dev/usr"
>> >
>> > MKIMG="${rootdir}/lede/staging_dir/host/bin/mkimage"
>> > DTC="/usr/bin/dtc"
>> > CPP="/usr/bin/cpp"
>> > OPENSSL="/usr/bin/openssl"
>> >
>> > #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
>> >
>> > # Control FDT (u-boot.dts) - hits uboot to have keys etc...
>> > BD_NAME="at91sam9260-plx35"
>> > PATH_TO_BIN="${rootdir}/lede/bin/targets/myboard/legacy"
>> >
>> > #
>> > # This is the uboot-nodtb.bin (just renamed)
>> > #
>> > UBOOT_NAME="lede-myboard.bin"
>> > UBOOT_WITH_DTB="${PATH_TO_BIN}/${UBOOT_NAME}"
>> >
>> >
>> > PATH_TO_CTRL_FDT="${rootdir}/lede/build_dir/target-arm_arm926ej-s_musl-1.1.15_eabi/linux-myboard/myboard-uboot-2016.05/arch/arm/dts/"
>> >
>> > CTRL_FDT="${PATH_TO_CTRL_FDT}${BD_NAME}"
>> >
>> > FIT_ITS="at91sam9260"
>> > FIT_IMG="${rootdir}/lede/bin/targets/myboard/legacy/lede-at91-image.fit"
>> >
>> > DOPTS="-I dts -O dtb -p 2000"
>> >
>> > # Generate fitImage with space for signature:
>> > echo "create FIT with space - no signing"
>> > echo " --------------------------------"
>> > $MKIMG -D "${DOPTS}" \
>> >  -f "${FIT_ITS}".its "${FIT_IMG}"
>> >
>> > echo ""
>> > echo ""
>> >
>> > # Now add them and sign them
>> > echo "Sign images with our keys"
>> > echo " --------------------------------"
>> > $MKIMG -D "${DOPTS}" -F \
>> > -k "${key_dir}" -K "${CTRL_FDT}".dtb -r "${FIT_IMG}"
>> >
>> > echo ""
>> > echo ""
>> >
>> > # Add FDT to image
>> > cp ${UBOOT_WITH_DTB} ${UBOOT_WITH_DTB}-wDTB
>> > cat ${PATH_TO_CTRL_FDT}/${BD_NAME}.dtb >> ${UBOOT_WITH_DTB}-wDTB
>> >
>> >
>> > Then I flash the uboot-WDTB to the board and also the FIT image.
>> > Following
>> > that, then I load the FIT into RAM and execute it with the command:
>> >
>> >
>> > cp.b 0xD0084000 0x22000000 0x186A00;setenv my_bootcount 0; bootm
>> > 0x22000000
>> >
>> > Initial value for argc=3
>> > Final value for argc=3
>> > ## Current stack ends at 0x23f119b8 *  kernel: cmdline image address =
>> > 0x22000000
>> > ## Loading kernel from FIT Image at 22000000 ...
>> > No configuration specified, trying default...
>> > Found default configuration: 'config at 1'
>> >    Using 'config at 1' configuration
>> >    Trying 'linux_kernel at 1' kernel subimage
>> >      Description:  Linux zImage
>> >      Type:         Kernel Image
>> >      Compression:  uncompressed
>> >      Data Start:   0x220000dc
>> >      Data Size:    1465544 Bytes = 1.4 MiB
>> >      Architecture: ARM
>> >      OS:           Linux
>> >      Load Address: 0x23008000
>> >      Entry Point:  0x23008000
>> >      Hash node:    'hash at 1'
>> >      Hash algo:    sha256
>> >      Hash value:
>> > 52f8048436c3f62d9108957cb4f6f7d4e58c8c9931d68ea6f0121f4c661c7ffe
>> >      Hash len:     32
>> >    Verifying Hash Integrity ... sha256+ OK
>> >    kernel data at 0x220000dc, len = 0x00165cc8 (1465544)
>> > *  ramdisk: using config 'config at 1' from image at 0x22000000
>> > *  ramdisk: no 'ramdisk' in config
>> > *  fdt: using config 'config at 1' from image at 0x22000000
>> > ## Checking for 'FDT'/'FDT Image' at 22000000
>> > ## Loading fdt from FIT Image at 22000000 ...
>> >    Using 'config at 1' configuration
>> >    Trying 'fdt at 1' fdt subimage
>> >      Description:  FDT blob
>> >      Type:         Flat Device Tree
>> >      Compression:  uncompressed
>> >      Data Start:   0x22165ea4
>> >      Data Size:    21681 Bytes = 21.2 KiB
>> >      Architecture: ARM
>> >      Hash node:    'hash at 1'
>> >      Hash algo:    sha256
>> >      Hash value:
>> > c7f32d039871d858dda8d397c3b6a685bc914c78cf70f03d1860f61ecfe9c689
>> >      Hash len:     32
>> >    Verifying Hash Integrity ... sha256+ OK
>> >    Loading fdt from 0x22165ea4 to 0x28000000
>> >    Booting using the fdt blob at 0x28000000
>> >    of_flat_tree at 0x28000000 size 0x000054b1
>> > Initial value for argc=3
>> > Final value for argc=3
>> >    Loading Kernel Image ... OK
>> > CACHE: Misaligned operation at range [23008000, 2316dcc8]
>> >    kernel loaded at 0x23008000, end = 0x2316dcc8
>> > using: FDT
>> > ## initrd_high = 0x24000000, copy_to_ram = 1
>> >    ramdisk load start = 0x00000000, ramdisk load end = 0x00000000
>> > ## device tree at 28000000 ... 280054b0 (len=33969 [0x84B1])
>> >    Loading Device Tree to 23f08000, end 23f104b0 ... OK
>> > Initial value for argc=3
>> > Final value for argc=3
>> > ## Transferring control to Linux (at address 23008000)...
>> >
>> > Starting kernel ...
>> >
>> > undefined instruction
>> > pc : [<23008028>]          lr : [<23f44ca4>]
>> > reloc pc : [<20fc3028>]    lr : [<21effca4>]
>> > sp : 23f11980  ip : 23f9472c     fp : 00000000
>> > r10: 23f1e61c  r9 : 23f17ef0     r8 : 23f4585c
>> > r7 : 00000000  r6 : 23008000     r5 : 23f9b0f4  r4 : 00000081
>> > r3 : 000054b1  r2 : 23f08000     r1 : 00000658  r0 : 23900000
>> > Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
>> > Resetting CPU ...
>> >
>> > With iminfo:
>> >
>> > #> cp.b 0xD0084000 0x22000000 0x186A00
>> > #> iminfo
>> >
>> > ## Checking Image at 22000000 ...
>> >    FIT image found
>> >    FIT description: Configuration to load a Basic Kernel
>> >     Image 0 (linux_kernel at 1)
>> >      Description:  Linux zImage
>> >      Type:         Kernel Image
>> >      Compression:  uncompressed
>> >      Data Start:   0x220000dc
>> >      Data Size:    1465544 Bytes = 1.4 MiB
>> >      Architecture: ARM
>> >      OS:           Linux
>> >      Load Address: 0x23008000
>> >      Entry Point:  0x23008000
>> >      Hash node:    'hash at 1'
>> >      Hash algo:    sha256
>> >      Hash value:
>> > 52f8048436c3f62d9108957cb4f6f7d4e58c8c9931d68ea6f0121f4c661c7ffe
>> >      Hash len:     32
>> >     Image 1 (fdt at 1)
>> >      Description:  FDT blob
>> >      Type:         Flat Device Tree
>> >      Compression:  uncompressed
>> >      Data Start:   0x22165ea4
>> >      Data Size:    21681 Bytes = 21.2 KiB
>> >      Architecture: ARM
>> >      Hash node:    'hash at 1'
>> >      Hash algo:    sha256
>> >      Hash value:
>> > c7f32d039871d858dda8d397c3b6a685bc914c78cf70f03d1860f61ecfe9c689
>> >      Hash len:     32
>> >     Default Configuration: 'config at 1'
>> >     Configuration 0 (config at 1)
>> >      Description:  Plain Linux
>> >      Kernel:       linux_kernel at 1
>> >      FDT:          fdt at 1
>> > ## Checking hash(es) for FIT Image at 22000000 ...
>> >    Hash(es) for Image 0 (linux_kernel at 1): sha256+
>> >    Hash(es) for Image 1 (fdt at 1): sha256+
>> >
>> >
>> > Any input?  This seems like offsets and not knowing where various
>> > components
>> > need to be looking.
>> >
>> >
>> >
>> >
>> >
>> >
>> > On 27 February 2017 at 16:53, Rick Altherr <raltherr@google.com> wrote:
>> >>
>> >> You set the load address for the linux image to the same location as
>> >> the
>> >> FIT.  U-Boot verified the hashes on the FIT and then tried to copy the
>> >> kernel over top the FIT.  I assume you put the FIT in flash.  Pick a
>> >> location in RAM for the kernel's load address.
>> >>
>> >> On Mon, Feb 27, 2017 at 1:49 PM, Ron Brash <ron.brash@gmail.com> wrote:
>> >>>
>> >>> Looks like far more progress:
>> >>>
>> >>> #> setenv my_bootcount 0; bootm 0xD0084000
>> >>> Initial value for argc=3
>> >>> Final value for argc=3
>> >>> ## Current stack ends at 0x23f11db8 *  kernel: cmdline image address =
>> >>> 0xd0084000
>> >>>    Reading image header from dataflash address d0084000 to RAM address
>> >>> 22000000
>> >>>    FIT/FDT format image found at 0x22000000, size 0x0016c0b1
>> >>>    Reading image remaining data from dataflash address d0084040 to RAM
>> >>> address 22000040
>> >>> ## Loading kernel from FIT Image at 22000000 ...
>> >>> No configuration specified, trying default...
>> >>> Found default configuration: 'config at 1'
>> >>>    Using 'config at 1' configuration
>> >>>    Trying 'linux_kernel at 1' kernel subimage
>> >>>      Description:  Linux zImage
>> >>>      Type:         Kernel Image
>> >>>      Compression:  uncompressed
>> >>>      Data Start:   0x220000dc
>> >>>      Data Size:    1465544 Bytes = 1.4 MiB
>> >>>      Architecture: ARM
>> >>>      OS:           Linux
>> >>>      Load Address: 0x22000000
>> >>>      Entry Point:  0x22008000
>> >>>      Hash node:    'hash at 1'
>> >>>      Hash algo:    sha256
>> >>>      Hash value:
>> >>> 5dcf9a4328bca6fe5c3405e03b9a58402dce36f3a4f0c757e52091b050d2bcb2
>> >>>      Hash len:     32
>> >>>    Verifying Hash Integrity ... sha256+ OK
>> >>>    kernel data at 0x220000dc, len = 0x00165cc8 (1465544)
>> >>> *  ramdisk: using config 'config at 1' from image at 0x22000000
>> >>> *  ramdisk: no 'ramdisk' in config
>> >>> *  fdt: using config 'config at 1' from image at 0x22000000
>> >>> ## Checking for 'FDT'/'FDT Image' at 22000000
>> >>> ## Loading fdt from FIT Image at 22000000 ...
>> >>>    Using 'config at 1' configuration
>> >>>    Trying 'fdt at 1' fdt subimage
>> >>>      Description:  FDT blob
>> >>>      Type:         Flat Device Tree
>> >>>      Compression:  uncompressed
>> >>>      Data Start:   0x22165ea4
>> >>>      Data Size:    21681 Bytes = 21.2 KiB
>> >>>      Architecture: ARM
>> >>>      Hash node:    'hash at 1'
>> >>>      Hash algo:    sha256
>> >>>      Hash value:
>> >>> c7f32d039871d858dda8d397c3b6a685bc914c78cf70f03d1860f61ecfe9c689
>> >>>      Hash len:     32
>> >>>    Verifying Hash Integrity ... sha256+ OK
>> >>>    Loading fdt from 0x22165ea4 to 0x28000000
>> >>>    Booting using the fdt blob at 0x28000000
>> >>>    of_flat_tree at 0x28000000 size 0x000054b1
>> >>> Initial value for argc=3
>> >>> Final value for argc=3
>> >>>    Loading Kernel Image ... OK
>> >>> CACHE: Misaligned operation at range [22000000, 22165cc8]
>> >>>    kernel loaded at 0x22000000, end = 0x22165cc8
>> >>> images.os.start = 0x22000000, images.os.end = 0x2216c0f1
>> >>> images.os.load = 0x22000000, load_end = 0x22165cc8
>> >>> ERROR: new format image overwritten - must RESET the board to recover
>> >>> resetting ...
>> >>>
>> >>> This appears to be an addressing issue.  Anyone care to comment?
>> >>>
>> >>> I'll put up how I got to this point after, but I am curious on how all
>> >>> of
>> >>> the addresses are leveraged, is there an order they follow and more?
>> >>>
>> >>>
>> >>>
>> >>> On 27 February 2017 at 15:58, Rick Altherr <raltherr@google.com>
>> >>> wrote:
>> >>>>
>> >>>> The projects I'm working on are based on Yocto so I've been using the
>> >>>> u-boot signing support that is built in there.  I believe the magic
>> >>>> you are
>> >>>> looking for is in
>> >>>>
>> >>>> http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/uboot-sign.bbclass.
>> >>>> Specifically, when you run 'mkimage -F -k <key-name> -K <control-dtb>
>> >>>> -r
>> >>>> <fit>', the public keys will be inserted into the control dtb.  You
>> >>>> can then
>> >>>> rebuild u-boot with 'make EXT_DTB=<control-dtb>' which will use the
>> >>>> dtb that
>> >>>> includes the keys.
>> >>>>
>> >>>> On Mon, Feb 27, 2017 at 7:34 AM, Ron Brash <ron.brash@gmail.com>
>> >>>> wrote:
>> >>>>>
>> >>>>> Okay - it seems, after working my way through a bunch of the
>> >>>>> documentation and examples in /doc/uImage.FIT - I noticed a
>> >>>>> discrepancy
>> >>>>>
>> >>>>> /dts-v1/;
>> >>>>> /{
>> >>>>> description = "Configuration to load a Basic Kernel";
>> >>>>> #address-cells = <1>;
>> >>>>> images {
>> >>>>> linux_kernel at 1 {
>> >>>>> description = "Linux zImage";
>> >>>>> data = /incbin/("zImage");
>> >>>>> type = "kernel";
>> >>>>> arch = "arm";
>> >>>>> os = "linux";
>> >>>>> compression = "none";
>> >>>>> load =  <0x20000000>;
>> >>>>> entry = <0x20008000>;
>> >>>>> kernel-version = <1>;
>> >>>>> hash at 1 {
>> >>>>> algo = "sha256";
>> >>>>> };
>> >>>>> };
>> >>>>> fdt at 1 {
>> >>>>> description = "FDT blob";
>> >>>>> data = /incbin/("myboard.dtn");
>> >>>>> type = "flat_dt";
>> >>>>> arch = "arm";
>> >>>>> compression = "none";
>> >>>>> fdt-version = <1>;
>> >>>>> hash at 1{
>> >>>>> algo = "sha256";
>> >>>>> };
>> >>>>> };
>> >>>>> };
>> >>>>> configurations {
>> >>>>> default = "config at 1";
>> >>>>> config at 1{
>> >>>>> description = "Plain Linux";
>> >>>>> kernel = "linux_kernel at 1";
>> >>>>> fdt = "fdt at 1";
>> >>>>> signature at 1{
>> >>>>> algo = "sha256,rsa2048";
>> >>>>> key-name-hint = "dev_key";
>> >>>>> sign-images = "fdt", "kernel";
>> >>>>> };
>> >>>>> };
>> >>>>> };
>> >>>>> };
>> >>>>>
>> >>>>> Does NOT equal (for brevity - I just used the node)
>> >>>>>
>> >>>>> fdt at 1 {
>> >>>>> description = "FDT blob";
>> >>>>> data = /incbin/("myboard.dtn");
>> >>>>> type = "flat_dt";
>> >>>>> arch = "arm";
>> >>>>> compression = "none";
>> >>>>> fdt-version = <1>;
>> >>>>> hash at 1{
>> >>>>> algo = "sha256";
>> >>>>> };
>> >>>>> signature at 1{
>> >>>>> algo = "sha256,rsa2048";
>> >>>>> key-name-hint = "dev_key";
>> >>>>> };
>> >>>>> };
>> >>>>>
>> >>>>> Apparently, this causes the mkimage tooling in my particular
>> >>>>> instance
>> >>>>> to explain invalid blob messages.  The large example above indeed
>> >>>>> does work
>> >>>>> once this nuance was noticed.
>> >>>>>
>> >>>>> Next,  once the final CTRL FDT is created, how does one get it back
>> >>>>> into the actual u-boot binary.  Does/can mkimage insert it into the
>> >>>>> binary
>> >>>>> image at a particular offset?  What is the command to do so?
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> On 23 February 2017 at 12:27, Rick Altherr <raltherr@google.com>
>> >>>>> wrote:
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> On Thu, Feb 23, 2017 at 7:48 AM, Ron Brash <ron.brash@gmail.com>
>> >>>>>> wrote:
>> >>>>>>>
>> >>>>>>> Hello all (and thanks Mr. Altherr for this insight),
>> >>>>>>>
>> >>>>>>> Excellent feedback and I agree that all of this needs to find a
>> >>>>>>> home
>> >>>>>>> either on the global docs on the website and/or the text-only
>> >>>>>>> documentation.
>> >>>>>>> Regardless, this leads me to a few questions.
>> >>>>>>>
>> >>>>>>> NOTE: the use of a uboot control DTS, control DTB and control FTD
>> >>>>>>> even in Mr. Altherr's email is confusion provoking.  One term to
>> >>>>>>> rule them
>> >>>>>>> all is needed ;)
>> >>>>>>
>> >>>>>>
>> >>>>>> Agreed.  Technically a flattened device tree (FDT) can be described
>> >>>>>> in
>> >>>>>> an ASCII form (dts) or binary form (dtb).
>> >>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 1.)  What if a board doesn't have OR has ever been configured to
>> >>>>>>> use
>> >>>>>>> u-boot DTS (could we call this a UDTS or something friendly to
>> >>>>>>> differentiate
>> >>>>>>> that fact?); this was a point of misunderstanding until I started
>> >>>>>>> scampering
>> >>>>>>> around into arch/arm/dts/?
>> >>>>>>>
>> >>>>>>> * For example, my board is a derivative of an Atmel at91sam9g20.
>> >>>>>>> It
>> >>>>>>> had a very generic implementation of a DTS that covered reference
>> >>>>>>> boards in
>> >>>>>>> the Linux kernel, but required a fair bit of modification to make
>> >>>>>>> it work.
>> >>>>>>> As the at91sam(legacy platform) isn't in u-boot's source tree for
>> >>>>>>> a DTS -
>> >>>>>>> what would someone like me need to do - do we have a barebones
>> >>>>>>> tutorial
>> >>>>>>> (again I don't mind publishing such with proofing)?  Is it even
>> >>>>>>> required if
>> >>>>>>> we have a platform/board already working in the traditional u-boot
>> >>>>>>> way?
>> >>>>>>>
>> >>>>>> I believe (but have no verified) that if your board is supported by
>> >>>>>> U-Boot without a control FDT today, you can just create one that
>> >>>>>> contains
>> >>>>>> only the public keys.  I've gathered from the mailing list that
>> >>>>>> using a
>> >>>>>> control FDT and the driver model is how all new boards should be
>> >>>>>> implemented.
>> >>>>>>
>> >>>>>>>
>> >>>>>>> 2.)  Just to summarise - everything winds up in two binaries:
>> >>>>>>> u-boot
>> >>>>>>> and the FIT image.  So the partition scheme would more or less
>> >>>>>>> would look
>> >>>>>>> like:
>> >>>>>>>
>> >>>>>>> /-----------------
>> >>>>>>> * Bootstrap/ROM (optional)
>> >>>>>>> /----------------
>> >>>>>>> * U-boot
>> >>>>>>> *    Control DTB
>> >>>>>>> *         Has keys
>> >>>>>>
>> >>>>>>
>> >>>>>> Only the public keys.  The private keys are never stored on the
>> >>>>>> target
>> >>>>>> device.
>> >>>>>>
>> >>>>>>>
>> >>>>>>> *         Driver loadout/init
>> >>>>>>
>> >>>>>> The control FDT only describes the hardware (see
>> >>>>>> https://www.devicetree.org/ and
>> >>>>>>
>> >>>>>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/usage-model.txt).
>> >>>>>> U-Boot's driver model matches device drivers against nodes in the
>> >>>>>> FDT and
>> >>>>>> starts them.
>> >>>>>>
>> >>>>>>>
>> >>>>>>> /----------------
>> >>>>>>> * U-boot env
>> >>>>>>> *----------------
>> >>>>>>> * FIT image
>> >>>>>>
>> >>>>>> The FIT shouldn't be in the U-Boot env section.  That's used by
>> >>>>>> U-Boot
>> >>>>>> to store its persistent environment.  The FIT is a replacement for
>> >>>>>> the
>> >>>>>> kernel image.  Keep a separate place allocated in the flash for
>> >>>>>> kernel but
>> >>>>>> store the FIT there.
>> >>>>>>
>> >>>>>>>
>> >>>>>>> *    ITS
>> >>>>>>
>> >>>>>> I never really thought of it this way, but yes, that's true.  The
>> >>>>>> ITS
>> >>>>>> is itself written in device tree syntax and gets compiled to binary
>> >>>>>> form.
>> >>>>>> dtb tends to get used only to describe device trees in binary form
>> >>>>>> that
>> >>>>>> describe hardware.  Maybe we need to introduce ITB to clarify this
>> >>>>>> is the
>> >>>>>> device tree in binary form describing the image.
>> >>>>>>
>> >>>>>>>
>> >>>>>>> *    Kernel
>> >>>>>>> *    DTS
>> >>>>>>
>> >>>>>>
>> >>>>>> Prefer the terms FDT or DTB.  Only the compiled form is stored in
>> >>>>>> the
>> >>>>>> FIT.
>> >>>>>>
>> >>>>>>>
>> >>>>>>> *    ....
>> >>>>>>> /---------------
>> >>>>>>> * Rootfs etc...
>> >>>>>>> * ...
>> >>>>>>> /---------------
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 3.)  What people used to use to load X address into Z location in
>> >>>>>>> memory is now removed by the usage of a DTB in u-boot correct?  I
>> >>>>>>> assume
>> >>>>>>> that the u-boot DTB now does this and bootarg/bootcmd is partially
>> >>>>>>> done away
>> >>>>>>> with - as its arguments are augmented by said file.
>> >>>>>>
>> >>>>>>
>> >>>>>> Not quite.  bootarg/bootcmd is still used.  What is different is
>> >>>>>> that
>> >>>>>> booting linux with a FDT with legacy images required multiple
>> >>>>>> arguments to
>> >>>>>> bootm.  In that case, bootarg would be 'bootm <zimage_addr> -
>> >>>>>> <fdt_addr>'.
>> >>>>>> With a FIT, you only provide the address of the FIT itself to bootm
>> >>>>>> so
>> >>>>>> bootarg is set to 'bootm <fit_addr>'.
>> >>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Anybody have the spare cycles to organise a
>> >>>>>>> web-tutorial/presentation/recording with me on a play-by-play to
>> >>>>>>> make all of
>> >>>>>>> this make sense?  I'm aiming to be in Prague for the 2017
>> >>>>>>> conference in
>> >>>>>>> October, might be a good place to showcase this fine-tuning.
>> >>>>>>>
>> >>>>>>
>> >>>>>> I'm not clear on what you are asking.  I probably have time to
>> >>>>>> review
>> >>>>>> docs and presentations and maybe a few phone or video conference
>> >>>>>> meetings.
>> >>>>>>
>> >>>>>>>
>> >>>>>>> Ron
>> >>>>>>>
>> >>>>>>> On 22 February 2017 at 13:51, Rick Altherr <raltherr@google.com>
>> >>>>>>> wrote:
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> On Tue, Feb 21, 2017 at 10:08 AM, Ron Brash <ron.brash@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
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>>
>> >>>>>
>> >>>>> Ron Brash
>> >>>>> CTO  & Co-founder of Atlants Embedded Inc.
>> >>>>> www.atlantsembedded.com
>> >>>>> ------------------------------------------------------------------
>> >>>>>
>> >>>>> Cell +1 438 880 6441
>> >>>>> Email  ron.brash at gmail.com
>> >>>>> Blog www.pacificsimplicity.ca
>> >>>>> LinkedIn ca.linkedin.com/in/ronbrash/
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> This communication is intended for the use of the recipient to which
>> >>>>> it
>> >>>>> is
>> >>>>> addressed, and may contain confidential, personal, and or privileged
>> >>>>> information. Please contact the sender immediately if you are not
>> >>>>> the
>> >>>>> intended recipient of this communication, and do not copy,
>> >>>>> distribute,
>> >>>>> or
>> >>>>> take action relying on it. Any communication received in error, or
>> >>>>> subsequent reply, should be deleted or destroyed.
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>>
>> >>>
>> >>> Ron Brash
>> >>> CTO  & Co-founder of Atlants Embedded Inc.
>> >>> www.atlantsembedded.com
>> >>> ------------------------------------------------------------------
>> >>>
>> >>> Cell +1 438 880 6441
>> >>> Email  ron.brash at gmail.com
>> >>> Blog www.pacificsimplicity.ca
>> >>> LinkedIn ca.linkedin.com/in/ronbrash/
>> >>>
>> >>>
>> >>>
>> >>> This communication is intended for the use of the recipient to which
>> >>> it
>> >>> is
>> >>> addressed, and may contain confidential, personal, and or privileged
>> >>> information. Please contact the sender immediately if you are not the
>> >>> intended recipient of this communication, and do not copy, distribute,
>> >>> or
>> >>> take action relying on it. Any communication received in error, or
>> >>> subsequent reply, should be deleted or destroyed.
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> >
>> >
>> > Ron Brash
>> > CTO  & Co-founder of Atlants Embedded Inc.
>> > www.atlantsembedded.com
>> > ------------------------------------------------------------------
>> >
>> > Cell +1 438 880 6441
>> > Email  ron.brash at gmail.com
>> > Blog www.pacificsimplicity.ca
>> > LinkedIn ca.linkedin.com/in/ronbrash/
>> >
>> >
>> >
>> > This communication is intended for the use of the recipient to which it
>> > is
>> > addressed, and may contain confidential, personal, and or privileged
>> > information. Please contact the sender immediately if you are not the
>> > intended recipient of this communication, and do not copy, distribute,
>> > or
>> > take action relying on it. Any communication received in error, or
>> > subsequent reply, should be deleted or destroyed.
>
>
>
>
> --
>
>
> Ron Brash
> CTO  & Co-founder of Atlants Embedded Inc.
> www.atlantsembedded.com
> ------------------------------------------------------------------
>
> Cell +1 438 880 6441
> Email  ron.brash at gmail.com
> Blog www.pacificsimplicity.ca
> LinkedIn ca.linkedin.com/in/ronbrash/
>
>
>
> This communication is intended for the use of the recipient to which it is
> addressed, and may contain confidential, personal, and or privileged
> information. Please contact the sender immediately if you are not the
> intended recipient of this communication, and do not copy, distribute, or
> take action relying on it. Any communication received in error, or
> subsequent reply, should be deleted or destroyed.

[U-Boot] Complete verified uboot example

[Simon Glass]

Hi Ron,

On 21 February 2017 at 11:08, Ron Brash <ron.brash@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.

See also the beaglebone_vboot.txt file which has an end-to-end example
for that board. That is a much better example than the test.

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

Yes.

>
> 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
>
> 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
>
> / 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 >;
> 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";

You need a signature at 1 node in here, otherwise mkimage will not sign anything.

> };
> };
> };
>
> 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...>
>  };

That goes in the config at 1 node, as above. See sign-configs.txt for an example.

>
> 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..
>
> #Assemble control FDT for U-Boot with space for public key:
> $DTC -p 0x1000 u-boot.dts -O dtb -o u-boot.dtb

Well if you are using CONFIG_OF_CONTROL, U-Boot will create this file
automatically. Also mkimage will add space if needed automatically. So
I don't think you need this step.

>
> 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?

You don't even need that. It will create it for you.

>
> 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?

It needs to be protected from being written. Normally it is added to
the end of U-Boot:

cat u-boot-nodtb.bin u-boot.dtb >u-boot.bin

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

Again, mkimage will add space if needed.

>
> 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.

>
> 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.
>
> # 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

Yes.

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

No, that step isn't needed.

>
> 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.

>
> Question: Do we just boot using anything else or just bootm
> 0xLocationOfTheFitImageInRAM

Just bootm.

>
> Greatly appreciate any assistance to all of these questions and I'm sure
> this threat will be of interest to anyone else too.

Reading your questions I can't helping thinking that you may have
missed the documentation.

See the files in doc/uImage.FIT and it will probably help a lot.

There are quite a few more things in this thread now that I have found
it, so I will take a look.

Regards,
Simon

[U-Boot] Complete verified uboot example

[Simon Glass]

Hi Ron,

On 27 February 2017 at 14:49, Ron Brash <ron.brash@gmail.com> wrote:
> Looks like far more progress:
>
> #> setenv my_bootcount 0; bootm 0xD0084000
> Initial value for argc=3
> Final value for argc=3
> ## Current stack ends at 0x23f11db8 *  kernel: cmdline image address =
> 0xd0084000
>    Reading image header from dataflash address d0084000 to RAM address
> 22000000
>    FIT/FDT format image found at 0x22000000, size 0x0016c0b1
>    Reading image remaining data from dataflash address d0084040 to RAM
> address 22000040
> ## Loading kernel from FIT Image at 22000000 ...
> No configuration specified, trying default...
> Found default configuration: 'config at 1'
>    Using 'config at 1' configuration
>    Trying 'linux_kernel at 1' kernel subimage
>      Description:  Linux zImage
>      Type:         Kernel Image
>      Compression:  uncompressed
>      Data Start:   0x220000dc
>      Data Size:    1465544 Bytes = 1.4 MiB
>      Architecture: ARM
>      OS:           Linux
>      Load Address: 0x22000000
>      Entry Point:  0x22008000
>      Hash node:    'hash at 1'
>      Hash algo:    sha256
>      Hash value:
> 5dcf9a4328bca6fe5c3405e03b9a58402dce36f3a4f0c757e52091b050d2bcb2
>      Hash len:     32
>    Verifying Hash Integrity ... sha256+ OK
>    kernel data at 0x220000dc, len = 0x00165cc8 (1465544)
> *  ramdisk: using config 'config at 1' from image at 0x22000000
> *  ramdisk: no 'ramdisk' in config
> *  fdt: using config 'config at 1' from image at 0x22000000
> ## Checking for 'FDT'/'FDT Image' at 22000000
> ## Loading fdt from FIT Image at 22000000 ...
>    Using 'config at 1' configuration
>    Trying 'fdt at 1' fdt subimage
>      Description:  FDT blob
>      Type:         Flat Device Tree
>      Compression:  uncompressed
>      Data Start:   0x22165ea4
>      Data Size:    21681 Bytes = 21.2 KiB
>      Architecture: ARM
>      Hash node:    'hash at 1'
>      Hash algo:    sha256
>      Hash value:
> c7f32d039871d858dda8d397c3b6a685bc914c78cf70f03d1860f61ecfe9c689
>      Hash len:     32
>    Verifying Hash Integrity ... sha256+ OK
>    Loading fdt from 0x22165ea4 to 0x28000000
>    Booting using the fdt blob at 0x28000000
>    of_flat_tree at 0x28000000 size 0x000054b1
> Initial value for argc=3
> Final value for argc=3
>    Loading Kernel Image ... OK
> CACHE: Misaligned operation at range [22000000, 22165cc8]
>    kernel loaded at 0x22000000, end = 0x22165cc8
> images.os.start = 0x22000000, images.os.end = 0x2216c0f1
> images.os.load = 0x22000000, load_end = 0x22165cc8
> ERROR: new format image overwritten - must RESET the board to recover
> resetting ...
>
> This appears to be an addressing issue.  Anyone care to comment?
>
> I'll put up how I got to this point after, but I am curious on how all of
> the addresses are leveraged, is there an order they follow and more?

At this point you are not dealing with a verified boot problem, IMO.
This is just about getting your board to load things at the right
address.

BTW you appear to be using image verification - I think you should
consider using configuration verification as it is more secure.

[...]

Regards,
Simon

[U-Boot] Complete verified uboot example

[Simon Glass]

Hi Ron,

On 28 February 2017 at 17:06, Ron Brash <ron.brash@gmail.com> wrote:
> Hello,
>
> Here is a list of things I have tried:  The raw zImage (which is compressed
> with XZ), various addresses from indeed load address 0x23000000, entry
> at 0x23008000
> (and the same), I've tried setting the FTD address since it sets itself
> neatly at 0x22f and change, which will probably get itself clobbered.
>
> I've tried playing with the "magic" variables of ftdaddr, loadaddr, and
> verify.  No luck other than a few loops, hangs and
> illegitimate instructions being executed.
>
> Something is missing from my system, documentation or more and it appears
> to be uboot and/or the fit format + FDT/DTBs.
>
> Is there a magic formula?  Before FIT I could just copy my kernel to
> 0x22... and my DTB to another address that wouldn't be clobbered, use bootm
> and everything would work given I set it to a uImage.
>
> Question, does the FDT need a load address specified as well?  Why does the
> documentation use all 0's?  Usually, all zeros is either an example, or
> will be inherit some address from a variable? (perhaps this is not
> obviously documented).

You should be able to set up load addresses for each image in the FIT,
and use the same addresses as you used to use before FIT. The FIT
itself can then be loaded to some other address. That's probably the
safest approach.

What board are you using? It's a shame to have to break new ground here.`

[...]

Regards,
Simon