Skip to contentSkip to conversation

Adds support for secure boot on Keystone SoCs (K2E)

PATCH Superseded Madan Srinivas 7 participants 36 messages Aug 26, 2016 – Sep 8, 2016

Subsystems (3)
Arm (32-bit) Arm sub-architectures Arm/Texas instrument Keystone architecture
lore
Share & tools
lore

Madan Srinivas

author
#0 lore raw

cover Adds support for secure boot on Keystone SoCs (K2E)

This series adds support for secure keystone family of devices, more specifically for K2E (Edison).This work is similar to what has already been done for the AM43xx and AM57xx SoCs and leverages much of the infrastructure from them.

The big difference here is the ROM on keystone2 devices does not provide any APIs for image authentication. Rather, the image authentication and decryption routines and other security functions are provided by software and can run on the ARM in Trustzone as well as on secure DSPs.

A component known as the boot monitor acts as they gateway to this secure processing, and abstracts out the details from the public world. Unlike OMAP class devices, where u-boot calls ROM APIs, u-boot calls into the boot- monitor on keystone devices.

Other than this difference, most of the secure framework for AMxx and DRAxx devices have been re-used.

Couple of other points to note :-

-Support for SPL on secure keystone devices is still TBD, so boot from SPI flash, which needs SPL, is not supported currently on K2 devices.

-A single image will work across all boot media for secure K2 devices.

Madan Srinivas (4):
include: image.h: Fixes build warning with
CONFIG_FIT_IMAGE_POST_PROCESS
arm: omap-common: Reuse secure image name between OMAP and keystone
arm: mach-keystone: config.mk: Adds support for secure images on K2
doc: Updates info on using keystone secure devices from TI

Vitaly Andrianov (3):
arm: mach-keystone: Implements FIT post-processing call for keystone
SoCs
arm: omap-common: Enable support for K2 HS devices in u-boot
configs: Adds a defconfig for K2E High Security EVM

 arch/arm/cpu/armv7/omap-common/Kconfig          |  2 +-
 arch/arm/cpu/armv7/omap-common/config_secure.mk |  4 +-
 arch/arm/mach-keystone/config.mk                |  6 +++
 arch/arm/mach-keystone/mon.c                    | 53 +++++++++++++++++++++++++
 configs/k2e_hs_evm_defconfig                    | 44 ++++++++++++++++++++
 doc/README.ti-secure                            | 20 ++++++++++
 include/image.h                                 |  3 +-
 7 files changed, 129 insertions(+), 3 deletions(-)
 create mode 100644 configs/k2e_hs_evm_defconfig
Signature · 1 line
2.7.4
author
#1 lore raw

PATCH 1/7 include: image.h: Fixes build warning with CONFIG_FIT_IMAGE_POST_PROCESS

The function board_fit_image_post_process is defined only when the config CONFIG_FIT_IMAGE_POST_PROCESS is enabled. For secure systems that do not use SPL but use FIT kernel images, only CONFIG_FIT_IMAGE_POST_PROCESS will defined, which will result in an implicit declaration of function 'board_fit_image_post_process' warning while building u-boot. This patch fixes this warning.

Signed-off-by Madan Srinivas <[email protected]>

---

 include/image.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
include/image.h +2 -1
index 64da722..6884421 100644
@@ -1245,7 +1245,8 @@ 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
+#if defined(CONFIG_SPL_FIT_IMAGE_POST_PROCESS) || \
+	defined(CONFIG_FIT_IMAGE_POST_PROCESS)
 /**
  * board_fit_image_post_process() - Do any post-process on FIT binary data
  *
Signature · 1 line
2.7.4
#2 lore raw

PATCH 1/7 include: image.h: Fixes build warning with CONFIG_FIT_IMAGE_POST_PROCESS

Quoted 1 line · Madan Srinivas

The function board_fit_image_post_process is defined only when the config

I think you mean "declared" here, it is "defined" when ether CONFIG_SPL_FIT_IMAGE_POST_PROCESS *or* CONFIG_FIT_IMAGE_POST_PROCESS is enabled, but only "declared" here in this header when the first is enabled.

Quoted 2 lines

CONFIG_FIT_IMAGE_POST_PROCESS is enabled. For secure systems that do not use SPL but use FIT kernel images, only CONFIG_FIT_IMAGE_POST_PROCESS will

I think you are missing a word here. (will {be} defined)

Quoted 5 lines

defined, which will result in an implicit declaration of function 'board_fit_image_post_process' warning while building u-boot. This patch fixes this warning.

Signed-off-by Madan Srinivas <[email protected]>

Otherwise looks good to me,

Acked-by Andrew F. Davis <[email protected]>
Quoted 20 lines

---

 include/image.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
include/image.h +2 -1
index 64da722..6884421 100644
@@ -1245,7 +1245,8 @@ 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
+#if defined(CONFIG_SPL_FIT_IMAGE_POST_PROCESS) || \
+	defined(CONFIG_FIT_IMAGE_POST_PROCESS)
 /**
  * board_fit_image_post_process() - Do any post-process on FIT binary data
  *
author
#3 lore raw

PATCH 2/7 arm: mach-keystone: Implements FIT post-processing call for keystone SoCs

In reply to Madan Srinivas

From: Vitaly Andrianov <[email protected]>

This commit implements the board_fit_image_post_process() function for the keystone architecture. Unlike OMAP class devices, security functions in keystone are not handled in the ROM.
The interface to the secure functions is TI proprietary and depending on the keystone platform, the security functions like encryption, decryption and authentication might even be offloaded to other secure processing elements in the SoC.
The boot monitor acts as the gateway to these secure functions and the boot monitor for secure devices is available as part of the SECDEV package for KS2. For more details refer doc/README.ti-secure

Signed-off-by Vitaly Andrianov <[email protected]>
Signed-off-by Madan Srinivas <[email protected]>

---

 arch/arm/mach-keystone/mon.c | 53 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 53 insertions(+)
arch/arm/mach-keystone/mon.c +53 -0
index 256f630..b4a6f1c 100644
@@ -12,10 +12,31 @@
 #include <mach/mon.h>
 asm(".arch_extension sec\n\t");
 
+#ifdef CONFIG_TI_SECURE_DEVICE
+#define KS2_HS_AUTH_FN_OFFSET	8
+#define KS2_HS_SEC_HEADER_LEN	0x60
+#define KS2_AUTH_CMD		"2"
+/**
+ * (*fn_auth)() - Invokes security functions using a
+ * proprietary TI interface. This binary and source for
+ * this is available in the secure development package or
+ * SECDEV. For details on how to access this please refer
+ * doc/README.ti-secure
+ *
+ * @first param:	no. of parameters
+ * @second param:	parameter list
+ * @return non-zero value on success, zero on error
+ */
+static unsigned int (*fn_auth)(int, char * const []);
+#endif
+
 int mon_install(u32 addr, u32 dpsc, u32 freq)
 {
 	int result;
 
+#ifdef CONFIG_TI_SECURE_DEVICE
+	fn_auth = (void *)(addr + KS2_HS_AUTH_FN_OFFSET);
+#endif
 	__asm__ __volatile__ (
 		"stmfd r13!, {lr}\n"
 		"mov r0, %1\n"

@@ -61,3 +82,35 @@ int mon_power_off(int core_id)
 		: "cc", "r0", "r1", "memory");
 	return  result;
 }
+
+#ifdef CONFIG_TI_SECURE_DEVICE
+static void k2_hs_auth(void *addr)
+{
+	char *argv1 = KS2_AUTH_CMD;
+	char argv2[32];
+	char *argv[3] = {NULL, argv1, argv2};
+	int ret;
+
+	sprintf(argv2, "0x%08x", (u32)addr);
+	ret = fn_auth(3, argv);
+
+	if (ret == 0) {
+		printf("FAIL!!!\n"); /* remove form production code */
+		hang();
+	}
+}
+
+void board_fit_image_post_process(void **p_image, size_t *p_size)
+{
+	void *dst = *p_image;
+	void *src = dst + KS2_HS_SEC_HEADER_LEN;
+
+	k2_hs_auth(*p_image);
+
+	/*
+	* Overwrite the image headers  after authentication
+	* and decryption. Move the image to its run address
+	*/
+	memcpy(dst, src, *p_size - KS2_HS_SEC_HEADER_LEN);
+}
+#endif
Signature · 1 line
2.7.4
#4 lore raw

