Skip to contentSkip to conversation

Add FIT loadable custom processing

PATCH Superseded Andrew F. Davis 2 participants 13 messages Nov 29, 2016

Subsystems (3)

v2 of 3 Superseded Latest is v3 →

lore
Share & tools
lore
#0 lore raw

v2 cover Add FIT loadable custom processing

Hello all,

To see the background on this see here[0].

As Simon suggested we are now using a linker list to keep any and all TEE specific code out of common files as, unlike kernel, dtb, and ramdisk TEE images may not be used by needed by all users.

The last 4 patches in this series are an example of how one can now add a handler for an image type for their platform.

Thanks,
Andrew

[0] http://lists.denx.de/pipermail/u-boot/2016-November/272614.html

Changes from v1:
- Added some additional documentation
- Last 4 patches are now the compleate working TEE loading solution for our DRA7xx/AM57xx platforms, not just an example

Andrew F. Davis (4):
image: Add FIT image loadable section custom processing
image: Add Trusted Execution Environment image type
board: ti: dra7xx: add FIT image TEE processing
board: ti: am57xx: add FIT image TEE processing

Harinarayan Bhatta (2):
arm: omap5: add function to make an SMC call on cpu1
arm: omap5: Add TEE loading support

 arch/arm/include/asm/omap_common.h         |   1 +
 arch/arm/include/asm/omap_sec_common.h     |   6 ++
 arch/arm/mach-omap2/omap5/Makefile         |   1 +
 arch/arm/mach-omap2/omap5/sec-fxns.c       | 114 ++++++++++++++++++++++++++
 arch/arm/mach-omap2/omap5/sec_entry_cpu1.S | 123 +++++++++++++++++++++++++++++
 board/ti/am57xx/board.c                    |   7 ++
 board/ti/dra7xx/evm.c                      |   7 ++
 common/image.c                             |  34 ++++++++
 doc/uImage.FIT/source_file_format.txt      |   4 +-
 include/image.h                            |  31 ++++++++
 10 files changed, 327 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-omap2/omap5/sec_entry_cpu1.S
Signature · 1 line
2.10.2
#1 lore raw

PATCH v2 1/6 image: Add FIT image loadable section custom processing

To help automate the loading of custom image types we add the ability to define custom handlers for the loadable section types. When we find a compatible type while loading a "loadable" image from a FIT image we run its associated handlers to perform any additional steps needed for loading this image.

---
 common/image.c                        | 33 +++++++++++++++++++++++++++++++++
 doc/uImage.FIT/source_file_format.txt |  4 +++-
 include/image.h                       | 30 ++++++++++++++++++++++++++++++
 3 files changed, 66 insertions(+), 1 deletion(-)
common/image.c +33 -0
index 7604494..2aac90d 100644
@@ -1389,6 +1389,23 @@ int boot_get_fpga(int argc, char * const argv[], bootm_headers_t *images,
 }
 #endif
 
