[U-Boot] [PATCH 0/7] Adds support for secure boot on Keystone SoCs (K2E)

[U-Boot] [PATCH 0/7] Adds support for secure boot on Keystone SoCs (K2E)

[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.

	-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

-- 
2.7.4

[U-Boot] [PATCH 1/7] include: image.h: Fixes build warning with CONFIG_FIT_IMAGE_POST_PROCESS

[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
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 <madans@ti.com>
---

 include/image.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/image.h b/include/image.h
index 64da722..6884421 100644
--- a/include/image.h
+++ b/include/image.h
@@ -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
  *
-- 
2.7.4

[U-Boot] [PATCH 1/7] include: image.h: Fixes build warning with CONFIG_FIT_IMAGE_POST_PROCESS

[Andrew F. Davis]

On 08/26/2016 01:30 AM, Madan Srinivas wrote:
> 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.

> 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)

> 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 <madans@ti.com>

Otherwise looks good to me,

Acked-by: Andrew F. Davis <afd@ti.com>

> ---
> 
>  include/image.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/include/image.h b/include/image.h
> index 64da722..6884421 100644
> --- a/include/image.h
> +++ b/include/image.h
> @@ -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
>   *
> 

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

[Madan Srinivas]

From: Vitaly Andrianov <vitalya@ti.com>

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 <vitalya@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
---

 arch/arm/mach-keystone/mon.c | 53 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 53 insertions(+)

diff --git a/arch/arm/mach-keystone/mon.c b/arch/arm/mach-keystone/mon.c
index 256f630..b4a6f1c 100644
--- a/arch/arm/mach-keystone/mon.c
+++ b/arch/arm/mach-keystone/mon.c
@@ -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
-- 
2.7.4

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

[Dan Murphy]

On 08/26/2016 01:30 AM, Madan Srinivas wrote:
> From: Vitaly Andrianov <vitalya@ti.com>
>
> 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 <vitalya@ti.com>
> Signed-off-by: Madan Srinivas <madans@ti.com>
> ---
>
>  arch/arm/mach-keystone/mon.c | 53 ++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 53 insertions(+)
>
> diff --git a/arch/arm/mach-keystone/mon.c b/arch/arm/mach-keystone/mon.c
> index 256f630..b4a6f1c 100644
> --- a/arch/arm/mach-keystone/mon.c
> +++ b/arch/arm/mach-keystone/mon.c
> @@ -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) {

Can this be if (!ret)?

> +		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

> +		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


-- 
------------------
Dan Murphy

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

[Lokesh Vutla]

On Friday 26 August 2016 12:00 PM, Madan Srinivas wrote:
> From: Vitaly Andrianov <vitalya@ti.com>
> 
> 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 <vitalya@ti.com>
> Signed-off-by: Madan Srinivas <madans@ti.com>
> ---
> 
>  arch/arm/mach-keystone/mon.c | 53 ++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 53 insertions(+)
> 
> diff --git a/arch/arm/mach-keystone/mon.c b/arch/arm/mach-keystone/mon.c
> index 256f630..b4a6f1c 100644
> --- a/arch/arm/mach-keystone/mon.c
> +++ b/arch/arm/mach-keystone/mon.c
> @@ -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);

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

> +
> +	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);

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

> +}
> +#endif
> 

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

[Madan Srinivas]

From: Vitaly Andrianov <vitalya@ti.com>

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 <vitalya@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
---

 arch/arm/cpu/armv7/omap-common/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/omap-common/Kconfig b/arch/arm/cpu/armv7/omap-common/Kconfig
index 4daccd9..91d6b2c 100644
--- a/arch/arm/cpu/armv7/omap-common/Kconfig
+++ b/arch/arm/cpu/armv7/omap-common/Kconfig
@@ -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
-- 
2.7.4

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

[Andrew F. Davis]

On 08/26/2016 01:30 AM, Madan Srinivas wrote:
> From: Vitaly Andrianov <vitalya@ti.com>
> 
> 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 <vitalya@ti.com>
> Signed-off-by: Madan Srinivas <madans@ti.com>
> ---

Acked-by: Andrew F. Davis <afd@ti.com>

> 
>  arch/arm/cpu/armv7/omap-common/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/cpu/armv7/omap-common/Kconfig b/arch/arm/cpu/armv7/omap-common/Kconfig
> index 4daccd9..91d6b2c 100644
> --- a/arch/arm/cpu/armv7/omap-common/Kconfig
> +++ b/arch/arm/cpu/armv7/omap-common/Kconfig
> @@ -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
> 

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