PATCH 2/7 arm: mach-keystone: Implements FIT post-processing call for keystone SoCs

Quoted 63 lines · Madan Srinivas

From: Vitaly Andrianov <[email protected]>

This commit implements the board_fit_image_post_process() function for the keystone architecture. Unlike OMAP class devices, security functions in keystone are not handled in the ROM.
The interface to the secure functions is TI proprietary and depending on the keystone platform, the security functions like encryption, decryption and authentication might even be offloaded to other secure processing elements in the SoC.
The boot monitor acts as the gateway to these secure functions and the boot monitor for secure devices is available as part of the SECDEV package for KS2. For more details refer doc/README.ti-secure

Signed-off-by Vitaly Andrianov <[email protected]>
Signed-off-by Madan Srinivas <[email protected]>

---

 arch/arm/mach-keystone/mon.c | 53 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 53 insertions(+)
arch/arm/mach-keystone/mon.c +24 -0
index 256f630..b4a6f1c 100644
@@ -12,10 +12,31 @@
 #include <mach/mon.h>
 asm(".arch_extension sec\n\t");
 
+#ifdef CONFIG_TI_SECURE_DEVICE
+#define KS2_HS_AUTH_FN_OFFSET	8
+#define KS2_HS_SEC_HEADER_LEN	0x60
+#define KS2_AUTH_CMD		"2"
+/**
+ * (*fn_auth)() - Invokes security functions using a
+ * proprietary TI interface. This binary and source for
+ * this is available in the secure development package or
+ * SECDEV. For details on how to access this please refer
+ * doc/README.ti-secure
+ *
+ * @first param:	no. of parameters
+ * @second param:	parameter list
+ * @return non-zero value on success, zero on error
+ */
+static unsigned int (*fn_auth)(int, char * const []);
+#endif
+
 int mon_install(u32 addr, u32 dpsc, u32 freq)
 {
 	int result;
 
+#ifdef CONFIG_TI_SECURE_DEVICE
+	fn_auth = (void *)(addr + KS2_HS_AUTH_FN_OFFSET);
+#endif
 	__asm__ __volatile__ (
 		"stmfd r13!, {lr}\n"
 		"mov r0, %1\n"

@@ -61,3 +82,35 @@ int mon_power_off(int core_id)
 		: "cc", "r0", "r1", "memory");
 	return  result;
 }
+
+#ifdef CONFIG_TI_SECURE_DEVICE
+static void k2_hs_auth(void *addr)

arch/arm/mach-keystone/mon.c int mon_power_off(int core_id) · line 97

Quoted 10 lines
arch/arm/mach-keystone/mon.c +10 -0
+{
+	char *argv1 = KS2_AUTH_CMD;
+	char argv2[32];
+	char *argv[3] = {NULL, argv1, argv2};
+	int ret;
+
+	sprintf(argv2, "0x%08x", (u32)addr);
+	ret = fn_auth(3, argv);
+
+	if (ret == 0) {

Can this be if (!ret)?

arch/arm/mach-keystone/mon.c int mon_power_off(int core_id) · line 98

Quoted 1 line
arch/arm/mach-keystone/mon.c +1 -0
+		printf("FAIL!!!\n"); /* remove form production code */

Wouldn't this be production code?
If this print is intended to stay the s/form/from

Dan

Quoted 18 lines
arch/arm/mach-keystone/mon.c +18 -0
+		hang();
+	}
+}
+
+void board_fit_image_post_process(void **p_image, size_t *p_size)
+{
+	void *dst = *p_image;
+	void *src = dst + KS2_HS_SEC_HEADER_LEN;
+
+	k2_hs_auth(*p_image);
+
+	/*
+	* Overwrite the image headers  after authentication
+	* and decryption. Move the image to its run address
+	*/
+	memcpy(dst, src, *p_size - KS2_HS_SEC_HEADER_LEN);
+}
+#endif
Signature · 2 lines
------------------
Dan Murphy
#5 lore raw

PATCH v2 2/7 arm: mach-keystone: Implements FIT post-processing call for keystone SoCs

In reply to Madan Srinivas
Quoted 61 lines · Madan Srinivas

From: Vitaly Andrianov <[email protected]>

This commit implements the board_fit_image_post_process() function for the keystone architecture. Unlike OMAP class devices, security functions in keystone are not handled in the ROM.
The interface to the secure functions is TI proprietary and depending on the keystone platform, the security functions like encryption, decryption and authentication might even be offloaded to other secure processing elements in the SoC.
The boot monitor acts as the gateway to these secure functions and the boot monitor for secure devices is available as part of the SECDEV package for KS2. For more details refer doc/README.ti-secure

Signed-off-by Vitaly Andrianov <[email protected]>
Signed-off-by Madan Srinivas <[email protected]>

---

 arch/arm/mach-keystone/mon.c | 53 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 53 insertions(+)
arch/arm/mach-keystone/mon.c +22 -0
index 256f630..b4a6f1c 100644
@@ -12,10 +12,31 @@
 #include <mach/mon.h>
 asm(".arch_extension sec\n\t");
 
+#ifdef CONFIG_TI_SECURE_DEVICE
+#define KS2_HS_AUTH_FN_OFFSET	8
+#define KS2_HS_SEC_HEADER_LEN	0x60
+#define KS2_AUTH_CMD		"2"
+/**
+ * (*fn_auth)() - Invokes security functions using a
+ * proprietary TI interface. This binary and source for
+ * this is available in the secure development package or
+ * SECDEV. For details on how to access this please refer
+ * doc/README.ti-secure
+ *
+ * @first param:	no. of parameters
+ * @second param:	parameter list
+ * @return non-zero value on success, zero on error
+ */
+static unsigned int (*fn_auth)(int, char * const []);
+#endif
+
 int mon_install(u32 addr, u32 dpsc, u32 freq)
 {
 	int result;
 
+#ifdef CONFIG_TI_SECURE_DEVICE
+	fn_auth = (void *)(addr + KS2_HS_AUTH_FN_OFFSET);
+#endif
 	__asm__ __volatile__ (
 		"stmfd r13!, {lr}\n"
 		"mov r0, %1\n"

@@ -61,3 +82,35 @@ int mon_power_off(int core_id)
 		: "cc", "r0", "r1", "memory");
 	return  result;
 }
+

arch/arm/mach-keystone/mon.c int mon_power_off(int core_id) · line 95

Quoted 10 lines
arch/arm/mach-keystone/mon.c +10 -0
+#ifdef CONFIG_TI_SECURE_DEVICE
+static void k2_hs_auth(void *addr)
+{
+	char *argv1 = KS2_AUTH_CMD;
+	char argv2[32];
+	char *argv[3] = {NULL, argv1, argv2};
+	int ret;
+
+	sprintf(argv2, "0x%08x", (u32)addr);
+	ret = fn_auth(3, argv);

Can fn_auth be checked before calling it? Just to make sure monitor is installed before processing any image.

Quoted 9 lines
arch/arm/mach-keystone/mon.c +9 -0
+
+	if (ret == 0) {
+		printf("FAIL!!!\n"); /* remove form production code */
+		hang();
+	}
+}
+
+void board_fit_image_post_process(void **p_image, size_t *p_size)
+{

arch/arm/mach-keystone/mon.c int mon_power_off(int core_id) · line 114

Quoted 10 lines
arch/arm/mach-keystone/mon.c +10 -0
+	void *dst = *p_image;
+	void *src = dst + KS2_HS_SEC_HEADER_LEN;
+
+	k2_hs_auth(*p_image);
+
+	/*
+	* Overwrite the image headers  after authentication
+	* and decryption. Move the image to its run address
+	*/
+	memcpy(dst, src, *p_size - KS2_HS_SEC_HEADER_LEN);

Technically image is not being moved to its run address. This is just updating FIT image after post processing. Also, *p_size should be updated to remove header size.

Thanks and regards,
Lokesh

Quoted 3 lines
arch/arm/mach-keystone/mon.c +2 -0
+}
+#endif
author
#6 lore raw

PATCH 3/7 arm: omap-common: Enable support for K2 HS devices in u-boot

In reply to Madan Srinivas

From: Vitaly Andrianov <[email protected]>

