[U-Boot] [PATCH v2 0/7] 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
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 *
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
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
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
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!
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
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
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
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
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
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
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
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) ======================================
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
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
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
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
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
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.
participants (6)
-
Andrew F. Davis -
Lokesh Vutla -
Madan Srinivas -
Nishanth Menon -
Srinivas, Madan
-
Tom Rini