+static void fit_loadable_process(uint8_t img_type,
+				 ulong img_data,
+				 ulong img_len)
+{
+	int i;
+	const unsigned int count =
+			ll_entry_count(struct fit_loadable_tbl, fit_loadable);
+	struct fit_loadable_tbl *fit_loadable_handler =
+			ll_entry_start(struct fit_loadable_tbl, fit_loadable);
+	/* For each loadable handler */
+	for (i = 0; i < count; i++, fit_loadable_handler++)
+		/* matching this type */
+		if (fit_loadable_handler->type == img_type)
+			/* call that handler with this image data */
+			fit_loadable_handler->handler(img_data, img_len);
+}
+
 int boot_get_loadable(int argc, char * const argv[], bootm_headers_t *images,
 		uint8_t arch, const ulong *ld_start, ulong * const ld_len)
 {
@@ -1407,6 +1424,7 @@ int boot_get_loadable(int argc, char * const argv[], bootm_headers_t *images,
 	int conf_noffset;
 	int fit_img_result;
 	const char *uname;
+	uint8_t img_type;
 
 	/* Check to see if the images struct has a FIT configuration */
 	if (!genimg_has_config(images)) {
@@ -1447,6 +1465,21 @@ int boot_get_loadable(int argc, char * const argv[], bootm_headers_t *images,
 				/* Something went wrong! */
 				return fit_img_result;
 			}
+
+			fit_img_result = fit_image_get_node(buf, uname);
+			if (fit_img_result < 0) {
+				/* Something went wrong! */
+				return fit_img_result;
+			}
+			fit_img_result = fit_image_get_type(buf,
+							    fit_img_result,
+							    &img_type);
+			if (fit_img_result < 0) {
+				/* Something went wrong! */
+				return fit_img_result;
+			}
+
+			fit_loadable_process(img_type, img_data, img_len);
 		}
 		break;
 	default:
doc/uImage.FIT/source_file_format.txt +3 -1
index 91aa89a..afff301 100644
@@ -256,7 +256,9 @@ o config at 1
     (component image node of a "fpga type").
   - loadables : Unit name containing a list of additional binaries to be
     loaded at their given locations.  "loadables" is a comma-separated list
-    of strings. U-Boot will load each binary at its given start-address.
+    of strings. U-Boot will load each binary@its given start-address and
+    may optionaly invoke additional post-processing steps on this binary based
+    on its component image node type.
 
 The FDT blob is required to properly boot FDT based kernel, so the minimal
 configuration for 2.6 FDT kernel is (kernel, fdt) pair.
include/image.h +30 -0
index 8131595..b96b8eb 100644
@@ -1271,4 +1271,34 @@ int board_fit_config_name_match(const char *name);
 void board_fit_image_post_process(void **p_image, size_t *p_size);
 #endif /* CONFIG_SPL_FIT_IMAGE_POST_PROCESS */
 
+/**
+ * Mapping of image types to function handlers to be invoked on the associated
+ * loaded images
+ *
+ * @type: Type of image, I.E. IH_TYPE_*
+ * @handler: Function to call on loaded image
+ */
+struct fit_loadable_tbl {
+	int type;
+	/**
+	 * handler() - Process a loaded image
+	 *
+	 * @data: Pointer to start of loaded image data
+	 * @size: Size of loaded image data
+	 */
+	void (*handler)(ulong data, size_t size);
+};
+
+/*
+ * Define a FIT loadable image type handler
+ *
+ * _type is a valid uimage_type ID as defined in the "Image Type" enum above
+ * _handler is the handler function to call after this image type is loaded
+ */
+#define U_BOOT_FIT_LOADABLE_HANDLER(_type, _handler) \
+	ll_entry_declare(struct fit_loadable_tbl, _function, fit_loadable) = { \
+		.type = _type, \
+		.handler = _handler, \
+	}
+
 #endif	/* __IMAGE_H__ */
Signature · 1 line
2.10.2
#2 lore raw

PATCH v2 2/6 image: Add Trusted Execution Environment image type

In reply to Andrew F. Davis

Add a new image type representing Trusted Execution Environment (TEE) image types. For example, an OP-TEE OS binary image.

---
 common/image.c  | 1 +
 include/image.h | 1 +
 2 files changed, 2 insertions(+)
common/image.c +1 -0
index 2aac90d..bd07e86 100644
@@ -165,6 +165,7 @@ static const table_entry_t uimage_type[] = {
 	{	IH_TYPE_ZYNQIMAGE,  "zynqimage",  "Xilinx Zynq Boot Image" },
 	{	IH_TYPE_ZYNQMPIMAGE, "zynqmpimage", "Xilinx ZynqMP Boot Image" },
 	{	IH_TYPE_FPGA,       "fpga",       "FPGA Image" },
+	{       IH_TYPE_TEE,        "tee",        "Trusted Execution Environment Image",},
 	{	-1,		    "",		  "",			},
 };
 
include/image.h +1 -0
index b96b8eb..575f592 100644
@@ -279,6 +279,7 @@ enum {
 	IH_TYPE_ZYNQMPIMAGE,		/* Xilinx ZynqMP Boot Image */
 	IH_TYPE_FPGA,			/* FPGA Image */
 	IH_TYPE_VYBRIDIMAGE,	/* VYBRID .vyb Image */
+	IH_TYPE_TEE,            /* Trusted Execution Environment OS Image */
 
 	IH_TYPE_COUNT,			/* Number of image types */
 };
Signature · 1 line
2.10.2
#3 lore raw

PATCH v2 3/6 arm: omap5: add function to make an SMC call on cpu1

In reply to Andrew F. Davis

From: Harinarayan Bhatta <[email protected]>

On DRA7xx platform, CPU Core 1 is not used in u-boot. However, in some cases it is need to make secure API calls from Core 1. This patch adds an assembly function to make a secure (SMC) call from CPU Core #1.

---
 arch/arm/include/asm/omap_common.h         |   1 +
 arch/arm/mach-omap2/omap5/Makefile         |   1 +
 arch/arm/mach-omap2/omap5/sec_entry_cpu1.S | 123 +++++++++++++++++++++++++++++
 3 files changed, 125 insertions(+)
 create mode 100644 arch/arm/mach-omap2/omap5/sec_entry_cpu1.S
arch/arm/include/asm/omap_common.h +1 -0
index 605c549..290a190 100644
@@ -632,6 +632,7 @@ void omap_smc1(u32 service, u32 val);
  * security (HS) device variants by doing a specially-formed smc entry.
  */
 u32 omap_smc_sec(u32 service, u32 proc_id, u32 flag, u32 *params);
+u32 omap_smc_sec_cpu1(u32 service, u32 proc_id, u32 flag, u32 *params);
 
 void enable_edma3_clocks(void);
 void disable_edma3_clocks(void);
arch/arm/mach-omap2/omap5/Makefile +1 -0
index 0212df7..af17a3d 100644
@@ -15,3 +15,4 @@ obj-y	+= abb.o
 obj-y	+= fdt.o
 obj-$(CONFIG_IODELAY_RECALIBRATION) += dra7xx_iodelay.o
 obj-$(CONFIG_TI_SECURE_DEVICE) += sec-fxns.o
+obj-$(CONFIG_DRA7XX) += sec_entry_cpu1.o
arch/arm/mach-omap2/omap5/sec_entry_cpu1.S new file +123 -0

123 lines not on this page · raw message

Signature · 1 line
2.10.2
#4 lore raw

PATCH v2 3/6 arm: omap5: add function to make an SMC call on cpu1

Quoted 8 lines · Andrew F. Davis

From: Harinarayan Bhatta <[email protected]>

On DRA7xx platform, CPU Core 1 is not used in u-boot. However, in some cases it is need to make secure API calls from Core 1. This patch adds an assembly function to make a secure (SMC) call from CPU Core #1.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161129/fe7bc014/attachment.sig>
#5 lore raw

PATCH v2 4/6 arm: omap5: Add TEE loading support

In reply to Andrew F. Davis

From: Harinarayan Bhatta <[email protected]>

secure_tee_install is used to install and initialize a secure TEE OS such as Linaro OP-TEE into the secure world. This function takes in the address where the signed TEE image is loaded as an argument. The signed TEE image consists of a header (struct tee_header), TEE code+data followed by the signature generated using image signing tool from TI security development package (SECDEV). Refer to README.ti-secure for more information.

This function uses 2 new secure APIs.

1. PPA_SERV_HAL_TEE_LOAD_MASTER - Must be called on CPU Core 0. Protected memory for TEE must be reserved before calling this function. This API needs arguments filled into struct ppa_tee_load_info. The TEE image is authenticated and if there are no errors, the control passes to the TEE entry point.

2. PPA_SERV_HAL_TEE_LOAD_SLAVE - Called on other CPU cores only after a TEE_LOAD_MASTER call. Takes no arguments. Checks if TEE was successfully loaded (on core 0) and transfers control to the same TEE entry point.

The code at TEE entry point is expected perform OS initialization steps and return back to non-secure world (U-Boot).

---
 arch/arm/include/asm/omap_sec_common.h |   6 ++
 arch/arm/mach-omap2/omap5/sec-fxns.c   | 114 +++++++++++++++++++++++++++++++++
 2 files changed, 120 insertions(+)
arch/arm/include/asm/omap_sec_common.h +6 -0
index 4bde93f..79f1fbd 100644
@@ -51,4 +51,10 @@ int secure_emif_reserve(void);
  */
 int secure_emif_firewall_lock(void);
 
+/*
+ * Invoke a secure HAL API to authenticate and install a Trusted Execution
+ * Environment (TEE) image.
+ */
+int secure_tee_install(u32 tee_image);
+
 #endif /* _OMAP_SEC_COMMON_H_ */
arch/arm/mach-omap2/omap5/sec-fxns.c +114 -0

130 lines not on this page · raw message

Signature · 1 line
2.10.2
#6 lore raw

PATCH v2 4/6 arm: omap5: Add TEE loading support

Quoted 27 lines · Andrew F. Davis

From: Harinarayan Bhatta <[email protected]>

secure_tee_install is used to install and initialize a secure TEE OS such as Linaro OP-TEE into the secure world. This function takes in the address where the signed TEE image is loaded as an argument. The signed TEE image consists of a header (struct tee_header), TEE code+data followed by the signature generated using image signing tool from TI security development package (SECDEV). Refer to README.ti-secure for more information.

This function uses 2 new secure APIs.

1. PPA_SERV_HAL_TEE_LOAD_MASTER - Must be called on CPU Core 0. Protected memory for TEE must be reserved before calling this function. This API needs arguments filled into struct ppa_tee_load_info. The TEE image is authenticated and if there are no errors, the control passes to the TEE entry point.

2. PPA_SERV_HAL_TEE_LOAD_SLAVE - Called on other CPU cores only after a TEE_LOAD_MASTER call. Takes no arguments. Checks if TEE was successfully loaded (on core 0) and transfers control to the same TEE entry point.

The code at TEE entry point is expected perform OS initialization steps and return back to non-secure world (U-Boot).

[snip]

arch/arm/mach-omap2/omap5/sec-fxns.c line 46

Quoted 12 lines
arch/arm/mach-omap2/omap5/sec-fxns.c +12 -0
+/* TEE header (From OPTEE) */
+struct tee_header {
+	u32 magic;
+	u8 version;
+	u8 arch;
+	u16 flags;
+	u32 init_size;
+	u32 loadaddr_hi;
+	u32 loadaddr_lo;
+	u32 init_mem_usage;
+	u32 paged_size;
+};

This, and anything else that's OPTEE specific should go in a more generically visible header as others will be doing OPTEE stuff too.

[snip]

arch/arm/mach-omap2/omap5/sec-fxns.c int secure_emif_firewall_lock(void) · line 179

Quoted 1 line
arch/arm/mach-omap2/omap5/sec-fxns.c +1 -0
+	if ((hdr->magic != 0x4554504f) ||

This too probably belongs in the generic OPTEE header.

arch/arm/mach-omap2/omap5/sec-fxns.c int secure_emif_firewall_lock(void) · line 221

Quoted 4 lines
arch/arm/mach-omap2/omap5/sec-fxns.c +4 -0
+	/* The return value is ignored. If something went wrong, the function
+	 * would probably not return at all
+	 */
+	(void)secure_rom_call(PPA_SERV_HAL_TEE_LOAD_MASTER, 0, 0, 1, &tee_info);

"probably". We must save and check the return value all the same.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161129/b756993e/attachment.sig>
#7 lore raw

PATCH v2 4/6 arm: omap5: Add TEE loading support

Quoted 30 lines · Tom Rini
Quoted 27 lines · Andrew F. Davis

From: Harinarayan Bhatta <[email protected]>

secure_tee_install is used to install and initialize a secure TEE OS such as Linaro OP-TEE into the secure world. This function takes in the address where the signed TEE image is loaded as an argument. The signed TEE image consists of a header (struct tee_header), TEE code+data followed by the signature generated using image signing tool from TI security development package (SECDEV). Refer to README.ti-secure for more information.

This function uses 2 new secure APIs.

1. PPA_SERV_HAL_TEE_LOAD_MASTER - Must be called on CPU Core 0. Protected memory for TEE must be reserved before calling this function. This API needs arguments filled into struct ppa_tee_load_info. The TEE image is authenticated and if there are no errors, the control passes to the TEE entry point.

2. PPA_SERV_HAL_TEE_LOAD_SLAVE - Called on other CPU cores only after a TEE_LOAD_MASTER call. Takes no arguments. Checks if TEE was successfully loaded (on core 0) and transfers control to the same TEE entry point.

The code at TEE entry point is expected perform OS initialization steps and return back to non-secure world (U-Boot).

[snip]

Quoted 16 lines

arch/arm/mach-omap2/omap5/sec-fxns.c line 46

Quoted 12 lines
arch/arm/mach-omap2/omap5/sec-fxns.c +12 -0
+/* TEE header (From OPTEE) */
+struct tee_header {
+	u32 magic;
+	u8 version;
+	u8 arch;
+	u16 flags;
+	u32 init_size;
+	u32 loadaddr_hi;
+	u32 loadaddr_lo;
+	u32 init_mem_usage;
+	u32 paged_size;
+};

This, and anything else that's OPTEE specific should go in a more generically visible header as others will be doing OPTEE stuff too.

Any preference on location, include/tee/optee.h?

Quoted 5 lines

[snip]

arch/arm/mach-omap2/omap5/sec-fxns.c int secure_emif_firewall_lock(void) · line 179

Quoted 1 line
arch/arm/mach-omap2/omap5/sec-fxns.c +1 -0
+	if ((hdr->magic != 0x4554504f) ||

This too probably belongs in the generic OPTEE header.

Quoted 7 lines

arch/arm/mach-omap2/omap5/sec-fxns.c int secure_emif_firewall_lock(void) · line 221

Quoted 4 lines
arch/arm/mach-omap2/omap5/sec-fxns.c +4 -0
+	/* The return value is ignored. If something went wrong, the function
+	 * would probably not return at all
+	 */
+	(void)secure_rom_call(PPA_SERV_HAL_TEE_LOAD_MASTER, 0, 0, 1, &tee_info);

"probably". We must save and check the return value all the same.

Will check.

Thanks,
Andrew

#8 lore raw

PATCH v2 4/6 arm: omap5: Add TEE loading support

Quoted 48 lines · Andrew F. Davis
Quoted 30 lines · Tom Rini
Quoted 27 lines · Andrew F. Davis

From: Harinarayan Bhatta <[email protected]>

secure_tee_install is used to install and initialize a secure TEE OS such as Linaro OP-TEE into the secure world. This function takes in the address where the signed TEE image is loaded as an argument. The signed TEE image consists of a header (struct tee_header), TEE code+data followed by the signature generated using image signing tool from TI security development package (SECDEV). Refer to README.ti-secure for more information.

This function uses 2 new secure APIs.

1. PPA_SERV_HAL_TEE_LOAD_MASTER - Must be called on CPU Core 0. Protected memory for TEE must be reserved before calling this function. This API needs arguments filled into struct ppa_tee_load_info. The TEE image is authenticated and if there are no errors, the control passes to the TEE entry point.

2. PPA_SERV_HAL_TEE_LOAD_SLAVE - Called on other CPU cores only after a TEE_LOAD_MASTER call. Takes no arguments. Checks if TEE was successfully loaded (on core 0) and transfers control to the same TEE entry point.

The code at TEE entry point is expected perform OS initialization steps and return back to non-secure world (U-Boot).

[snip]

Quoted 16 lines

arch/arm/mach-omap2/omap5/sec-fxns.c line 46

Quoted 12 lines
arch/arm/mach-omap2/omap5/sec-fxns.c +12 -0
+/* TEE header (From OPTEE) */
+struct tee_header {
+	u32 magic;
+	u8 version;
+	u8 arch;
+	u16 flags;
+	u32 init_size;
+	u32 loadaddr_hi;
+	u32 loadaddr_lo;
+	u32 init_mem_usage;
+	u32 paged_size;
+};

This, and anything else that's OPTEE specific should go in a more generically visible header as others will be doing OPTEE stuff too.

Quoted 1 line

Any preference on location, include/tee/optee.h?

Sure.

Quoted 13 lines
Quoted 5 lines

[snip]

arch/arm/mach-omap2/omap5/sec-fxns.c int secure_emif_firewall_lock(void) · line 179

Quoted 1 line
arch/arm/mach-omap2/omap5/sec-fxns.c +1 -0
+	if ((hdr->magic != 0x4554504f) ||

This too probably belongs in the generic OPTEE header.

Quoted 7 lines

arch/arm/mach-omap2/omap5/sec-fxns.c int secure_emif_firewall_lock(void) · line 221

Quoted 4 lines
arch/arm/mach-omap2/omap5/sec-fxns.c +4 -0
+	/* The return value is ignored. If something went wrong, the function
+	 * would probably not return at all
+	 */
+	(void)secure_rom_call(PPA_SERV_HAL_TEE_LOAD_MASTER, 0, 0, 1, &tee_info);

"probably". We must save and check the return value all the same.

Quoted 1 line

Will check.

OK, thanks.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161129/a3ebae18/attachment.sig>
#9 lore raw

PATCH v2 5/6 board: ti: dra7xx: add FIT image TEE processing

In reply to Andrew F. Davis

Populate the corresponding TEE image processing call to be performed during FIT loadable processing.

---
 board/ti/dra7xx/evm.c | 7 +++++++
 1 file changed, 7 insertions(+)
board/ti/dra7xx/evm.c +7 -0
index 3c16846..3bb895c 100644
@@ -848,4 +848,11 @@ void board_fit_image_post_process(void **p_image, size_t *p_size)
 {
 	secure_boot_verify_image(p_image, p_size);
 }
+
+void board_tee_image_process(ulong tee_image, size_t tee_size)
+{
+	secure_tee_install((u32)tee_image);
+}
+
+U_BOOT_FIT_LOADABLE_HANDLER(IH_TYPE_TEE, board_tee_image_process);
 #endif
Signature · 1 line
2.10.2
#10 lore raw

PATCH v2 5/6 board: ti: dra7xx: add FIT image TEE processing

Quoted 5 lines · Andrew F. Davis

Populate the corresponding TEE image processing call to be performed during FIT loadable processing.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161129/5a718529/attachment.sig>
#11 lore raw

PATCH v2 6/6 board: ti: am57xx: add FIT image TEE processing

In reply to Andrew F. Davis

Populate the corresponding TEE image processing call to be performed during FIT loadable processing.

---
 board/ti/am57xx/board.c | 7 +++++++
 1 file changed, 7 insertions(+)
board/ti/am57xx/board.c +7 -0
index f3e3f0b..1895a30 100644
@@ -739,4 +739,11 @@ void board_fit_image_post_process(void **p_image, size_t *p_size)
 {
 	secure_boot_verify_image(p_image, p_size);
 }
+
+void board_tee_image_process(ulong tee_image, size_t tee_size)
+{
+	secure_tee_install((u32)tee_image);
+}
+
+U_BOOT_FIT_LOADABLE_HANDLER(IH_TYPE_TEE, board_tee_image_process);
 #endif
Signature · 1 line
2.10.2
#12 lore raw

PATCH v2 6/6 board: ti: am57xx: add FIT image TEE processing

Quoted 4 lines · Andrew F. Davis

Populate the corresponding TEE image processing call to be performed during FIT loadable processing.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161129/ec2b0d3d/attachment.sig>