Like the OMAP54xx, AM43xx & AM33xx family SoCs, the keystone family of SoCs also have high security enabled models. Allow K2E devices to be built with HS Device Type Support.

This patch applies on top of the patch
ti: omap-common: Allow AM33xx devices to be built securely sumitted by Andrew Davis

Signed-off-by Vitaly Andrianov <[email protected]>
Signed-off-by Madan Srinivas <[email protected]>

---

 arch/arm/cpu/armv7/omap-common/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/cpu/armv7/omap-common/Kconfig +1 -1
index 4daccd9..91d6b2c 100644
@@ -1,6 +1,6 @@
 config TI_SECURE_DEVICE
 	bool "HS Device Type Support"
-	depends on OMAP54XX || AM43XX || AM33XX
+	depends on OMAP54XX || AM43XX || AM33XX || ARCH_KEYSTONE
 	help
 	  If a high secure (HS) device type is being used, this config
 	  must be set. This option impacts various aspects of the
Signature · 1 line
2.7.4
#7 lore raw

PATCH 3/7 arm: omap-common: Enable support for K2 HS devices in u-boot

Quoted 6 lines · Madan Srinivas

From: Vitaly Andrianov <[email protected]>

Like the OMAP54xx, AM43xx & AM33xx family SoCs, the keystone family of SoCs also have high security enabled models. Allow K2E devices to be built with HS Device Type Support.

Quoted 7 lines

This patch applies on top of the patch
ti: omap-common: Allow AM33xx devices to be built securely sumitted by Andrew Davis

Signed-off-by Vitaly Andrianov <[email protected]>
Signed-off-by Madan Srinivas <[email protected]>

---

Acked-by Andrew F. Davis <[email protected]>
Quoted 17 lines
 arch/arm/cpu/armv7/omap-common/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/cpu/armv7/omap-common/Kconfig +1 -1
index 4daccd9..91d6b2c 100644
@@ -1,6 +1,6 @@
 config TI_SECURE_DEVICE
 	bool "HS Device Type Support"
-	depends on OMAP54XX || AM43XX || AM33XX
+	depends on OMAP54XX || AM43XX || AM33XX || ARCH_KEYSTONE
 	help
 	  If a high secure (HS) device type is being used, this config
 	  must be set. This option impacts various aspects of the
#8 lore raw

PATCH 3/7 arm: omap-common: Enable support for K2 HS devices in u-boot

In reply to Madan Srinivas
Quoted 22 lines · Madan Srinivas

From: Vitaly Andrianov <[email protected]>

Like the OMAP54xx, AM43xx & AM33xx family SoCs, the keystone family of SoCs also have high security enabled models. Allow K2E devices to be built with HS Device Type Support.

This patch applies on top of the patch
ti: omap-common: Allow AM33xx devices to be built securely sumitted by Andrew Davis

Signed-off-by Vitaly Andrianov <[email protected]>
Signed-off-by Madan Srinivas <[email protected]>

---

 arch/arm/cpu/armv7/omap-common/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/cpu/armv7/omap-common/Kconfig +0 -0
index 4daccd9..91d6b2c 100644

arch/arm/cpu/armv7/omap-common/Kconfig line 6

Quoted 7 lines
arch/arm/cpu/armv7/omap-common/Kconfig +1 -1
@@ -1,6 +1,6 @@
 config TI_SECURE_DEVICE
 	bool "HS Device Type Support"
-	depends on OMAP54XX || AM43XX || AM33XX
+	depends on OMAP54XX || AM43XX || AM33XX || ARCH_KEYSTONE
 	help
 	  If a high secure (HS) device type is being used, this config
 	  must be set. This option impacts various aspects of the
Acked-by Dan Murphy <[email protected]>
Signature · 2 lines
------------------
Dan Murphy
author
#9 lore raw

PATCH 4/7 arm: omap-common: Reuse secure image name between OMAP and keystone

In reply to Madan Srinivas

As K2 can directly boot u-boot, re-use u-boot_HS_XIP_X-LOADER as the secure image while booting secure K2 devices. Updates the comments in the file to reflect this.

Signed-off-by Madan Srinivas <[email protected]>

---

 arch/arm/cpu/armv7/omap-common/config_secure.mk | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
arch/arm/cpu/armv7/omap-common/config_secure.mk +3 -1
index 1122439..ae5e8de 100644
@@ -78,7 +78,9 @@ u-boot-spl_HS_SPI_X-LOADER: $(obj)/u-boot-spl.bin
 
 # 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_* prefix. Keystone devices also support a single stage boot
+# so this image can be used for booting from all media on keystone
+# secure devices
 u-boot_HS_XIP_X-LOADER: $(obj)/u-boot.bin
 	$(call if_changed,mkomapsecimg)
Signature · 1 line
2.7.4
#10 lore raw

PATCH 4/7 arm: omap-common: Reuse secure image name between OMAP and keystone

Quoted 15 lines · Madan Srinivas

As K2 can directly boot u-boot, re-use u-boot_HS_XIP_X-LOADER as the secure image while booting secure K2 devices. Updates the comments in the file to reflect this.

Signed-off-by Madan Srinivas <[email protected]>

---

 arch/arm/cpu/armv7/omap-common/config_secure.mk | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
arch/arm/cpu/armv7/omap-common/config_secure.mk +0 -0
index 1122439..ae5e8de 100644

arch/arm/cpu/armv7/omap-common/config_secure.mk u-boot-spl_HS_SPI_X-LOADER: $(obj)/u-boot-spl.bin · line 79

Quoted 2 lines
arch/arm/cpu/armv7/omap-common/config_secure.mk +0 -0
@@ -78,7 +78,9 @@ u-boot-spl_HS_SPI_X-LOADER: $(obj)/u-boot-spl.bin
 
 # For supporting single stage XiP QSPI on AM43xx, the image is a full u-boot

If we are re-using this name for as the various mode image for K2, then this above line is wrong, and much of the XIP* info in this file is then wrong.

I think it would make more sense to just go ahead and add a new target for this, u-boot_HS_MLO perhaps, as the "MLO" target is already used for K2 as the general boot media target.

Quoted 9 lines
arch/arm/cpu/armv7/omap-common/config_secure.mk +3 -1
 # file, not an SPL. In this case the mkomapsecimg command looks for a
-# u-boot-HS_* prefix
+# u-boot-HS_* prefix. Keystone devices also support a single stage boot
+# so this image can be used for booting from all media on keystone
+# secure devices
 u-boot_HS_XIP_X-LOADER: $(obj)/u-boot.bin
 	$(call if_changed,mkomapsecimg)
author
#11 lore raw

PATCH 5/7 arm: mach-keystone: config.mk: Adds support for secure images on K2

In reply to Madan Srinivas

Adds an additional image type needed for supporting secure keystone devices. The build generates u-boot_HS_XIP_X-LOADER which can be used to boot from all media on secure keystone devices.

Signed-off-by Madan Srinivas <[email protected]>

---

 arch/arm/mach-keystone/config.mk | 6 ++++++
 1 file changed, 6 insertions(+)
arch/arm/mach-keystone/config.mk +6 -0
index 9ae1e9a..565d718 100644
@@ -5,9 +5,15 @@
 # SPDX-License-Identifier:     GPL-2.0+
 #
 
+include  $(srctree)/$(CPUDIR)/omap-common/config_secure.mk
+
 ifndef CONFIG_SPL_BUILD
+ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
+ALL-y += u-boot_HS_XIP_X-LOADER
+else
 ALL-y += MLO
 endif
+endif
 
 MKIMAGEFLAGS_u-boot-spl.gph = -A $(ARCH) -T gpimage -C none \
 	-a $(CONFIG_SPL_TEXT_BASE) -e $(CONFIG_SPL_TEXT_BASE) -n SPL
Signature · 1 line
2.7.4
#12 lore raw

PATCH 5/7 arm: mach-keystone: config.mk: Adds support for secure images on K2

Quoted 15 lines · Madan Srinivas

Adds an additional image type needed for supporting secure keystone devices. The build generates u-boot_HS_XIP_X-LOADER which can be used to boot from all media on secure keystone devices.

Signed-off-by Madan Srinivas <[email protected]>

---

 arch/arm/mach-keystone/config.mk | 6 ++++++
 1 file changed, 6 insertions(+)
arch/arm/mach-keystone/config.mk +0 -0
index 9ae1e9a..565d718 100644

