Patchwork [U-Boot,v3,12/12] Add verified boot information and test

login
register
mail settings
Submitter Simon Glass
Date June 13, 2013, 10:10 p.m.
Message ID <1371161411-2834-13-git-send-email-sjg@chromium.org>
Download mbox | patch
Permalink /patch/251188/
State Accepted
Delegated to: Tom Rini
Headers show

Comments

Simon Glass - June 13, 2013, 10:10 p.m.
Add a description of how to implement verified boot using signed FIT images,
and a simple test which verifies operation on sandbox.

The test signs a FIT image and verifies it, then signs a FIT configuration
and verifies it. Then it corrupts the signature to check that this is
detected.

Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v3:
- Fix 'compile' typo
- Rebase to master

Changes in v2:
- Update README to fix typos
- Use U-Boot's -c option instead of hard-coding a boot script

 doc/uImage.FIT/verified-boot.txt | 104 ++++++++++++++++++++++++++++++++
 test/vboot/.gitignore            |   3 +
 test/vboot/sandbox-kernel.dts    |   7 +++
 test/vboot/sandbox-u-boot.dts    |   7 +++
 test/vboot/sign-configs.its      |  45 ++++++++++++++
 test/vboot/sign-images.its       |  42 +++++++++++++
 test/vboot/vboot_test.sh         | 126 +++++++++++++++++++++++++++++++++++++++
 7 files changed, 334 insertions(+)
 create mode 100644 doc/uImage.FIT/verified-boot.txt
 create mode 100644 test/vboot/.gitignore
 create mode 100644 test/vboot/sandbox-kernel.dts
 create mode 100644 test/vboot/sandbox-u-boot.dts
 create mode 100644 test/vboot/sign-configs.its
 create mode 100644 test/vboot/sign-images.its
 create mode 100755 test/vboot/vboot_test.sh
Simon Glass - June 13, 2013, 10:33 p.m.
Hi Tom,

On Thu, Jun 13, 2013 at 3:10 PM, Simon Glass <sjg@chromium.org> wrote:

> Add a description of how to implement verified boot using signed FIT
> images,
> and a simple test which verifies operation on sandbox.
>
> The test signs a FIT image and verifies it, then signs a FIT configuration
> and verifies it. Then it corrupts the signature to check that this is
> detected.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
>

If it helps, here are the results of my build for this series (and the
trace one). No new failures but you can see quite a few problems with
Xscale.

 ./tools/buildman/buildman -b us-vboot9c -s
Summary of 35 commits for 1124 boards (32 threads, 1 job per thread)
01: pci: introduce CONFIG_PCI_INDIRECT_BRIDGE option
  blackfin: +   bf561-acvilon cm-bf561 blackstamp br4 bct-brettl2 cm-bf527
dnp5370 bf506f-ezkit ip04 bf527-sdp bf609-ezkit bf537-stamp bf527-ezkit-v2
cm-bf537e tcm-bf518 cm-bf537u bf527-ezkit bf537-pnav cm-bf533 pr1
bf533-ezkit ibf-dsp561 bf537-srv1 cm-bf548 bf537-minotaur bf538f-ezkit
bf548-ezkit bf525-ucr2 blackvme tcm-bf537 bf533-stamp bf518f-ezbrd
bf527-ad7160-eval bf526-ezbrd bf561-ezkit
      m68k: +   M54455EVB_a66 M5329AFEE M5249EVB idmr M5208EVBE M5475FFE
M54451EVB astro_mcf5373l M54418TWR_serial_rmii M54455EVB_intel M5282EVB
M54455EVB_i66 M5475GFE M5253DEMO M54455EVB_stm33 M5485BFE M5485DFE
M5329BFEE M52277EVB M5475EFE M5475CFE M5485AFE M53017EVB M5475AFE M5485HFE
M5235EVB M5253EVBE M54418TWR_nand_mii M54418TWR_nand_rmii_lowfreq TASREG
cobra5272 M5475BFE M5475DFE M5275EVB M52277EVB_stmicro eb_cpu5282
eb_cpu5282_internal M54451EVB_stmicro M5271EVB M5485GFE M5485EFE M5485FFE
M54418TWR M5235EVB_Flash32 M5373EVB M54418TWR_nand_rmii
M54418TWR_serial_mii M5485CFE M54455EVB M5272C3
   powerpc: +   MVBLM7 MVSMR lcd4_lwmon5
        sh: +   rsk7269 rsk7264 sh7757lcr sh7752evb rsk7203