[Dan Murphy]

On 08/26/2016 01:30 AM, Madan Srinivas wrote:
> From: Vitaly Andrianov <vitalya@ti.com>
>
> 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 <vitalya@ti.com>
> Signed-off-by: Madan Srinivas <madans@ti.com>
> ---
>
>  arch/arm/cpu/armv7/omap-common/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/cpu/armv7/omap-common/Kconfig b/arch/arm/cpu/armv7/omap-common/Kconfig
> index 4daccd9..91d6b2c 100644
> --- a/arch/arm/cpu/armv7/omap-common/Kconfig
> +++ b/arch/arm/cpu/armv7/omap-common/Kconfig
> @@ -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 <dmurphy@ti.com>

-- 
------------------
Dan Murphy

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

[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 <madans@ti.com>
---

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

diff --git a/arch/arm/cpu/armv7/omap-common/config_secure.mk b/arch/arm/cpu/armv7/omap-common/config_secure.mk
index 1122439..ae5e8de 100644
--- a/arch/arm/cpu/armv7/omap-common/config_secure.mk
+++ b/arch/arm/cpu/armv7/omap-common/config_secure.mk
@@ -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)
 
-- 
2.7.4

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

[Andrew F. Davis]

On 08/26/2016 01:30 AM, Madan Srinivas wrote:
> 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 <madans@ti.com>
> ---
> 
>  arch/arm/cpu/armv7/omap-common/config_secure.mk | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/cpu/armv7/omap-common/config_secure.mk b/arch/arm/cpu/armv7/omap-common/config_secure.mk
> index 1122439..ae5e8de 100644
> --- a/arch/arm/cpu/armv7/omap-common/config_secure.mk
> +++ b/arch/arm/cpu/armv7/omap-common/config_secure.mk
> @@ -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.

>  # 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)
>  
> 

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

[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 <madans@ti.com>
---

 arch/arm/mach-keystone/config.mk | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-keystone/config.mk b/arch/arm/mach-keystone/config.mk
index 9ae1e9a..565d718 100644
--- a/arch/arm/mach-keystone/config.mk
+++ b/arch/arm/mach-keystone/config.mk
@@ -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
-- 
2.7.4

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

[Andrew F. Davis]

On 08/26/2016 01:30 AM, Madan Srinivas wrote:
> 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 <madans@ti.com>
> ---
> 
>  arch/arm/mach-keystone/config.mk | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm/mach-keystone/config.mk b/arch/arm/mach-keystone/config.mk
> index 9ae1e9a..565d718 100644
> --- a/arch/arm/mach-keystone/config.mk
> +++ b/arch/arm/mach-keystone/config.mk
> @@ -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.

> +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
> 

[U-Boot] [PATCH 6/7] doc: Updates info on using keystone secure devices from TI

[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 <madans@ti.com>
---

 doc/README.ti-secure | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/doc/README.ti-secure b/doc/README.ti-secure
index 9b0fbf9..ffda69a 100644
--- a/doc/README.ti-secure
+++ b/doc/README.ti-secure
@@ -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)
 ======================================
 
-- 
2.7.4

[U-Boot] [PATCH 7/7] configs: Adds a defconfig for K2E High Security EVM

[Madan Srinivas]

From: Vitaly Andrianov <vitalya@ti.com>

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 <vitalya@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
---

 configs/k2e_hs_evm_defconfig | 44 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)
 create mode 100644 configs/k2e_hs_evm_defconfig

diff --git a/configs/k2e_hs_evm_defconfig b/configs/k2e_hs_evm_defconfig
new file mode 100644
index 0000000..ec0542d
--- /dev/null
+++ b/configs/k2e_hs_evm_defconfig
@@ -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
-- 
2.7.4

[U-Boot] [PATCH 7/7] configs: Adds a defconfig for K2E High Security EVM

[Andrew F. Davis]

On 08/26/2016 01:30 AM, Madan Srinivas wrote:
> From: Vitaly Andrianov <vitalya@ti.com>
> 
> 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 <vitalya@ti.com>
> Signed-off-by: Madan Srinivas <madans@ti.com>
> ---
> 
>  configs/k2e_hs_evm_defconfig | 44 ++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 44 insertions(+)
>  create mode 100644 configs/k2e_hs_evm_defconfig
> 
> diff --git a/configs/k2e_hs_evm_defconfig b/configs/k2e_hs_evm_defconfig
> new file mode 100644
> index 0000000..ec0542d
> --- /dev/null
> +++ b/configs/k2e_hs_evm_defconfig
> @@ -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
> 

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).

