arm: mvebu: Implement secure boot

The patch implements secure booting for the mvebu architecture.

This includes:
- The addition of secure headers and all needed signatures and keys in
  mkimage
- Commands capable of writing the board's efuses to both write the
  needed cryptographic data and enable the secure booting mechanism
- The creation of convenience text files containing the necessary
  commands to write the efuses

The KAK and CSK keys are expected to reside in the files kwb_kak.key and
kwb_csk.key (OpenSSL 2048 bit private keys) in the top-level directory.

Signed-off-by: Reinhard Pfau <reinhard.pfau@gdsys.cc>
Signed-off-by: Mario Six <mario.six@gdsys.cc>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Stefan Roese <sr@denx.de>

1 files changed, 373 insertions, 0 deletions

diff --git a/doc/README.armada-secureboot b/doc/README.armada-secureboot
new file mode 100644
index 0000000..157cb5a
--- /dev/null
+++ b/doc/README.armada-secureboot
@@ -0,0 +1,373 @@
+The trusted boot framework on Marvell Armada 38x
+================================================
+
+Contents:
+
+1. Overview of the trusted boot
+2. Terminology
+3. Boot image layout
+4. The secured header
+5. The secured boot flow
+6. Usage example
+7. Work to be done
+8. Bibliography
+
+1. Overview of the trusted boot
+-------------------------------
+
+The Armada's trusted boot framework enables the SoC to cryptographically verify
+a specially prepared boot image. This can be used to establish a chain of trust
+from the boot firmware all the way to the OS.
+
+To achieve this, the Armada SoC requires a specially prepared boot image, which
+contains the relevant cryptographic data, as well as other information
+pertaining to the boot process. Furthermore, a eFuse structure (a
+one-time-writeable memory) need to be configured in the correct way.
+
+Roughly, the secure boot process works as follows:
+
+* Load the header block of the boot image, extract a special "root" public RSA
+  key from it, and verify its SHA-256 hash against a SHA-256 stored in a eFuse
+  field.
+* Load an array of code signing public RSA keys from the header block, and
+  verify its RSA signature (contained in the header block as well) using the
+  "root" RSA key.
+* Choose a code signing key, and use it to verify the header block (excluding
+  the key array).
+* Verify the binary image's signature (contained in the header block) using the
+  code signing key.
+* If all checks pass successfully, boot the image.
+
+The chain of trust is thus as follows:
+
+* The SHA-256 value in the eFuse field verifies the "root" public key.
+* The "root" public key verifies the code signing key array.
+* The selected code signing key verifies the header block and the binary image.
+
+In the special case of building a boot image containing U-Boot as the binary
+image, which employs this trusted boot framework, the following tasks need to
+be addressed:
+
+1. Creation of the needed cryptographic key material.
+2. Creation of a conforming boot image containing the U-Boot image as binary
+   image.
+3. Burning the necessary eFuse values.
+
+(1) will be addressed later, (2) will be taken care of by U-Boot's build
+system (some user configuration is required, though), and for (3) the necessary
+data (essentially a series of U-Boot commands to be entered at the U-Boot
+command prompt) will be created by the build system as well.
+
+The documentation of the trusted boot mode is contained in part 1, chapter
+7.2.5 in the functional specification [1], and in application note [2].
+
+2. Terminology
+--------------
+
+	           CSK - Code Signing Key(s): An array of RSA key pairs, which
+                         are used to sign and verify the secured header and the
+                         boot loader image.
+	           KAK - Key Authentication Key: A RSA key pair, which is used
+                         to sign and verify the array of CSKs.
+	  Header block - The first part of the boot image, which contains the
+			 image's headers (also known as "headers block", "boot
+			 header", and "image header")
+                 eFuse - A one-time-writeable memory.
+               BootROM - The Armada's built-in boot firmware, which is
+                         responsible for verifying and starting secure images.
+	    Boot image - The complete image the SoC's boot firmware loads
+			 (contains the header block and the binary image)
+	   Main header - The header in the header block containing information
+			 and data pertaining to the boot process (used for both
+			 the regular and secured boot processes)
+	  Binary image - The binary code payload of the boot image; in this
+			 case the U-Boot's code (also known as "source image",
+			 or just "image")
+	Secured header - The specialized header in the header block that
+			 contains information and data pertaining to the
+			 trusted boot (also known as "security header")
+     Secured boot mode - A special boot mode of the Armada SoC in which secured
+                         images are verified (non-secure images won't boot);
+                         the mode is activated by setting a eFuse field.
+    Trusted debug mode - A special mode for the trusted boot that allows
+			 debugging of devices employing the trusted boot
+			 framework in a secure manner (untested in the current
+			 implementation).
+Trusted boot framework - The ARMADA SoC's implementation of a secure verified
+                         boot process.
+
+3. Boot image layout
+--------------------
+
++-- Boot image --------------------------------------------+
+|                                                          |
+| +-- Header block --------------------------------------+ |
+| | Main header                                          | |
+| +------------------------------------------------------+ |
+| | Secured header                                       | |
+| +------------------------------------------------------+ |
+| | BIN header(s)                                        | |
+| +------------------------------------------------------+ |
+| | REG header(s)                                        | |
+| +------------------------------------------------------+ |
+| | Padding                                              | |
+| +------------------------------------------------------+ |
+|                                                          |
+| +------------------------------------------------------+ |
+| | Binary image + checksum                              | |
+| +------------------------------------------------------+ |
++----------------------------------------------------------+
+
+4. The secured header
+---------------------
+
+For the trusted boot framework, a additional header is added to the boot image.
+The following data are relevant for the secure boot:
+
+		   KAK: The KAK is contained in the secured header in the form
+		        of a RSA-2048 public key in DER format with a length of
+			524 bytes.
+Header block signature: The RSA signature of the header block (excluding the
+                        CSK array), created using the selected CSK.
+Binary image signature: The RSA signature of the binary image, created using
+                        the selected CSK.
+             CSK array: The array of the 16 CSKs as RSA-2048 public keys in DER
+	                format with a length of 8384 = 16 * 524 bytes.
+   CSK block signature: The RSA signature of the CSK array, created using the
+                        KAK.
+
+NOTE: The JTAG delay, Box ID, and Flash ID header fields do play a role in the
+trusted boot process to enable and configure secure debugging, but they were
+not tested in the current implementation of the trusted boot in U-Boot.
+
+5. The secured boot flow
+------------------------
+
+The steps in the boot flow that are relevant for the trusted boot framework
+proceed as follows:
+
+1) Check if trusted boot is enabled, and perform regular boot if it is not.
+2) Load the secured header, and verify its checksum.
+3) Select the lowest valid CSK from CSK0 to CSK15.
+4) Verify the SHA-256 hash of the KAK embedded in the secured header.
+5) Verify the RSA signature of the CSK block from the secured header with the
+   KAK.
+6) Verify the header block signature (which excludes the CSK block) from the
+   secured header with the selected CSK.
+7) Load the binary image to the main memory and verify its checksum.
+8) Verify the binary image's RSA signature from the secured header with the
+   selected CSK.
+9) Continue the boot process as in the case of the regular boot.
+
+NOTE: All RSA signatures are verified according to the PKCS #1 v2.1 standard
+described in [3].
+
+NOTE: The Box ID and Flash ID are checked after step 6, and the trusted debug
+mode may be entered there, but since this mode is untested in the current
+implementation, it is not described further.
+
+6. Usage example
+----------------
+
+### Create key material
+
+To employ the trusted boot framework, cryptographic key material needs to be
+created. In the current implementation, two keys are needed to build a valid
+secured boot image: The KAK private key and a CSK private key (both have to be
+2048 bit RSA keys in PEM format). Note that the usage of more than one CSK is
+currently not supported.
+
+NOTE: Since the public key can be generated from the private key, it is
+sufficient to store the private key for each key pair.
+
+OpenSSL can be used to generate the needed files kwb_kak.key and kwb_csk.key
+(the names of these files have to be configured, see the next section on
+kwbimage.cfg settings):
+
+openssl genrsa -out kwb_kak.key 2048
+openssl genrsa -out kwb_csk.key 2048
+
+The generated files have to be placed in the U-Boot root directory.
+
+Alternatively, instead of copying the files, symlinks to the private keys can
+be placed in the U-Boot root directory.
+
+WARNING: Knowledge of the KAK or CSK private key would enable an attacker to
+generate secured boot images containing arbitrary code. Hence, the private keys
+should be carefully guarded.
+
+### Create/Modifiy kwbimage.cfg
+
+The Kirkwook architecture in U-Boot employs a special board-specific
+configuration file (kwbimage.cfg), which controls various boot image settings
+that are interpreted by the BootROM, such as the boot medium. The support the
+trusted boot framework, several new options were added to faciliate
+configuration of the secured boot.
+
+The configuration file's layout has been retained, only the following new
+options were added:
+
+		KAK - The name of the KAK RSA private key file in the U-Boot
+                      root directory, without the trailing extension of ".key".
+		CSK - The name of the (active) CSK RSA private key file in the
+		      U-Boot root directory, without the trailing extension of
+		      ".key".
+	     BOX_ID - The BoxID to be used for trusted debugging (a integer
+	              value).
+	   FLASH_ID - The FlashID to be used for trusted debugging (a integer
+	              value).
+	 JTAG_DELAY - The JTAG delay to be used for trusted debugging (a
+	              integer value).
+          CSK_INDEX - The index of the active CSK (a integer value).
+SEC_SPECIALIZED_IMG - Flag to indicate whether to include the BoxID and FlashID
+		      in the image (that is, whether to use the trusted debug
+		      mode or not); no parameters.
+       SEC_BOOT_DEV - The boot device from which the trusted boot is allowed to
+		      proceed, identified via a numeric ID. The tested values
+		      are 0x34 = NOR flash, 0x31 = SDIO/MMC card; for
+		      additional ID values, consult the documentation in [1].
+      SEC_FUSE_DUMP - Dump the "fuse prog" commands necessary for writing the
+		      correct eFuse values to a text file in the U-Boot root
+		      directory. The parameter is the architecture for which to
+		      dump the commands (currently only "a38x" is supported).
+
+The parameter values may be hardcoded into the file, but it is also possible to
+employ a dynamic approach of creating a Autoconf-like kwbimage.cfg.in, then
+reading configuration values from Kconfig options or from the board config
+file, and generating the actual kwbimage.cfg from this template using Makefile
+mechanisms (see board/gdsys/a38x/Makefile as an example for this approach).
+
+### Set config options
+
+To enable the generation of trusted boot images, the corresponding support
+needs to be activated, and a index for the active CSK needs to be selected as
+well.
+
+Furthermore, eFuse writing support has to be activated in order to burn the
+eFuse structure's values (this option is just needed for programming the eFuse
+structure; production boot images may disable it).
+
+ARM architecture
+ -> [*] Build image for trusted boot
+    (0)   Index of active CSK
+ -> [*] Enable eFuse support
+    [ ]   Fake eFuse access (dry run)
+
+### Build and test boot image
+
+The creation of the boot image is done via the usual invocation of make (with a
+suitably set CROSS_COMPILE environment variable, of course). The resulting boot
+image u-boot-spl.kwb can then be tested, if so desired. The hdrparser from [5]
+can be used for this purpose. To build the tool, invoke make in the
+'tools/marvell/doimage_mv' directory of [5], which builds a stand-alone
+hdrparser executable. A test can be conducted by calling hdrparser with the
+produced boot image and the following (mandatory) parameters:
+
+./hdrparser -k 0 -t u-boot-spl.kwb
+
+Here we assume that the CSK index is 0 and the boot image file resides in the
+same directory (adapt accordingly if needed). The tool should report that all
+checksums are valid ("GOOD"), that all signature verifications succeed
+("PASSED"), and, finally, that the overall test was successful
+("T E S T   S U C C E E D E D" in the last line of output).
+
+### Burn eFuse structure
+
++----------------------------------------------------------+
+| WARNING: Burning the eFuse structure is a irreversible   |
+| operation! Should wrong or corrupted values be used, the |
+| board won't boot anymore, and recovery is likely         |
+| impossible!                                              |
++----------------------------------------------------------+
+
+After the build process has finished, and the SEC_FUSE_DUMP option was set in
+the kwbimage.cfg was set, a text file kwb_fuses_a38x.txt should be present in
+the U-Boot top-level directory. It contains all the necessary commands to set
+the eFuse structure to the values needed for the used KAK digest, as well as
+the CSK index, Flash ID and Box ID that were selected in kwbimage.cfg.
+
+Sequentially executing the commands in this file at the U-Boot command prompt
+will write these values to the eFuse structure.
+
+If the SEC_FUSE_DUMP option was not set, the commands needed to burn the fuses
+have to be crafted by hand. The needed fuse lines can be looked up in [1]; a
+rough overview of the process is:
+
+* Burn the KAK public key hash. The hash itself can be found in the file
+  pub_kak_hash.txt in the U-Boot top-level directory; be careful to account for
+  the endianness!
+* Burn the CSK selection, BoxID, and FlashID
+* Enable trusted boot by burning the corresponding fuse (WARNING: this must be
+  the last fuse line written!)
+* Lock the unused fuse lines
+
+The command to employ is the "fuse prog" command previously enabled by setting
+the corresponding configuration option.
+
+For the trusted boot, the fuse prog command has a special syntax, since the
+ARMADA SoC demands that whole fuse lines (64 bit values) have to be written as
+a whole. The fuse prog command itself allows lists of 32 bit words to be
+written at a time, but this is translated to a series of single 32 bit write
+operations to the fuse line, where the individual 32 bit words are identified
+by a "word" counter that is increased for each write.
+
+To work around this restriction, we interpret each line to have three "words"
+(0-2): The first and second words are the values to be written to the fuse
+line, and the third is a lock flag, which is supposed to lock the fuse line
+when set to 1. Writes to the first and second words are memoized between
+function calls, and the fuse line is only really written and locked (on writing
+the third word) if both words were previously set, so that "incomplete" writes
+are prevented. An exception to this is a single write to the third word (index
+2) without previously writing neither the first nor the second word, which
+locks the fuse line without setting any value; this is needed to lock the
+unused fuse lines.
+
+As an example, to write the value 0011223344556677 to fuse line 10, we would
+use the following command:
+
+fuse prog -y 10 0 00112233 44556677 1
+
+Here 10 is the fuse line number, 0 is the index of the first word to be
+written, 00112233 and 44556677 are the values to be written to the fuse line
+(first and second word) and the trailing 1 is the value for the third word
+responsible for locking the line.
+
+A "lock-only" command would look like this:
+
+fuse prog -y 11 2 1
+
+Here 11 is the fuse number, 2 is the index of the first word to be written
+(notice that we only write to word 2 here; the third word for fuse line
+locking), and the 1 is the value for the word we are writing to.
+
+WARNING: According to application note [4], the VHV pin of the SoC must be
+connected to a 1.8V source during eFuse programming, but *must* be disconnected
+for normal operation. The AN [4] describes a software-controlled circuit (based
+on a N-channel or P-channel FET and a free GPIO pin of the SoC) to achieve
+this, but a jumper-based circuit should suffice as well. Regardless of the
+chosen circuit, the issue needs to be addressed accordingly!
+
+7. Work to be done
+------------------
+
+* Add the ability to populate more than one CSK
+* Test secure debug
+* Test on Armada XP
+
+8. Bibliography
+---------------
+
+[1] ARMADA(R) 38x Family High-Performance Single/Dual CPU System on Chip
+    Functional Specification; MV-S109094-00, Rev. C; August 2, 2015,
+    Preliminary
+[2] AN-383: ARMADA(R) 38x Families Secure Boot Mode Support; MV-S302501-00
+    Rev.  A; March 11, 2015, Preliminary
+[3] Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography
+    Specifications Version 2.1; February 2003;
+    https://www.ietf.org/rfc/rfc3447.txt
+[4] AN-389: ARMADA(R) VHV Power; MV-S302545-00 Rev. B; January 28, 2016,
+    Released
+[5] Marvell Armada 38x U-Boot support; November 25, 2015;
+    https://github.com/MarvellEmbeddedProcessors/u-boot-marvell
+
+2017-01-05, Mario Six <mario.six@gdsys.cc>