* [U-Boot] [PATCH v3 1/9] arm: cache: add missing dummy functions for when dcache disabled
2016-06-27 14:19 [U-Boot] [PATCH v3 0/9] Secure Boot by Authenticating/Decrypting SPL FIT blobs Andreas Dannenberg
@ 2016-06-27 14:19 ` Andreas Dannenberg
2016-07-16 13:47 ` [U-Boot] [U-Boot, v3, " Tom Rini
2016-06-27 14:19 ` [U-Boot] [PATCH v3 2/9] arm: omap-common: add secure smc entry Andreas Dannenberg
` (9 subsequent siblings)
10 siblings, 1 reply; 26+ messages in thread
From: Andreas Dannenberg @ 2016-06-27 14:19 UTC (permalink / raw)
To: u-boot
From: Daniel Allred <d-allred@ti.com>
Adds missing flush_dcache_range and invalidate_dcache_range dummy
(empty) placeholder functions to the #else portion of the #ifndef
CONFIG_SYS_DCACHE_OFF, where full implementations of these functions
are defined.
Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
---
arch/arm/cpu/armv7/cache_v7.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/cpu/armv7/cache_v7.c b/arch/arm/cpu/armv7/cache_v7.c
index dc309da..24fe0c5 100644
--- a/arch/arm/cpu/armv7/cache_v7.c
+++ b/arch/arm/cpu/armv7/cache_v7.c
@@ -195,6 +195,14 @@ void flush_dcache_all(void)
{
}
+void invalidate_dcache_range(unsigned long start, unsigned long stop)
+{
+}
+
+void flush_dcache_range(unsigned long start, unsigned long stop)
+{
+}
+
void arm_init_before_mmu(void)
{
}
--
2.6.4
^ permalink raw reply related [flat|nested] 26+ messages in thread* [U-Boot] [PATCH v3 2/9] arm: omap-common: add secure smc entry
2016-06-27 14:19 [U-Boot] [PATCH v3 0/9] Secure Boot by Authenticating/Decrypting SPL FIT blobs Andreas Dannenberg
2016-06-27 14:19 ` [U-Boot] [PATCH v3 1/9] arm: cache: add missing dummy functions for when dcache disabled Andreas Dannenberg
@ 2016-06-27 14:19 ` Andreas Dannenberg
2016-07-16 13:47 ` [U-Boot] [U-Boot, v3, " Tom Rini
2016-06-27 14:19 ` [U-Boot] [PATCH v3 3/9] arm: omap-common: add secure rom call API for secure devices Andreas Dannenberg
` (8 subsequent siblings)
10 siblings, 1 reply; 26+ messages in thread
From: Andreas Dannenberg @ 2016-06-27 14:19 UTC (permalink / raw)
To: u-boot
From: Daniel Allred <d-allred@ti.com>
Add an interface for calling secure ROM APIs across a range of OMAP and
OMAP compatible high-security (HS) device variants. While at it, also
perform minor cleanup/alignment without any change in functionality.
Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
---
arch/arm/cpu/armv7/omap-common/lowlevel_init.S | 45 ++++++++++++++++++++------
arch/arm/include/asm/omap_common.h | 6 ++++
2 files changed, 42 insertions(+), 9 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
index 5283135..66a3b3d 100644
--- a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
@@ -16,9 +16,10 @@
#include <asm/arch/spl.h>
#include <linux/linkage.h>
+.arch_extension sec
+
#ifdef CONFIG_SPL
ENTRY(save_boot_params)
-
ldr r1, =OMAP_SRAM_SCRATCH_BOOT_PARAMS
str r0, [r1]
b save_boot_params_ret
@@ -26,14 +27,40 @@ ENDPROC(save_boot_params)
#endif
ENTRY(omap_smc1)
- PUSH {r4-r12, lr} @ save registers - ROM code may pollute
+ push {r4-r12, lr} @ save registers - ROM code may pollute
@ our registers
- MOV r12, r0 @ Service
- MOV r0, r1 @ Argument
- DSB
- DMB
- .word 0xe1600070 @ SMC #0 - hand assembled for GCC versions
- @ call ROM Code API for the service requested
+ mov r12, r0 @ Service
+ mov r0, r1 @ Argument
- POP {r4-r12, pc}
+ dsb
+ dmb
+ smc 0 @ SMC #0 to enter monitor mode
+ @ call ROM Code API for the service requested
+ pop {r4-r12, pc}
ENDPROC(omap_smc1)
+
+ENTRY(omap_smc_sec)
+ push {r4-r12, lr} @ save registers - ROM code may pollute
+ @ our registers
+ mov r6, #0xFF @ Indicate new Task call
+ mov r12, #0x00 @ Secure Service ID in R12
+
+ dsb
+ dmb
+ smc 0 @ SMC #0 to enter monitor mode
+
+ b omap_smc_sec_end @ exit at end of the service execution
+ nop
+
+ @ In case of IRQ happening in Secure, then ARM will branch here.
+ @ At that moment, IRQ will be pending and ARM will jump to Non Secure
+ @ IRQ handler
+ mov r12, #0xFE
+
+ dsb
+ dmb
+ smc 0 @ SMC #0 to enter monitor mode
+
+omap_smc_sec_end:
+ pop {r4-r12, pc}
+ENDPROC(omap_smc_sec)
diff --git a/arch/arm/include/asm/omap_common.h b/arch/arm/include/asm/omap_common.h
index 07f3848..605c549 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -627,6 +627,12 @@ void recalibrate_iodelay(void);
void omap_smc1(u32 service, u32 val);
+/*
+ * Low-level helper function used when performing secure ROM calls on high-
+ * security (HS) device variants by doing a specially-formed smc entry.
+ */
+u32 omap_smc_sec(u32 service, u32 proc_id, u32 flag, u32 *params);
+
void enable_edma3_clocks(void);
void disable_edma3_clocks(void);
--
2.6.4
^ permalink raw reply related [flat|nested] 26+ messages in thread* [U-Boot] [PATCH v3 3/9] arm: omap-common: add secure rom call API for secure devices
2016-06-27 14:19 [U-Boot] [PATCH v3 0/9] Secure Boot by Authenticating/Decrypting SPL FIT blobs Andreas Dannenberg
2016-06-27 14:19 ` [U-Boot] [PATCH v3 1/9] arm: cache: add missing dummy functions for when dcache disabled Andreas Dannenberg
2016-06-27 14:19 ` [U-Boot] [PATCH v3 2/9] arm: omap-common: add secure smc entry Andreas Dannenberg
@ 2016-06-27 14:19 ` Andreas Dannenberg
2016-07-16 13:47 ` [U-Boot] [U-Boot, v3, " Tom Rini
2016-06-27 14:19 ` [U-Boot] [PATCH v3 4/9] arm: omap-common: secure ROM signature verify API Andreas Dannenberg
` (7 subsequent siblings)
10 siblings, 1 reply; 26+ messages in thread
From: Andreas Dannenberg @ 2016-06-27 14:19 UTC (permalink / raw)
To: u-boot
Adds a generic C-callable API for making secure ROM calls on OMAP and
OMAP-compatible devices. This API provides the important function of
flushing the ROM call arguments to memory from the cache, so that the
secure world will have a coherent view of those arguments. Then is
simply calls the omap_smc_sec routine.
Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
---
arch/arm/cpu/armv7/omap-common/Makefile | 2 ++
arch/arm/cpu/armv7/omap-common/sec-common.c | 51 +++++++++++++++++++++++++++++
arch/arm/include/asm/omap_sec_common.h | 21 ++++++++++++
3 files changed, 74 insertions(+)
create mode 100644 arch/arm/cpu/armv7/omap-common/sec-common.c
create mode 100644 arch/arm/include/asm/omap_sec_common.h
diff --git a/arch/arm/cpu/armv7/omap-common/Makefile b/arch/arm/cpu/armv7/omap-common/Makefile
index 87a7ac0..3172bae 100644
--- a/arch/arm/cpu/armv7/omap-common/Makefile
+++ b/arch/arm/cpu/armv7/omap-common/Makefile
@@ -36,3 +36,5 @@ obj-y += boot-common.o
obj-y += lowlevel_init.o
obj-y += mem-common.o
+
+obj-$(CONFIG_TI_SECURE_DEVICE) += sec-common.o
diff --git a/arch/arm/cpu/armv7/omap-common/sec-common.c b/arch/arm/cpu/armv7/omap-common/sec-common.c
new file mode 100644
index 0000000..4ec736f
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap-common/sec-common.c
@@ -0,0 +1,51 @@
+/*
+ *
+ * Common security related functions for OMAP devices
+ *
+ * (C) Copyright 2016
+ * Texas Instruments, <www.ti.com>
+ *
+ * Daniel Allred <d-allred@ti.com>
+ * Andreas Dannenberg <dannenberg@ti.com>
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include <common.h>
+#include <stdarg.h>
+
+#include <asm/arch/sys_proto.h>
+#include <asm/omap_common.h>
+#include <asm/omap_sec_common.h>
+
+static uint32_t secure_rom_call_args[5] __aligned(ARCH_DMA_MINALIGN);
+
+u32 secure_rom_call(u32 service, u32 proc_id, u32 flag, ...)
+{
+ int i;
+ u32 num_args;
+ va_list ap;
+
+ va_start(ap, flag);
+
+ num_args = va_arg(ap, u32);
+
+ if (num_args > 4)
+ return 1;
+
+ /* Copy args to aligned args structure */
+ for (i = 0; i < num_args; i++)
+ secure_rom_call_args[i + 1] = va_arg(ap, u32);
+
+ secure_rom_call_args[0] = num_args;
+
+ va_end(ap);
+
+ /* if data cache is enabled, flush the aligned args structure */
+ flush_dcache_range(
+ (unsigned int)&secure_rom_call_args[0],
+ (unsigned int)&secure_rom_call_args[0] +
+ roundup(sizeof(secure_rom_call_args), ARCH_DMA_MINALIGN));
+
+ return omap_smc_sec(service, proc_id, flag, secure_rom_call_args);
+}
diff --git a/arch/arm/include/asm/omap_sec_common.h b/arch/arm/include/asm/omap_sec_common.h
new file mode 100644
index 0000000..1f50f83
--- /dev/null
+++ b/arch/arm/include/asm/omap_sec_common.h
@@ -0,0 +1,21 @@
+/*
+ * (C) Copyright 2016
+ * Texas Instruments, <www.ti.com>
+ *
+ * Andreas Dannenberg <dannenberg@ti.com>
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+#ifndef _OMAP_SEC_COMMON_H_
+#define _OMAP_SEC_COMMON_H_
+
+#include <common.h>
+
+/*
+ * Invoke secure ROM API on high-security (HS) device variants. It formats
+ * the variable argument list into the format expected by the ROM code before
+ * triggering the actual low-level smc entry.
+ */
+u32 secure_rom_call(u32 service, u32 proc_id, u32 flag, ...);
+
+#endif /* _OMAP_SEC_COMMON_H_ */
--
2.6.4
^ permalink raw reply related [flat|nested] 26+ messages in thread* [U-Boot] [PATCH v3 4/9] arm: omap-common: secure ROM signature verify API
2016-06-27 14:19 [U-Boot] [PATCH v3 0/9] Secure Boot by Authenticating/Decrypting SPL FIT blobs Andreas Dannenberg
` (2 preceding siblings ...)
2016-06-27 14:19 ` [U-Boot] [PATCH v3 3/9] arm: omap-common: add secure rom call API for secure devices Andreas Dannenberg
@ 2016-06-27 14:19 ` Andreas Dannenberg
2016-07-16 13:47 ` [U-Boot] [U-Boot, v3, " Tom Rini
2016-06-27 14:19 ` [U-Boot] [PATCH v3 5/9] arm: omap-common: Update to generate secure U-Boot FIT blob Andreas Dannenberg
` (6 subsequent siblings)
10 siblings, 1 reply; 26+ messages in thread
From: Andreas Dannenberg @ 2016-06-27 14:19 UTC (permalink / raw)
To: u-boot
Adds an API that verifies a signature attached to an image (binary
blob). This API is basically a entry to a secure ROM service provided by
the device and accessed via an SMC call, using a particular calling
convention.
Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
---
arch/arm/cpu/armv7/omap-common/sec-common.c | 88 +++++++++++++++++++++++++++++
arch/arm/include/asm/omap_sec_common.h | 9 +++
2 files changed, 97 insertions(+)
diff --git a/arch/arm/cpu/armv7/omap-common/sec-common.c b/arch/arm/cpu/armv7/omap-common/sec-common.c
index 4ec736f..246a239 100644
--- a/arch/arm/cpu/armv7/omap-common/sec-common.c
+++ b/arch/arm/cpu/armv7/omap-common/sec-common.c
@@ -17,6 +17,11 @@
#include <asm/arch/sys_proto.h>
#include <asm/omap_common.h>
#include <asm/omap_sec_common.h>
+#include <asm/spl.h>
+#include <spl.h>
+
+/* Index for signature verify ROM API */
+#define API_HAL_KM_VERIFYCERTIFICATESIGNATURE_INDEX (0x0000000E)
static uint32_t secure_rom_call_args[5] __aligned(ARCH_DMA_MINALIGN);
@@ -49,3 +54,86 @@ u32 secure_rom_call(u32 service, u32 proc_id, u32 flag, ...)
return omap_smc_sec(service, proc_id, flag, secure_rom_call_args);
}
+
+static u32 find_sig_start(char *image, size_t size)
+{
+ char *image_end = image + size;
+ char *sig_start_magic = "CERT_";
+ int magic_str_len = strlen(sig_start_magic);
+ char *ch;
+
+ while (--image_end > image) {
+ if (*image_end == '_') {
+ ch = image_end - magic_str_len + 1;
+ if (!strncmp(ch, sig_start_magic, magic_str_len))
+ return (u32)ch;
+ }
+ }
+ return 0;
+}
+
+int secure_boot_verify_image(void **image, size_t *size)
+{
+ int result = 1;
+ u32 cert_addr, sig_addr;
+ size_t cert_size;
+
+ /* Perform cache writeback on input buffer */
+ flush_dcache_range(
+ (u32)*image,
+ (u32)*image + roundup(*size, ARCH_DMA_MINALIGN));
+
+ cert_addr = (uint32_t)*image;
+ sig_addr = find_sig_start((char *)*image, *size);
+
+ if (sig_addr == 0) {
+ printf("No signature found in image!\n");
+ result = 1;
+ goto auth_exit;
+ }
+
+ *size = sig_addr - cert_addr; /* Subtract out the signature size */
+ cert_size = *size;
+
+ /* Check if image load address is 32-bit aligned */
+ if (!IS_ALIGNED(cert_addr, 4)) {
+ printf("Image is not 4-byte aligned!\n");
+ result = 1;
+ goto auth_exit;
+ }
+
+ /* Image size also should be multiple of 4 */
+ if (!IS_ALIGNED(cert_size, 4)) {
+ printf("Image size is not 4-byte aligned!\n");
+ result = 1;
+ goto auth_exit;
+ }
+
+ /* Call ROM HAL API to verify certificate signature */
+ debug("%s: load_addr = %x, size = %x, sig_addr = %x\n", __func__,
+ cert_addr, cert_size, sig_addr);
+
+ result = secure_rom_call(
+ API_HAL_KM_VERIFYCERTIFICATESIGNATURE_INDEX, 0, 0,
+ 4, cert_addr, cert_size, sig_addr, 0xFFFFFFFF);
+auth_exit:
+ if (result != 0) {
+ printf("Authentication failed!\n");
+ printf("Return Value = %08X\n", result);
+ hang();
+ }
+
+ /*
+ * Output notification of successful authentication as well the name of
+ * the signing certificate used to re-assure the user that the secure
+ * code is being processed as expected. However suppress any such log
+ * output in case of building for SPL and booting via YMODEM. This is
+ * done to avoid disturbing the YMODEM serial protocol transactions.
+ */
+ if (!(IS_ENABLED(CONFIG_SPL_BUILD) &&
+ IS_ENABLED(CONFIG_SPL_YMODEM_SUPPORT) &&
+ spl_boot_device() == BOOT_DEVICE_UART))
+ printf("Authentication passed: %s\n", (char *)sig_addr);
+
+ return result;
+}
diff --git a/arch/arm/include/asm/omap_sec_common.h b/arch/arm/include/asm/omap_sec_common.h
index 1f50f83..842f2af 100644
--- a/arch/arm/include/asm/omap_sec_common.h
+++ b/arch/arm/include/asm/omap_sec_common.h
@@ -18,4 +18,13 @@
*/
u32 secure_rom_call(u32 service, u32 proc_id, u32 flag, ...);
+/*
+ * Invoke a secure ROM API on high-secure (HS) device variants that can be used
+ * to verify a secure blob by authenticating and optionally decrypting it. The
+ * exact operation performed depends on how the certificate that was embedded
+ * into the blob during the signing/encryption step when the secure blob was
+ * first created.
+ */
+int secure_boot_verify_image(void **p_image, size_t *p_size);
+
#endif /* _OMAP_SEC_COMMON_H_ */
--
2.6.4
^ permalink raw reply related [flat|nested] 26+ messages in thread* [U-Boot] [PATCH v3 5/9] arm: omap-common: Update to generate secure U-Boot FIT blob
2016-06-27 14:19 [U-Boot] [PATCH v3 0/9] Secure Boot by Authenticating/Decrypting SPL FIT blobs Andreas Dannenberg
` (3 preceding siblings ...)
2016-06-27 14:19 ` [U-Boot] [PATCH v3 4/9] arm: omap-common: secure ROM signature verify API Andreas Dannenberg
@ 2016-06-27 14:19 ` Andreas Dannenberg
2016-07-16 13:47 ` [U-Boot] [U-Boot, v3, " Tom Rini
2016-06-27 14:19 ` [U-Boot] [PATCH v3 6/9] spl: fit: add support for post-processing of images Andreas Dannenberg
` (5 subsequent siblings)
10 siblings, 1 reply; 26+ messages in thread
From: Andreas Dannenberg @ 2016-06-27 14:19 UTC (permalink / raw)
To: u-boot
Adds commands so that when a secure device is in use and the SPL is
built to load a FIT image (with combined U-Boot binary and various
DTBs), these components that get fed into the FIT are all processed to
be signed/encrypted/etc. as per the operations performed by the
secure-binary-image.sh script of the TI SECDEV package. Furthermore,
perform minor comments cleanup to make better use of the available
space.
Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
arch/arm/cpu/armv7/omap-common/config_secure.mk | 75 ++++++++++++++++++++-----
1 file changed, 61 insertions(+), 14 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/config_secure.mk b/arch/arm/cpu/armv7/omap-common/config_secure.mk
index c7bb101..1122439 100644
--- a/arch/arm/cpu/armv7/omap-common/config_secure.mk
+++ b/arch/arm/cpu/armv7/omap-common/config_secure.mk
@@ -12,8 +12,8 @@ cmd_mkomapsecimg = $(TI_SECURE_DEV_PKG)/scripts/create-boot-image.sh \
$(if $(KBUILD_VERBOSE:1=), >/dev/null)
else
cmd_mkomapsecimg = $(TI_SECURE_DEV_PKG)/scripts/create-boot-image.sh \
- $(patsubst u-boot_HS_%,%,$(@F)) $< $@ $(CONFIG_ISW_ENTRY_ADDR) \
- $(if $(KBUILD_VERBOSE:1=), >/dev/null)
+ $(patsubst u-boot_HS_%,%,$(@F)) $< $@ $(CONFIG_ISW_ENTRY_ADDR) \
+ $(if $(KBUILD_VERBOSE:1=), >/dev/null)
endif
else
cmd_mkomapsecimg = echo "WARNING:" \
@@ -25,14 +25,33 @@ cmd_mkomapsecimg = echo "WARNING: TI_SECURE_DEV_PKG environment" \
"variable must be defined for TI secure devices. $@ was NOT created!"
endif
+ifdef CONFIG_SPL_LOAD_FIT
+quiet_cmd_omapsecureimg = SECURE $@
+ifneq ($(TI_SECURE_DEV_PKG),)
+ifneq ($(wildcard $(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh),)
+cmd_omapsecureimg = $(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh \
+ $< $@ \
+ $(if $(KBUILD_VERBOSE:1=), >/dev/null)
+else
+cmd_omapsecureimg = echo "WARNING:" \
+ "$(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh not found." \
+ "$@ was NOT created!"; cp $< $@
+endif
+else
+cmd_omapsecureimg = echo "WARNING: TI_SECURE_DEV_PKG environment" \
+ "variable must be defined for TI secure devices." \
+ "$@ was NOT created!"; cp $< $@
+endif
+endif
+
+
# Standard X-LOADER target (QPSI, NOR flash)
u-boot-spl_HS_X-LOADER: $(obj)/u-boot-spl.bin
$(call if_changed,mkomapsecimg)
-# For MLO targets (SD card boot) the final file name
-# that is copied to the SD card fAT partition must
-# be MLO, so we make a copy of the output file to a
-# new file with that name
+# For MLO targets (SD card boot) the final file name that is copied to the SD
+# card FAT partition must be MLO, so we make a copy of the output file to a new
+# file with that name
u-boot-spl_HS_MLO: $(obj)/u-boot-spl.bin
$(call if_changed,mkomapsecimg)
@if [ -f $@ ]; then \
@@ -51,16 +70,44 @@ u-boot-spl_HS_ULO: $(obj)/u-boot-spl.bin
u-boot-spl_HS_ISSW: $(obj)/u-boot-spl.bin
$(call if_changed,mkomapsecimg)
-# For SPI flash on AM335x and AM43xx, these
-# require special byte swap handling so we use
-# the SPI_X-LOADER target instead of X-LOADER
-# and let the create-boot-image.sh script handle
-# that
+# For SPI flash on AM335x and AM43xx, these require special byte swap handling
+# so we use the SPI_X-LOADER target instead of X-LOADER and let the
+# create-boot-image.sh script handle that
u-boot-spl_HS_SPI_X-LOADER: $(obj)/u-boot-spl.bin
$(call if_changed,mkomapsecimg)
-# For supporting single stage XiP QSPI on AM43xx, the
-# image is a full u-boot file, not an SPL. In this case
-# the mkomapsecimg command looks for a u-boot-HS_* prefix
+# For supporting single stage XiP QSPI on AM43xx, the image is a full u-boot
+# file, not an SPL. In this case the mkomapsecimg command looks for a
+# u-boot-HS_* prefix
u-boot_HS_XIP_X-LOADER: $(obj)/u-boot.bin
$(call if_changed,mkomapsecimg)
+
+# For supporting the SPL loading and interpreting of FIT images whose
+# components are pre-processed before being integrated into the FIT image in
+# order to secure them in some way
+ifdef CONFIG_SPL_LOAD_FIT
+
+MKIMAGEFLAGS_u-boot_HS.img = -f auto -A $(ARCH) -T firmware -C none -O u-boot \
+ -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \
+ -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" -E \
+ $(patsubst %,-b arch/$(ARCH)/dts/%.dtb,$(subst ",,$(CONFIG_OF_LIST)))
+
+OF_LIST_TARGETS = $(patsubst %,arch/$(ARCH)/dts/%.dtb,$(subst ",,$(CONFIG_OF_LIST)))
+$(OF_LIST_TARGETS): dtbs
+
+%_HS.dtb: %.dtb
+ $(call if_changed,omapsecureimg)
+ $(Q)if [ -f $@ ]; then \
+ cp -f $@ $<; \
+ fi
+
+u-boot-nodtb_HS.bin: u-boot-nodtb.bin
+ $(call if_changed,omapsecureimg)
+
+u-boot_HS.img: u-boot-nodtb_HS.bin u-boot.img $(patsubst %.dtb,%_HS.dtb,$(OF_LIST_TARGETS))
+ $(call if_changed,mkimage)
+ $(Q)if [ -f $@ ]; then \
+ cp -f $@ u-boot.img; \
+ fi
+
+endif
--
2.6.4
^ permalink raw reply related [flat|nested] 26+ messages in thread* [U-Boot] [PATCH v3 6/9] spl: fit: add support for post-processing of images
2016-06-27 14:19 [U-Boot] [PATCH v3 0/9] Secure Boot by Authenticating/Decrypting SPL FIT blobs Andreas Dannenberg
` (4 preceding siblings ...)
2016-06-27 14:19 ` [U-Boot] [PATCH v3 5/9] arm: omap-common: Update to generate secure U-Boot FIT blob Andreas Dannenberg
@ 2016-06-27 14:19 ` Andreas Dannenberg
2016-06-29 3:28 ` Simon Glass
2016-07-16 13:47 ` [U-Boot] [U-Boot, v3, " Tom Rini
2016-06-27 14:19 ` [U-Boot] [PATCH v3 7/9] arm: omap5: add U-Boot FIT signing and SPL image post-processing Andreas Dannenberg
` (4 subsequent siblings)
10 siblings, 2 replies; 26+ messages in thread
From: Andreas Dannenberg @ 2016-06-27 14:19 UTC (permalink / raw)
To: u-boot
From: Daniel Allred <d-allred@ti.com>
The next stage boot loader image and the selected FDT can be post-
processed by board/platform/device-specific code, which can include
modifying the size and altering the starting source address before
copying these binary blobs to their final destination. This might be
desired to do things like strip headers or footers attached to the
images before they were packaged into the FIT, or to perform operations
such as decryption or authentication. Introduce new configuration
option CONFIG_SPL_FIT_IMAGE_POST_PROCESS to allow controlling this
feature. If enabled, a platform-specific post-process function must
be provided.
Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
---
Kconfig | 14 ++++++++++++++
common/spl/spl_fit.c | 21 ++++++++++++++++-----
include/image.h | 17 +++++++++++++++++
3 files changed, 47 insertions(+), 5 deletions(-)
diff --git a/Kconfig b/Kconfig
index 3ceff25..2afbaaf 100644
--- a/Kconfig
+++ b/Kconfig
@@ -313,6 +313,20 @@ config SPL_LOAD_FIT
particular it can handle selecting from multiple device tree
and passing the correct one to U-Boot.
+config SPL_FIT_IMAGE_POST_PROCESS
+ bool "Enable post-processing of FIT artifacts after loading by the SPL"
+ depends on SPL_LOAD_FIT && TI_SECURE_DEVICE
+ help
+ Allows doing any sort of manipulation to blobs after they got extracted
+ from the U-Boot FIT image like stripping off headers or modifying the
+ size of the blob, verification, authentication, decryption etc. in a
+ platform or board specific way. In order to use this feature a platform
+ or board-specific implementation of board_fit_image_post_process() must
+ be provided. Also, anything done during this post-processing step would
+ need to be comprehended in how the images were prepared before being
+ injected into the FIT creation (i.e. the blobs would have been pre-
+ processed before being added to the FIT image).
+
config SYS_CLK_FREQ
depends on ARC || ARCH_SUNXI
int "CPU clock frequency"
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 9874708..069e94d 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -132,7 +132,7 @@ int spl_load_simple_fit(struct spl_load_info *info, ulong sector, void *fit)
int data_offset, data_size;
int base_offset, align_len = ARCH_DMA_MINALIGN - 1;
int src_sector;
- void *dst;
+ void *dst, *src;
/*
* Figure out where the external images start. This is the base for the
@@ -206,8 +206,13 @@ int spl_load_simple_fit(struct spl_load_info *info, ulong sector, void *fit)
return -EIO;
debug("image: dst=%p, data_offset=%x, size=%x\n", dst, data_offset,
data_size);
- memcpy(dst, dst + get_aligned_image_overhead(info, data_offset),
- data_size);
+ src = dst + get_aligned_image_overhead(info, data_offset);
+
+#ifdef CONFIG_SPL_FIT_IMAGE_POST_PROCESS
+ board_fit_image_post_process((void **)&src, (size_t *)&data_size);
+#endif
+
+ memcpy(dst, src, data_size);
/* Figure out which device tree the board wants to use */
fdt_len = spl_fit_select_fdt(fit, images, &fdt_offset);
@@ -236,8 +241,14 @@ int spl_load_simple_fit(struct spl_load_info *info, ulong sector, void *fit)
*/
debug("fdt: dst=%p, data_offset=%x, size=%x\n", dst, fdt_offset,
fdt_len);
- memcpy(load_ptr + data_size,
- dst + get_aligned_image_overhead(info, fdt_offset), fdt_len);
+ src = dst + get_aligned_image_overhead(info, fdt_offset);
+ dst = load_ptr + data_size;
+
+#ifdef CONFIG_SPL_FIT_IMAGE_POST_PROCESS
+ board_fit_image_post_process((void **)&src, (size_t *)&fdt_len);
+#endif
+
+ memcpy(dst, src, fdt_len);
return 0;
}
diff --git a/include/image.h b/include/image.h
index d788c26..93d39e1 100644
--- a/include/image.h
+++ b/include/image.h
@@ -1173,4 +1173,21 @@ void android_print_contents(const struct andr_img_hdr *hdr);
*/
int board_fit_config_name_match(const char *name);
+#ifdef CONFIG_SPL_FIT_IMAGE_POST_PROCESS
+/**
+ * board_fit_image_post_process() - Do any post-process on FIT binary data
+ *
+ * This is used to do any sort of image manipulation, verification, decryption
+ * etc. in a platform or board specific way. Obviously, anything done here would
+ * need to be comprehended in how the images were prepared before being injected
+ * into the FIT creation (i.e. the binary blobs would have been pre-processed
+ * before being added to the FIT image).
+ *
+ * @image: pointer to the image start pointer
+ * @size: pointer to the image size
+ * @return no return value (failure should be handled internally)
+ */
+void board_fit_image_post_process(void **p_image, size_t *p_size);
+#endif /* CONFIG_SPL_FIT_IMAGE_POST_PROCESS */
+
#endif /* __IMAGE_H__ */
--
2.6.4
^ permalink raw reply related [flat|nested] 26+ messages in thread* [U-Boot] [PATCH v3 6/9] spl: fit: add support for post-processing of images
2016-06-27 14:19 ` [U-Boot] [PATCH v3 6/9] spl: fit: add support for post-processing of images Andreas Dannenberg
@ 2016-06-29 3:28 ` Simon Glass
2016-06-29 14:19 ` Andreas Dannenberg
2016-07-16 13:47 ` [U-Boot] [U-Boot, v3, " Tom Rini
1 sibling, 1 reply; 26+ messages in thread
From: Simon Glass @ 2016-06-29 3:28 UTC (permalink / raw)
To: u-boot
On 27 June 2016 at 07:19, Andreas Dannenberg <dannenberg@ti.com> wrote:
> From: Daniel Allred <d-allred@ti.com>
>
> The next stage boot loader image and the selected FDT can be post-
> processed by board/platform/device-specific code, which can include
> modifying the size and altering the starting source address before
> copying these binary blobs to their final destination. This might be
> desired to do things like strip headers or footers attached to the
> images before they were packaged into the FIT, or to perform operations
> such as decryption or authentication. Introduce new configuration
> option CONFIG_SPL_FIT_IMAGE_POST_PROCESS to allow controlling this
> feature. If enabled, a platform-specific post-process function must
> be provided.
>
> Signed-off-by: Daniel Allred <d-allred@ti.com>
> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
> Reviewed-by: Tom Rini <trini@konsulko.com>
> ---
> Kconfig | 14 ++++++++++++++
> common/spl/spl_fit.c | 21 ++++++++++++++++-----
> include/image.h | 17 +++++++++++++++++
> 3 files changed, 47 insertions(+), 5 deletions(-)
Reviewed-by: Simon Glass <sjg@chromium.org>
Nit below in case you do a new version.
>
> diff --git a/Kconfig b/Kconfig
> index 3ceff25..2afbaaf 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -313,6 +313,20 @@ config SPL_LOAD_FIT
> particular it can handle selecting from multiple device tree
> and passing the correct one to U-Boot.
>
> +config SPL_FIT_IMAGE_POST_PROCESS
> + bool "Enable post-processing of FIT artifacts after loading by the SPL"
> + depends on SPL_LOAD_FIT && TI_SECURE_DEVICE
> + help
> + Allows doing any sort of manipulation to blobs after they got extracted
> + from the U-Boot FIT image like stripping off headers or modifying the
> + size of the blob, verification, authentication, decryption etc. in a
> + platform or board specific way. In order to use this feature a platform
> + or board-specific implementation of board_fit_image_post_process() must
> + be provided. Also, anything done during this post-processing step would
> + need to be comprehended in how the images were prepared before being
> + injected into the FIT creation (i.e. the blobs would have been pre-
> + processed before being added to the FIT image).
> +
> config SYS_CLK_FREQ
> depends on ARC || ARCH_SUNXI
> int "CPU clock frequency"
> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> index 9874708..069e94d 100644
> --- a/common/spl/spl_fit.c
> +++ b/common/spl/spl_fit.c
> @@ -132,7 +132,7 @@ int spl_load_simple_fit(struct spl_load_info *info, ulong sector, void *fit)
> int data_offset, data_size;
> int base_offset, align_len = ARCH_DMA_MINALIGN - 1;
> int src_sector;
> - void *dst;
> + void *dst, *src;
>
> /*
> * Figure out where the external images start. This is the base for the
> @@ -206,8 +206,13 @@ int spl_load_simple_fit(struct spl_load_info *info, ulong sector, void *fit)
> return -EIO;
> debug("image: dst=%p, data_offset=%x, size=%x\n", dst, data_offset,
> data_size);
> - memcpy(dst, dst + get_aligned_image_overhead(info, data_offset),
> - data_size);
> + src = dst + get_aligned_image_overhead(info, data_offset);
> +
> +#ifdef CONFIG_SPL_FIT_IMAGE_POST_PROCESS
> + board_fit_image_post_process((void **)&src, (size_t *)&data_size);
> +#endif
> +
> + memcpy(dst, src, data_size);
>
> /* Figure out which device tree the board wants to use */
> fdt_len = spl_fit_select_fdt(fit, images, &fdt_offset);
> @@ -236,8 +241,14 @@ int spl_load_simple_fit(struct spl_load_info *info, ulong sector, void *fit)
> */
> debug("fdt: dst=%p, data_offset=%x, size=%x\n", dst, fdt_offset,
> fdt_len);
> - memcpy(load_ptr + data_size,
> - dst + get_aligned_image_overhead(info, fdt_offset), fdt_len);
> + src = dst + get_aligned_image_overhead(info, fdt_offset);
> + dst = load_ptr + data_size;
> +
> +#ifdef CONFIG_SPL_FIT_IMAGE_POST_PROCESS
> + board_fit_image_post_process((void **)&src, (size_t *)&fdt_len);
> +#endif
> +
> + memcpy(dst, src, fdt_len);
>
> return 0;
> }
> diff --git a/include/image.h b/include/image.h
> index d788c26..93d39e1 100644
> --- a/include/image.h
> +++ b/include/image.h
> @@ -1173,4 +1173,21 @@ void android_print_contents(const struct andr_img_hdr *hdr);
> */
> int board_fit_config_name_match(const char *name);
>
> +#ifdef CONFIG_SPL_FIT_IMAGE_POST_PROCESS
> +/**
> + * board_fit_image_post_process() - Do any post-process on FIT binary data
> + *
> + * This is used to do any sort of image manipulation, verification, decryption
> + * etc. in a platform or board specific way. Obviously, anything done here would
> + * need to be comprehended in how the images were prepared before being injected
> + * into the FIT creation (i.e. the binary blobs would have been pre-processed
> + * before being added to the FIT image).
> + *
> + * @image: pointer to the image start pointer
> + * @size: pointer to the image size
> + * @return no return value (failure should be handled internally)
> + */
> +void board_fit_image_post_process(void **p_image, size_t *p_size);
> +#endif /* CONFIG_SPL_FIT_IMAGE_POST_PROCESS */
We don't need #ifdef in header files - it just makes the code harder
to read, and we'll still get a build error (with correct line number
info) if someone uses it when they should not.
> +
> #endif /* __IMAGE_H__ */
> --
> 2.6.4
>
Regards,
Simon
^ permalink raw reply [flat|nested] 26+ messages in thread* [U-Boot] [PATCH v3 6/9] spl: fit: add support for post-processing of images
2016-06-29 3:28 ` Simon Glass
@ 2016-06-29 14:19 ` Andreas Dannenberg
0 siblings, 0 replies; 26+ messages in thread
From: Andreas Dannenberg @ 2016-06-29 14:19 UTC (permalink / raw)
To: u-boot
Hi Simon, please see below...
On Tue, Jun 28, 2016 at 08:28:07PM -0700, Simon Glass wrote:
> On 27 June 2016 at 07:19, Andreas Dannenberg <dannenberg@ti.com> wrote:
> > diff --git a/include/image.h b/include/image.h
> > index d788c26..93d39e1 100644
> > --- a/include/image.h
> > +++ b/include/image.h
> > @@ -1173,4 +1173,21 @@ void android_print_contents(const struct andr_img_hdr *hdr);
> > */
> > int board_fit_config_name_match(const char *name);
> >
> > +#ifdef CONFIG_SPL_FIT_IMAGE_POST_PROCESS
> > +/**
> > + * board_fit_image_post_process() - Do any post-process on FIT binary data
> > + *
> > + * This is used to do any sort of image manipulation, verification, decryption
> > + * etc. in a platform or board specific way. Obviously, anything done here would
> > + * need to be comprehended in how the images were prepared before being injected
> > + * into the FIT creation (i.e. the binary blobs would have been pre-processed
> > + * before being added to the FIT image).
> > + *
> > + * @image: pointer to the image start pointer
> > + * @size: pointer to the image size
> > + * @return no return value (failure should be handled internally)
> > + */
> > +void board_fit_image_post_process(void **p_image, size_t *p_size);
> > +#endif /* CONFIG_SPL_FIT_IMAGE_POST_PROCESS */
>
> We don't need #ifdef in header files - it just makes the code harder
> to read, and we'll still get a build error (with correct line number
> info) if someone uses it when they should not.
You are right that's technically not needed, but rather I was following
how other prototypes are defined in that header file (like the ones that
get declared when CONFIG_ANDROID_BOOT_IMAGE is defined).
For now I'm not planning to re-spin the patch series, but if there is
additional feedback I can take care of this one as well.
Thanks and Regards,
--
Andreas Dannenberg
Texas Instruments Inc
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [U-Boot, v3, 6/9] spl: fit: add support for post-processing of images
2016-06-27 14:19 ` [U-Boot] [PATCH v3 6/9] spl: fit: add support for post-processing of images Andreas Dannenberg
2016-06-29 3:28 ` Simon Glass
@ 2016-07-16 13:47 ` Tom Rini
1 sibling, 0 replies; 26+ messages in thread
From: Tom Rini @ 2016-07-16 13:47 UTC (permalink / raw)
To: u-boot
On Mon, Jun 27, 2016 at 09:19:21AM -0500, Andreas Dannenberg wrote:
> From: Daniel Allred <d-allred@ti.com>
>
> The next stage boot loader image and the selected FDT can be post-
> processed by board/platform/device-specific code, which can include
> modifying the size and altering the starting source address before
> copying these binary blobs to their final destination. This might be
> desired to do things like strip headers or footers attached to the
> images before they were packaged into the FIT, or to perform operations
> such as decryption or authentication. Introduce new configuration
> option CONFIG_SPL_FIT_IMAGE_POST_PROCESS to allow controlling this
> feature. If enabled, a platform-specific post-process function must
> be provided.
>
> Signed-off-by: Daniel Allred <d-allred@ti.com>
> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
> Reviewed-by: Tom Rini <trini@konsulko.com>
> Reviewed-by: Simon Glass <sjg@chromium.org>
Applied to u-boot/master, thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160716/39a82a66/attachment.sig>
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH v3 7/9] arm: omap5: add U-Boot FIT signing and SPL image post-processing
2016-06-27 14:19 [U-Boot] [PATCH v3 0/9] Secure Boot by Authenticating/Decrypting SPL FIT blobs Andreas Dannenberg
` (5 preceding siblings ...)
2016-06-27 14:19 ` [U-Boot] [PATCH v3 6/9] spl: fit: add support for post-processing of images Andreas Dannenberg
@ 2016-06-27 14:19 ` Andreas Dannenberg
2016-07-16 13:47 ` [U-Boot] [U-Boot, v3, " Tom Rini
2016-06-27 14:19 ` [U-Boot] [PATCH v3 8/9] arm: am4x: " Andreas Dannenberg
` (3 subsequent siblings)
10 siblings, 1 reply; 26+ messages in thread
From: Andreas Dannenberg @ 2016-06-27 14:19 UTC (permalink / raw)
To: u-boot
Modify the SPL build procedure for AM57xx and DRA7xx high-security (HS)
device variants to create a secure u-boot_HS.img FIT blob that contains
U-Boot and DTB artifacts signed with a TI-specific process based on the
CONFIG_TI_SECURE_DEVICE config option and the externally-provided image
signing tool.
Also populate the corresponding FIT image post processing call to be
performed during SPL runtime.
Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
---
arch/arm/cpu/armv7/omap5/config.mk | 3 +++
board/ti/am57xx/board.c | 8 ++++++++
board/ti/dra7xx/evm.c | 9 +++++++++
configs/am57xx_hs_evm_defconfig | 1 +
configs/dra7xx_hs_evm_defconfig | 1 +
5 files changed, 22 insertions(+)
diff --git a/arch/arm/cpu/armv7/omap5/config.mk b/arch/arm/cpu/armv7/omap5/config.mk
index a7e55a5..d245572 100644
--- a/arch/arm/cpu/armv7/omap5/config.mk
+++ b/arch/arm/cpu/armv7/omap5/config.mk
@@ -15,5 +15,8 @@ else
ALL-y += MLO
endif
else
+ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
+ALL-y += u-boot_HS.img
+endif
ALL-y += u-boot.img
endif
diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
index 08cf14d..927d136 100644
--- a/board/ti/am57xx/board.c
+++ b/board/ti/am57xx/board.c
@@ -13,6 +13,7 @@
#include <sata.h>
#include <usb.h>
#include <asm/omap_common.h>
+#include <asm/omap_sec_common.h>
#include <asm/emif.h>
#include <asm/gpio.h>
#include <asm/arch/gpio.h>
@@ -750,3 +751,10 @@ int board_fit_config_name_match(const char *name)
return -1;
}
#endif
+
+#ifdef CONFIG_TI_SECURE_DEVICE
+void board_fit_image_post_process(void **p_image, size_t *p_size)
+{
+ secure_boot_verify_image(p_image, p_size);
+}
+#endif
diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index 0394e4e..f9382b8 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -17,6 +17,8 @@
#include <asm/gpio.h>
#include <usb.h>
#include <linux/usb/gadget.h>
+#include <asm/omap_common.h>
+#include <asm/omap_sec_common.h>
#include <asm/arch/gpio.h>
#include <asm/arch/dra7xx_iodelay.h>
#include <asm/emif.h>
@@ -830,3 +832,10 @@ int board_fit_config_name_match(const char *name)
return -1;
}
#endif
+
+#ifdef CONFIG_TI_SECURE_DEVICE
+void board_fit_image_post_process(void **p_image, size_t *p_size)
+{
+ secure_boot_verify_image(p_image, p_size);
+}
+#endif
diff --git a/configs/am57xx_hs_evm_defconfig b/configs/am57xx_hs_evm_defconfig
index e01e504..01a4701 100644
--- a/configs/am57xx_hs_evm_defconfig
+++ b/configs/am57xx_hs_evm_defconfig
@@ -40,4 +40,5 @@ CONFIG_USB_XHCI_DWC3=y
CONFIG_FIT=y
CONFIG_SPL_OF_LIBFDT=y
CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
CONFIG_OF_LIST="am57xx-beagle-x15"
diff --git a/configs/dra7xx_hs_evm_defconfig b/configs/dra7xx_hs_evm_defconfig
index 6933ab5..eb01f41 100644
--- a/configs/dra7xx_hs_evm_defconfig
+++ b/configs/dra7xx_hs_evm_defconfig
@@ -58,4 +58,5 @@ CONFIG_G_DNL_PRODUCT_NUM=0xd022
CONFIG_FIT=y
CONFIG_SPL_OF_LIBFDT=y
CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
CONFIG_OF_LIST="dra7-evm dra72-evm"
--
2.6.4
^ permalink raw reply related [flat|nested] 26+ messages in thread* [U-Boot] [PATCH v3 8/9] arm: am4x: add U-Boot FIT signing and SPL image post-processing
2016-06-27 14:19 [U-Boot] [PATCH v3 0/9] Secure Boot by Authenticating/Decrypting SPL FIT blobs Andreas Dannenberg
` (6 preceding siblings ...)
2016-06-27 14:19 ` [U-Boot] [PATCH v3 7/9] arm: omap5: add U-Boot FIT signing and SPL image post-processing Andreas Dannenberg
@ 2016-06-27 14:19 ` Andreas Dannenberg
2016-07-16 13:47 ` [U-Boot] [U-Boot, v3, " Tom Rini
2016-06-27 14:19 ` [U-Boot] [PATCH v3 9/9] doc: Update info on using secure devices from TI Andreas Dannenberg
` (2 subsequent siblings)
10 siblings, 1 reply; 26+ messages in thread
From: Andreas Dannenberg @ 2016-06-27 14:19 UTC (permalink / raw)
To: u-boot
From: Madan Srinivas <madans@ti.com>
Modify the SPL build procedure for AM437x high-security (HS) device
variants to create a secure u-boot_HS.img FIT blob that contains U-Boot
and DTB artifacts signed (and optionally encrypted) with a TI-specific
process based on the CONFIG_TI_SECURE_DEVICE config option and the
externally-provided image signing tool.
Also populate the corresponding FIT image post processing call to be
performed during SPL runtime.
Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
---
arch/arm/cpu/armv7/am33xx/config.mk | 1 +
board/ti/am43xx/board.c | 8 ++++++++
configs/am43xx_hs_evm_defconfig | 1 +
3 files changed, 10 insertions(+)
diff --git a/arch/arm/cpu/armv7/am33xx/config.mk b/arch/arm/cpu/armv7/am33xx/config.mk
index 6d95d32..ab94708 100644
--- a/arch/arm/cpu/armv7/am33xx/config.mk
+++ b/arch/arm/cpu/armv7/am33xx/config.mk
@@ -26,6 +26,7 @@ endif
else
ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
ALL-$(CONFIG_QSPI_BOOT) += u-boot_HS_XIP_X-LOADER
+ALL-y += u-boot_HS.img
endif
ALL-y += u-boot.img
endif
diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
index f005762..27c311e 100644
--- a/board/ti/am43xx/board.c
+++ b/board/ti/am43xx/board.c
@@ -13,6 +13,7 @@
#include <asm/errno.h>
#include <spl.h>
#include <usb.h>
+#include <asm/omap_sec_common.h>
#include <asm/arch/clock.h>
#include <asm/arch/sys_proto.h>
#include <asm/arch/mux.h>
@@ -862,3 +863,10 @@ int board_fit_config_name_match(const char *name)
return -1;
}
#endif
+
+#ifdef CONFIG_TI_SECURE_DEVICE
+void board_fit_image_post_process(void **p_image, size_t *p_size)
+{
+ secure_boot_verify_image(p_image, p_size);
+}
+#endif
diff --git a/configs/am43xx_hs_evm_defconfig b/configs/am43xx_hs_evm_defconfig
index 4856a19..68dfb6c 100644
--- a/configs/am43xx_hs_evm_defconfig
+++ b/configs/am43xx_hs_evm_defconfig
@@ -13,6 +13,7 @@ CONFIG_SPL_STACK_R=y
CONFIG_FIT=y
CONFIG_SYS_EXTRA_OPTIONS="CONS_INDEX=1, NAND"
CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
CONFIG_HUSH_PARSER=y
CONFIG_CMD_BOOTZ=y
# CONFIG_CMD_IMLS is not set
--
2.6.4
^ permalink raw reply related [flat|nested] 26+ messages in thread* [U-Boot] [U-Boot, v3, 8/9] arm: am4x: add U-Boot FIT signing and SPL image post-processing
2016-06-27 14:19 ` [U-Boot] [PATCH v3 8/9] arm: am4x: " Andreas Dannenberg
@ 2016-07-16 13:47 ` Tom Rini
0 siblings, 0 replies; 26+ messages in thread
From: Tom Rini @ 2016-07-16 13:47 UTC (permalink / raw)
To: u-boot
On Mon, Jun 27, 2016 at 09:19:23AM -0500, Andreas Dannenberg wrote:
> From: Madan Srinivas <madans@ti.com>
>
> Modify the SPL build procedure for AM437x high-security (HS) device
> variants to create a secure u-boot_HS.img FIT blob that contains U-Boot
> and DTB artifacts signed (and optionally encrypted) with a TI-specific
> process based on the CONFIG_TI_SECURE_DEVICE config option and the
> externally-provided image signing tool.
>
> Also populate the corresponding FIT image post processing call to be
> performed during SPL runtime.
>
> Signed-off-by: Madan Srinivas <madans@ti.com>
> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
> Reviewed-by: Tom Rini <trini@konsulko.com>
Applied to u-boot/master, thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160716/102d6e88/attachment.sig>
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH v3 9/9] doc: Update info on using secure devices from TI
2016-06-27 14:19 [U-Boot] [PATCH v3 0/9] Secure Boot by Authenticating/Decrypting SPL FIT blobs Andreas Dannenberg
` (7 preceding siblings ...)
2016-06-27 14:19 ` [U-Boot] [PATCH v3 8/9] arm: am4x: " Andreas Dannenberg
@ 2016-06-27 14:19 ` Andreas Dannenberg
2016-07-16 13:47 ` [U-Boot] [U-Boot, v3, " Tom Rini
2016-07-14 13:55 ` [U-Boot] [PATCH v3 0/9] Secure Boot by Authenticating/Decrypting SPL FIT blobs Andreas Dannenberg
2016-07-20 18:19 ` Andreas Dannenberg
10 siblings, 1 reply; 26+ messages in thread
From: Andreas Dannenberg @ 2016-06-27 14:19 UTC (permalink / raw)
To: u-boot
Adds information regarding SPL handling the loading and processing of
secured u-boot images as part of the second stage boot the SPL does.
Introduces the description of a new interface script in the TI SECDEV
Package which handles the creation and prep of secured binary images.
Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
doc/README.ti-secure | 177 +++++++++++++++++++++++++++++++++++----------------
1 file changed, 123 insertions(+), 54 deletions(-)
diff --git a/doc/README.ti-secure b/doc/README.ti-secure
index 7fc9b9b..54c996d 100644
--- a/doc/README.ti-secure
+++ b/doc/README.ti-secure
@@ -19,69 +19,80 @@ control restrictions. Access must be requested and granted by TI before the
package is viewable and downloadable. Contact TI, either online or by way
of a local TI representative, to request access.
-When CONFIG_TI_SECURE_DEVICE is set, the U-Boot SPL build process requires
-the presence and use of these tools in order to create a viable boot image.
-The build process will look for the environment variable TI_SECURE_DEV_PKG,
-which should be the path of the installed SECDEV package. If the
-TI_SECURE_DEV_PKG variable is not defined or if it is defined but doesn't
-point to a valid SECDEV package, a warning is issued during the build to
-indicate that a final secure bootable image was not created.
-
-Within the SECDEV package exists an image creation script:
-
-${TI_SECURE_DEV_PKG}/scripts/create-boot-image.sh
-
-This is called as part of the SPL/u-boot build process. As the secure boot
-image formats and requirements differ between secure SOC from TI, the
-purpose of this script is to abstract these details as much as possible.
-
-The script is basically the only required interface to the TI SECDEV package
-for secure TI devices.
-
-Invoking the script for AM43xx Secure Devices
-=============================================
-
-create-boot-image.sh <IMAGE_FLAG> <INPUT_FILE> <OUTPUT_FILE> <SPL_LOAD_ADDR>
-
-<IMAGE_FLAG> is a value that specifies the type of the image to generate OR
-the action the image generation tool will take. Valid values are:
- SPI_X-LOADER - Generates an image for SPI flash (byte swapped)
- XIP_X-LOADER - Generates a single stage u-boot for NOR/QSPI XiP
- ISSW - Generates an image for all other boot modes
-
-<INPUT_FILE> is the full path and filename of the public world boot loader
-binary file (depending on the boot media, this is usually either
-u-boot-spl.bin or u-boot.bin).
-
-<OUTPUT_FILE> is the full path and filename of the final secure image. The
-output binary images should be used in place of the standard non-secure
-binary images (see the platform-specific user's guides and releases notes
-for how the non-secure images are typically used)
+Booting of U-Boot SPL
+=====================
+
+ When CONFIG_TI_SECURE_DEVICE is set, the U-Boot SPL build process
+ requires the presence and use of these tools in order to create a
+ viable boot image. The build process will look for the environment
+ variable TI_SECURE_DEV_PKG, which should be the path of the installed
+ SECDEV package. If the TI_SECURE_DEV_PKG variable is not defined or
+ if it is defined but doesn't point to a valid SECDEV package, a
+ warning is issued during the build to indicate that a final secure
+ bootable image was not created.
+
+ Within the SECDEV package exists an image creation script:
+
+ ${TI_SECURE_DEV_PKG}/scripts/create-boot-image.sh
+
+ This is called as part of the SPL/u-boot build process. As the secure
+ boot image formats and requirements differ between secure SOC from TI,
+ the purpose of this script is to abstract these details as much as
+ possible.
+
+ The script is basically the only required interface to the TI SECDEV
+ package for creating a bootable SPL image for secure TI devices.
+
+ Invoking the script for AM43xx Secure Devices
+ =============================================
+
+ create-boot-image.sh \
+ <IMAGE_FLAG> <INPUT_FILE> <OUTPUT_FILE> <SPL_LOAD_ADDR>
+
+ <IMAGE_FLAG> is a value that specifies the type of the image to
+ generate OR the action the image generation tool will take. Valid
+ values are:
+ SPI_X-LOADER - Generates an image for SPI flash (byte
+ swapped)
+ XIP_X-LOADER - Generates a single stage u-boot for
+ NOR/QSPI XiP
+ ISSW - Generates an image for all other boot modes
+
+ <INPUT_FILE> is the full path and filename of the public world boot
+ loaderbinary file (depending on the boot media, this is usually
+ either u-boot-spl.bin or u-boot.bin).
+
+ <OUTPUT_FILE> is the full path and filename of the final secure
+ image. The output binary images should be used in place of the standard
+ non-secure binary images (see the platform-specific user's guides and
+ releases notes for how the non-secure images are typically used)
u-boot-spl_HS_SPI_X-LOADER - byte swapped boot image for SPI flash
u-boot_HS_XIP_X-LOADER - boot image for NOR or QSPI flash
u-boot-spl_HS_ISSW - boot image for all other boot media
-<SPL_LOAD_ADDR> is the address at which SOC ROM should load the <INPUT_FILE>
+ <SPL_LOAD_ADDR> is the address at which SOC ROM should load the
+ <INPUT_FILE>
-Invoking the script for DRA7xx/AM57xx Secure Devices
-====================================================
+ Invoking the script for DRA7xx/AM57xx Secure Devices
+ ====================================================
-create-boot-image.sh <IMAGE_TYPE> <INPUT_FILE> <OUTPUT_FILE>
+ create-boot-image.sh <IMAGE_TYPE> <INPUT_FILE> <OUTPUT_FILE>
-<IMAGE_TYPE> is a value that specifies the type of the image to generate OR
-the action the image generation tool will take. Valid values are:
- X-LOADER - Generates an image for NOR or QSPI boot modes
- MLO - Generates an image for SD/MMC/eMMC boot modes
- ULO - Generates an image for USB/UART peripheral boot modes
- Note: ULO is not yet used by the u-boot build process
+ <IMAGE_TYPE> is a value that specifies the type of the image to
+ generate OR the action the image generation tool will take. Valid
+ values are:
+ X-LOADER - Generates an image for NOR or QSPI boot modes
+ MLO - Generates an image for SD/MMC/eMMC boot modes
+ ULO - Generates an image for USB/UART peripheral boot modes
+ Note: ULO is not yet used by the u-boot build process
-<INPUT_FILE> is the full path and filename of the public world boot loader
-binary file (for this platform, this is always u-boot-spl.bin).
+ <INPUT_FILE> is the full path and filename of the public world boot
+ loader binary file (for this platform, this is always u-boot-spl.bin).
-<OUTPUT_FILE> is the full path and filename of the final secure image. The
-output binary images should be used in place of the standard non-secure
-binary images (see the platform-specific user's guides and releases notes
-for how the non-secure images are typically used)
+ <OUTPUT_FILE> is the full path and filename of the final secure image.
+ The output binary images should be used in place of the standard
+ non-secure binary images (see the platform-specific user's guides
+ and releases notes for how the non-secure images are typically used)
u-boot-spl_HS_MLO - boot image for SD/MMC/eMMC. This image is
copied to a file named MLO, which is the name that
the device ROM bootloader requires for loading from
@@ -89,3 +100,61 @@ for how the non-secure images are typically used)
non-secure devices)
u-boot-spl_HS_X-LOADER - boot image for all other flash memories
including QSPI and NOR flash
+
+Booting of Primary U-Boot (u-boot.img)
+======================================
+
+ The SPL image is responsible for loading the next stage boot loader,
+ which is the main u-boot image. For secure TI devices, the SPL will
+ be authenticated, as described above, as part of the particular
+ device's ROM boot process. In order to continue the secure boot
+ process, the authenticated SPL must authenticate the main u-boot
+ image that it loads.
+
+ The configurations for secure TI platforms are written to make the boot
+ process use the FIT image format for the u-boot.img (CONFIG_SPL_FRAMEWORK
+ and CONFIG_SPL_LOAD_FIT). With these configurations the binary
+ components that the SPL loads include a specific DTB image and u-boot
+ image. These DTB image may be one of many available to the boot
+ process. In order to secure these components so that they can be
+ authenticated by the SPL as they are loaded from the FIT image, the
+ build procedure for secure TI devices will secure these images before
+ they are integrated into the FIT image. When those images are extracted
+ from the FIT image at boot time, they are post-processed to verify that
+ they are still secure. The outlined security-related SPL post-processing
+ is enabled through the CONFIG_SPL_FIT_IMAGE_POST_PROCESS option which
+ must be enabled for the secure boot scheme to work. In order to allow
+ verifying proper operation of the secure boot chain in case of successful
+ authentication messages like "Authentication passed: CERT_U-BOOT-NOD" are
+ output by the SPL to the console for each blob that got extracted from the
+ FIT image. Note that the last part of this log message is the (truncated)
+ name of the signing certificate embedded into the blob that got processed.
+
+ The exact details of the how the images are secured is handled by the
+ SECDEV package. Within the SECDEV package exists a script to process
+ an input binary image:
+
+ ${TI_SECURE_DEV_PKG}/scripts/secure-binary-image.sh
+
+ This is called as part of the u-boot build process. As the secure
+ image formats and requirements can differ between the various secure
+ SOCs from TI, this script in the SECDEV package abstracts these
+ details. This script is essentially the only required interface to the
+ TI SECDEV package for creating a u-boot.img image for secure TI
+ devices.
+
+ The SPL/u-boot code contains calls to dedicated secure ROM functions
+ to perform the validation on the secured images. The details of the
+ interface to those functions is shown in the code. The summary
+ is that they are accessed by invoking an ARM secure monitor call to
+ the device's secure ROM (fixed read-only-memory that is secure and
+ only accessible when the ARM core is operating in the secure mode).
+
+ Invoking the secure-binary-image script for Secure Devices
+ ==========================================================
+
+ secure-binary-image.sh <INPUT_FILE> <OUTPUT_FILE>
+
+ <INPUT_FILE> is the full path and filename of the input binary image
+
+ <OUTPUT_FILE> is the full path and filename of the output secure image.
--
2.6.4
^ permalink raw reply related [flat|nested] 26+ messages in thread* [U-Boot] [PATCH v3 0/9] Secure Boot by Authenticating/Decrypting SPL FIT blobs
2016-06-27 14:19 [U-Boot] [PATCH v3 0/9] Secure Boot by Authenticating/Decrypting SPL FIT blobs Andreas Dannenberg
` (8 preceding siblings ...)
2016-06-27 14:19 ` [U-Boot] [PATCH v3 9/9] doc: Update info on using secure devices from TI Andreas Dannenberg
@ 2016-07-14 13:55 ` Andreas Dannenberg
2016-07-14 14:57 ` Tom Rini
2016-07-14 14:59 ` Simon Glass
2016-07-20 18:19 ` Andreas Dannenberg
10 siblings, 2 replies; 26+ messages in thread
From: Andreas Dannenberg @ 2016-07-14 13:55 UTC (permalink / raw)
To: u-boot
Hi Tom, Simon,
On Mon, Jun 27, 2016 at 09:19:15AM -0500, Andreas Dannenberg wrote:
> This is an updated version of a patch series that introduces a generic way
> to optionally post-process blobs as they get extracted by the SPL from the
> u-boot.img FIT image, and uses this scheme to perform some authentication/
> decryption related processing on TI's high-secure (HS) SoC variants. For
> additional background please see here [1].
just wanted to send a quick ping on this patch series. My optimistic
understanding from the review and comments is that it should be in a
reasonable state right now. Please let me know if there is anything else
gating the acceptance other perhaps you wanting it to give more time for
others to chime in.
Thanks and Regards,
Andreas
^ permalink raw reply [flat|nested] 26+ messages in thread* [U-Boot] [PATCH v3 0/9] Secure Boot by Authenticating/Decrypting SPL FIT blobs
2016-07-14 13:55 ` [U-Boot] [PATCH v3 0/9] Secure Boot by Authenticating/Decrypting SPL FIT blobs Andreas Dannenberg
@ 2016-07-14 14:57 ` Tom Rini
2016-07-14 15:22 ` Andreas Dannenberg
2016-07-14 14:59 ` Simon Glass
1 sibling, 1 reply; 26+ messages in thread
From: Tom Rini @ 2016-07-14 14:57 UTC (permalink / raw)
To: u-boot
On Thu, Jul 14, 2016 at 08:55:21AM -0500, Andreas Dannenberg wrote:
> Hi Tom, Simon,
>
> On Mon, Jun 27, 2016 at 09:19:15AM -0500, Andreas Dannenberg wrote:
> > This is an updated version of a patch series that introduces a generic way
> > to optionally post-process blobs as they get extracted by the SPL from the
> > u-boot.img FIT image, and uses this scheme to perform some authentication/
> > decryption related processing on TI's high-secure (HS) SoC variants. For
> > additional background please see here [1].
>
> just wanted to send a quick ping on this patch series. My optimistic
> understanding from the review and comments is that it should be in a
> reasonable state right now. Please let me know if there is anything else
> gating the acceptance other perhaps you wanting it to give more time for
> others to chime in.
I'm giving people a little more time to chime in and will pick it up
soon. Thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160714/2f13e915/attachment.sig>
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH v3 0/9] Secure Boot by Authenticating/Decrypting SPL FIT blobs
2016-07-14 14:57 ` Tom Rini
@ 2016-07-14 15:22 ` Andreas Dannenberg
0 siblings, 0 replies; 26+ messages in thread
From: Andreas Dannenberg @ 2016-07-14 15:22 UTC (permalink / raw)
To: u-boot
Hi Tom,
On Thu, Jul 14, 2016 at 10:57:34AM -0400, Tom Rini wrote:
> On Thu, Jul 14, 2016 at 08:55:21AM -0500, Andreas Dannenberg wrote:
> > Hi Tom, Simon,
> >
> > On Mon, Jun 27, 2016 at 09:19:15AM -0500, Andreas Dannenberg wrote:
> > > This is an updated version of a patch series that introduces a generic way
> > > to optionally post-process blobs as they get extracted by the SPL from the
> > > u-boot.img FIT image, and uses this scheme to perform some authentication/
> > > decryption related processing on TI's high-secure (HS) SoC variants. For
> > > additional background please see here [1].
> >
> > just wanted to send a quick ping on this patch series. My optimistic
> > understanding from the review and comments is that it should be in a
> > reasonable state right now. Please let me know if there is anything else
> > gating the acceptance other perhaps you wanting it to give more time for
> > others to chime in.
>
> I'm giving people a little more time to chime in and will pick it up
> soon. Thanks!
Understood, that's what I thought since it touches rather "global"
files. I also just re-applied the patch series to the latest 'master'
branch and it still applies cleanly and the resulting MLO/u-boot.img
images still perform as expected.
Thanks and Regards,
Andreas
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH v3 0/9] Secure Boot by Authenticating/Decrypting SPL FIT blobs
2016-07-14 13:55 ` [U-Boot] [PATCH v3 0/9] Secure Boot by Authenticating/Decrypting SPL FIT blobs Andreas Dannenberg
2016-07-14 14:57 ` Tom Rini
@ 2016-07-14 14:59 ` Simon Glass
1 sibling, 0 replies; 26+ messages in thread
From: Simon Glass @ 2016-07-14 14:59 UTC (permalink / raw)
To: u-boot
Hi Andreas,
On 14 July 2016 at 07:55, Andreas Dannenberg <dannenberg@ti.com> wrote:
> Hi Tom, Simon,
>
> On Mon, Jun 27, 2016 at 09:19:15AM -0500, Andreas Dannenberg wrote:
>> This is an updated version of a patch series that introduces a generic way
>> to optionally post-process blobs as they get extracted by the SPL from the
>> u-boot.img FIT image, and uses this scheme to perform some authentication/
>> decryption related processing on TI's high-secure (HS) SoC variants. For
>> additional background please see here [1].
>
> just wanted to send a quick ping on this patch series. My optimistic
> understanding from the review and comments is that it should be in a
> reasonable state right now. Please let me know if there is anything else
> gating the acceptance other perhaps you wanting it to give more time for
> others to chime in.
It looks fine to me. I think it should go through Tom's tree, but I'm
happy to pick it up via dm if needed.
Regards,
Simon
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] [PATCH v3 0/9] Secure Boot by Authenticating/Decrypting SPL FIT blobs
2016-06-27 14:19 [U-Boot] [PATCH v3 0/9] Secure Boot by Authenticating/Decrypting SPL FIT blobs Andreas Dannenberg
` (9 preceding siblings ...)
2016-07-14 13:55 ` [U-Boot] [PATCH v3 0/9] Secure Boot by Authenticating/Decrypting SPL FIT blobs Andreas Dannenberg
@ 2016-07-20 18:19 ` Andreas Dannenberg
10 siblings, 0 replies; 26+ messages in thread
From: Andreas Dannenberg @ 2016-07-20 18:19 UTC (permalink / raw)
To: u-boot
On Mon, Jun 27, 2016 at 09:19:15AM -0500, Andreas Dannenberg wrote:
> This is an updated version of a patch series that introduces a generic way
> to optionally post-process blobs as they get extracted by the SPL from the
> u-boot.img FIT image, and uses this scheme to perform some authentication/
> decryption related processing on TI's high-secure (HS) SoC variants. For
> additional background please see here [1].
I just wanted to point out that this now-accepted patch series in by
itself is not a 100% complete solution to address all needs of secure
boot. Specifically, the extensions made rely on loading U-Boot as a FIT
image (CONFIG_SPL_LOAD_FIT) but do not prevent the loading of a legacy
non-FIT U-Boot image. This is something that will need to get addressed
in a follow-on patch.
Regards,
Andreas
> [1] http://lists.denx.de/pipermail/u-boot/2016-June/258716.html
^ permalink raw reply [flat|nested] 26+ messages in thread