[U-Boot] [PATCH v2 0/7] Adds support for secure boot on Keystone SoCs (K2E)

[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.

	-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

-- 
2.7.4

[U-Boot] [PATCH v2 1/7] include: image.h: Fixes build warning with CONFIG_FIT_IMAGE_POST_PROCESS

[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 <madans@ti.com>
Acked-by: Andrew F. Davis <afd@ti.com>

Cc: Andrew F. Davis <afd@ti.com>
---

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(-)

diff --git a/include/image.h b/include/image.h
index 64da722..6884421 100644
--- a/include/image.h
+++ b/include/image.h
@@ -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
  *
-- 
2.7.4

[U-Boot] [PATCH v2 1/7] include: image.h: Fixes build warning with CONFIG_FIT_IMAGE_POST_PROCESS

[Tom Rini]

On Thu, Sep 01, 2016 at 01:04:36AM -0400, Madan Srinivas wrote:

> 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 <madans@ti.com>
> Acked-by: Andrew F. Davis <afd@ti.com>
> 
> Cc: Andrew F. Davis <afd@ti.com>

Reviewed-by: Tom Rini <trini@konsulko.com>

-- 
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>

[U-Boot] [PATCH v2 1/7] include: image.h: Fixes build warning with CONFIG_FIT_IMAGE_POST_PROCESS

[Tom Rini]

On Thu, Sep 01, 2016 at 01:04:36AM -0400, Madan Srinivas wrote:

> 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 <madans@ti.com>
> Acked-by: Andrew F. Davis <afd@ti.com>
> 
> Cc: Andrew F. Davis <afd@ti.com>

Reviewed-by: Tom Rini <trini@konsulko.com>

-- 
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>

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

[Madan Srinivas]

From: Vitaly Andrianov <vitalya@ti.com>

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 <vitalya@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>

Cc: Lokesh Vutla <lokeshvutla@ti.com>
Cc: Dan Murphy <dmurphy@ti.com>
---

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(+)

diff --git a/arch/arm/mach-keystone/mon.c b/arch/arm/mach-keystone/mon.c
index 256f630..6b79077 100644
--- a/arch/arm/mach-keystone/mon.c
+++ b/arch/arm/mach-keystone/mon.c
@@ -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
-- 
2.7.4

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

[Tom Rini]

On Thu, Sep 01, 2016 at 01:04:37AM -0400, Madan Srinivas wrote:

> From: Vitaly Andrianov <vitalya@ti.com>
> 
> 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 <vitalya@ti.com>
> Signed-off-by: Madan Srinivas <madans@ti.com>
> 
> Cc: Lokesh Vutla <lokeshvutla@ti.com>
> Cc: Dan Murphy <dmurphy@ti.com>

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!

-- 
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>

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

[Srinivas, Madan]

On 9/6/2016 9:34 AM, Tom Rini wrote:
> On Thu, Sep 01, 2016 at 01:04:37AM -0400, Madan Srinivas wrote:
>
>> From: Vitaly Andrianov <vitalya@ti.com>
>>
>> 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 <vitalya@ti.com>
>> Signed-off-by: Madan Srinivas <madans@ti.com>
>>
>> Cc: Lokesh Vutla <lokeshvutla@ti.com>
>> Cc: Dan Murphy <dmurphy@ti.com>
>
> 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.
> 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.
> 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

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

[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 <madans@ti.com>

---

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(+)

diff --git a/arch/arm/cpu/armv7/omap-common/config_secure.mk b/arch/arm/cpu/armv7/omap-common/config_secure.mk
index 1122439..0ece3f8 100644
--- a/arch/arm/cpu/armv7/omap-common/config_secure.mk
+++ b/arch/arm/cpu/armv7/omap-common/config_secure.mk
@@ -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
-- 
2.7.4

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

[Tom Rini]

On Thu, Sep 01, 2016 at 01:04:38AM -0400, Madan Srinivas wrote:

> 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 <madans@ti.com>
> 

Reviewed-by: Tom Rini <trini@konsulko.com>

-- 
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>

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

[Madan Srinivas]

From: Vitaly Andrianov <vitalya@ti.com>

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 <vitalya@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
Acked-by: Andrew F. Davis <afd@ti.com>
---

Changes in v2: None

 arch/arm/cpu/armv7/omap-common/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/omap-common/Kconfig b/arch/arm/cpu/armv7/omap-common/Kconfig
index 4daccd9..91d6b2c 100644
--- a/arch/arm/cpu/armv7/omap-common/Kconfig
+++ b/arch/arm/cpu/armv7/omap-common/Kconfig
@@ -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
-- 
2.7.4

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

[Tom Rini]

On Thu, Sep 01, 2016 at 01:04:39AM -0400, Madan Srinivas wrote:

> From: Vitaly Andrianov <vitalya@ti.com>
> 
> 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 <vitalya@ti.com>
> Signed-off-by: Madan Srinivas <madans@ti.com>
> Acked-by: Andrew F. Davis <afd@ti.com>

Reviewed-by: Tom Rini <trini@konsulko.com>

-- 
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>

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

[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 <madans@ti.com>

Cc: Andrew F. Davis <afd@ti.com>
---

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(+)

diff --git a/arch/arm/mach-keystone/config.mk b/arch/arm/mach-keystone/config.mk
index 9ae1e9a..32fef42 100644
--- a/arch/arm/mach-keystone/config.mk
+++ b/arch/arm/mach-keystone/config.mk
@@ -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
-- 
2.7.4

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

[Andrew F. Davis]

On 09/01/2016 12:04 AM, Madan Srinivas wrote:
> 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 <madans@ti.com>
> 
> Cc: Andrew F. Davis <afd@ti.com>
> ---
> 
> 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.

>  arch/arm/mach-keystone/config.mk | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm/mach-keystone/config.mk b/arch/arm/mach-keystone/config.mk
> index 9ae1e9a..32fef42 100644
> --- a/arch/arm/mach-keystone/config.mk
> +++ b/arch/arm/mach-keystone/config.mk
> @@ -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
> 

[U-Boot] [PATCH v2 6/7] doc: Updates info on using keystone secure devices from TI

[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 <madans@ti.com>

---

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(+)

diff --git a/doc/README.ti-secure b/doc/README.ti-secure
index 9b0fbf9..84c7206 100644
--- a/doc/README.ti-secure
+++ b/doc/README.ti-secure
@@ -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)
 ======================================
 
-- 
2.7.4

[U-Boot] [PATCH v2 6/7] doc: Updates info on using keystone secure devices from TI

[Tom Rini]

On Thu, Sep 01, 2016 at 01:04:41AM -0400, Madan Srinivas wrote:

> 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 <madans@ti.com>
> 

Reviewed-by: Tom Rini <trini@konsulko.com>

-- 
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>

[U-Boot] [PATCH v2 7/7] configs: Adds a defconfig for K2E High Security EVM

[Madan Srinivas]

From: Vitaly Andrianov <vitalya@ti.com>

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 <vitalya@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>

Cc: Andrew F. Davis <afd@ti.com>
---

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

diff --git a/configs/k2e_hs_evm_defconfig b/configs/k2e_hs_evm_defconfig
new file mode 100644
index 0000000..fc8f22a
--- /dev/null
+++ b/configs/k2e_hs_evm_defconfig
@@ -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
-- 
2.7.4

[U-Boot] [PATCH v2 0/7] Adds support for secure boot on Keystone SoCs (K2E)

[Lokesh Vutla]

On Thursday 01 September 2016 10:34 AM, Madan Srinivas wrote:
> 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.

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

> 
> 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
> 

[U-Boot] [PATCH v2 0/7] Adds support for secure boot on Keystone SoCs (K2E)

[Srinivas, Madan]

On 9/2/2016 12:25 AM, Lokesh Vutla wrote:
>
>
> On Thursday 01 September 2016 10:34 AM, Madan Srinivas wrote:
>> 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.
>
> 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
>>
>> 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
>>

[U-Boot] [PATCH v2 0/7] Adds support for secure boot on Keystone SoCs (K2E)

[Lokesh Vutla]

On Friday 02 September 2016 10:18 PM, Srinivas, Madan wrote:
> On 9/2/2016 12:25 AM, Lokesh Vutla wrote:
>>
>>
>> On Thursday 01 September 2016 10:34 AM, Madan Srinivas wrote:
>>> 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.
>>
>> 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.

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

> 
> Regards,
> Madan
>>>
>>> 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
>>>
> 

[U-Boot] [PATCH v2 0/7] Adds support for secure boot on Keystone SoCs (K2E)

[Nishanth Menon]

On 09/03/2016 11:56 AM, Lokesh Vutla wrote:
[...]
> 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.


-- 
Regards,
Nishanth Menon