microblaze: +   microblaze-generic
  openrisc: +   openrisc-generic
       arm: +   palmtc zipitz2 VCMA9 lubbock zynq_dcc vpac270_nor_128
colibri_pxa270 kzm9g zynq xaeniax polaris pxa255_idp vpac270_ond_256
vpac270_nor_256 smdk2410 h2200 balloon3 palmld trizepsiv
     nds32: +   adp-ag101p adp-ag102 adp-ag101
02: pci: Convert extern inline functions to static inline
03: x86: Correct missing local variable in bootm
04: Fix missing return in do_mem_loop()
05: Show stdout on error in fit-test
06: bootstage: Correct printf types
07: Add function to print a number with grouped digits
08: Add trace library
09: Add a trace command
10: Support tracing in config.mk when enabled
11: Add trace support to generic board
12: Add proftool to decode profile data
13: sandbox: Support trace feature
14: Add a simple test for sandbox trace
15: Clarify bootm OS arguments
16: Refactor the bootm command to reduce code duplication
17: Add a 'fake' go command to the bootm command
18: arm: Implement the 'fake' go command
19: exynos: Avoid function instrumentation for microsecond timer
20: exynos: config: Add tracing options
21: x86: Support tracing function
22: x86: config: Add tracing options
23: wip
24: image: Add signing infrastructure
25: image: Support signing of images
26: image: Add RSA support for image signing
27: mkimage: Add -k option to specify key directory
28: mkimage: Add -K to write public keys to an FDT blob
29: mkimage: Add -F option to modify an existing .fit file
30: mkimage: Add -c option to specify a comment for key signing
31: mkimage: Add -r option to specify keys that must be verified
32: libfdt: Add fdt_find_regions()
33: image: Add support for signing of FIT configurations
34: sandbox: config: Enable FIT signatures with RSA
35: Add verified boot information and test

Regards,
Simon
Tom Rini - June 20, 2013, 4:07 p.m.
On Thu, Jun 13, 2013 at 03:33:19PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, Jun 13, 2013 at 3:10 PM, Simon Glass <sjg@chromium.org> wrote:
> 
> > Add a description of how to implement verified boot using signed FIT
> > images,
> > and a simple test which verifies operation on sandbox.
> >
> > The test signs a FIT image and verifies it, then signs a FIT configuration
> > and verifies it. Then it corrupts the signature to check that this is
> > detected.
> >
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> >
> 
> If it helps, here are the results of my build for this series (and the
> trace one). No new failures but you can see quite a few problems with
> Xscale.

I _think_ Xscale is toolchain choice related.  My question is, for
arches which use --gc-sections, what is the size change from before to
after, when not opting in on this?
Simon Glass - June 20, 2013, 4:18 p.m.
Hi Tom,

On Thu, Jun 20, 2013 at 9:07 AM, Tom Rini <trini@ti.com> wrote:

> On Thu, Jun 13, 2013 at 03:33:19PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, Jun 13, 2013 at 3:10 PM, Simon Glass <sjg@chromium.org> wrote:
> >
> > > Add a description of how to implement verified boot using signed FIT
> > > images,
> > > and a simple test which verifies operation on sandbox.
> > >
> > > The test signs a FIT image and verifies it, then signs a FIT
> configuration
> > > and verifies it. Then it corrupts the signature to check that this is
> > > detected.
> > >
> > > Signed-off-by: Simon Glass <sjg@chromium.org>
> > >
> >
> > If it helps, here are the results of my build for this series (and the
> > trace one). No new failures but you can see quite a few problems with
> > Xscale.
>
> I _think_ Xscale is toolchain choice related.  My question is, for
> arches which use --gc-sections, what is the size change from before to
> after, when not opting in on this?
>