arch/arm/mach-keystone/config.mk line 12

Quoted 8 lines
arch/arm/mach-keystone/config.mk +4 -0
@@ -5,9 +5,15 @@
 # SPDX-License-Identifier:     GPL-2.0+
 #
 
+include  $(srctree)/$(CPUDIR)/omap-common/config_secure.mk
+
 ifndef CONFIG_SPL_BUILD
+ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
+ALL-y += u-boot_HS_XIP_X-LOADER

Same comment as before, u-boot_HS_MLO here would match the regular MLO target below.

Quoted 8 lines
arch/arm/mach-keystone/config.mk +2 -0
+else
 ALL-y += MLO
 endif
+endif
 
 MKIMAGEFLAGS_u-boot-spl.gph = -A $(ARCH) -T gpimage -C none \
 	-a $(CONFIG_SPL_TEXT_BASE) -e $(CONFIG_SPL_TEXT_BASE) -n SPL
author
#13 lore raw

PATCH 6/7 doc: Updates info on using keystone secure devices from TI

In reply to Madan Srinivas

Add a section describing the secure boot image used on keystone secure devices.

This patch applies on top of the patch
doc: Update info on using AM33xx secure devices from TI submitted by Andrew Davis

Signed-off-by Madan Srinivas <[email protected]>

---

 doc/README.ti-secure | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)
doc/README.ti-secure +20 -0
index 9b0fbf9..ffda69a 100644
@@ -133,6 +133,26 @@ Booting of U-Boot SPL
 	u-boot-spl_HS_X-LOADER - boot image for all other flash memories
 		including QSPI and NOR flash
 
+        Invoking the script for Keystone Secure Devices
+        =============================================
+
+        create-boot-image.sh \
+                <UNUSED> <INPUT_FILE> <OUTPUT_FILE> <UNUSED>
+
+        <UNUSED> is currently ignored and reserved for future use.
+
+        <INPUT_FILE> is the full path and filename of the public world boot
+        loader binary file (only u-boot.bin is currently supported on
+	keystone devices, u-boot-spl.bin is not currently supported).
+
+        <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_HS_XIP_X-LOADER - signed and encrypted boot image that can
+		be used to boot from all media. Secure boot from SPI NOR
+		flash is not currently supported.
+
 Booting of Primary U-Boot (u-boot.img)
 ======================================
Signature · 1 line
2.7.4
author
#14 lore raw

PATCH 7/7 configs: Adds a defconfig for K2E High Security EVM

In reply to Madan Srinivas

From: Vitaly Andrianov <[email protected]>

Add a new defconfig file for the K2E High Security EVM.

This defconfig is the same as for the non-secure part, except for:
CONFIG_TI_SECURE_DEVICE option set to 'y' CONFIG_FIT option set to 'y' CONFIG_FIT_IMAGE_POST_PROCESS option set to 'y'

Enables the platform-specific post-processing of FIT-extracted blobs such as Kernel, DTB, and initramfs on TI K2E high-security (HS) devices which will ultimately invokes TI proprietary secure functions that performs secure processing such as blob authentication and decryption.

Signed-off-by Vitaly Andrianov <[email protected]>
Signed-off-by Madan Srinivas <[email protected]>

---

 configs/k2e_hs_evm_defconfig | 44 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)
 create mode 100644 configs/k2e_hs_evm_defconfig
configs/k2e_hs_evm_defconfig new file +44 -0
new file mode 100644
index 0000000..ec0542d
@@ -0,0 +1,44 @@
+CONFIG_ARM=y
+CONFIG_ARCH_KEYSTONE=y
+CONFIG_TARGET_K2E_EVM=y
+CONFIG_DM_SERIAL=y
+CONFIG_DEFAULT_DEVICE_TREE="k2e-evm"
+CONFIG_SPL=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_HUSH_PARSER=y
+CONFIG_SYS_PROMPT="K2E EVM # "
+CONFIG_CMD_BOOTZ=y
+# CONFIG_CMD_IMLS is not set
+CONFIG_CMD_ASKENV=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_NAND=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_EXT4_WRITE=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
+CONFIG_OF_CONTROL=y
+CONFIG_DM=y
+CONFIG_TI_AEMIF=y
+CONFIG_DM_SPI=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_DM_ETH=y
+CONFIG_SYS_NS16550=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_LIB_RAND=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_FIT=y
+CONFIG_FIT_IMAGE_POST_PROCESS=y
Signature · 1 line
2.7.4
#15 lore raw

PATCH 7/7 configs: Adds a defconfig for K2E High Security EVM

Quoted 64 lines · Madan Srinivas

From: Vitaly Andrianov <[email protected]>

Add a new defconfig file for the K2E High Security EVM.

This defconfig is the same as for the non-secure part, except for:
CONFIG_TI_SECURE_DEVICE option set to 'y' CONFIG_FIT option set to 'y' CONFIG_FIT_IMAGE_POST_PROCESS option set to 'y'

Enables the platform-specific post-processing of FIT-extracted blobs such as Kernel, DTB, and initramfs on TI K2E high-security (HS) devices which will ultimately invokes TI proprietary secure functions that performs secure processing such as blob authentication and decryption.

Signed-off-by Vitaly Andrianov <[email protected]>
Signed-off-by Madan Srinivas <[email protected]>

---

 configs/k2e_hs_evm_defconfig | 44 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)
 create mode 100644 configs/k2e_hs_evm_defconfig
configs/k2e_hs_evm_defconfig new file +34 -0
new file mode 100644
index 0000000..ec0542d
@@ -0,0 +1,44 @@
+CONFIG_ARM=y
+CONFIG_ARCH_KEYSTONE=y
+CONFIG_TARGET_K2E_EVM=y
+CONFIG_DM_SERIAL=y
+CONFIG_DEFAULT_DEVICE_TREE="k2e-evm"
+CONFIG_SPL=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_HUSH_PARSER=y
+CONFIG_SYS_PROMPT="K2E EVM # "
+CONFIG_CMD_BOOTZ=y
+# CONFIG_CMD_IMLS is not set
+CONFIG_CMD_ASKENV=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_NAND=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_EXT4_WRITE=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
+CONFIG_OF_CONTROL=y
+CONFIG_DM=y
+CONFIG_TI_AEMIF=y
+CONFIG_DM_SPI=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_STMICRO=y

configs/k2e_hs_evm_defconfig line 44

Quoted 10 lines
configs/k2e_hs_evm_defconfig new file +10 -0
+CONFIG_DM_ETH=y
+CONFIG_SYS_NS16550=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_LIB_RAND=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_FIT=y
+CONFIG_FIT_IMAGE_POST_PROCESS=y

Although it makes it more clear when adding new options to add them to the end, when someone regenerates this defconfig with savedefconfig or similar tools, these options will get moved up into their natural order, causing more delta to their patches than necessary. This should be regenerated (make k2e_hs_evm_defconfig; make savedefconfig; cp defconfig configs/k2e_hs_evm_defconfig).

author
#16 lore raw

v2 cover Adds support for secure boot on Keystone SoCs (K2E)

This series adds support for secure keystone family of devices, more specifically for K2E (Edison).This work is similar to what has already been done for the AM43xx and AM57xx SoCs and leverages much of the infrastructure from them.

The big difference here is the ROM on keystone2 devices does not provide any APIs for image authentication. Rather, the image authentication and decryption routines and other security functions are provided by software and can run on the ARM in Trustzone as well as on secure DSPs.

A component known as the boot monitor acts as they gateway to this secure processing, and abstracts out the details from the public world. Unlike OMAP class devices, where u-boot calls ROM APIs, u-boot calls into the boot- monitor on keystone devices.

Other than this difference, most of the secure framework for AMxx and DRAxx devices have been re-used.

Couple of other points to note :-

-Support for SPL on secure keystone devices is still TBD, so boot from SPI flash, which needs SPL, is not supported currently on K2 devices.

-A single image will work across all other boot media for secure K2 devices.

Changes in v2:
- Corrects typo in commit message for PATCH 1/7 in this series
- The following changes are made to mon.c based on review comments Adds NULL pointer check before calling authentication interface Removes an unnecessary printf
Updates size of signed FIT blob after post processing removes header
- Adds a new name for the signed output image in config_secure.mk to keep it in line with the image name used by non-secure keystone devices.
- Changes the target for secure keystone devices in config.mk
to u-boot_HS_MLO to keep it in line with the MLO target that is built for non-secure keystone devices.
- Updates k2e_hs_evm_defconfig to reduce the delta seen if one regenerates it using savedefconfig or similar tools.

