diff mbox series

doc: uniphier: add simple guide to Verified Boot

Message ID 1508652901-15684-1-git-send-email-yamada.masahiro@socionext.com
State Accepted
Commit 9e19031ca3d019f99239ce48508f91b105d68d5e
Headers show
Series doc: uniphier: add simple guide to Verified Boot | expand

Commit Message

Masahiro Yamada Oct. 22, 2017, 6:15 a.m. UTC
Add a simple documentation about how to use the Verified Boot on
UniPhier boards.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

 doc/README.uniphier | 227 +++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 226 insertions(+), 1 deletion(-)

Comments

Masahiro Yamada Oct. 22, 2017, 4:11 p.m. UTC | #1
2017-10-22 15:15 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>:
> Add a simple documentation about how to use the Verified Boot on
> UniPhier boards.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---


Applied to u-boot-uniphier/master.
diff mbox series

Patch

diff --git a/doc/README.uniphier b/doc/README.uniphier
index e4fd9a3..a58041a 100644
--- a/doc/README.uniphier
+++ b/doc/README.uniphier
@@ -107,6 +107,231 @@  Firmware.
 [ARM Trusted Firmware]: https://github.com/ARM-software/arm-trusted-firmware
 
 
+Verified Boot
+-------------
+
+U-Boot supports an image verification method called "Verified Boot".
+This is a brief tutorial to utilize this feature for the UniPhier platform.
+You will find details docs in the doc/uImage.FIT directory.
+
+Here, we take LD20 reference board for example, but it should work for any
+other boards including 32 bit SoCs.
+
+1. Generate key to sign with
+
+  $ mkdir keys
+  $ openssl genpkey -algorithm RSA -out keys/dev.key \
+    -pkeyopt rsa_keygen_bits:2048 -pkeyopt rsa_keygen_pubexp:65537
+  $ openssl req -batch -new -x509 -key keys/dev.key -out keys/dev.crt
+
+Two files "dev.key" and "dev.crt" will be created.  The base name is arbitrary,
+but need to match to the "key-name-hint" property described below.
+
+2. Describe FIT source
+
+You need to write an FIT (Flattened Image Tree) source file to describe the
+structure of the image container.
+
+The following is an example for a simple usecase:
+
+---------------------------------------->8----------------------------------------
+/dts-v1/;
+
+/ {
+	description = "Kernel, DTB and Ramdisk for UniPhier LD20 Reference Board";
+	#address-cells = <1>;
+
+	images {
+		kernel@0 {
+			description = "linux";
+			data = /incbin/("PATH/TO/YOUR/LINUX/DIR/arch/arm64/boot/Image.gz");
+			type = "kernel";
+			arch = "arm64";
+			os = "linux";
+			compression = "gzip";
+			load = <0x82080000>;
+			entry = <0x82080000>;
+			hash@0 {
+				algo = "sha256";
+			};
+		};
+
+		fdt@0 {
+			description = "fdt";
+			data = /incbin/("PATH/TO/YOUR/LINUX/DIR/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dtb");
+			type = "flat_dt";
+			arch = "arm64";
+			compression = "none";
+			hash@0 {
+				algo = "sha256";
+			};
+		};
+
+		ramdisk@0 {
+			description = "ramdisk";
+			data = /incbin/("PATH/TO/YOUR/ROOTFS/DIR/rootfs.cpio");
+			type = "ramdisk";
+			arch = "arm64";
+			os = "linux";
+			compression = "none";
+			hash@0 {
+				algo = "sha256";
+			};
+		};
+	};
+
+	configurations {
+		default = "config@0";
+
+		config@0 {
+			description = "Configuration0";
+			kernel = "kernel@0";
+			fdt = "fdt@0";
+			ramdisk = "ramdisk@0";
+			signature@0 {
+				algo = "sha256,rsa2048";
+				key-name-hint = "dev";
+				sign-images = "kernel", "fdt", "ramdisk";
+			};
+		};
+	};
+};
+---------------------------------------->8----------------------------------------
+
+You need to change the three '/incbin/' lines, depending on the location of
+your kernel image, device tree blob, and init ramdisk.  The "load" and "entry"
+properties also need to be adjusted if you want to change the physical placement
+of the kernel.
+
+The "key-name-hint" must specify the key name you have created in the step 1.
+
+The FIT file name is arbitrary.  Let's say you saved it into "fit.its".
+
+3. Compile U-Boot with FIT and signature enabled
+
+To use the Verified Boot, you need to enable the following two options:
+  CONFIG_FIT
+  CONFIG_FIT_SIGNATURE
+
+They are disabled by default for UniPhier defconfig files.  So, you need to
+tweak the configuration from "make menuconfig" or friends.
+
+  $ make uniphier_v8_defconfig
+  $ make menuconfig
+      [ enable CONFIG_FIT and CONFIG_FIT_SIGNATURE ]
+  $ make CROSS_COMPILE=aarch64-linux-gnu-
+
+4. Build the image tree blob
+
+After building U-Boot, you will see tools/mkimage.  With this tool, you can
+create an image tree blob as follows:
+
+  $ tools/mkimage -f fit.its -k keys -K dts/dt.dtb -r -F fitImage
+
+The -k option must specify the key directory you have created in step 1.
+
+A file "fitImage" will be created.  This includes kernel, DTB, Init-ramdisk,
+hash data for each of the three, and signature data.
+
+The public key needed for the run-time verification is stored in "dts/dt.dtb".
+
+5. Compile U-Boot again
+
+Since the "dt.dtb" has been updated in step 4, you need to re-compile the
+U-Boot.
+
+  $ make CROSS_COMPILE=aarch64-linux-gnu-
+
+The re-compiled "u-boot.bin" is appended with DTB that contains the public key.
+
+6. Flash the image
+
+Flash the "fitImage" to a storage device (NAND, eMMC, or whatever) on your
+board.
+
+Please note the "u-boot.bin" must be signed, and verified by someone when it is
+loaded.  For ARMv8 SoCs, the "someone" is generally ARM Trusted Firmware BL2.
+ARM Trusted Firmware supports an image authentication mechanism called Trusted
+Board Boot (TBB).  The verification process must be chained from the moment of
+the system reset.  If the Chain of Trust has a breakage somewhere, the verified
+boot process is entirely pointless.
+
+7. Boot verified kernel
+
+Load the fitImage to memory and run the following from the U-Boot command line.
+
+  > bootm <addr>
+
+Here, <addr> is the base address of the fitImage.
+
+If it is successful, you will see messages like follows:
+
+---------------------------------------->8----------------------------------------
+## Loading kernel from FIT Image at 84100000 ...
+   Using 'config@0' configuration
+   Verifying Hash Integrity ... sha256,rsa2048:dev+ OK
+   Trying 'kernel@0' kernel subimage
+     Description:  linux
+     Created:      2017-10-20  14:32:29 UTC
+     Type:         Kernel Image
+     Compression:  gzip compressed
+     Data Start:   0x841000c8
+     Data Size:    6957818 Bytes = 6.6 MiB
+     Architecture: AArch64
+     OS:           Linux
+     Load Address: 0x82080000
+     Entry Point:  0x82080000
+     Hash algo:    sha256
+     Hash value:   82a37b7f11ae55f4e07aa25bf77e4067cb9dc1014d52d6cd4d588f92eee3aaad
+   Verifying Hash Integrity ... sha256+ OK
+## Loading ramdisk from FIT Image at 84100000 ...
+   Using 'config@0' configuration
+   Trying 'ramdisk@0' ramdisk subimage
+     Description:  ramdisk
+     Created:      2017-10-20  14:32:29 UTC
+     Type:         RAMDisk Image
+     Compression:  uncompressed
+     Data Start:   0x847a5cc0
+     Data Size:    5264365 Bytes = 5 MiB
+     Architecture: AArch64
+     OS:           Linux
+     Load Address: unavailable
+     Entry Point:  unavailable
+     Hash algo:    sha256
+     Hash value:   44980a2874154a2e31ed59222c9f8ea968867637f35c81e4107a984de7014deb
+   Verifying Hash Integrity ... sha256+ OK
+## Loading fdt from FIT Image at 84100000 ...
+   Using 'config@0' configuration
+   Trying 'fdt@0' fdt subimage
+     Description:  fdt
+     Created:      2017-10-20  14:32:29 UTC
+     Type:         Flat Device Tree
+     Compression:  uncompressed
+     Data Start:   0x847a2cb0
+     Data Size:    12111 Bytes = 11.8 KiB
+     Architecture: AArch64
+     Hash algo:    sha256
+     Hash value:   c517099db537f6d325e6be46b25c871a41331ad5af0283883fd29d40bfc14e1d
+   Verifying Hash Integrity ... sha256+ OK
+   Booting using the fdt blob at 0x847a2cb0
+   Uncompressing Kernel Image ... OK
+   reserving fdt memory region: addr=80000000 size=2000000
+   Loading Device Tree to 000000009fffa000, end 000000009fffff4e ... OK
+
+Starting kernel ...
+---------------------------------------->8----------------------------------------
+
+Please pay attention to the lines that start with "Verifying Hash Integrity".
+
+"Verifying Hash Integrity ... sha256,rsa2048:dev+ OK" means the signature check
+passed.
+
+"Verifying Hash Integrity ... sha256+ OK" (3 times) means the hash check passed
+for kernel, DTB, and Init ramdisk.
+
+If they are not displayed, the Verified Boot is not working.
+
+
 UniPhier specific commands
 --------------------------
 
@@ -179,4 +404,4 @@  newer SoCs.  Even if it is, EA[25] is not connected on most of the boards.
 
 --
 Masahiro Yamada <yamada.masahiro@socionext.com>
-Sep. 2017
+Oct. 2017