Yes I think you are right. Unfortunately I don't have that build now, but I
will redo it and check.

Regards,
Simon


>
> --
> Tom
>
Simon Glass - June 20, 2013, 8:55 p.m.
Hi Tom,

On Thu, Jun 20, 2013 at 9:07 AM, Tom Rini <trini@ti.com> wrote:

> On Thu, Jun 13, 2013 at 03:33:19PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, Jun 13, 2013 at 3:10 PM, Simon Glass <sjg@chromium.org> wrote:
> >
> > > Add a description of how to implement verified boot using signed FIT
> > > images,
> > > and a simple test which verifies operation on sandbox.
> > >
> > > The test signs a FIT image and verifies it, then signs a FIT
> configuration
> > > and verifies it. Then it corrupts the signature to check that this is
> > > detected.
> > >
> > > Signed-off-by: Simon Glass <sjg@chromium.org>
> > >
> >
> > If it helps, here are the results of my build for this series (and the
> > trace one). No new failures but you can see quite a few problems with
> > Xscale.
>
> I _think_ Xscale is toolchain choice related.  My question is, for
> arches which use --gc-sections, what is the size change from before to
> after, when not opting in on this?
>

Including both trace and verified boot series, the size drops a little for
ARM and powerpc:

$ ./tools/buildman/buildman -b us-vboot9d  -sS arm powerpc --step 0
Summary of 2 commits for 955 boards (32 threads, 1 job per thread)
01: Merge branch 'master' of git://www.denx.de/git/u-boot-mmc
       arm: +   palmtc zipitz2 VCMA9 lubbock vpac270_nor_128 colibri_pxa270
kzm9g zynq_dcc zynq xaeniax polaris pxa255_idp vpac270_ond_256
vpac270_nor_256 smdk2410 balloon3 palmld trizepsiv h2200
   powerpc: +   MVBLM7 MVSMR lcd4_lwmon5
36: wip
       arm: (for 290/314 boards)  all -142.6  bss +4.5  data +27.1  rodata
-20.4  spl/u-boot-spl:all +1.9  spl/u-boot-spl:bss +0.0
 spl/u-boot-spl:rodata +1.9  text -153.8
   powerpc: (for 639/641 boards)  all -190.2  bss +0.0  data +25.6  rodata
-12.2  spl/u-boot-spl:all +0.2  spl/u-boot-spl:rodata +0.2  text -203.6

(the wip commit is just a patman change). You can see the text size drops
by 100-200 bytes. This is all due to the bootm refactor which removed
duplicated code.

If you are interested you can see this in the detail view. Commit 16
removes quite a bit of code. Commit 25 adds up to 80 bytes of text.

$ ./tools/buildman/buildman -b us-vboot9d  -sS arm powerpc
Summary of 36 commits for 955 boards (32 threads, 1 job per thread)
01: Merge branch 'master' of git://www.denx.de/git/u-boot-mmc
       arm: +   palmtc zipitz2 VCMA9 lubbock vpac270_nor_128 colibri_pxa270
kzm9g zynq_dcc zynq xaeniax polaris pxa255_idp vpac270_ond_256
vpac270_nor_256 smdk2410 balloon3 palmld trizepsiv h2200
   powerpc: +   MVBLM7 MVSMR lcd4_lwmon5
02: pci: Convert extern inline functions to static inline
03: x86: Correct missing local variable in bootm
04: Fix missing return in do_mem_loop()
05: Show stdout on error in fit-test
06: bootstage: Correct printf types
07: Add function to print a number with grouped digits
       arm: (for 290/314 boards)  all +6.0  bss -1.2  data +0.0  rodata