Madan Srinivas (4):
include: image.h: Fixes build warning with
CONFIG_FIT_IMAGE_POST_PROCESS
arm: omap-common: adds secure image name common to OMAP and keystone
arm: mach-keystone: config.mk: Adds support for secure images on K2
doc: Updates info on using keystone secure devices from TI

Vitaly Andrianov (3):
arm: mach-keystone: Implements FIT post-processing call for keystone
SoCs
arm: omap-common: Enable support for K2 HS devices in u-boot
configs: Adds a defconfig for K2E High Security EVM

 arch/arm/cpu/armv7/omap-common/Kconfig          |  2 +-
 arch/arm/cpu/armv7/omap-common/config_secure.mk |  6 +++
 arch/arm/mach-keystone/config.mk                |  6 +++
 arch/arm/mach-keystone/mon.c                    | 55 +++++++++++++++++++++++++
 configs/k2e_hs_evm_defconfig                    | 43 +++++++++++++++++++
 doc/README.ti-secure                            | 20 +++++++++
 include/image.h                                 |  3 +-
 7 files changed, 133 insertions(+), 2 deletions(-)
 create mode 100644 configs/k2e_hs_evm_defconfig
Signature · 1 line
2.7.4
author
#17 lore raw

PATCH v2 1/7 include: image.h: Fixes build warning with CONFIG_FIT_IMAGE_POST_PROCESS

The function board_fit_image_post_process is defined only when the config CONFIG_FIT_IMAGE_POST_PROCESS is enabled. For secure systems that do not use SPL but use FIT kernel images, only CONFIG_FIT_IMAGE_POST_PROCESS will be defined, which will result in an implicit declaration of function 'board_fit_image_post_process' warning while building u-boot. This patch fixes this warning.

Signed-off-by Madan Srinivas <[email protected]>
Acked-by Andrew F. Davis <[email protected]>
Cc Andrew F. Davis <[email protected]>

---

Changes in v2:
- Corrects typo in commit message for PATCH 1/7 in this series

 include/image.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
include/image.h +2 -1
index 64da722..6884421 100644
@@ -1245,7 +1245,8 @@ 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
+#if defined(CONFIG_SPL_FIT_IMAGE_POST_PROCESS) || \
+	defined(CONFIG_FIT_IMAGE_POST_PROCESS)
 /**
  * board_fit_image_post_process() - Do any post-process on FIT binary data
  *
Signature · 1 line
2.7.4
#18 lore raw

PATCH v2 1/7 include: image.h: Fixes build warning with CONFIG_FIT_IMAGE_POST_PROCESS

Quoted 11 lines · Madan Srinivas

The function board_fit_image_post_process is defined only when the config CONFIG_FIT_IMAGE_POST_PROCESS is enabled. For secure systems that do not use SPL but use FIT kernel images, only CONFIG_FIT_IMAGE_POST_PROCESS will be defined, which will result in an implicit declaration of function 'board_fit_image_post_process' warning while building u-boot. This patch fixes this warning.

Signed-off-by Madan Srinivas <[email protected]>
Acked-by Andrew F. Davis <[email protected]>
Cc Andrew F. Davis <[email protected]>
Reviewed-by Tom Rini <[email protected]>
Signature · 8 lines
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/20160906/0c055ee8/attachment.sig>
#19 lore raw

PATCH v2 1/7 include: image.h: Fixes build warning with CONFIG_FIT_IMAGE_POST_PROCESS

In reply to Madan Srinivas
Quoted 11 lines · Madan Srinivas

The function board_fit_image_post_process is defined only when the config CONFIG_FIT_IMAGE_POST_PROCESS is enabled. For secure systems that do not use SPL but use FIT kernel images, only CONFIG_FIT_IMAGE_POST_PROCESS will be defined, which will result in an implicit declaration of function 'board_fit_image_post_process' warning while building u-boot. This patch fixes this warning.

Signed-off-by Madan Srinivas <[email protected]>
Acked-by Andrew F. Davis <[email protected]>
Cc Andrew F. Davis <[email protected]>
Reviewed-by Tom Rini <[email protected]>
Signature · 8 lines
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/20160906/3f89dabb/attachment.sig>
author
#20 lore raw

PATCH v2 2/7 arm: mach-keystone: Implements FIT post-processing call for keystone SoCs

In reply to Madan Srinivas

From: Vitaly Andrianov <[email protected]>

This commit implements the board_fit_image_post_process() function for the keystone architecture. Unlike OMAP class devices, security functions in keystone are not handled in the ROM.
The interface to the secure functions is TI proprietary and depending on the keystone platform, the security functions like encryption, decryption and authentication might even be offloaded to other secure processing elements in the SoC.
The boot monitor acts as the gateway to these secure functions and the boot monitor for secure devices is available as part of the SECDEV package for KS2. For more details refer doc/README.ti-secure

Signed-off-by Vitaly Andrianov <[email protected]>
Signed-off-by Madan Srinivas <[email protected]>
Cc Lokesh Vutla <[email protected]>
Cc Dan Murphy <[email protected]>

---

Changes in v2:
- The following changes are made to mon.c based on review comments Adds NULL pointer check before calling authentication interface Removes an unnecessary printf
Updates size of signed FIT blob after post processing removes header

 arch/arm/mach-keystone/mon.c | 55 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)
arch/arm/mach-keystone/mon.c +55 -0
index 256f630..6b79077 100644
@@ -12,10 +12,31 @@
 #include <mach/mon.h>
 asm(".arch_extension sec\n\t");
 
+#ifdef CONFIG_TI_SECURE_DEVICE
+#define KS2_HS_AUTH_FN_OFFSET	8
+#define KS2_HS_SEC_HEADER_LEN	0x60
+#define KS2_AUTH_CMD		"2"
+/**
+ * (*fn_auth)() - Invokes security functions using a
+ * proprietary TI interface. This binary and source for
+ * this is available in the secure development package or
+ * SECDEV. For details on how to access this please refer
+ * doc/README.ti-secure
+ *
+ * @first param:	no. of parameters
+ * @second param:	parameter list
+ * @return non-zero value on success, zero on error
+ */
+static unsigned int (*fn_auth)(int, char * const []);
+#endif
+
 int mon_install(u32 addr, u32 dpsc, u32 freq)
 {
 	int result;
 
+#ifdef CONFIG_TI_SECURE_DEVICE
+	fn_auth = (void *)(addr + KS2_HS_AUTH_FN_OFFSET);
+#endif
 	__asm__ __volatile__ (
 		"stmfd r13!, {lr}\n"
 		"mov r0, %1\n"

@@ -61,3 +82,37 @@ int mon_power_off(int core_id)
 		: "cc", "r0", "r1", "memory");
 	return  result;
 }
+
+#ifdef CONFIG_TI_SECURE_DEVICE
+static void k2_hs_auth(void *addr)
+{
+	char *argv1 = KS2_AUTH_CMD;
+	char argv2[32];
+	char *argv[3] = {NULL, argv1, argv2};
+	int ret = 0;
+
+	sprintf(argv2, "0x%08x", (u32)addr);
+
+	if (fn_auth)
+		ret = fn_auth(3, argv);
+
+	if (ret == 0)
+		hang();
+}
+
+void board_fit_image_post_process(void **p_image, size_t *p_size)
+{
+	void *dst = *p_image;
+	void *src = dst + KS2_HS_SEC_HEADER_LEN;
+
+	k2_hs_auth(*p_image);
+
+	/*
+	* Overwrite the image headers  after authentication
+	* and decryption. Update size to relect removal
+	* of header.
+	*/
+	*p_size -= KS2_HS_SEC_HEADER_LEN;
+	memcpy(dst, src, *p_size);
+}
+#endif
Signature · 1 line
2.7.4
#21 lore raw

PATCH v2 2/7 arm: mach-keystone: Implements FIT post-processing call for keystone SoCs

Quoted 13 lines · Madan Srinivas

From: Vitaly Andrianov <[email protected]>