+7.2  spl/u-boot-spl:all +1.8  spl/u-boot-spl:bss -0.1
 spl/u-boot-spl:rodata +1.9
   powerpc: (for 639/641 boards)  all +7.8  bss -0.0  rodata +4.8
 spl/u-boot-spl:all +0.1  spl/u-boot-spl:rodata +0.1  text +3.0
08: Add trace library
       arm: (for 290/314 boards)  all +0.1  bss -0.0  data +0.1
 spl/u-boot-spl:all +0.1  spl/u-boot-spl:bss +0.1
   powerpc: (for 639/641 boards)  all +0.0  bss +0.0
09: Add a trace command
10: Support tracing in config.mk when enabled
11: Add trace support to generic board
       arm: (for 290/314 boards)  all +2.7  bss -0.4  data +0.6  text +2.5
12: Add proftool to decode profile data
13: sandbox: Support trace feature
14: Add a simple test for sandbox trace
15: Clarify bootm OS arguments
       arm: (for 290/314 boards)  all +13.0  bss +1.1  text +12.0
   powerpc: (for 639/641 boards)  all +15.4  text +15.4
16: Refactor the bootm command to reduce code duplication
       arm: (for 290/314 boards)  all -352.1  bss +2.1  rodata -69.0  text
-285.2
   powerpc: (for 639/641 boards)  all -345.4  rodata -44.2  text -301.2
17: Add a 'fake' go command to the bootm command
       arm: (for 290/314 boards)  all +55.1  bss +0.1  data +26.2  rodata
+5.0  text +23.8
   powerpc: (for 639/641 boards)  all +42.5  data +25.6  rodata +3.2  text
+13.7
18: arm: Implement the 'fake' go command
       arm: (for 290/314 boards)  all +89.4  bss +4.5  rodata +25.0  text
+59.9
19: exynos: Avoid function instrumentation for microsecond timer
20: exynos: config: Add tracing options
       arm: (for 290/314 boards)  all +25.0  bss -0.1  data +0.2  rodata
+6.9  text +18.0
   powerpc: (for 639/641 boards)  all -0.0  text -0.0
21: x86: Support tracing function
   powerpc: (for 639/641 boards)  all +0.0  text +0.0
22: x86: config: Add tracing options
       arm: (for 290/314 boards)  all -0.9  bss -0.7  rodata -0.1
   powerpc: (for 639/641 boards)  all -0.4  rodata -0.4
23: wip
       arm: (for 290/314 boards)  all +0.9  bss +0.7  rodata +0.1
   powerpc: (for 639/641 boards)  all +0.4  rodata +0.4
24: image: Add signing infrastructure
       arm: (for 290/314 boards)  all -0.3  bss -0.4  data +0.1
25: image: Support signing of images
       arm: (for 290/314 boards)  all +18.9  bss -0.6  data -0.0  rodata
+4.5  text +15.1
   powerpc: (for 639/641 boards)  all +89.4  rodata +23.9
 spl/u-boot-spl:all +0.1  spl/u-boot-spl:rodata +0.1  text +65.5
26: image: Add RSA support for image signing
   powerpc: (for 639/641 boards)  all +0.0  rodata +0.0
27: mkimage: Add -k option to specify key directory
   powerpc: (for 639/641 boards)  all +0.0  text +0.0
28: mkimage: Add -K to write public keys to an FDT blob
29: mkimage: Add -F option to modify an existing .fit file
   powerpc: (for 639/641 boards)  all -0.0  rodata -0.0  text -0.0
30: mkimage: Add -c option to specify a comment for key signing
   powerpc: (for 639/641 boards)  all -0.0  rodata -0.0  text +0.0
31: mkimage: Add -r option to specify keys that must be verified
   powerpc: (for 639/641 boards)  all +0.0  rodata +0.0
32: libfdt: Add fdt_find_regions()
       arm: (for 290/314 boards)  all -0.4  bss -0.4  data +0.0
33: image: Add support for signing of FIT configurations
       arm: (for 290/314 boards)  all +0.0  bss +0.1  data -0.0