This commit implements the board_fit_image_post_process() function for the keystone architecture. Unlike OMAP class devices, security functions in keystone are not handled in the ROM.
The interface to the secure functions is TI proprietary and depending on the keystone platform, the security functions like encryption, decryption and authentication might even be offloaded to other secure processing elements in the SoC.
The boot monitor acts as the gateway to these secure functions and the boot monitor for secure devices is available as part of the SECDEV package for KS2. For more details refer doc/README.ti-secure

Quoted 5 lines
Signed-off-by Vitaly Andrianov <[email protected]>
Signed-off-by Madan Srinivas <[email protected]>
Cc Lokesh Vutla <[email protected]>
Cc Dan Murphy <[email protected]>

First, what is done to ensure that the magic blob we're offloading to isn't malicious? Second, this appears to be missing cache flushes that're done in arch/arm/cpu/armv7/omap-common/sec-common.c and, well, why can't we re-use the existing code? Given how rarely IP blocks are written from scratch rather than being an evolution of a previous block I can't imagine that we can't make the code there be re-used nor that we don't need / couldn't use the flushing and alignment checks nor status messages. Thanks!

Signature · 8 lines
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/20160906/51e8e8f6/attachment.sig>
#22 lore raw

PATCH v2 2/7 arm: mach-keystone: Implements FIT post-processing call for keystone SoCs

Quoted 15 lines · Tom Rini
Quoted 13 lines · Madan Srinivas

From: Vitaly Andrianov <[email protected]>

This commit implements the board_fit_image_post_process() function for the keystone architecture. Unlike OMAP class devices, security functions in keystone are not handled in the ROM.
The interface to the secure functions is TI proprietary and depending on the keystone platform, the security functions like encryption, decryption and authentication might even be offloaded to other secure processing elements in the SoC.
The boot monitor acts as the gateway to these secure functions and the boot monitor for secure devices is available as part of the SECDEV package for KS2. For more details refer doc/README.ti-secure

Quoted 8 lines
Quoted 5 lines
Signed-off-by Vitaly Andrianov <[email protected]>
Signed-off-by Madan Srinivas <[email protected]>
Cc Lokesh Vutla <[email protected]>
Cc Dan Murphy <[email protected]>

First, what is done to ensure that the magic blob we're offloading to isn't malicious?

The magic blob is signed and authenticated as part of the boot flow to ensure that it is not malicious.

Quoted 4 lines

Second, this appears to be missing cache flushes
that're done in arch/arm/cpu/armv7/omap-common/sec-common.c and, well, why can't we re-use the existing code? Given how rarely IP blocks are written from scratch rather than being an evolution of a previous block

Valid point Tom, but this case is the exception to that rule - the Keystone and the OMAP ROMs were developed independently, the keystone ROMs were based on DSP ROMs, not on OMAP, and therefore the code omap-common/in sec-common.c cannot be reused at all for keystone - the calling conventions, parameters APIs are all different.

Quoted 4 lines

I can't imagine that we can't make the code there be re-used nor that we don't need / couldn't use the flushing and alignment checks nor status messages. Thanks!

Unlike OMAP, in keystone2 for eg, the authentication is also done by DSP, so the code in sec-common.c cannot be reused at all. Even if K2 ROM APIs are used, the calling conventions are different. Also, unlike OMAP, the boot monitor has a secure and non-secure component (everything gets authenticated).

Again in OMAP the authentication is always done using only ROM APIs, whereas in keystone the authentication and decryption can be done using ROM, Secure ARM libraries or Secure DSP libraries. Using the current scheme, this can be achieved simply by selecting a different boot monitor binary to include in the signing step, the same u-boot binary will work for all three authentication schemes.

Regards,
Madan

author
#23 lore raw

PATCH v2 3/7 arm: omap-common: adds secure image name common to OMAP and keystone

In reply to Madan Srinivas

As K2 can directly boot u-boot, add u-boot_HS_MLO as the secure image while booting secure K2 devicesr, for all boot modes other than SPI flash.

Signed-off-by Madan Srinivas <[email protected]>

---

Changes in v2:
- Adds a new name for the signed output image in config_secure.mk to keep it in line with the image name used by non-secure keystone devices.

 arch/arm/cpu/armv7/omap-common/config_secure.mk | 6 ++++++
 1 file changed, 6 insertions(+)
arch/arm/cpu/armv7/omap-common/config_secure.mk +6 -0
index 1122439..0ece3f8 100644
@@ -76,6 +76,12 @@ u-boot-spl_HS_ISSW: $(obj)/u-boot-spl.bin
 u-boot-spl_HS_SPI_X-LOADER: $(obj)/u-boot-spl.bin
 	$(call if_changed,mkomapsecimg)
 
+# For supporting single stage boot on keystone, the image is a full u-boot
+# file, not an SPL. This will work for all boot devices, other than SPI
+# flash
+u-boot_HS_MLO: $(obj)/u-boot.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
Signature · 1 line
2.7.4
#24 lore raw

PATCH v2 3/7 arm: omap-common: adds secure image name common to OMAP and keystone

Quoted 6 lines · Madan Srinivas

As K2 can directly boot u-boot, add u-boot_HS_MLO as the secure image while booting secure K2 devicesr, for all boot modes other than SPI flash.

Signed-off-by Madan Srinivas <[email protected]>
Reviewed-by Tom Rini <[email protected]>
Signature · 8 lines
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/20160906/8da205df/attachment.sig>
author
#25 lore raw

PATCH v2 4/7 arm: omap-common: Enable support for K2 HS devices in u-boot

In reply to Madan Srinivas

From: Vitaly Andrianov <[email protected]>

Like the OMAP54xx, AM43xx & AM33xx family SoCs, the keystone family of SoCs also have high security enabled models. Allow K2E devices to be built with HS Device Type Support.

This patch applies on top of the patch
ti: omap-common: Allow AM33xx devices to be built securely submitted by Andrew Davis

Signed-off-by Vitaly Andrianov <[email protected]>
Signed-off-by Madan Srinivas <[email protected]>
Acked-by Andrew F. Davis <[email protected]>

---

Changes in v2: None

 arch/arm/cpu/armv7/omap-common/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/cpu/armv7/omap-common/Kconfig +1 -1
index 4daccd9..91d6b2c 100644
@@ -1,6 +1,6 @@
 config TI_SECURE_DEVICE
 	bool "HS Device Type Support"
-	depends on OMAP54XX || AM43XX || AM33XX
+	depends on OMAP54XX || AM43XX || AM33XX || ARCH_KEYSTONE
 	help
 	  If a high secure (HS) device type is being used, this config
 	  must be set. This option impacts various aspects of the
Signature · 1 line
2.7.4
#26 lore raw

PATCH v2 4/7 arm: omap-common: Enable support for K2 HS devices in u-boot

Quoted 6 lines · Madan Srinivas

From: Vitaly Andrianov <[email protected]>

Like the OMAP54xx, AM43xx & AM33xx family SoCs, the keystone family of SoCs also have high security enabled models. Allow K2E devices to be built with HS Device Type Support.

Quoted 7 lines

This patch applies on top of the patch
ti: omap-common: Allow AM33xx devices to be built securely submitted by Andrew Davis

Signed-off-by Vitaly Andrianov <[email protected]>
Signed-off-by Madan Srinivas <[email protected]>
Acked-by Andrew F. Davis <[email protected]>
Reviewed-by Tom Rini <[email protected]>
Signature · 8 lines
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/20160906/8b770e8e/attachment.sig>
author
#27 lore raw

PATCH v2 5/7 arm: mach-keystone: config.mk: Adds support for secure images on K2

In reply to Madan Srinivas

Adds an additional image type needed for supporting secure keystone devices. The build generates u-boot_HS_XIP_X-LOADER which can be used to boot from all media on secure keystone devices.

Signed-off-by Madan Srinivas <[email protected]>
Cc Andrew F. Davis <[email protected]>

---

Changes in v2:
- Changes the target for secure keystone devices in config.mk to u-boot_HS_MLO to keep it in line with the MLO target that is built for non-secure keystone devices.

 arch/arm/mach-keystone/config.mk | 6 ++++++
 1 file changed, 6 insertions(+)
arch/arm/mach-keystone/config.mk +6 -0
index 9ae1e9a..32fef42 100644
@@ -5,9 +5,15 @@
 # SPDX-License-Identifier:     GPL-2.0+
 #
 
+include  $(srctree)/$(CPUDIR)/omap-common/config_secure.mk
+
 ifndef CONFIG_SPL_BUILD
+ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
+ALL-y += u-boot_HS_MLO
+else
 ALL-y += MLO
 endif
+endif
 
 MKIMAGEFLAGS_u-boot-spl.gph = -A $(ARCH) -T gpimage -C none \
 	-a $(CONFIG_SPL_TEXT_BASE) -e $(CONFIG_SPL_TEXT_BASE) -n SPL
Signature · 1 line
2.7.4
#28 lore raw

PATCH v2 5/7 arm: mach-keystone: config.mk: Adds support for secure images on K2

Quoted 6 lines · Madan Srinivas

Adds an additional image type needed for supporting secure keystone devices. The build generates u-boot_HS_XIP_X-LOADER which can be used to boot from all media on secure keystone devices.

Signed-off-by Madan Srinivas <[email protected]>
Quoted 8 lines
Cc Andrew F. Davis <[email protected]>

---

Changes in v2:
- Changes the target for secure keystone devices in config.mk to u-boot_HS_MLO to keep it in line with the MLO target that is built for non-secure keystone devices.

The commit message is wrong now, it still calls it XIP_X-LOADER.

Quoted 24 lines
 arch/arm/mach-keystone/config.mk | 6 ++++++
 1 file changed, 6 insertions(+)
arch/arm/mach-keystone/config.mk +6 -0
index 9ae1e9a..32fef42 100644
@@ -5,9 +5,15 @@
 # SPDX-License-Identifier:     GPL-2.0+
 #
 
+include  $(srctree)/$(CPUDIR)/omap-common/config_secure.mk
+
 ifndef CONFIG_SPL_BUILD
+ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
+ALL-y += u-boot_HS_MLO
+else
 ALL-y += MLO
 endif
+endif
 
 MKIMAGEFLAGS_u-boot-spl.gph = -A $(ARCH) -T gpimage -C none \
 	-a $(CONFIG_SPL_TEXT_BASE) -e $(CONFIG_SPL_TEXT_BASE) -n SPL
author
#29 lore raw

PATCH v2 6/7 doc: Updates info on using keystone secure devices from TI

In reply to Madan Srinivas

Add a section describing the secure boot image used on keystone secure devices.

This patch applies on top of the patch
doc: Update info on using AM33xx secure devices from TI submitted by Andrew Davis

Signed-off-by Madan Srinivas <[email protected]>

---

Changes in v2:
- Updates the secure keystone image name to u-boot_HS_MLO in README.ti-secure to match with the changes made to config.mk in this series version.

 doc/README.ti-secure | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)
doc/README.ti-secure +20 -0
index 9b0fbf9..84c7206 100644
@@ -133,6 +133,26 @@ Booting of U-Boot SPL
 	u-boot-spl_HS_X-LOADER - boot image for all other flash memories
 		including QSPI and NOR flash
 
+        Invoking the script for Keystone Secure Devices
+        =============================================
+
+        create-boot-image.sh \
+                <UNUSED> <INPUT_FILE> <OUTPUT_FILE> <UNUSED>
+
+        <UNUSED> is currently ignored and reserved for future use.
+
+        <INPUT_FILE> is the full path and filename of the public world boot
+        loader binary file (only u-boot.bin is currently supported on
+	keystone devices, u-boot-spl.bin is not currently supported).
+
+        <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_HS_MLO - signed and encrypted boot image that can
+		be used to boot from all media. Secure boot from SPI NOR
+		flash is not currently supported.
+
 Booting of Primary U-Boot (u-boot.img)
 ======================================
Signature · 1 line
2.7.4
#30 lore raw

PATCH v2 6/7 doc: Updates info on using keystone secure devices from TI

Quoted 9 lines · Madan Srinivas

Add a section describing the secure boot image used on keystone secure devices.

This patch applies on top of the patch
doc: Update info on using AM33xx secure devices from TI submitted by Andrew Davis

Signed-off-by Madan Srinivas <[email protected]>
Reviewed-by Tom Rini <[email protected]>
Signature · 8 lines
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/20160906/38d75b3a/attachment.sig>
author
#31 lore raw

PATCH v2 7/7 configs: Adds a defconfig for K2E High Security EVM

In reply to Madan Srinivas

From: Vitaly Andrianov <[email protected]>

Add a new defconfig file for the K2E High Security EVM.

This defconfig is the same as for the non-secure part, except for:
CONFIG_TI_SECURE_DEVICE option set to 'y' CONFIG_FIT option set to 'y' CONFIG_FIT_IMAGE_POST_PROCESS option set to 'y'

Enables the platform-specific post-processing of FIT-extracted blobs such as Kernel, DTB, and initramfs on TI K2E high-security (HS) devices which will ultimately invokes TI proprietary secure functions that performs secure processing such as blob authentication and decryption.

Signed-off-by Vitaly Andrianov <[email protected]>
Signed-off-by Madan Srinivas <[email protected]>
Cc Andrew F. Davis <[email protected]>

---

Changes in v2:
- Updates k2e_hs_evm_defconfig to reduce the delta seen if one regenerates it using savedefconfig or similar tools.

 configs/k2e_hs_evm_defconfig | 43 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)
 create mode 100644 configs/k2e_hs_evm_defconfig
configs/k2e_hs_evm_defconfig new file +43 -0
new file mode 100644
index 0000000..fc8f22a
@@ -0,0 +1,43 @@
+CONFIG_ARM=y
+CONFIG_ARCH_KEYSTONE=y
+CONFIG_TARGET_K2E_EVM=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_DM_SERIAL=y
+CONFIG_DEFAULT_DEVICE_TREE="k2e-evm"
+CONFIG_SPL=y
+CONFIG_FIT=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_FIT_IMAGE_POST_PROCESS=y
+CONFIG_HUSH_PARSER=y
+CONFIG_SYS_PROMPT="K2E EVM # "
+CONFIG_CMD_BOOTZ=y
+# CONFIG_CMD_IMLS is not set
+CONFIG_CMD_ASKENV=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_NAND=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_EXT4_WRITE=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
+CONFIG_OF_CONTROL=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_DM=y
+CONFIG_TI_AEMIF=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_DM_ETH=y
+CONFIG_SYS_NS16550=y
+CONFIG_DM_SPI=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
Signature · 1 line
2.7.4
#32 lore raw

v2 cover Adds support for secure boot on Keystone SoCs (K2E)

In reply to Madan Srinivas
Quoted 18 lines · Madan Srinivas

This series adds support for secure keystone family of devices, more specifically for K2E (Edison).This work is similar to what has already been done for the AM43xx and AM57xx SoCs and leverages much of the infrastructure from them.

The big difference here is the ROM on keystone2 devices does not provide any APIs for image authentication. Rather, the image authentication and decryption routines and other security functions are provided by software and can run on the ARM in Trustzone as well as on secure DSPs.

A component known as the boot monitor acts as they gateway to this secure processing, and abstracts out the details from the public world. Unlike OMAP class devices, where u-boot calls ROM APIs, u-boot calls into the boot- monitor on keystone devices.

Other than this difference, most of the secure framework for AMxx and DRAxx devices have been re-used.

Quoted 8 lines

Couple of other points to note :-

-Support for SPL on secure keystone devices is still TBD, so boot from SPI flash, which needs SPL, is not supported currently on K2 devices.

-A single image will work across all other boot media for secure K2 devices.

Overall looks good to me. What happened to the early abort seen on H2 HS devices. How are you handling it?

Thanks and regards,
Lokesh

Quoted 39 lines

Changes in v2:
- Corrects typo in commit message for PATCH 1/7 in this series
- The following changes are made to mon.c based on review comments Adds NULL pointer check before calling authentication interface Removes an unnecessary printf
Updates size of signed FIT blob after post processing removes header
- Adds a new name for the signed output image in config_secure.mk to keep it in line with the image name used by non-secure keystone devices.
- Changes the target for secure keystone devices in config.mk
to u-boot_HS_MLO to keep it in line with the MLO target that is built for non-secure keystone devices.
- Updates k2e_hs_evm_defconfig to reduce the delta seen if one regenerates it using savedefconfig or similar tools.