34: sandbox: config: Enable FIT signatures with RSA
35: Add verified boot information and test
36: wip

Regards,
Simon

Patch

diff --git a/doc/uImage.FIT/verified-boot.txt b/doc/uImage.FIT/verified-boot.txt
new file mode 100644
index 0000000..3c83fbc
--- /dev/null
+++ b/doc/uImage.FIT/verified-boot.txt
@@ -0,0 +1,104 @@ 
+U-Boot Verified Boot
+====================
+
+Introduction
+------------
+Verified boot here means the verification of all software loaded into a
+machine during the boot process to ensure that it is authorised and correct
+for that machine.
+
+Verified boot extends from the moment of system reset to as far as you wish
+into the boot process. An example might be loading U-Boot from read-only
+memory, then loading a signed kernel, then using the kernel's dm-verity
+driver to mount a signed root filesystem.
+
+A key point is that it is possible to field-upgrade the software on machines
+which use verified boot. Since the machine will only run software that has
+been correctly signed, it is safe to read software from an updatable medium.
+It is also possible to add a secondary signed firmware image, in read-write
+memory, so that firmware can easily be upgraded in a secure manner.
+
+
+Signing
+-------
+Verified boot uses cryptographic algorithms to 'sign' software images.
+Images are signed using a private key known only to the signer, but can
+be verified using a public key. As its name suggests the public key can be
+made available without risk to the verification process. The private and
+public keys are mathematically related. For more information on how this
+works look up "public key cryptography" and "RSA" (a particular algorithm).
+
+The signing and verification process looks something like this:
+
+
+      Signing                                      Verification
+      =======                                      ============
+
+ +--------------+                   *
+ | RSA key pair |                   *             +---------------+
+ | .key  .crt   |                   *             | Public key in |
+ +--------------+       +------> public key ----->| trusted place |
+       |                |           *             +---------------+
+       |                |           *                    |
+       v                |           *                    v
+   +---------+          |           *              +--------------+
+   |         |----------+           *              |              |
+   | signer  |                      *              |    U-Boot    |
+   |         |----------+           *              |  signature   |--> yes/no
+   +---------+          |           *              | verification |
+      ^                 |           *              |              |
+      |                 |           *              +--------------+
+      |                 |           *                    ^
+ +----------+           |           *                    |
+ | Software |           +----> signed image -------------+
+ |  image   |                       *
+ +----------+                       *
+
+
+The signature algorithm relies only on the public key to do its work. Using
+this key it checks the signature that it finds in the image. If it verifies
+then we know that the image is OK.
+
+The public key from the signer allows us to verify and therefore trust
+software from updatable memory.
+
+It is critical that the public key be secure and cannot be tampered with.
+It can be stored in read-only memory, or perhaps protected by other on-chip
+crypto provided by some modern SOCs. If the public key can ben changed, then
+the verification is worthless.
+
+
+Chaining Images
+---------------
+The above method works for a signer providing images to a run-time U-Boot.
+It is also possible to extend this scheme to a second level, like this:
+
+1. Master private key is used by the signer to sign a first-stage image.
+2. Master public key is placed in read-only memory.
+2. Secondary private key is created and used to sign second-stage images.
+3. Secondary public key is placed in first stage images
+4. We use the master public key to verify the first-stage image. We then
+use the secondary public key in the first-stage image to verify the second-
+state image.
+5. This chaining process can go on indefinitely. It is recommended to use a
+different key at each stage, so that a compromise in one place will not
+affect the whole change.
+
+
+Flattened Image Tree (FIT)
+--------------------------
+The FIT format is alreay widely used in U-Boot. It is a flattened device
+tree (FDT) in a particular format, with images contained within. FITs
+include hashes to verify images, so it is relatively straightforward to
+add signatures as well.
+
+The public key can be stored in U-Boot's CONFIG_OF_CONTROL device tree in
+a standard place. Then when a FIT it loaded it can be verified using that
+public key. Multiple keys and multiple signatures are supported.
+
+See signature.txt for more information.
+
+
+Simon Glass
+sjg@chromium.org
+1-1-13
diff --git a/test/vboot/.gitignore b/test/vboot/.gitignore
new file mode 100644
index 0000000..4631242
--- /dev/null
+++ b/test/vboot/.gitignore
@@ -0,0 +1,3 @@ 
+/*.dtb
+/test.fit
+/dev-keys
diff --git a/test/vboot/sandbox-kernel.dts b/test/vboot/sandbox-kernel.dts
new file mode 100644
index 0000000..a1e853c
--- /dev/null
+++ b/test/vboot/sandbox-kernel.dts
@@ -0,0 +1,7 @@ 
+/dts-v1/;
+
+/ {
+	model = "Sandbox Verified Boot Test";
+	compatible = "sandbox";
+
+};
diff --git a/test/vboot/sandbox-u-boot.dts b/test/vboot/sandbox-u-boot.dts
new file mode 100644
index 0000000..a1e853c
--- /dev/null
+++ b/test/vboot/sandbox-u-boot.dts
@@ -0,0 +1,7 @@ 
+/dts-v1/;
+
+/ {
+	model = "Sandbox Verified Boot Test";
+	compatible = "sandbox";
+
+};
diff --git a/test/vboot/sign-configs.its b/test/vboot/sign-configs.its
new file mode 100644
index 0000000..db2ed79
--- /dev/null
+++ b/test/vboot/sign-configs.its
@@ -0,0 +1,45 @@ 
+/dts-v1/;
+
+/ {
+	description = "Chrome OS kernel image with one or more FDT blobs";
+	#address-cells = <1>;
+
+	images {
+		kernel@1 {
+			data = /incbin/("test-kernel.bin");
+			type = "kernel_noload";
+			arch = "sandbox";
+			os = "linux";
+			compression = "none";
+			load = <0x4>;
+			entry = <0x8>;
+			kernel-version = <1>;
+			hash@1 {
+				algo = "sha1";
+			};
+		};
+		fdt@1 {
+			description = "snow";
+			data = /incbin/("sandbox-kernel.dtb");
+			type = "flat_dt";
+			arch = "sandbox";
+			compression = "none";
+			fdt-version = <1>;
+			hash@1 {
+				algo = "sha1";
+			};
+		};
+	};
+	configurations {
+		default = "conf@1";
+		conf@1 {
+			kernel = "kernel@1";
+			fdt = "fdt@1";
+			signature@1 {
+				algo = "sha1,rsa2048";
+				key-name-hint = "dev";
+				sign-images = "fdt", "kernel";
+			};
+		};
+	};
+};
diff --git a/test/vboot/sign-images.its b/test/vboot/sign-images.its
new file mode 100644
index 0000000..f69326a
--- /dev/null
+++ b/test/vboot/sign-images.its
@@ -0,0 +1,42 @@ 
+/dts-v1/;
+
+/ {
+	description = "Chrome OS kernel image with one or more FDT blobs";
+	#address-cells = <1>;
+
+	images {
+		kernel@1 {
+			data = /incbin/("test-kernel.bin");
+			type = "kernel_noload";
+			arch = "sandbox";
+			os = "linux";
+			compression = "none";
+			load = <0x4>;
+			entry = <0x8>;
+			kernel-version = <1>;
+			signature@1 {
+				algo = "sha1,rsa2048";
+				key-name-hint = "dev";
+			};
+		};
+		fdt@1 {
+			description = "snow";
+			data = /incbin/("sandbox-kernel.dtb");
+			type = "flat_dt";
+			arch = "sandbox";
+			compression = "none";
+			fdt-version = <1>;
+			signature@1 {
+				algo = "sha1,rsa2048";
+				key-name-hint = "dev";
+			};
+		};
+	};
+	configurations {
+		default = "conf@1";
+		conf@1 {
+			kernel = "kernel@1";
+			fdt = "fdt@1";
+		};
+	};
+};
diff --git a/test/vboot/vboot_test.sh b/test/vboot/vboot_test.sh
new file mode 100755
index 0000000..c3cfade
--- /dev/null
+++ b/test/vboot/vboot_test.sh
@@ -0,0 +1,126 @@ 
+#!/bin/sh
+#
+# Copyright (c) 2013, Google Inc.
+#
+# Simple Verified Boot Test Script
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+
+set -e
+
+# Run U-Boot and report the result
+# Args:
+#	$1:	Test message
+run_uboot() {
+	echo -n "Test Verified Boot Run: $1: "
+	${uboot} -d sandbox-u-boot.dtb >${tmp} -c '
+sb load host 0 100 test.fit;
+fdt addr 100;
+bootm 100;
+reset'
+	if ! grep -q "$2" ${tmp}; then
+		echo
+		echo "Verified boot key check failed, output follows:"
+		cat ${tmp}
+		false
+	else
+		echo "OK"
+	fi
+}
+
+echo "Simple Verified Boot Test"
+echo "========================="
+echo
+echo "Please see doc/uImage.FIT/verified-boot.txt for more information"
+echo
+
+err=0
+tmp=/tmp/vboot_test.$$
+
+dir=$(dirname $0)
+
+if [ -z ${O} ]; then
+	O=.
+fi
+O=$(readlink -f ${O})
+
+dtc="-I dts -O dtb -p 2000"
+uboot="${O}/u-boot"
+mkimage="${O}/tools/mkimage"
+keys="${dir}/dev-keys"
+echo ${mkimage} -D "${dtc}"
+
+echo "Build keys"
+mkdir -p ${keys}
+
+# Create an RSA key pair
+openssl genrsa -F4 -out ${keys}/dev.key 2048 2>/dev/null
+
+# Create a certificate containing the public key
+openssl req -batch -new -x509 -key ${keys}/dev.key -out ${keys}/dev.crt
+
+pushd ${dir} >/dev/null
+
+# Compile our device tree files for kernel and U-Boot (CONFIG_OF_CONTROL)
+dtc -p 0x1000 sandbox-kernel.dts -O dtb -o sandbox-kernel.dtb
+dtc -p 0x1000 sandbox-u-boot.dts -O dtb -o sandbox-u-boot.dtb
+
+# Create a number kernel image with zeroes
+head -c 5000 /dev/zero >test-kernel.bin
+
+# Build the FIT, but don't sign anything yet
+echo Build FIT with signed images
+${mkimage} -D "${dtc}" -f sign-images.its test.fit >${tmp}
+
+run_uboot "unsigned signatures:" "dev-"
+
+# Sign images with our dev keys
+echo Sign images
+${mkimage} -D "${dtc}" -F -k dev-keys -K sandbox-u-boot.dtb -r test.fit >${tmp}
+
+run_uboot "signed images" "dev+"
+
+
+# Create a fresh .dtb without the public keys
+dtc -p 0x1000 sandbox-u-boot.dts -O dtb -o sandbox-u-boot.dtb
+
+echo Build FIT with signed configuration
+${mkimage} -D "${dtc}" -f sign-configs.its test.fit >${tmp}
+
+run_uboot "unsigned config" "sha1+ OK"
+
+# Sign images with our dev keys
+echo Sign images
+${mkimage} -D "${dtc}" -F -k dev-keys -K sandbox-u-boot.dtb -r test.fit >${tmp}
+
+run_uboot "signed config" "dev+"
+
+# Increment the first byte of the signature, which should cause failure
+sig=$(fdtget -t bx test.fit /configurations/conf@1/signature@1 value)
+newbyte=$(printf %x $((0x${sig:0:2} + 1)))
+sig="${newbyte} ${sig:2}"
+fdtput -t bx test.fit /configurations/conf@1/signature@1 value ${sig}
+
+run_uboot "signed config with bad hash" "Bad Data Hash"
+
+popd >/dev/null
+
+echo
+if ${ok}; then
+	echo "Test passed"
+else
+	echo "Test failed"
+fi