Madan Srinivas (4):
include: image.h: Fixes build warning with
CONFIG_FIT_IMAGE_POST_PROCESS
arm: omap-common: adds secure image name common to OMAP and keystone
arm: mach-keystone: config.mk: Adds support for secure images on K2
doc: Updates info on using keystone secure devices from TI

Vitaly Andrianov (3):
arm: mach-keystone: Implements FIT post-processing call for keystone
SoCs
arm: omap-common: Enable support for K2 HS devices in u-boot
configs: Adds a defconfig for K2E High Security EVM

 arch/arm/cpu/armv7/omap-common/Kconfig          |  2 +-
 arch/arm/cpu/armv7/omap-common/config_secure.mk |  6 +++
 arch/arm/mach-keystone/config.mk                |  6 +++
 arch/arm/mach-keystone/mon.c                    | 55 +++++++++++++++++++++++++
 configs/k2e_hs_evm_defconfig                    | 43 +++++++++++++++++++
 doc/README.ti-secure                            | 20 +++++++++
 include/image.h                                 |  3 +-
 7 files changed, 133 insertions(+), 2 deletions(-)
 create mode 100644 configs/k2e_hs_evm_defconfig
#33 lore raw

v2 cover Adds support for secure boot on Keystone SoCs (K2E)

Quoted 27 lines · Lokesh Vutla
Quoted 24 lines · Madan Srinivas

This series adds support for secure keystone family of devices, more specifically for K2E (Edison).This work is similar to what has already been done for the AM43xx and AM57xx SoCs and leverages much of the infrastructure from them.

The big difference here is the ROM on keystone2 devices does not provide any APIs for image authentication. Rather, the image authentication and decryption routines and other security functions are provided by software and can run on the ARM in Trustzone as well as on secure DSPs.

A component known as the boot monitor acts as they gateway to this secure processing, and abstracts out the details from the public world. Unlike OMAP class devices, where u-boot calls ROM APIs, u-boot calls into the boot- monitor on keystone devices.

Other than this difference, most of the secure framework for AMxx and DRAxx devices have been re-used.

Couple of other points to note :-

-Support for SPL on secure keystone devices is still TBD, so boot from SPI flash, which needs SPL, is not supported currently on K2 devices.

Quoted 9 lines
Quoted 2 lines

-A single image will work across all other boot media for secure K2 devices.

Overall looks good to me. What happened to the early abort seen on H2 HS devices. How are you handling it?

Thanks and regards,
Lokesh

The early abort is being handled in the boot monitor code. When the abort handler is implemented in u-boot, we can remove it from the boot monitor.

Regards,
Madan

Quoted 39 lines
Quoted 39 lines

Changes in v2:
- Corrects typo in commit message for PATCH 1/7 in this series
- The following changes are made to mon.c based on review comments Adds NULL pointer check before calling authentication interface Removes an unnecessary printf
Updates size of signed FIT blob after post processing removes header
- Adds a new name for the signed output image in config_secure.mk to keep it in line with the image name used by non-secure keystone devices.
- Changes the target for secure keystone devices in config.mk
to u-boot_HS_MLO to keep it in line with the MLO target that is built for non-secure keystone devices.
- Updates k2e_hs_evm_defconfig to reduce the delta seen if one regenerates it using savedefconfig or similar tools.

Madan Srinivas (4):
include: image.h: Fixes build warning with
CONFIG_FIT_IMAGE_POST_PROCESS
arm: omap-common: adds secure image name common to OMAP and keystone
arm: mach-keystone: config.mk: Adds support for secure images on K2
doc: Updates info on using keystone secure devices from TI

Vitaly Andrianov (3):
arm: mach-keystone: Implements FIT post-processing call for keystone
SoCs
arm: omap-common: Enable support for K2 HS devices in u-boot
configs: Adds a defconfig for K2E High Security EVM

  arch/arm/cpu/armv7/omap-common/Kconfig          |  2 +-
  arch/arm/cpu/armv7/omap-common/config_secure.mk |  6 +++
  arch/arm/mach-keystone/config.mk                |  6 +++
  arch/arm/mach-keystone/mon.c                    | 55 +++++++++++++++++++++++++
  configs/k2e_hs_evm_defconfig                    | 43 +++++++++++++++++++
  doc/README.ti-secure                            | 20 +++++++++
  include/image.h                                 |  3 +-
  7 files changed, 133 insertions(+), 2 deletions(-)

create mode 100644 configs/k2e_hs_evm_defconfig

#34 lore raw

v2 cover Adds support for secure boot on Keystone SoCs (K2E)

Quoted 36 lines · Madan
Quoted 35 lines · Lokesh Vutla
Quoted 20 lines · Madan Srinivas

This series adds support for secure keystone family of devices, more specifically for K2E (Edison).This work is similar to what has already been done for the AM43xx and AM57xx SoCs and leverages much of the infrastructure from them.

The big difference here is the ROM on keystone2 devices does not provide any APIs for image authentication. Rather, the image authentication and decryption routines and other security functions are provided by software and can run on the ARM in Trustzone as well as on secure DSPs.

A component known as the boot monitor acts as they gateway to this secure
processing, and abstracts out the details from the public world. Unlike OMAP class devices, where u-boot calls ROM APIs, u-boot calls into the boot-
monitor on keystone devices.

Other than this difference, most of the secure framework for AMxx and DRAxx devices have been re-used.

Quoted 8 lines

Couple of other points to note :-

-Support for SPL on secure keystone devices is still TBD, so boot from SPI flash, which needs SPL, is not supported currently on K2 devices.

-A single image will work across all other boot media for secure K2 devices.

Overall looks good to me. What happened to the early abort seen on H2 HS devices. How are you handling it?

Quoted 6 lines
Quoted 3 lines

Thanks and regards,
Lokesh

The early abort is being handled in the boot monitor code. When the abort handler is implemented in u-boot, we can remove it from the boot monitor.

What is the expectation when you meant abort handler in u-boot? Do you want to clear the abort or something else?

Thanks and regards,
Lokesh

Quoted 45 lines

Regards,
Madan

Quoted 41 lines
Quoted 41 lines

Changes in v2:
- Corrects typo in commit message for PATCH 1/7 in this series
- The following changes are made to mon.c based on review comments Adds NULL pointer check before calling authentication interface Removes an unnecessary printf
Updates size of signed FIT blob after post processing removes header
- Adds a new name for the signed output image in config_secure.mk to keep it in line with the image name used by non-secure keystone devices.
- Changes the target for secure keystone devices in config.mk to u-boot_HS_MLO to keep it in line with the MLO target that is built for non-secure keystone devices.
- Updates k2e_hs_evm_defconfig to reduce the delta seen if one regenerates it using savedefconfig or similar tools.

Madan Srinivas (4):
include: image.h: Fixes build warning with
CONFIG_FIT_IMAGE_POST_PROCESS
arm: omap-common: adds secure image name common to OMAP and keystone
arm: mach-keystone: config.mk: Adds support for secure images on K2
doc: Updates info on using keystone secure devices from TI

Vitaly Andrianov (3):
arm: mach-keystone: Implements FIT post-processing call for keystone
SoCs
arm: omap-common: Enable support for K2 HS devices in u-boot
configs: Adds a defconfig for K2E High Security EVM

  arch/arm/cpu/armv7/omap-common/Kconfig          |  2 +-
  arch/arm/cpu/armv7/omap-common/config_secure.mk |  6 +++
  arch/arm/mach-keystone/config.mk                |  6 +++
  arch/arm/mach-keystone/mon.c                    | 55
+++++++++++++++++++++++++
  configs/k2e_hs_evm_defconfig                    | 43
+++++++++++++++++++
  doc/README.ti-secure                            | 20 +++++++++
  include/image.h                                 |  3 +-
  7 files changed, 133 insertions(+), 2 deletions(-)

create mode 100644 configs/k2e_hs_evm_defconfig

maintainer
#35 lore raw

v2 cover Adds support for secure boot on Keystone SoCs (K2E)

On 09/03/2016 11:56 AM, Lokesh Vutla wrote:
[...]

Quoted 3 lines

What is the expectation when you meant abort handler in u-boot? Do you want to clear the abort or something else?

report the error and clear the error in u-boot. we should be able to catch errors generated at u-boot level OR rom code level at u-boot. we dont want to detect and hang in kernel - the debug is just painful.

Signature · 2 lines
Regards,
Nishanth Menon