[U-Boot] [PATCH 0/6] imx8: support container

[U-Boot] [PATCH 0/6] imx8: support container

[Peng Fan]

This patchset is to support i.MX8 container loading from SPL,
i.MX8 AHAB secure boot not support FIT image, so we need to
use container image.

Currently still use a fixed offset for the 2nd container(u-boot.cnt),
future patches will drop this fixed offset and use dynamaic offset
according to the size of 1st container for spl.
Only MMC is supported now, future patches will also support SPI/NOR/NAND
following similar style as mmc part, if the mmc part is ok.

Build pass: https://travis-ci.org/MrVan/u-boot/builds/529180267

Peng Fan (6):
  imx: mach-imx: clean up Makefile
  spl: Add function to get u-boot raw sector
  imx8: support parsing i.MX8 Container file
  spl: mmc: support loading i.MX container format file
  imx: add container target
  imx8qxp_mek: switch to use container image

 Makefile                                        |   8 ++
 arch/arm/include/asm/arch-imx8/image.h          |  56 +++++++++++
 arch/arm/mach-imx/Makefile                      |  26 +++--
 arch/arm/mach-imx/imx8/Kconfig                  |  13 +++
 arch/arm/mach-imx/imx8/Makefile                 |   4 +
 arch/arm/mach-imx/imx8/parse-container.c        | 120 ++++++++++++++++++++++++
 board/freescale/imx8qxp_mek/README              |   4 +-
 board/freescale/imx8qxp_mek/uboot-container.cfg |  13 +++
 common/spl/spl_mmc.c                            |  21 ++++-
 configs/imx8qxp_mek_defconfig                   |   5 +-
 include/spl.h                                   |  12 +++
 11 files changed, 268 insertions(+), 14 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-imx8/image.h
 create mode 100644 arch/arm/mach-imx/imx8/parse-container.c
 create mode 100644 board/freescale/imx8qxp_mek/uboot-container.cfg

-- 
2.16.4

[U-Boot] [PATCH 1/6] imx: mach-imx: clean up Makefile

[Peng Fan]

Only eval the variables when building related target, then
we will not see unrelated warning that when building spl and u-boot.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 arch/arm/mach-imx/Makefile | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index 37675d0558..0562640599 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -104,18 +104,15 @@ IMX_CONFIG = $(CONFIG_IMX_CONFIG:"%"=%)
 	$(Q)mkdir -p $(dir $@)
 	$(call if_changed_dep,cpp_cfg)
 
+DEPFILE_EXISTS := 0
 ifeq ($(CONFIG_ARCH_IMX8), y)
 CNTR_DEPFILES := $(srctree)/tools/imx_cntr_image.sh
 IMAGE_TYPE := imx8image
-SPL_DEPFILE_EXISTS := $(shell $(CPP) $(cpp_flags) -x c -o spl/u-boot-spl.cfgout $(srctree)/$(IMX_CONFIG); if [ -f spl/u-boot-spl.cfgout ]; then $(CNTR_DEPFILES) spl/u-boot-spl.cfgout; echo $$?; fi)
-DEPFILE_EXISTS := $(shell $(CPP) $(cpp_flags) -x c -o u-boot-dtb.cfgout $(srctree)/$(IMX_CONFIG); if [ -f u-boot-dtb.cfgout ]; then $(CNTR_DEPFILES) u-boot-dtb.cfgout; echo $$?; fi)
 else ifeq ($(CONFIG_ARCH_IMX8M), y)
 IMAGE_TYPE := imx8mimage
 IMX8M_DEPFILES := $(srctree)/tools/imx8m_image.sh
-DEPFILE_EXISTS := $(shell $(CPP) $(cpp_flags) -x c -o spl/u-boot-spl.cfgout $(srctree)/$(IMX_CONFIG);if [ -f spl/u-boot-spl.cfgout ]; then $(IMX8M_DEPFILES) spl/u-boot-spl.cfgout 0; echo $$?; fi)
 else
 IMAGE_TYPE := imximage
-DEPFILE_EXISTS := 0
 endif
 
 MKIMAGEFLAGS_u-boot.imx = -n $(filter-out $(PLUGIN).bin $< $(PHONY),$^) \
@@ -139,30 +136,33 @@ endif
 
 ifdef CONFIG_ARM64
 ifeq ($(CONFIG_ARCH_IMX8M), y)
-SPL:
+SPL: spl/u-boot-spl.bin spl/u-boot-spl.cfgout FORCE
 
 MKIMAGEFLAGS_flash.bin = -n spl/u-boot-spl.cfgout \
 		   -T $(IMAGE_TYPE) -e $(CONFIG_SPL_TEXT_BASE)
 flash.bin: MKIMAGEOUTPUT = flash.log
 
 spl/u-boot-spl-ddr.bin: spl/u-boot-spl.bin spl/u-boot-spl.cfgout FORCE
+	$(eval DEPFILE_EXISTS := $(shell $(CPP) $(cpp_flags) -x c -o spl/u-boot-spl.cfgout $(srctree)/$(IMX_CONFIG);if [ -f spl/u-boot-spl.cfgout ]; then $(IMX8M_DEPFILES) spl/u-boot-spl.cfgout 0; echo $$?; fi))
 ifeq ($(DEPFILE_EXISTS),0)
 	$(IMX8M_DEPFILES) spl/u-boot-spl.cfgout 1
 endif
 
 flash.bin: spl/u-boot-spl-ddr.bin u-boot.itb FORCE
+	$(eval DEPFILE_EXISTS := $(shell $(CPP) $(cpp_flags) -x c -o spl/u-boot-spl.cfgout $(srctree)/$(IMX_CONFIG);if [ -f spl/u-boot-spl.cfgout ]; then $(IMX8M_DEPFILES) spl/u-boot-spl.cfgout 0; echo $$?; fi))
 ifeq ($(DEPFILE_EXISTS),0)
 	$(call if_changed,mkimage)
 endif
 endif
 
 ifeq ($(CONFIG_ARCH_IMX8), y)
-SPL:
+SPL: spl/u-boot-spl.bin spl/u-boot-spl.cfgout FORCE
 
 MKIMAGEFLAGS_flash.bin = -n spl/u-boot-spl.cfgout -T $(IMAGE_TYPE) -e 0x100000
 flash.bin: MKIMAGEOUTPUT = flash.log
 
 flash.bin: spl/u-boot-spl.bin u-boot.itb FORCE
+	$(eval SPL_DEPFILE_EXISTS := $(shell $(CPP) $(cpp_flags) -x c -o spl/u-boot-spl.cfgout $(srctree)/$(IMX_CONFIG); if [ -f spl/u-boot-spl.cfgout ]; then $(CNTR_DEPFILES) spl/u-boot-spl.cfgout; echo $$?; fi))
 ifeq ($(SPL_DEPFILE_EXISTS),0)
 	$(call if_changed,mkimage)
 endif
-- 
2.16.4

[U-Boot] [PATCH 2/6] spl: Add function to get u-boot raw sector

[Peng Fan]

Add a weak function spl_mmc_get_uboot_raw_sector to get u-boot raw
sector. At default it returns CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR.
Users can overwrite it to return customized offset.

This is to support i.MX8 specific image type container image type.

Cc: Tien Fong Chee <tien.fong.chee@intel.com>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: York Sun <york.sun@nxp.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Alex Kiernan <alex.kiernan@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 common/spl/spl_mmc.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index 324d91c884..bf53a1dadf 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -149,6 +149,13 @@ static int spl_mmc_find_device(struct mmc **mmcp, u32 boot_device)
 	return 0;
 }
 
+#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
+unsigned long __weak spl_mmc_get_uboot_raw_sector(struct mmc *mmc)
+{
+	return CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR;
+}
+#endif
+
 #ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
 static int mmc_load_image_raw_partition(struct spl_image_info *spl_image,
 					struct mmc *mmc, int partition)
@@ -181,7 +188,7 @@ static int mmc_load_image_raw_partition(struct spl_image_info *spl_image,
 
 #ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
 	return mmc_load_image_raw_sector(spl_image, mmc,
-			info.start + CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR);
+			info.start + spl_mmc_get_uboot_raw_sector(mmc));
 #else
 	return mmc_load_image_raw_sector(spl_image, mmc, info.start);
 #endif
@@ -366,7 +373,7 @@ int spl_mmc_load_image(struct spl_image_info *spl_image,
 #endif
 #ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
 		err = mmc_load_image_raw_sector(spl_image, mmc,
-			CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR);
+			spl_mmc_get_uboot_raw_sector(mmc));
 		if (!err)
 			return err;
 #endif
-- 
2.16.4

[U-Boot] [PATCH 3/6] imx8: support parsing i.MX8 Container file

[Peng Fan]

Add parsing i.MX8 Container file support, this is to let
SPL could load images in a container file to destination address.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 arch/arm/include/asm/arch-imx8/image.h   |  56 +++++++++++++++
 arch/arm/mach-imx/imx8/Kconfig           |   6 ++
 arch/arm/mach-imx/imx8/Makefile          |   4 ++
 arch/arm/mach-imx/imx8/parse-container.c | 120 +++++++++++++++++++++++++++++++
 4 files changed, 186 insertions(+)
 create mode 100644 arch/arm/include/asm/arch-imx8/image.h
 create mode 100644 arch/arm/mach-imx/imx8/parse-container.c

diff --git a/arch/arm/include/asm/arch-imx8/image.h b/arch/arm/include/asm/arch-imx8/image.h
new file mode 100644
index 0000000000..c1e5700859
--- /dev/null
+++ b/arch/arm/include/asm/arch-imx8/image.h
@@ -0,0 +1,56 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2018-2019 NXP
+ */
+
+#ifndef __CONTAINER_HEADER_H_
+#define __CONTAINER_HEADER_H_
+
+#include <linux/sizes.h>
+#include <linux/types.h>
+
+#define IV_MAX_LEN			32
+#define HASH_MAX_LEN			64
+
+#define CONTAINER_HDR_ALIGNMENT 0x400
+#define CONTAINER_HDR_EMMC_OFFSET 0
+#define CONTAINER_HDR_MMCSD_OFFSET SZ_32K
+#define CONTAINER_HDR_QSPI_OFFSET SZ_4K
+#define CONTAINER_HDR_NAND_OFFSET SZ_128M
+
+struct container_hdr {
+	u8 version;
+	u8 length_lsb;
+	u8 length_msb;
+	u8 tag;
+	u32 flags;
+	u16 sw_version;
+	u8 fuse_version;
+	u8 num_images;
+	u16 sig_blk_offset;
+	u16 reserved;
+} __packed;
+
+struct boot_img_t {
+	u32 offset;
+	u32 size;
+	u64 dst;
+	u64 entry;
+	u32 hab_flags;
+	u32 meta;
+	u8 hash[HASH_MAX_LEN];
+	u8 iv[IV_MAX_LEN];
+} __packed;
+
+struct signature_block_hdr {
+	u8 version;
+	u8 length_lsb;
+	u8 length_msb;
+	u8 tag;
+	u16 srk_table_offset;
+	u16 cert_offset;
+	u16 blob_offset;
+	u16 signature_offset;
+	u32 reserved;
+} __packed;
+#endif
diff --git a/arch/arm/mach-imx/imx8/Kconfig b/arch/arm/mach-imx/imx8/Kconfig
index c32f7dbb61..8e6b79eb77 100644
--- a/arch/arm/mach-imx/imx8/Kconfig
+++ b/arch/arm/mach-imx/imx8/Kconfig
@@ -23,6 +23,12 @@ config IMX8QXP
 config SYS_SOC
 	default "imx8"
 
+config SPL_LOAD_IMX_CONTAINER
+	bool "Enable SPL loading U-Boot as a i.MX Container image"
+	depends on SPL
+	help
+	  This is to let SPL could load i.MX8 Container image
+
 choice
 	prompt "i.MX8 board select"
 	optional
diff --git a/arch/arm/mach-imx/imx8/Makefile b/arch/arm/mach-imx/imx8/Makefile
index 31ad169ccf..19690110a5 100644
--- a/arch/arm/mach-imx/imx8/Makefile
+++ b/arch/arm/mach-imx/imx8/Makefile
@@ -5,3 +5,7 @@
 #
 
 obj-y += cpu.o iomux.o
+
+ifdef CONFIG_SPL_BUILD
+obj-$(CONFIG_SPL_LOAD_IMX_CONTAINER) += parse-container.o
+endif
diff --git a/arch/arm/mach-imx/imx8/parse-container.c b/arch/arm/mach-imx/imx8/parse-container.c
new file mode 100644
index 0000000000..32f78bdddf
--- /dev/null
+++ b/arch/arm/mach-imx/imx8/parse-container.c
@@ -0,0 +1,120 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2018-2019 NXP
+ */
+
+#include <common.h>
+#include <errno.h>
+#include <spl.h>
+#include <asm/arch/image.h>
+
+static struct boot_img_t *read_auth_image(struct spl_image_info *spl_image,
+					  struct spl_load_info *info,
+					  struct container_hdr *container,
+					  int image_index,
+					  u32 container_sector)
+{
+	struct boot_img_t *images;
+	ulong sector;
+	u32 sectors;
+
+	if (image_index > container->num_images) {
+		debug("Invalid image number\n");
+		return NULL;
+	}
+
+	images = (struct boot_img_t *)((u8 *)container +
+				       sizeof(struct container_hdr));
+
+	if (images[image_index].offset % info->bl_len) {
+		printf("%s: image%d offset not aligned to %u\n",
+		       __func__, image_index, info->bl_len);
+		return NULL;
+	}
+
+	sectors = roundup(images[image_index].size, info->bl_len) /
+		info->bl_len;
+	sector = images[image_index].offset / info->bl_len +
+		container_sector;
+
+	debug("%s: container: %p sector: %lu sectors: %u\n", __func__,
+	      container, sector, sectors);
+	if (info->read(info, sector, sectors,
+		       (void *)images[image_index].entry) != sectors) {
+		printf("%s wrong\n", __func__);
+		return NULL;
+	}
+
+	return &images[image_index];
+}
+
+static int read_auth_container(struct spl_image_info *spl_image,
+			       struct spl_load_info *info, ulong sector)
+{
+	struct container_hdr *container = NULL;
+	u16 length;
+	u32 sectors;
+	int i, size;
+
+	size = roundup(CONTAINER_HDR_ALIGNMENT, info->bl_len);
+	sectors = size / info->bl_len;
+
+	/*
+	 * It will not override the ATF code, so safe to use it here,
+	 * no need malloc
+	 */
+	container = (struct container_hdr *)spl_get_load_buffer(-size, size);
+
+	debug("%s: container: %p sector: %lu sectors: %u\n", __func__,
+	      container, sector, sectors);
+	if (info->read(info, sector, sectors, container) != sectors)
+		return -EIO;
+
+	if (container->tag != 0x87 && container->version != 0x0) {
+		printf("Wrong container header");
+		return -ENOENT;
+	}
+
+	if (!container->num_images) {
+		printf("Wrong container, no image found");
+		return -ENOENT;
+	}
+
+	length = container->length_lsb + (container->length_msb << 8);
+	debug("Container length %u\n", length);
+
+	if (length > CONTAINER_HDR_ALIGNMENT) {
+		size = roundup(length, info->bl_len);
+		sectors = size / info->bl_len;
+
+		container = (struct container_hdr *)spl_get_load_buffer(-size, size);
+
+		debug("%s: container: %p sector: %lu sectors: %u\n",
+		      __func__, container, sector, sectors);
+		if (info->read(info, sector, sectors, container) !=
+		    sectors)
+			return -EIO;
+	}
+
+	for (i = 0; i < container->num_images; i++) {
+		struct boot_img_t *image = read_auth_image(spl_image, info,
+							   container, i,
+							   sector);
+
+		if (!image)
+			return -EINVAL;
+
+		if (i == 0) {
+			spl_image->load_addr = image->dst;
+			spl_image->entry_point = image->entry;
+		}
+	}
+
+	return 0;
+}
+
+int spl_load_imx_container(struct spl_image_info *spl_image,
+			   struct spl_load_info *info, ulong sector)
+{
+	return read_auth_container(spl_image, info, sector);
+}
-- 
2.16.4

[U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Peng Fan]

i.MX8 only support AHAB secure boot with Container format image,
we could not use FIT to support secure boot, so introduce container
support to let SPL could load container images.

Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Tien Fong Chee <tien.fong.chee@intel.com>
Cc: York Sun <york.sun@nxp.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Alex Kiernan <alex.kiernan@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Cc: Kever Yang <kever.yang@rock-chips.com>
Cc: Heiko Schocher <hs@denx.de>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 common/spl/spl_mmc.c | 10 ++++++++++
 include/spl.h        | 12 ++++++++++++
 2 files changed, 22 insertions(+)

diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index bf53a1dadf..6320af055b 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -79,6 +79,16 @@ int mmc_load_image_raw_sector(struct spl_image_info *spl_image,
 		load.bl_len = mmc->read_bl_len;
 		load.read = h_spl_load_read;
 		ret = spl_load_simple_fit(spl_image, &load, sector, header);
+	} else if (IS_ENABLED(CONFIG_SPL_LOAD_IMX_CONTAINER)) {
+		struct spl_load_info load;
+
+		load.dev = mmc;
+		load.priv = NULL;
+		load.filename = NULL;
+		load.bl_len = mmc->read_bl_len;
+		load.read = h_spl_load_read;
+
+		ret = spl_load_imx_container(spl_image, &load, sector);
 	} else {
 		ret = mmc_load_legacy(spl_image, mmc, sector, header);
 	}
diff --git a/include/spl.h b/include/spl.h
index f09909e189..b7c8a972dd 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -125,6 +125,18 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
 #define SPL_COPY_PAYLOAD_ONLY	1
 #define SPL_FIT_FOUND		2
 
+/**
+ * spl_load_imx_container() - Loads a imx container image from a device.
+ * @spl_image:	Image description to set up
+ * @info:	Structure containing the information required to load data.
+ * @sector:	Sector number where container image is located in the device
+ *
+ * Reads the container image @sector in the device. Loads u-boot image to
+ * specified load address.
+ */
+int spl_load_imx_container(struct spl_image_info *spl_image,
+			   struct spl_load_info *info, ulong sector);
+
 /* SPL common functions */
 void preloader_console_init(void);
 u32 spl_boot_device(void);
-- 
2.16.4

[U-Boot] [PATCH 5/6] imx: add container target

[Peng Fan]

To support SPL loading container file, add a new Makefile target,
and introduce a new Kconfig file to source the cfg file which
will be parsed by mkimage.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 Makefile                       |  8 ++++++++
 arch/arm/mach-imx/Makefile     | 14 ++++++++++++++
 arch/arm/mach-imx/imx8/Kconfig |  7 +++++++
 3 files changed, 29 insertions(+)

diff --git a/Makefile b/Makefile
index d6a6ef19ab..2912cebaf6 100644
--- a/Makefile
+++ b/Makefile
@@ -1300,9 +1300,17 @@ SPL: spl/u-boot-spl.bin FORCE
 	$(Q)$(MAKE) $(build)=arch/arm/mach-imx $@
 
 ifeq ($(CONFIG_ARCH_IMX8M)$(CONFIG_ARCH_IMX8), y)
+ifeq ($(CONFIG_SPL_LOAD_IMX_CONTAINER), y)
+u-boot.cnt: u-boot.bin FORCE
+	$(Q)$(MAKE) $(build)=arch/arm/mach-imx $@
+
+flash.bin: spl/u-boot-spl.bin u-boot.cnt FORCE
+	$(Q)$(MAKE) $(build)=arch/arm/mach-imx $@
+else
 flash.bin: spl/u-boot-spl.bin u-boot.itb FORCE
 	$(Q)$(MAKE) $(build)=arch/arm/mach-imx $@
 endif
+endif
 
 u-boot-with-spl.imx u-boot-with-nand-spl.imx: SPL u-boot.bin FORCE
 	$(Q)$(MAKE) $(build)=arch/arm/mach-imx $@
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index 0562640599..494eee8e5a 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -104,6 +104,11 @@ IMX_CONFIG = $(CONFIG_IMX_CONFIG:"%"=%)
 	$(Q)mkdir -p $(dir $@)
 	$(call if_changed_dep,cpp_cfg)
 
+IMX_CONTAINER_CFG = $(CONFIG_IMX_CONTAINER_CFG:"%"=%)
+container.cfg: $(IMX_CONTAINER_CFG) FORCE
+	$(Q)mkdir -p $(dir $@)
+	$(call if_changed_dep,cpp_cfg)
+
 DEPFILE_EXISTS := 0
 ifeq ($(CONFIG_ARCH_IMX8), y)
 CNTR_DEPFILES := $(srctree)/tools/imx_cntr_image.sh
@@ -161,7 +166,16 @@ SPL: spl/u-boot-spl.bin spl/u-boot-spl.cfgout FORCE
 MKIMAGEFLAGS_flash.bin = -n spl/u-boot-spl.cfgout -T $(IMAGE_TYPE) -e 0x100000
 flash.bin: MKIMAGEOUTPUT = flash.log
 
+MKIMAGEFLAGS_u-boot.cnt = -n container.cfg -T $(IMAGE_TYPE) -e 0x100000
+u-boot.cnt: MKIMAGEOUTPUT = u-boot.cnt.log
+
+ifeq ($(CONFIG_SPL_LOAD_IMX_CONTAINER), y)
+u-boot.cnt: u-boot.bin container.cfg FORCE
+	$(call if_changed,mkimage)
+flash.bin: spl/u-boot-spl.bin u-boot.cnt FORCE
+else
 flash.bin: spl/u-boot-spl.bin u-boot.itb FORCE
+endif
 	$(eval SPL_DEPFILE_EXISTS := $(shell $(CPP) $(cpp_flags) -x c -o spl/u-boot-spl.cfgout $(srctree)/$(IMX_CONFIG); if [ -f spl/u-boot-spl.cfgout ]; then $(CNTR_DEPFILES) spl/u-boot-spl.cfgout; echo $$?; fi))
 ifeq ($(SPL_DEPFILE_EXISTS),0)
 	$(call if_changed,mkimage)
diff --git a/arch/arm/mach-imx/imx8/Kconfig b/arch/arm/mach-imx/imx8/Kconfig
index 8e6b79eb77..8128ec16b4 100644
--- a/arch/arm/mach-imx/imx8/Kconfig
+++ b/arch/arm/mach-imx/imx8/Kconfig
@@ -29,6 +29,13 @@ config SPL_LOAD_IMX_CONTAINER
 	help
 	  This is to let SPL could load i.MX8 Container image
 
+config IMX_CONTAINER_CFG
+	string "i.MX Container config file"
+	depends on SPL
+	help
+	  This is to specific the cfg file for generating container
+	  image which will be loaded by SPL.
+
 choice
 	prompt "i.MX8 board select"
 	optional
-- 
2.16.4

[U-Boot] [PATCH 6/6] imx8qxp_mek: switch to use container image

[Peng Fan]

Because FIT could not be used for AHAB secure boot on i.MX8,
so switch to use container image that could let SPL verify
ATF and U-Boot with AHAB.

Note: The AHAB related code has not been added.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 board/freescale/imx8qxp_mek/README              |  4 +---
 board/freescale/imx8qxp_mek/uboot-container.cfg | 13 +++++++++++++
 configs/imx8qxp_mek_defconfig                   |  5 ++---
 3 files changed, 16 insertions(+), 6 deletions(-)
 create mode 100644 board/freescale/imx8qxp_mek/uboot-container.cfg

diff --git a/board/freescale/imx8qxp_mek/README b/board/freescale/imx8qxp_mek/README
index f32290e3a2..6dc151b166 100644
--- a/board/freescale/imx8qxp_mek/README
+++ b/board/freescale/imx8qxp_mek/README
@@ -39,11 +39,9 @@ $ cp imx-sc-firmware-0.7/mx8qx-mek-scfw-tcm.bin	.
 
 Build U-Boot
 ============
-$ export ATF_LOAD_ADDR=0x80000000
-$ export BL33_LOAD_ADDR=0x80020000
 $ make imx8qxp_mek_defconfig
 $ make flash.bin
-$ dd if=u-boot.itb of=flash.bin bs=512 seek=528
+$ dd if=u-boot.cnt of=flash.bin bs=512 seek=528
 
 Flash the binary into the SD card
 =================================
diff --git a/board/freescale/imx8qxp_mek/uboot-container.cfg b/board/freescale/imx8qxp_mek/uboot-container.cfg
new file mode 100644
index 0000000000..8165811818
--- /dev/null
+++ b/board/freescale/imx8qxp_mek/uboot-container.cfg
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2019 NXP
+ */
+
+#define __ASSEMBLY__
+
+/* This file is to create a container image could be loaded by SPL */
+BOOT_FROM SD 0x400
+SOC_TYPE IMX8QX
+CONTAINER
+IMAGE A35 bl31.bin	0x80000000
+IMAGE A35 u-boot.bin	CONFIG_SYS_TEXT_BASE
diff --git a/configs/imx8qxp_mek_defconfig b/configs/imx8qxp_mek_defconfig
index 6101f62087..8fafb3cf1a 100644
--- a/configs/imx8qxp_mek_defconfig
+++ b/configs/imx8qxp_mek_defconfig
@@ -5,15 +5,14 @@ CONFIG_SPL_GPIO_SUPPORT=y
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
 CONFIG_SYS_MALLOC_F_LEN=0x4000
+CONFIG_SPL_LOAD_IMX_CONTAINER=y
+CONFIG_IMX_CONTAINER_CFG="board/freescale/imx8qxp_mek/uboot-container.cfg"
 CONFIG_TARGET_IMX8QXP_MEK=y
 CONFIG_SPL_MMC_SUPPORT=y
 CONFIG_SPL_SERIAL_SUPPORT=y
 CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
 CONFIG_NR_DRAM_BANKS=3
 CONFIG_SPL=y
-CONFIG_FIT=y
-CONFIG_SPL_LOAD_FIT=y
-CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/imx8qxp_mek/imximage.cfg"
 CONFIG_BOOTDELAY=3
 CONFIG_LOG=y
-- 
2.16.4

[U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Simon Glass]

Hi Peng,

On Tue, 7 May 2019 at 06:52, Peng Fan <peng.fan@nxp.com> wrote:
>
> i.MX8 only support AHAB secure boot with Container format image,
> we could not use FIT to support secure boot, so introduce container

Why not FIT?

> support to let SPL could load container images.

What is a container image? Can you please point to documentation?

>
> Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
> Cc: Tien Fong Chee <tien.fong.chee@intel.com>
> Cc: York Sun <york.sun@nxp.com>
> Cc: Marek Vasut <marex@denx.de>
> Cc: Alex Kiernan <alex.kiernan@gmail.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
> Cc: Kever Yang <kever.yang@rock-chips.com>
> Cc: Heiko Schocher <hs@denx.de>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
>  common/spl/spl_mmc.c | 10 ++++++++++
>  include/spl.h        | 12 ++++++++++++
>  2 files changed, 22 insertions(+)

Regards,
Simon

[U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Peng Fan]

Hi Simon,

> Subject: Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
> 
> Hi Peng,
> 
> On Tue, 7 May 2019 at 06:52, Peng Fan <peng.fan@nxp.com> wrote:
> >
> > i.MX8 only support AHAB secure boot with Container format image, we
> > could not use FIT to support secure boot, so introduce container
> 
> Why not FIT?

Actually before we implement secure boot, we use FIT image, however
i.MX8 only support i.MX container format image for secure boot,
The chip will verify the container image when secure boot. It could not recognize
FIT image. So we have to drop FIT image.

> 
> > support to let SPL could load container images.
> 
> What is a container image? Can you please point to documentation?

Sadly, there is no public reference manual. There is a doc that has
a bit of information. https://community.nxp.com/docs/DOC-343178

Thanks,
Peng.

> 
> >
> > Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
> > Cc: Tien Fong Chee <tien.fong.chee@intel.com>
> > Cc: York Sun <york.sun@nxp.com>
> > Cc: Marek Vasut <marex@denx.de>
> > Cc: Alex Kiernan <alex.kiernan@gmail.com>
> > Cc: Simon Glass <sjg@chromium.org>
> > Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
> > Cc: Kever Yang <kever.yang@rock-chips.com>
> > Cc: Heiko Schocher <hs@denx.de>
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > ---
> >  common/spl/spl_mmc.c | 10 ++++++++++
> >  include/spl.h        | 12 ++++++++++++
> >  2 files changed, 22 insertions(+)
> 
> Regards,
> Simon

[U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Marek Vasut]

On 5/20/19 3:30 AM, Peng Fan wrote:
> Hi Simon,
> 
>> Subject: Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
>>
>> Hi Peng,
>>
>> On Tue, 7 May 2019 at 06:52, Peng Fan <peng.fan@nxp.com> wrote:
>>>
>>> i.MX8 only support AHAB secure boot with Container format image, we
>>> could not use FIT to support secure boot, so introduce container
>>
>> Why not FIT?
> 
> Actually before we implement secure boot, we use FIT image, however
> i.MX8 only support i.MX container format image for secure boot,
> The chip will verify the container image when secure boot. It could not recognize
> FIT image. So we have to drop FIT image.
> 
>>
>>> support to let SPL could load container images.
>>
>> What is a container image? Can you please point to documentation?
> 
> Sadly, there is no public reference manual. There is a doc that has
> a bit of information. https://community.nxp.com/docs/DOC-343178

Shouldn't it suffice for the SPL to be in this custom format , while the
rest of the binaries can be in fitImage ?

-- 
Best regards,
Marek Vasut

[U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Peng Fan]

Hi Marek,

> Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container
> format file
> 
> On 5/20/19 3:30 AM, Peng Fan wrote:
> > Hi Simon,
> >
> >> Subject: Re: [PATCH 4/6] spl: mmc: support loading i.MX container
> >> format file
> >>
> >> Hi Peng,
> >>
> >> On Tue, 7 May 2019 at 06:52, Peng Fan <peng.fan@nxp.com> wrote:
> >>>
> >>> i.MX8 only support AHAB secure boot with Container format image, we
> >>> could not use FIT to support secure boot, so introduce container
> >>
> >> Why not FIT?
> >
> > Actually before we implement secure boot, we use FIT image, however
> > i.MX8 only support i.MX container format image for secure boot, The
> > chip will verify the container image when secure boot. It could not
> > recognize FIT image. So we have to drop FIT image.
> >
> >>
> >>> support to let SPL could load container images.
> >>
> >> What is a container image? Can you please point to documentation?
> >
> > Sadly, there is no public reference manual. There is a doc that has a
> > bit of information.
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcomm
> >
> unity.nxp.com%2Fdocs%2FDOC-343178&amp;data=02%7C01%7Cpeng.fan%4
> 0nxp.co
> >
> m%7C8626e7a1d20c44b8715408d6dcc4d866%7C686ea1d3bc2b4c6fa92cd9
> 9c5c30163
> >
> 5%7C0%7C0%7C636939135344595378&amp;sdata=vmIaO78XmuL1tQJufqf7
> HCGdWHTCJ
> > bEpmGBio15j46U%3D&amp;reserved=0
> 
> Shouldn't it suffice for the SPL to be in this custom format , while the rest of
> the binaries can be in fitImage ?

The issue is the SoC only support i.MX container format for secure boot(AHAB boot),
if we not use secure boot, FIT image do work and could work well.

We investigated using FIT for i.MX8 secure boot, but it does not make sense
we did a FIT wrapper for container. Container itself is also an image format, it contains
image load/entry/size and etc information.

I add a kconfig entry in SPL code, it does not hurt others if the Kconfig entry not chosen.

I do not know how other SoC vendor did FIT hardware secure boot, please share
you have any information.

Thanks,
Peng.

> 
> --
> Best regards,
> Marek Vasut

[U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Marek Vasut]

On 5/20/19 3:54 AM, Peng Fan wrote:
> Hi Marek,
> 
>> Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container
>> format file
>>
>> On 5/20/19 3:30 AM, Peng Fan wrote:
>>> Hi Simon,
>>>
>>>> Subject: Re: [PATCH 4/6] spl: mmc: support loading i.MX container
>>>> format file
>>>>
>>>> Hi Peng,
>>>>
>>>> On Tue, 7 May 2019 at 06:52, Peng Fan <peng.fan@nxp.com> wrote:
>>>>>
>>>>> i.MX8 only support AHAB secure boot with Container format image, we
>>>>> could not use FIT to support secure boot, so introduce container
>>>>
>>>> Why not FIT?
>>>
>>> Actually before we implement secure boot, we use FIT image, however
>>> i.MX8 only support i.MX container format image for secure boot, The
>>> chip will verify the container image when secure boot. It could not
>>> recognize FIT image. So we have to drop FIT image.
>>>
>>>>
>>>>> support to let SPL could load container images.
>>>>
>>>> What is a container image? Can you please point to documentation?
>>>
>>> Sadly, there is no public reference manual. There is a doc that has a
>>> bit of information.
>>>
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcomm
>>>
>> unity.nxp.com%2Fdocs%2FDOC-343178&amp;data=02%7C01%7Cpeng.fan%4
>> 0nxp.co
>>>
>> m%7C8626e7a1d20c44b8715408d6dcc4d866%7C686ea1d3bc2b4c6fa92cd9
>> 9c5c30163
>>>
>> 5%7C0%7C0%7C636939135344595378&amp;sdata=vmIaO78XmuL1tQJufqf7
>> HCGdWHTCJ
>>> bEpmGBio15j46U%3D&amp;reserved=0
>>
>> Shouldn't it suffice for the SPL to be in this custom format , while the rest of
>> the binaries can be in fitImage ?
> 
> The issue is the SoC only support i.MX container format for secure boot(AHAB boot),
> if we not use secure boot, FIT image do work and could work well.
> 
> We investigated using FIT for i.MX8 secure boot, but it does not make sense
> we did a FIT wrapper for container. Container itself is also an image format, it contains
> image load/entry/size and etc information.
> 
> I add a kconfig entry in SPL code, it does not hurt others if the Kconfig entry not chosen.
> 
> I do not know how other SoC vendor did FIT hardware secure boot, please share
> you have any information.

The SPL can be in the custom format, but then can load fitImage with the
next stage(s), right ?

-- 
Best regards,
Marek Vasut

[U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Peng Fan]

Hi Marek,

> Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container
> format file
> 
> On 5/20/19 3:54 AM, Peng Fan wrote:
> > Hi Marek,
> >
> >> Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
> >> container format file
> >>
> >> On 5/20/19 3:30 AM, Peng Fan wrote:
> >>> Hi Simon,
> >>>
> >>>> Subject: Re: [PATCH 4/6] spl: mmc: support loading i.MX container
> >>>> format file
> >>>>
> >>>> Hi Peng,
> >>>>
> >>>> On Tue, 7 May 2019 at 06:52, Peng Fan <peng.fan@nxp.com> wrote:
> >>>>>
> >>>>> i.MX8 only support AHAB secure boot with Container format image,
> >>>>> we could not use FIT to support secure boot, so introduce
> >>>>> container
> >>>>
> >>>> Why not FIT?
> >>>
> >>> Actually before we implement secure boot, we use FIT image, however
> >>> i.MX8 only support i.MX container format image for secure boot, The
> >>> chip will verify the container image when secure boot. It could not
> >>> recognize FIT image. So we have to drop FIT image.
> >>>
> >>>>
> >>>>> support to let SPL could load container images.
> >>>>
> >>>> What is a container image? Can you please point to documentation?
> >>>
> >>> Sadly, there is no public reference manual. There is a doc that has
> >>> a bit of information.
> >>>
> >>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcom
> >> m
> >>>
> >>
> unity.nxp.com%2Fdocs%2FDOC-343178&amp;data=02%7C01%7Cpeng.fan%4
> >> 0nxp.co
> >>>
> >>
> m%7C8626e7a1d20c44b8715408d6dcc4d866%7C686ea1d3bc2b4c6fa92cd9
> >> 9c5c30163
> >>>
> >>
> 5%7C0%7C0%7C636939135344595378&amp;sdata=vmIaO78XmuL1tQJufqf7
> >> HCGdWHTCJ
> >>> bEpmGBio15j46U%3D&amp;reserved=0
> >>
> >> Shouldn't it suffice for the SPL to be in this custom format , while
> >> the rest of the binaries can be in fitImage ?
> >
> > The issue is the SoC only support i.MX container format for secure
> > boot(AHAB boot), if we not use secure boot, FIT image do work and could
> work well.
> >
> > We investigated using FIT for i.MX8 secure boot, but it does not make
> > sense we did a FIT wrapper for container. Container itself is also an
> > image format, it contains image load/entry/size and etc information.
> >
> > I add a kconfig entry in SPL code, it does not hurt others if the Kconfig entry
> not chosen.
> >
> > I do not know how other SoC vendor did FIT hardware secure boot,
> > please share you have any information.
> 
> The SPL can be in the custom format, but then can load fitImage with the next
> stage(s), right ?

I am not able to follow you, could you share more details?

Thanks,
Peng.

> 
> --
> Best regards,
> Marek Vasut

[U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Marek Vasut]

On 5/21/19 4:31 AM, Peng Fan wrote:
> Hi Marek,
> 
>> Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container
>> format file
>>
>> On 5/20/19 3:54 AM, Peng Fan wrote:
>>> Hi Marek,
>>>
>>>> Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
>>>> container format file
>>>>
>>>> On 5/20/19 3:30 AM, Peng Fan wrote:
>>>>> Hi Simon,
>>>>>
>>>>>> Subject: Re: [PATCH 4/6] spl: mmc: support loading i.MX container
>>>>>> format file
>>>>>>
>>>>>> Hi Peng,
>>>>>>
>>>>>> On Tue, 7 May 2019 at 06:52, Peng Fan <peng.fan@nxp.com> wrote:
>>>>>>>
>>>>>>> i.MX8 only support AHAB secure boot with Container format image,
>>>>>>> we could not use FIT to support secure boot, so introduce
>>>>>>> container
>>>>>>
>>>>>> Why not FIT?
>>>>>
>>>>> Actually before we implement secure boot, we use FIT image, however
>>>>> i.MX8 only support i.MX container format image for secure boot, The
>>>>> chip will verify the container image when secure boot. It could not
>>>>> recognize FIT image. So we have to drop FIT image.
>>>>>
>>>>>>
>>>>>>> support to let SPL could load container images.
>>>>>>
>>>>>> What is a container image? Can you please point to documentation?
>>>>>
>>>>> Sadly, there is no public reference manual. There is a doc that has
>>>>> a bit of information.
>>>>>
>>>>
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcom
>>>> m
>>>>>
>>>>
>> unity.nxp.com%2Fdocs%2FDOC-343178&amp;data=02%7C01%7Cpeng.fan%4
>>>> 0nxp.co
>>>>>
>>>>
>> m%7C8626e7a1d20c44b8715408d6dcc4d866%7C686ea1d3bc2b4c6fa92cd9
>>>> 9c5c30163
>>>>>
>>>>
>> 5%7C0%7C0%7C636939135344595378&amp;sdata=vmIaO78XmuL1tQJufqf7
>>>> HCGdWHTCJ
>>>>> bEpmGBio15j46U%3D&amp;reserved=0
>>>>
>>>> Shouldn't it suffice for the SPL to be in this custom format , while
>>>> the rest of the binaries can be in fitImage ?
>>>
>>> The issue is the SoC only support i.MX container format for secure
>>> boot(AHAB boot), if we not use secure boot, FIT image do work and could
>> work well.
>>>
>>> We investigated using FIT for i.MX8 secure boot, but it does not make
>>> sense we did a FIT wrapper for container. Container itself is also an
>>> image format, it contains image load/entry/size and etc information.
>>>
>>> I add a kconfig entry in SPL code, it does not hurt others if the Kconfig entry
>> not chosen.
>>>
>>> I do not know how other SoC vendor did FIT hardware secure boot,
>>> please share you have any information.
>>
>> The SPL can be in the custom format, but then can load fitImage with the next
>> stage(s), right ?
> 
> I am not able to follow you, could you share more details?

Wrap the SPL into this custom format and then have the SPL
load/authenticate fitImage with the rest (U-Boot, Linux, DTB etc).
Would that work ?

-- 
Best regards,
Marek Vasut

[U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Peng Fan]

Hi Marek,
> Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container
> format file
> 
> On 5/21/19 4:31 AM, Peng Fan wrote:
> > Hi Marek,
> >
> >> Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
> >> container format file
> >>
> >> On 5/20/19 3:54 AM, Peng Fan wrote:
> >>> Hi Marek,
> >>>
> >>>> Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
> >>>> container format file
> >>>>
> >>>> On 5/20/19 3:30 AM, Peng Fan wrote:
> >>>>> Hi Simon,
> >>>>>
> >>>>>> Subject: Re: [PATCH 4/6] spl: mmc: support loading i.MX container
> >>>>>> format file
> >>>>>>
> >>>>>> Hi Peng,
> >>>>>>
> >>>>>> On Tue, 7 May 2019 at 06:52, Peng Fan <peng.fan@nxp.com> wrote:
> >>>>>>>
> >>>>>>> i.MX8 only support AHAB secure boot with Container format image,
> >>>>>>> we could not use FIT to support secure boot, so introduce
> >>>>>>> container
> >>>>>>
> >>>>>> Why not FIT?
> >>>>>
> >>>>> Actually before we implement secure boot, we use FIT image,
> >>>>> however
> >>>>> i.MX8 only support i.MX container format image for secure boot,
> >>>>> The chip will verify the container image when secure boot. It
> >>>>> could not recognize FIT image. So we have to drop FIT image.
> >>>>>
> >>>>>>
> >>>>>>> support to let SPL could load container images.
> >>>>>>
> >>>>>> What is a container image? Can you please point to documentation?
> >>>>>
> >>>>> Sadly, there is no public reference manual. There is a doc that
> >>>>> has a bit of information.
> >>>>>
> >>>>
> >>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcom
> >>>> m
> >>>>>
> >>>>
> >>
> unity.nxp.com%2Fdocs%2FDOC-343178&amp;data=02%7C01%7Cpeng.fan%4
> >>>> 0nxp.co
> >>>>>
> >>>>
> >>
> m%7C8626e7a1d20c44b8715408d6dcc4d866%7C686ea1d3bc2b4c6fa92cd9
> >>>> 9c5c30163
> >>>>>
> >>>>
> >>
> 5%7C0%7C0%7C636939135344595378&amp;sdata=vmIaO78XmuL1tQJufqf7
> >>>> HCGdWHTCJ
> >>>>> bEpmGBio15j46U%3D&amp;reserved=0
> >>>>
> >>>> Shouldn't it suffice for the SPL to be in this custom format ,
> >>>> while the rest of the binaries can be in fitImage ?
> >>>
> >>> The issue is the SoC only support i.MX container format for secure
> >>> boot(AHAB boot), if we not use secure boot, FIT image do work and
> >>> could
> >> work well.
> >>>
> >>> We investigated using FIT for i.MX8 secure boot, but it does not
> >>> make sense we did a FIT wrapper for container. Container itself is
> >>> also an image format, it contains image load/entry/size and etc
> information.
> >>>
> >>> I add a kconfig entry in SPL code, it does not hurt others if the
> >>> Kconfig entry
> >> not chosen.
> >>>
> >>> I do not know how other SoC vendor did FIT hardware secure boot,
> >>> please share you have any information.
> >>
> >> The SPL can be in the custom format, but then can load fitImage with
> >> the next stage(s), right ?
> >
> > I am not able to follow you, could you share more details?
> 
> Wrap the SPL into this custom format and then have the SPL
> load/authenticate fitImage with the rest (U-Boot, Linux, DTB etc).
> Would that work ?

It not work.
We already wrap SPL in i.MX container format, this patchset
is to let SPL could load the 2nd container file which contains
U-Boot/DTB/OP-TEE/ATF.  If we let SPL load a fitimage which contains
(U-Boot/DTB and etc), it could not pass secure boot authentication,
because ROM not know fitimage, it only know i.MX container format.

For authentication, we always let ROM to authenticate including
SPL authenticating U-Boot, so we need pass an image to ROM that ROM
could recognize when SPL booting 2nd image.

Thanks,
Peng.


> 
> --
> Best regards,
> Marek Vasut

[U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Marek Vasut]

On 5/21/19 4:55 AM, Peng Fan wrote:
[...]

>>>>> I do not know how other SoC vendor did FIT hardware secure boot,
>>>>> please share you have any information.
>>>>
>>>> The SPL can be in the custom format, but then can load fitImage with
>>>> the next stage(s), right ?
>>>
>>> I am not able to follow you, could you share more details?
>>
>> Wrap the SPL into this custom format and then have the SPL
>> load/authenticate fitImage with the rest (U-Boot, Linux, DTB etc).
>> Would that work ?
> 
> It not work.
> We already wrap SPL in i.MX container format, this patchset
> is to let SPL could load the 2nd container file which contains
> U-Boot/DTB/OP-TEE/ATF.  If we let SPL load a fitimage which contains
> (U-Boot/DTB and etc), it could not pass secure boot authentication,
> because ROM not know fitimage, it only know i.MX container format.

It's not bootrom that authenticates the next stage, it's U-Boot SPL.
BootROM already authenticated and started the U-Boot SPL, so that's a
trusted code. Now this trusted code can authenticate and start the next
stage (U-Boot, ATF, OpTee OS, etc) ; the BootROM is already out of the
picture at this point.

> For authentication, we always let ROM to authenticate including
> SPL authenticating U-Boot, so we need pass an image to ROM that ROM
> could recognize when SPL booting 2nd image.

Shouldn't the CPU have some sort of facility, like a crypto engine,
which authenticates whatever blob with the right signature against a key
burned into the CPU ? If so, then you would just implement a crypto
driver and pass the blob and signature to it. I suspect that's how it
should work, how else would Linux be able to make use of these secure
bits if it cannot call the bootrom anymore ?

-- 
Best regards,
Marek Vasut

[U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Peng Fan]

> Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container
> format file
> 
> On 5/21/19 4:55 AM, Peng Fan wrote:
> [...]
> 
> >>>>> I do not know how other SoC vendor did FIT hardware secure boot,
> >>>>> please share you have any information.
> >>>>
> >>>> The SPL can be in the custom format, but then can load fitImage
> >>>> with the next stage(s), right ?
> >>>
> >>> I am not able to follow you, could you share more details?
> >>
> >> Wrap the SPL into this custom format and then have the SPL
> >> load/authenticate fitImage with the rest (U-Boot, Linux, DTB etc).
> >> Would that work ?
> >
> > It not work.
> > We already wrap SPL in i.MX container format, this patchset is to let
> > SPL could load the 2nd container file which contains
> > U-Boot/DTB/OP-TEE/ATF.  If we let SPL load a fitimage which contains
> > (U-Boot/DTB and etc), it could not pass secure boot authentication,
> > because ROM not know fitimage, it only know i.MX container format.
> 
> It's not bootrom that authenticates the next stage, it's U-Boot SPL.
> BootROM already authenticated and started the U-Boot SPL, so that's a
> trusted code. Now this trusted code can authenticate and start the next stage
> (U-Boot, ATF, OpTee OS, etc) ; the BootROM is already out of the picture at
> this point.

Sorry for not clear. On i.MX8, SCFW (a runtime firmware )exports API for others to use, 
sc_seco_authenticate is the API that used for authentication. I could not
share more information about this API works inside SCFW and ROM.
sc_err_t sc_seco_authenticate(sc_ipc_t ipc, sc_seco_auth_cmd_t cmd, sc_faddr_t addr)

SPL will call this API, one parameter is address which needs a container image there.

> 
> > For authentication, we always let ROM to authenticate including SPL
> > authenticating U-Boot, so we need pass an image to ROM that ROM could
> > recognize when SPL booting 2nd image.
> 
> Shouldn't the CPU have some sort of facility, like a crypto engine, which
> authenticates whatever blob with the right signature against a key burned into
> the CPU ? If so, then you would just implement a crypto driver and pass the
> blob and signature to it. I suspect that's how it should work, how else would
> Linux be able to make use of these secure bits if it cannot call the bootrom
> anymore ?

sc_seco_authenticate on i.MX8 will always be available. It is exported by a runtime
firmware running on a Cortex-M core inside i.MX8. The API will do authentication,
its accepts container format image as input and no other format.

Thanks,
Peng.

> 
> --
> Best regards,
> Marek Vasut

[U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Lukasz Majewski]

Hi Peng,

> > Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
> > container format file
> > 
> > On 5/21/19 4:55 AM, Peng Fan wrote:
> > [...]
> >   
> > >>>>> I do not know how other SoC vendor did FIT hardware secure
> > >>>>> boot, please share you have any information.  
> > >>>>
> > >>>> The SPL can be in the custom format, but then can load fitImage
> > >>>> with the next stage(s), right ?  
> > >>>
> > >>> I am not able to follow you, could you share more details?  
> > >>
> > >> Wrap the SPL into this custom format and then have the SPL
> > >> load/authenticate fitImage with the rest (U-Boot, Linux, DTB
> > >> etc). Would that work ?  
> > >
> > > It not work.
> > > We already wrap SPL in i.MX container format, this patchset is to
> > > let SPL could load the 2nd container file which contains
> > > U-Boot/DTB/OP-TEE/ATF.  If we let SPL load a fitimage which
> > > contains (U-Boot/DTB and etc), it could not pass secure boot
> > > authentication, because ROM not know fitimage, it only know i.MX
> > > container format.  
> > 
> > It's not bootrom that authenticates the next stage, it's U-Boot SPL.
> > BootROM already authenticated and started the U-Boot SPL, so that's
> > a trusted code. Now this trusted code can authenticate and start
> > the next stage (U-Boot, ATF, OpTee OS, etc) ; the BootROM is
> > already out of the picture at this point.  
> 
> Sorry for not clear. On i.MX8, SCFW (a runtime firmware )exports API
> for others to use, sc_seco_authenticate is the API that used for
> authentication. I could not share more information about this API
> works inside SCFW and ROM. sc_err_t sc_seco_authenticate(sc_ipc_t
> ipc, sc_seco_auth_cmd_t cmd, sc_faddr_t addr)
> 
> SPL will call this API, one parameter is address which needs a
> container image there.

Please consider following scenario (I think that this is in sync with
Marek's point):

1. You wrap SPL into i.MX8 "container", so the SPL would be recognised
an checked by secure code in ROM.

2. Then we do have SPL "trusted". It is up to SPL to:

2.1. Use its private key to check u-boot, dtb, etc embedded into
FitImage (as written here: ./doc/uImage.FIT/verified-boot.txt).

2.2. Use crypto engine (it's API) with fused keys to speed-up the
process of boot (by HW support to check the binary). Such approach is
in i.MX6Q.


By using above approach we do have the NXP's "container" format only
seen in the SPL (which is OK, as for example Samsung does similar thing
with FBL/BL1). When SPL is "trused" we may use available facilities.

> 
> >   
> > > For authentication, we always let ROM to authenticate including
> > > SPL authenticating U-Boot, so we need pass an image to ROM that
> > > ROM could recognize when SPL booting 2nd image.  
> > 
> > Shouldn't the CPU have some sort of facility, like a crypto engine,
> > which authenticates whatever blob with the right signature against
> > a key burned into the CPU ? If so, then you would just implement a
> > crypto driver and pass the blob and signature to it. I suspect
> > that's how it should work, how else would Linux be able to make use
> > of these secure bits if it cannot call the bootrom anymore ?  
> 
> sc_seco_authenticate on i.MX8 will always be available. It is
> exported by a runtime firmware running on a Cortex-M core inside
> i.MX8. The API will do authentication, its accepts container format
> image as input and no other format.
> 
> Thanks,
> Peng.
> 
> > 
> > --
> > Best regards,
> > Marek Vasut  
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190521/64c1ffcf/attachment.sig>

[U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Marek Vasut]

On 5/21/19 10:32 AM, Lukasz Majewski wrote:
> Hi Peng,
> 
>>> Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
>>> container format file
>>>
>>> On 5/21/19 4:55 AM, Peng Fan wrote:
>>> [...]
>>>   
>>>>>>>> I do not know how other SoC vendor did FIT hardware secure
>>>>>>>> boot, please share you have any information.  
>>>>>>>
>>>>>>> The SPL can be in the custom format, but then can load fitImage
>>>>>>> with the next stage(s), right ?  
>>>>>>
>>>>>> I am not able to follow you, could you share more details?  
>>>>>
>>>>> Wrap the SPL into this custom format and then have the SPL
>>>>> load/authenticate fitImage with the rest (U-Boot, Linux, DTB
>>>>> etc). Would that work ?  
>>>>
>>>> It not work.
>>>> We already wrap SPL in i.MX container format, this patchset is to
>>>> let SPL could load the 2nd container file which contains
>>>> U-Boot/DTB/OP-TEE/ATF.  If we let SPL load a fitimage which
>>>> contains (U-Boot/DTB and etc), it could not pass secure boot
>>>> authentication, because ROM not know fitimage, it only know i.MX
>>>> container format.  
>>>
>>> It's not bootrom that authenticates the next stage, it's U-Boot SPL.
>>> BootROM already authenticated and started the U-Boot SPL, so that's
>>> a trusted code. Now this trusted code can authenticate and start
>>> the next stage (U-Boot, ATF, OpTee OS, etc) ; the BootROM is
>>> already out of the picture at this point.  
>>
>> Sorry for not clear. On i.MX8, SCFW (a runtime firmware )exports API
>> for others to use, sc_seco_authenticate is the API that used for
>> authentication. I could not share more information about this API
>> works inside SCFW and ROM. sc_err_t sc_seco_authenticate(sc_ipc_t
>> ipc, sc_seco_auth_cmd_t cmd, sc_faddr_t addr)
>>
>> SPL will call this API, one parameter is address which needs a
>> container image there.
> 
> Please consider following scenario (I think that this is in sync with
> Marek's point):

It's not in sync, see 2.1 below.

> 1. You wrap SPL into i.MX8 "container", so the SPL would be recognised
> an checked by secure code in ROM.
> 
> 2. Then we do have SPL "trusted". It is up to SPL to:
> 
> 2.1. Use its private key to check u-boot, dtb, etc embedded into
> FitImage (as written here: ./doc/uImage.FIT/verified-boot.txt).

Then you have two private keys, one which is potentially exposed by
being in the SPL. You want to use the crypto engine, which has a key in
it and which cannot be easily extracted.

> 2.2. Use crypto engine (it's API) with fused keys to speed-up the
> process of boot (by HW support to check the binary). Such approach is
> in i.MX6Q.
> 
> 
> By using above approach we do have the NXP's "container" format only
> seen in the SPL (which is OK, as for example Samsung does similar thing
> with FBL/BL1). When SPL is "trused" we may use available facilities.
My question is, how can Linux crypto API make use of the built-in
private key in the iMX8 to authenticate payload ? There surely is a way.

-- 
Best regards,
Marek Vasut

[U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Lukasz Majewski]

Hi Marek,

> On 5/21/19 10:32 AM, Lukasz Majewski wrote:
> > Hi Peng,
> >   
> >>> Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
> >>> container format file
> >>>
> >>> On 5/21/19 4:55 AM, Peng Fan wrote:
> >>> [...]
> >>>     
> >>>>>>>> I do not know how other SoC vendor did FIT hardware secure
> >>>>>>>> boot, please share you have any information.    
> >>>>>>>
> >>>>>>> The SPL can be in the custom format, but then can load
> >>>>>>> fitImage with the next stage(s), right ?    
> >>>>>>
> >>>>>> I am not able to follow you, could you share more details?    
> >>>>>
> >>>>> Wrap the SPL into this custom format and then have the SPL
> >>>>> load/authenticate fitImage with the rest (U-Boot, Linux, DTB
> >>>>> etc). Would that work ?    
> >>>>
> >>>> It not work.
> >>>> We already wrap SPL in i.MX container format, this patchset is to
> >>>> let SPL could load the 2nd container file which contains
> >>>> U-Boot/DTB/OP-TEE/ATF.  If we let SPL load a fitimage which
> >>>> contains (U-Boot/DTB and etc), it could not pass secure boot
> >>>> authentication, because ROM not know fitimage, it only know i.MX
> >>>> container format.    
> >>>
> >>> It's not bootrom that authenticates the next stage, it's U-Boot
> >>> SPL. BootROM already authenticated and started the U-Boot SPL, so
> >>> that's a trusted code. Now this trusted code can authenticate and
> >>> start the next stage (U-Boot, ATF, OpTee OS, etc) ; the BootROM is
> >>> already out of the picture at this point.    
> >>
> >> Sorry for not clear. On i.MX8, SCFW (a runtime firmware )exports
> >> API for others to use, sc_seco_authenticate is the API that used
> >> for authentication. I could not share more information about this
> >> API works inside SCFW and ROM. sc_err_t
> >> sc_seco_authenticate(sc_ipc_t ipc, sc_seco_auth_cmd_t cmd,
> >> sc_faddr_t addr)
> >>
> >> SPL will call this API, one parameter is address which needs a
> >> container image there.  
> > 
> > Please consider following scenario (I think that this is in sync
> > with Marek's point):  
> 
> It's not in sync, see 2.1 below.
> 
> > 1. You wrap SPL into i.MX8 "container", so the SPL would be
> > recognised an checked by secure code in ROM.
> > 
> > 2. Then we do have SPL "trusted". It is up to SPL to:
> > 
> > 2.1. Use its private key to check u-boot, dtb, etc embedded into
> > FitImage (as written here: ./doc/uImage.FIT/verified-boot.txt).  
> 
> Then you have two private keys, 

There shall be s/private key/public key/g in the SPL (but then the
SPL needs to be trusted). 

And I fully agree that we shall use crypto engine whenever possible.

> one which is potentially exposed by
> being in the SPL. You want to use the crypto engine, which has a key
> in it and which cannot be easily extracted.
> 
> > 2.2. Use crypto engine (it's API) with fused keys to speed-up the
> > process of boot (by HW support to check the binary). Such approach
> > is in i.MX6Q.
> > 
> > 
> > By using above approach we do have the NXP's "container" format only
> > seen in the SPL (which is OK, as for example Samsung does similar
> > thing with FBL/BL1). When SPL is "trused" we may use available
> > facilities.  
> My question is, how can Linux crypto API make use of the built-in
> private key in the iMX8 to authenticate payload ? There surely is a
> way.
> 




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190521/610d9fa4/attachment.sig>

[U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Peng Fan]

Simon,

> Subject: RE: [PATCH 4/6] spl: mmc: support loading i.MX container format file
> 
> Hi Simon,
> 
> > Subject: Re: [PATCH 4/6] spl: mmc: support loading i.MX container
> > format file
> >
> > Hi Peng,
> >
> > On Tue, 7 May 2019 at 06:52, Peng Fan <peng.fan@nxp.com> wrote:
> > >
> > > i.MX8 only support AHAB secure boot with Container format image, we
> > > could not use FIT to support secure boot, so introduce container
> >
> > Why not FIT?
> 
> Actually before we implement secure boot, we use FIT image, however
> i.MX8 only support i.MX container format image for secure boot, The chip will
> verify the container image when secure boot. It could not recognize FIT image.
> So we have to drop FIT image.
> 
> >
> > > support to let SPL could load container images.
> >
> > What is a container image? Can you please point to documentation?
> 
> Sadly, there is no public reference manual. There is a doc that has a bit of
> information. https://community.nxp.com/docs/DOC-343178

https://www.nxp.com/docs/en/reference-manual/IMX8DQXPRM.pdf
Chapter 5.9.4 High Level Container Format

Thanks,
Peng.

> 
> Thanks,
> Peng.
> 
> >
> > >
> > > Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
> > > Cc: Tien Fong Chee <tien.fong.chee@intel.com>
> > > Cc: York Sun <york.sun@nxp.com>
> > > Cc: Marek Vasut <marex@denx.de>
> > > Cc: Alex Kiernan <alex.kiernan@gmail.com>
> > > Cc: Simon Glass <sjg@chromium.org>
> > > Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
> > > Cc: Kever Yang <kever.yang@rock-chips.com>
> > > Cc: Heiko Schocher <hs@denx.de>
> > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > ---
> > >  common/spl/spl_mmc.c | 10 ++++++++++
> > >  include/spl.h        | 12 ++++++++++++
> > >  2 files changed, 22 insertions(+)
> >
> > Regards,
> > Simon

[U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Peng Fan]

Hi Lukasz,

> -----Original Message-----
> From: Lukasz Majewski [mailto:lukma at denx.de]
> Sent: 2019年5月21日 16:33
> To: Peng Fan <peng.fan@nxp.com>
> Cc: Marek Vasut <marex@denx.de>; Marek Vasut <marek.vasut@gmail.com>;
> Simon Glass <sjg@chromium.org>; u-boot at lists.denx.de; Tien Fong Chee
> <tien.fong.chee@intel.com>; York Sun <york.sun@nxp.com>; dl-uboot-imx
> <uboot-imx@nxp.com>
> Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container
> format file
> 
> Hi Peng,
> 
> > > Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
> > > container format file
> > >
> > > On 5/21/19 4:55 AM, Peng Fan wrote:
> > > [...]
> > >
> > > >>>>> I do not know how other SoC vendor did FIT hardware secure
> > > >>>>> boot, please share you have any information.
> > > >>>>
> > > >>>> The SPL can be in the custom format, but then can load fitImage
> > > >>>> with the next stage(s), right ?
> > > >>>
> > > >>> I am not able to follow you, could you share more details?
> > > >>
> > > >> Wrap the SPL into this custom format and then have the SPL
> > > >> load/authenticate fitImage with the rest (U-Boot, Linux, DTB
> > > >> etc). Would that work ?
> > > >
> > > > It not work.
> > > > We already wrap SPL in i.MX container format, this patchset is to
> > > > let SPL could load the 2nd container file which contains
> > > > U-Boot/DTB/OP-TEE/ATF.  If we let SPL load a fitimage which
> > > > contains (U-Boot/DTB and etc), it could not pass secure boot
> > > > authentication, because ROM not know fitimage, it only know i.MX
> > > > container format.
> > >
> > > It's not bootrom that authenticates the next stage, it's U-Boot SPL.
> > > BootROM already authenticated and started the U-Boot SPL, so that's
> > > a trusted code. Now this trusted code can authenticate and start the
> > > next stage (U-Boot, ATF, OpTee OS, etc) ; the BootROM is already out
> > > of the picture at this point.
> >
> > Sorry for not clear. On i.MX8, SCFW (a runtime firmware )exports API
> > for others to use, sc_seco_authenticate is the API that used for
> > authentication. I could not share more information about this API
> > works inside SCFW and ROM. sc_err_t sc_seco_authenticate(sc_ipc_t ipc,
> > sc_seco_auth_cmd_t cmd, sc_faddr_t addr)
> >
> > SPL will call this API, one parameter is address which needs a
> > container image there.
> 
> Please consider following scenario (I think that this is in sync with Marek's
> point):
> 
> 1. You wrap SPL into i.MX8 "container", so the SPL would be recognised an
> checked by secure code in ROM.
> 
> 2. Then we do have SPL "trusted". It is up to SPL to:
> 
> 2.1. Use its private key to check u-boot, dtb, etc embedded into FitImage (as
> written here: ./doc/uImage.FIT/verified-boot.txt).
> 
> 2.2. Use crypto engine (it's API) with fused keys to speed-up the process of
> boot (by HW support to check the binary). Such approach is in i.MX6Q.

I suppose you talking HAB.

> 
> 
> By using above approach we do have the NXP's "container" format only seen
> in the SPL (which is OK, as for example Samsung does similar thing with
> FBL/BL1). When SPL is "trused" we may use available facilities.

The issue to me is that sc_seco_authenticate could not take a FIT image
as input.

If I switch to FIT, I need to use FIT to wrap a container image, it does not
make sense to me.

Thanks,
Peng.
> 
> >
> > >
> > > > For authentication, we always let ROM to authenticate including
> > > > SPL authenticating U-Boot, so we need pass an image to ROM that
> > > > ROM could recognize when SPL booting 2nd image.
> > >
> > > Shouldn't the CPU have some sort of facility, like a crypto engine,
> > > which authenticates whatever blob with the right signature against a
> > > key burned into the CPU ? If so, then you would just implement a
> > > crypto driver and pass the blob and signature to it. I suspect
> > > that's how it should work, how else would Linux be able to make use
> > > of these secure bits if it cannot call the bootrom anymore ?
> >
> > sc_seco_authenticate on i.MX8 will always be available. It is exported
> > by a runtime firmware running on a Cortex-M core inside i.MX8. The API
> > will do authentication, its accepts container format image as input
> > and no other format.
> >
> > Thanks,
> > Peng.
> >
> > >
> > > --
> > > Best regards,
> > > Marek Vasut
> > _______________________________________________
> > U-Boot mailing list
> > U-Boot at lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
> 
> 
> 
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> lukma at denx.de

[U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Lukasz Majewski]

Hi Peng,

> Hi Lukasz,
> 
> > -----Original Message-----
> > From: Lukasz Majewski [mailto:lukma at denx.de]
> > Sent: 2019年5月21日 16:33
> > To: Peng Fan <peng.fan@nxp.com>
> > Cc: Marek Vasut <marex@denx.de>; Marek Vasut
> > <marek.vasut@gmail.com>; Simon Glass <sjg@chromium.org>;
> > u-boot at lists.denx.de; Tien Fong Chee <tien.fong.chee@intel.com>;
> > York Sun <york.sun@nxp.com>; dl-uboot-imx <uboot-imx@nxp.com>
> > Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
> > container format file
> > 
> > Hi Peng,
> >   
> > > > Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
> > > > container format file
> > > >
> > > > On 5/21/19 4:55 AM, Peng Fan wrote:
> > > > [...]
> > > >  
> > > > >>>>> I do not know how other SoC vendor did FIT hardware secure
> > > > >>>>> boot, please share you have any information.  
> > > > >>>>
> > > > >>>> The SPL can be in the custom format, but then can load
> > > > >>>> fitImage with the next stage(s), right ?  
> > > > >>>
> > > > >>> I am not able to follow you, could you share more details?  
> > > > >>
> > > > >> Wrap the SPL into this custom format and then have the SPL
> > > > >> load/authenticate fitImage with the rest (U-Boot, Linux, DTB
> > > > >> etc). Would that work ?  
> > > > >
> > > > > It not work.
> > > > > We already wrap SPL in i.MX container format, this patchset
> > > > > is to let SPL could load the 2nd container file which contains
> > > > > U-Boot/DTB/OP-TEE/ATF.  If we let SPL load a fitimage which
> > > > > contains (U-Boot/DTB and etc), it could not pass secure boot
> > > > > authentication, because ROM not know fitimage, it only know
> > > > > i.MX container format.  
> > > >
> > > > It's not bootrom that authenticates the next stage, it's U-Boot
> > > > SPL. BootROM already authenticated and started the U-Boot SPL,
> > > > so that's a trusted code. Now this trusted code can
> > > > authenticate and start the next stage (U-Boot, ATF, OpTee OS,
> > > > etc) ; the BootROM is already out of the picture at this
> > > > point.  
> > >
> > > Sorry for not clear. On i.MX8, SCFW (a runtime firmware )exports
> > > API for others to use, sc_seco_authenticate is the API that used
> > > for authentication. I could not share more information about this
> > > API works inside SCFW and ROM. sc_err_t
> > > sc_seco_authenticate(sc_ipc_t ipc, sc_seco_auth_cmd_t cmd,
> > > sc_faddr_t addr)
> > >
> > > SPL will call this API, one parameter is address which needs a
> > > container image there.  
> > 
> > Please consider following scenario (I think that this is in sync
> > with Marek's point):
> > 
> > 1. You wrap SPL into i.MX8 "container", so the SPL would be
> > recognised an checked by secure code in ROM.
> > 
> > 2. Then we do have SPL "trusted". It is up to SPL to:
> > 
> > 2.1. Use its private key to check u-boot, dtb, etc embedded into
> > FitImage (as written here: ./doc/uImage.FIT/verified-boot.txt).
> > 
> > 2.2. Use crypto engine (it's API) with fused keys to speed-up the
> > process of boot (by HW support to check the binary). Such approach
> > is in i.MX6Q.  
> 
> I suppose you talking HAB.

Yes. As described here:

https://www.nxp.com/docs/en/application-note/AN4581.pdf

> 
> > 
> > 
> > By using above approach we do have the NXP's "container" format
> > only seen in the SPL (which is OK, as for example Samsung does
> > similar thing with FBL/BL1). When SPL is "trused" we may use
> > available facilities.  
> 
> The issue to me is that sc_seco_authenticate could not take a FIT
> image as input.

Is the sc_seco_authenticate an API accessible from SPL, U-Boot proper
or Linux crypro engine driver?

Or is it just the function executed by ROM on the very beginning to
load SPL?

> 
> If I switch to FIT, I need to use FIT to wrap a container image, it
> does not make sense to me.

Please correct me if I'm wrong, but isn't the container image only
needed to wrap SPL?

In which other cases the container image is needed in U-Boot proper or
Linux kernel?

> 
> Thanks,
> Peng.
> >   
> > >  
> > > >  
> > > > > For authentication, we always let ROM to authenticate
> > > > > including SPL authenticating U-Boot, so we need pass an image
> > > > > to ROM that ROM could recognize when SPL booting 2nd image.  
> > > >
> > > > Shouldn't the CPU have some sort of facility, like a crypto
> > > > engine, which authenticates whatever blob with the right
> > > > signature against a key burned into the CPU ? If so, then you
> > > > would just implement a crypto driver and pass the blob and
> > > > signature to it. I suspect that's how it should work, how else
> > > > would Linux be able to make use of these secure bits if it
> > > > cannot call the bootrom anymore ?  
> > >
> > > sc_seco_authenticate on i.MX8 will always be available. It is
> > > exported by a runtime firmware running on a Cortex-M core inside
> > > i.MX8. The API will do authentication, its accepts container
> > > format image as input and no other format.
> > >
> > > Thanks,
> > > Peng.
> > >  
> > > >
> > > > --
> > > > Best regards,
> > > > Marek Vasut  
> > > _______________________________________________
> > > U-Boot mailing list
> > > U-Boot at lists.denx.de
> > > https://lists.denx.de/listinfo/u-boot  
> > 
> > 
> > 
> > 
> > Best regards,
> > 
> > Lukasz Majewski
> > 
> > --
> > 
> > DENX Software Engineering GmbH,      Managing Director: Wolfgang
> > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> > lukma at denx.de  




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190522/f055de0b/attachment.sig>

[U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Peng Fan]

> > > > > Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
> > > > > container format file
> > > > >
> > > > > On 5/21/19 4:55 AM, Peng Fan wrote:
> > > > > [...]
> > > > >
> > > > > >>>>> I do not know how other SoC vendor did FIT hardware secure
> > > > > >>>>> boot, please share you have any information.
> > > > > >>>>
> > > > > >>>> The SPL can be in the custom format, but then can load
> > > > > >>>> fitImage with the next stage(s), right ?
> > > > > >>>
> > > > > >>> I am not able to follow you, could you share more details?
> > > > > >>
> > > > > >> Wrap the SPL into this custom format and then have the SPL
> > > > > >> load/authenticate fitImage with the rest (U-Boot, Linux, DTB
> > > > > >> etc). Would that work ?
> > > > > >
> > > > > > It not work.
> > > > > > We already wrap SPL in i.MX container format, this patchset is
> > > > > > to let SPL could load the 2nd container file which contains
> > > > > > U-Boot/DTB/OP-TEE/ATF.  If we let SPL load a fitimage which
> > > > > > contains (U-Boot/DTB and etc), it could not pass secure boot
> > > > > > authentication, because ROM not know fitimage, it only know
> > > > > > i.MX container format.
> > > > >
> > > > > It's not bootrom that authenticates the next stage, it's U-Boot
> > > > > SPL. BootROM already authenticated and started the U-Boot SPL,
> > > > > so that's a trusted code. Now this trusted code can authenticate
> > > > > and start the next stage (U-Boot, ATF, OpTee OS,
> > > > > etc) ; the BootROM is already out of the picture at this point.
> > > >
> > > > Sorry for not clear. On i.MX8, SCFW (a runtime firmware )exports
> > > > API for others to use, sc_seco_authenticate is the API that used
> > > > for authentication. I could not share more information about this
> > > > API works inside SCFW and ROM. sc_err_t
> > > > sc_seco_authenticate(sc_ipc_t ipc, sc_seco_auth_cmd_t cmd,
> > > > sc_faddr_t addr)
> > > >
> > > > SPL will call this API, one parameter is address which needs a
> > > > container image there.
> > >
> > > Please consider following scenario (I think that this is in sync
> > > with Marek's point):
> > >
> > > 1. You wrap SPL into i.MX8 "container", so the SPL would be
> > > recognised an checked by secure code in ROM.
> > >
> > > 2. Then we do have SPL "trusted". It is up to SPL to:
> > >
> > > 2.1. Use its private key to check u-boot, dtb, etc embedded into
> > > FitImage (as written here: ./doc/uImage.FIT/verified-boot.txt).
> > >
> > > 2.2. Use crypto engine (it's API) with fused keys to speed-up the
> > > process of boot (by HW support to check the binary). Such approach
> > > is in i.MX6Q.
> >
> > I suppose you talking HAB.
> 
> Yes. As described here:
> 
> https://www.nxp.com/docs/en/application-note/AN4581.pdf
> 
> >
> > >
> > >
> > > By using above approach we do have the NXP's "container" format only
> > > seen in the SPL (which is OK, as for example Samsung does similar
> > > thing with FBL/BL1). When SPL is "trused" we may use available
> > > facilities.
> >
> > The issue to me is that sc_seco_authenticate could not take a FIT
> > image as input.
> 
> Is the sc_seco_authenticate an API accessible from SPL, U-Boot proper or
> Linux crypro engine driver?

Yes, it is an API accessible in SPL/U-Boot stage. I do not know about Linux
crypto driver.

> 
> Or is it just the function executed by ROM on the very beginning to load SPL?
> 
> >
> > If I switch to FIT, I need to use FIT to wrap a container image, it
> > does not make sense to me.
> 
> Please correct me if I'm wrong, but isn't the container image only needed to
> wrap SPL?

Container image will wrap SPL to make ROM could load SPL, Kick SPL and
authenticate SPL.

When SPL booting U-Boot, SPL could use FIT to load and boot uboot.
But when SPL need to authenticate U-Boot with AHAB on i.MX8, a container
format header/image needs to be passed to sc_seco_authenticate API, the API
internal implementation is it will parse the container header/image.

So in vendor tree, uboot/atf/optee are wrapped into a container format image.

> 
> In which other cases the container image is needed in U-Boot proper or Linux
> kernel?

When uboot authenticate kernel, we also wrap kernel image into a container format
file using CST. I do not know how Linux kernel itself authenticate others.

Thanks,
Peng.

> 
> >
> > Thanks,
> > Peng.
> > >
> > > >
> > > > >
> > > > > > For authentication, we always let ROM to authenticate
> > > > > > including SPL authenticating U-Boot, so we need pass an image
> > > > > > to ROM that ROM could recognize when SPL booting 2nd image.
> > > > >
> > > > > Shouldn't the CPU have some sort of facility, like a crypto
> > > > > engine, which authenticates whatever blob with the right
> > > > > signature against a key burned into the CPU ? If so, then you
> > > > > would just implement a crypto driver and pass the blob and
> > > > > signature to it. I suspect that's how it should work, how else
> > > > > would Linux be able to make use of these secure bits if it
> > > > > cannot call the bootrom anymore ?
> > > >
> > > > sc_seco_authenticate on i.MX8 will always be available. It is
> > > > exported by a runtime firmware running on a Cortex-M core inside
> > > > i.MX8. The API will do authentication, its accepts container
> > > > format image as input and no other format.
> > > >
> > > > Thanks,
> > > > Peng.
> > > >
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Marek Vasut
> > > > _______________________________________________
> > > > U-Boot mailing list
> > > > U-Boot at lists.denx.de
> > > > https://lists.denx.de/listinfo/u-boot
> > >
> > >
> > >
> > >
> > > Best regards,
> > >
> > > Lukasz Majewski
> > >
> > > --
> > >
> > > DENX Software Engineering GmbH,      Managing Director: Wolfgang
> > > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > > Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> > > lukma at denx.de
> 
> 
> 
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> lukma at denx.de

[U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Lukasz Majewski]

Hi Peng,

> > > > > > Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading
> > > > > > i.MX container format file
> > > > > >
> > > > > > On 5/21/19 4:55 AM, Peng Fan wrote:
> > > > > > [...]
> > > > > >  
> > > > > > >>>>> I do not know how other SoC vendor did FIT hardware
> > > > > > >>>>> secure boot, please share you have any information.  
> > > > > > >>>>
> > > > > > >>>> The SPL can be in the custom format, but then can load
> > > > > > >>>> fitImage with the next stage(s), right ?  
> > > > > > >>>
> > > > > > >>> I am not able to follow you, could you share more
> > > > > > >>> details?  
> > > > > > >>
> > > > > > >> Wrap the SPL into this custom format and then have the
> > > > > > >> SPL load/authenticate fitImage with the rest (U-Boot,
> > > > > > >> Linux, DTB etc). Would that work ?  
> > > > > > >
> > > > > > > It not work.
> > > > > > > We already wrap SPL in i.MX container format, this
> > > > > > > patchset is to let SPL could load the 2nd container file
> > > > > > > which contains U-Boot/DTB/OP-TEE/ATF.  If we let SPL load
> > > > > > > a fitimage which contains (U-Boot/DTB and etc), it could
> > > > > > > not pass secure boot authentication, because ROM not know
> > > > > > > fitimage, it only know i.MX container format.  
> > > > > >
> > > > > > It's not bootrom that authenticates the next stage, it's
> > > > > > U-Boot SPL. BootROM already authenticated and started the
> > > > > > U-Boot SPL, so that's a trusted code. Now this trusted code
> > > > > > can authenticate and start the next stage (U-Boot, ATF,
> > > > > > OpTee OS, etc) ; the BootROM is already out of the picture
> > > > > > at this point.  
> > > > >
> > > > > Sorry for not clear. On i.MX8, SCFW (a runtime firmware
> > > > > )exports API for others to use, sc_seco_authenticate is the
> > > > > API that used for authentication. I could not share more
> > > > > information about this API works inside SCFW and ROM. sc_err_t
> > > > > sc_seco_authenticate(sc_ipc_t ipc, sc_seco_auth_cmd_t cmd,
> > > > > sc_faddr_t addr)
> > > > >
> > > > > SPL will call this API, one parameter is address which needs a
> > > > > container image there.  
> > > >
> > > > Please consider following scenario (I think that this is in sync
> > > > with Marek's point):
> > > >
> > > > 1. You wrap SPL into i.MX8 "container", so the SPL would be
> > > > recognised an checked by secure code in ROM.
> > > >
> > > > 2. Then we do have SPL "trusted". It is up to SPL to:
> > > >
> > > > 2.1. Use its private key to check u-boot, dtb, etc embedded into
> > > > FitImage (as written here: ./doc/uImage.FIT/verified-boot.txt).
> > > >
> > > > 2.2. Use crypto engine (it's API) with fused keys to speed-up
> > > > the process of boot (by HW support to check the binary). Such
> > > > approach is in i.MX6Q.  
> > >
> > > I suppose you talking HAB.  
> > 
> > Yes. As described here:
> > 
> > https://www.nxp.com/docs/en/application-note/AN4581.pdf
> >   
> > >  
> > > >
> > > >
> > > > By using above approach we do have the NXP's "container" format
> > > > only seen in the SPL (which is OK, as for example Samsung does
> > > > similar thing with FBL/BL1). When SPL is "trused" we may use
> > > > available facilities.  
> > >
> > > The issue to me is that sc_seco_authenticate could not take a FIT
> > > image as input.  
> > 
> > Is the sc_seco_authenticate an API accessible from SPL, U-Boot
> > proper or Linux crypro engine driver?  
> 
> Yes, it is an API accessible in SPL/U-Boot stage. I do not know about
> Linux crypto driver.

Maybe it would be worth to check how Linux handle this? Maybe it would
shed some more light on it?

> 
> > 
> > Or is it just the function executed by ROM on the very beginning to
> > load SPL? 
> > >
> > > If I switch to FIT, I need to use FIT to wrap a container image,
> > > it does not make sense to me.  
> > 
> > Please correct me if I'm wrong, but isn't the container image only
> > needed to wrap SPL?  
> 
> Container image will wrap SPL to make ROM could load SPL, Kick SPL and
> authenticate SPL.

Ok. So it is needed in the ROM "part" of security.

> 
> When SPL booting U-Boot, SPL could use FIT to load and boot uboot.
> But when SPL need to authenticate U-Boot with AHAB on i.MX8, a
> container format header/image needs to be passed to
> sc_seco_authenticate API, the API internal implementation is it will
> parse the container header/image.

Ok. So every time we want to use the sc_seco_authenticate API the
provided image for checking needs to be wrapped into the "container"
iMX8 specific format.

> 
> So in vendor tree, uboot/atf/optee are wrapped into a container
> format image.

Ok.

> 
> > 
> > In which other cases the container image is needed in U-Boot proper
> > or Linux kernel?  
> 
> When uboot authenticate kernel, we also wrap kernel image into a
> container format file using CST. I do not know how Linux kernel
> itself authenticate others.
> 
> Thanks,
> Peng.
> 
> >   
> > >
> > > Thanks,
> > > Peng.  
> > > >  
> > > > >  
> > > > > >  
> > > > > > > For authentication, we always let ROM to authenticate
> > > > > > > including SPL authenticating U-Boot, so we need pass an
> > > > > > > image to ROM that ROM could recognize when SPL booting
> > > > > > > 2nd image.  
> > > > > >
> > > > > > Shouldn't the CPU have some sort of facility, like a crypto
> > > > > > engine, which authenticates whatever blob with the right
> > > > > > signature against a key burned into the CPU ? If so, then
> > > > > > you would just implement a crypto driver and pass the blob
> > > > > > and signature to it. I suspect that's how it should work,
> > > > > > how else would Linux be able to make use of these secure
> > > > > > bits if it cannot call the bootrom anymore ?  
> > > > >
> > > > > sc_seco_authenticate on i.MX8 will always be available. It is
> > > > > exported by a runtime firmware running on a Cortex-M core
> > > > > inside i.MX8. The API will do authentication, its accepts
> > > > > container format image as input and no other format.
> > > > >
> > > > > Thanks,
> > > > > Peng.
> > > > >  
> > > > > >
> > > > > > --
> > > > > > Best regards,
> > > > > > Marek Vasut  
> > > > > _______________________________________________
> > > > > U-Boot mailing list
> > > > > U-Boot at lists.denx.de
> > > > > https://lists.denx.de/listinfo/u-boot  
> > > >
> > > >
> > > >
> > > >
> > > > Best regards,
> > > >
> > > > Lukasz Majewski
> > > >
> > > > --
> > > >
> > > > DENX Software Engineering GmbH,      Managing Director: Wolfgang
> > > > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194
> > > > Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax:
> > > > (+49)-8142-66989-80 Email: lukma at denx.de  
> > 
> > 
> > 
> > 
> > Best regards,
> > 
> > Lukasz Majewski
> > 
> > --
> > 
> > DENX Software Engineering GmbH,      Managing Director: Wolfgang
> > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> > lukma at denx.de  




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190522/fff7327a/attachment.sig>

[U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Peng Fan]

> 
> > > > > > > Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading
> > > > > > > i.MX container format file
> > > > > > >
> > > > > > > On 5/21/19 4:55 AM, Peng Fan wrote:
> > > > > > > [...]
> > > > > > >
> > > > > > > >>>>> I do not know how other SoC vendor did FIT hardware
> > > > > > > >>>>> secure boot, please share you have any information.
> > > > > > > >>>>
> > > > > > > >>>> The SPL can be in the custom format, but then can load
> > > > > > > >>>> fitImage with the next stage(s), right ?
> > > > > > > >>>
> > > > > > > >>> I am not able to follow you, could you share more
> > > > > > > >>> details?
> > > > > > > >>
> > > > > > > >> Wrap the SPL into this custom format and then have the
> > > > > > > >> SPL load/authenticate fitImage with the rest (U-Boot,
> > > > > > > >> Linux, DTB etc). Would that work ?
> > > > > > > >
> > > > > > > > It not work.
> > > > > > > > We already wrap SPL in i.MX container format, this
> > > > > > > > patchset is to let SPL could load the 2nd container file
> > > > > > > > which contains U-Boot/DTB/OP-TEE/ATF.  If we let SPL load
> > > > > > > > a fitimage which contains (U-Boot/DTB and etc), it could
> > > > > > > > not pass secure boot authentication, because ROM not know
> > > > > > > > fitimage, it only know i.MX container format.
> > > > > > >
> > > > > > > It's not bootrom that authenticates the next stage, it's
> > > > > > > U-Boot SPL. BootROM already authenticated and started the
> > > > > > > U-Boot SPL, so that's a trusted code. Now this trusted code
> > > > > > > can authenticate and start the next stage (U-Boot, ATF,
> > > > > > > OpTee OS, etc) ; the BootROM is already out of the picture
> > > > > > > at this point.
> > > > > >
> > > > > > Sorry for not clear. On i.MX8, SCFW (a runtime firmware
> > > > > > )exports API for others to use, sc_seco_authenticate is the
> > > > > > API that used for authentication. I could not share more
> > > > > > information about this API works inside SCFW and ROM. sc_err_t
> > > > > > sc_seco_authenticate(sc_ipc_t ipc, sc_seco_auth_cmd_t cmd,
> > > > > > sc_faddr_t addr)
> > > > > >
> > > > > > SPL will call this API, one parameter is address which needs a
> > > > > > container image there.
> > > > >
> > > > > Please consider following scenario (I think that this is in sync
> > > > > with Marek's point):
> > > > >
> > > > > 1. You wrap SPL into i.MX8 "container", so the SPL would be
> > > > > recognised an checked by secure code in ROM.
> > > > >
> > > > > 2. Then we do have SPL "trusted". It is up to SPL to:
> > > > >
> > > > > 2.1. Use its private key to check u-boot, dtb, etc embedded into
> > > > > FitImage (as written here: ./doc/uImage.FIT/verified-boot.txt).
> > > > >
> > > > > 2.2. Use crypto engine (it's API) with fused keys to speed-up
> > > > > the process of boot (by HW support to check the binary). Such
> > > > > approach is in i.MX6Q.
> > > >
> > > > I suppose you talking HAB.
> > >
> > > Yes. As described here:
> > >
> > > https://www.nxp.com/docs/en/application-note/AN4581.pdf
> > >
> > > >
> > > > >
> > > > >
> > > > > By using above approach we do have the NXP's "container" format
> > > > > only seen in the SPL (which is OK, as for example Samsung does
> > > > > similar thing with FBL/BL1). When SPL is "trused" we may use
> > > > > available facilities.
> > > >
> > > > The issue to me is that sc_seco_authenticate could not take a FIT
> > > > image as input.
> > >
> > > Is the sc_seco_authenticate an API accessible from SPL, U-Boot
> > > proper or Linux crypro engine driver?
> >
> > Yes, it is an API accessible in SPL/U-Boot stage. I do not know about
> > Linux crypto driver.
> 
> Maybe it would be worth to check how Linux handle this? Maybe it would
> shed some more light on it?

I am not familiar with that, so might be stupid question below.
Does it really matter? i.MX6 HAB secure boot also requires CSF padding
into image, we could not pass other format image to ROM when using HAB,
right?

> 
> >
> > >
> > > Or is it just the function executed by ROM on the very beginning to
> > > load SPL?
> > > >
> > > > If I switch to FIT, I need to use FIT to wrap a container image,
> > > > it does not make sense to me.
> > >
> > > Please correct me if I'm wrong, but isn't the container image only
> > > needed to wrap SPL?
> >
> > Container image will wrap SPL to make ROM could load SPL, Kick SPL and
> > authenticate SPL.
> 
> Ok. So it is needed in the ROM "part" of security.
> 
> >
> > When SPL booting U-Boot, SPL could use FIT to load and boot uboot.
> > But when SPL need to authenticate U-Boot with AHAB on i.MX8, a
> > container format header/image needs to be passed to
> > sc_seco_authenticate API, the API internal implementation is it will
> > parse the container header/image.
> 
> Ok. So every time we want to use the sc_seco_authenticate API the provided
> image for checking needs to be wrapped into the "container"
> iMX8 specific format.

Yes. Otherwise sc_seco_authenticate will return failure. I could not think
out better solution, another approach is let uboot generating a container header,
and use FIT to wrap the header and other payload images, but I think
directly generating a container image is simpler, because we already have
SPL been wrapped into container format.

Thanks,
Peng.

> 
> >
> > So in vendor tree, uboot/atf/optee are wrapped into a container format
> > image.
> 
> Ok.
> 
> >
> > >
> > > In which other cases the container image is needed in U-Boot proper
> > > or Linux kernel?
> >
> > When uboot authenticate kernel, we also wrap kernel image into a
> > container format file using CST. I do not know how Linux kernel itself
> > authenticate others.
> >
> > Thanks,
> > Peng.
> >
> > >
> > > >
> > > > Thanks,
> > > > Peng.
> > > > >
> > > > > >
> > > > > > >
> > > > > > > > For authentication, we always let ROM to authenticate
> > > > > > > > including SPL authenticating U-Boot, so we need pass an
> > > > > > > > image to ROM that ROM could recognize when SPL booting 2nd
> > > > > > > > image.
> > > > > > >
> > > > > > > Shouldn't the CPU have some sort of facility, like a crypto
> > > > > > > engine, which authenticates whatever blob with the right
> > > > > > > signature against a key burned into the CPU ? If so, then
> > > > > > > you would just implement a crypto driver and pass the blob
> > > > > > > and signature to it. I suspect that's how it should work,
> > > > > > > how else would Linux be able to make use of these secure
> > > > > > > bits if it cannot call the bootrom anymore ?
> > > > > >
> > > > > > sc_seco_authenticate on i.MX8 will always be available. It is
> > > > > > exported by a runtime firmware running on a Cortex-M core
> > > > > > inside i.MX8. The API will do authentication, its accepts
> > > > > > container format image as input and no other format.
> > > > > >
> > > > > > Thanks,
> > > > > > Peng.
> > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Best regards,
> > > > > > > Marek Vasut
> > > > > > _______________________________________________
> > > > > > U-Boot mailing list
> > > > > > U-Boot at lists.denx.de
> > > > > > https://lists.denx.de/listinfo/u-boot
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Lukasz Majewski
> > > > >
> > > > > --
> > > > >
> > > > > DENX Software Engineering GmbH,      Managing Director:
> Wolfgang
> > > > > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194
> > > > > Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax:
> > > > > (+49)-8142-66989-80 Email: lukma at denx.de
> > >
> > >
> > >
> > >
> > > Best regards,
> > >
> > > Lukasz Majewski
> > >
> > > --
> > >
> > > DENX Software Engineering GmbH,      Managing Director: Wolfgang
> > > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > > Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> > > lukma at denx.de
> 
> 
> 
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> lukma at denx.de

[U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Lukasz Majewski]

Hi Peng,

> >   
> > > > > > > > Subject: Re: [U-Boot] [PATCH 4/6] spl: mmc: support
> > > > > > > > loading i.MX container format file
> > > > > > > >
> > > > > > > > On 5/21/19 4:55 AM, Peng Fan wrote:
> > > > > > > > [...]
> > > > > > > >  
> > > > > > > > >>>>> I do not know how other SoC vendor did FIT
> > > > > > > > >>>>> hardware secure boot, please share you have any
> > > > > > > > >>>>> information.  
> > > > > > > > >>>>
> > > > > > > > >>>> The SPL can be in the custom format, but then can
> > > > > > > > >>>> load fitImage with the next stage(s), right ?  
> > > > > > > > >>>
> > > > > > > > >>> I am not able to follow you, could you share more
> > > > > > > > >>> details?  
> > > > > > > > >>
> > > > > > > > >> Wrap the SPL into this custom format and then have
> > > > > > > > >> the SPL load/authenticate fitImage with the rest
> > > > > > > > >> (U-Boot, Linux, DTB etc). Would that work ?  
> > > > > > > > >
> > > > > > > > > It not work.
> > > > > > > > > We already wrap SPL in i.MX container format, this
> > > > > > > > > patchset is to let SPL could load the 2nd container
> > > > > > > > > file which contains U-Boot/DTB/OP-TEE/ATF.  If we let
> > > > > > > > > SPL load a fitimage which contains (U-Boot/DTB and
> > > > > > > > > etc), it could not pass secure boot authentication,
> > > > > > > > > because ROM not know fitimage, it only know i.MX
> > > > > > > > > container format.  
> > > > > > > >
> > > > > > > > It's not bootrom that authenticates the next stage, it's
> > > > > > > > U-Boot SPL. BootROM already authenticated and started
> > > > > > > > the U-Boot SPL, so that's a trusted code. Now this
> > > > > > > > trusted code can authenticate and start the next stage
> > > > > > > > (U-Boot, ATF, OpTee OS, etc) ; the BootROM is already
> > > > > > > > out of the picture at this point.  
> > > > > > >
> > > > > > > Sorry for not clear. On i.MX8, SCFW (a runtime firmware
> > > > > > > )exports API for others to use, sc_seco_authenticate is
> > > > > > > the API that used for authentication. I could not share
> > > > > > > more information about this API works inside SCFW and
> > > > > > > ROM. sc_err_t sc_seco_authenticate(sc_ipc_t ipc,
> > > > > > > sc_seco_auth_cmd_t cmd, sc_faddr_t addr)
> > > > > > >
> > > > > > > SPL will call this API, one parameter is address which
> > > > > > > needs a container image there.  
> > > > > >
> > > > > > Please consider following scenario (I think that this is in
> > > > > > sync with Marek's point):
> > > > > >
> > > > > > 1. You wrap SPL into i.MX8 "container", so the SPL would be
> > > > > > recognised an checked by secure code in ROM.
> > > > > >
> > > > > > 2. Then we do have SPL "trusted". It is up to SPL to:
> > > > > >
> > > > > > 2.1. Use its private key to check u-boot, dtb, etc embedded
> > > > > > into FitImage (as written
> > > > > > here: ./doc/uImage.FIT/verified-boot.txt).
> > > > > >
> > > > > > 2.2. Use crypto engine (it's API) with fused keys to
> > > > > > speed-up the process of boot (by HW support to check the
> > > > > > binary). Such approach is in i.MX6Q.  
> > > > >
> > > > > I suppose you talking HAB.  
> > > >
> > > > Yes. As described here:
> > > >
> > > > https://www.nxp.com/docs/en/application-note/AN4581.pdf
> > > >  
> > > > >  
> > > > > >
> > > > > >
> > > > > > By using above approach we do have the NXP's "container"
> > > > > > format only seen in the SPL (which is OK, as for example
> > > > > > Samsung does similar thing with FBL/BL1). When SPL is
> > > > > > "trused" we may use available facilities.  
> > > > >
> > > > > The issue to me is that sc_seco_authenticate could not take a
> > > > > FIT image as input.  
> > > >
> > > > Is the sc_seco_authenticate an API accessible from SPL, U-Boot
> > > > proper or Linux crypro engine driver?  
> > >
> > > Yes, it is an API accessible in SPL/U-Boot stage. I do not know
> > > about Linux crypto driver.  
> > 
> > Maybe it would be worth to check how Linux handle this? Maybe it
> > would shed some more light on it?  
> 
> I am not familiar with that, so might be stupid question below.
> Does it really matter? 

I would check it just out of curiosity.

> i.MX6 HAB secure boot also requires CSF padding
> into image, we could not pass other format image to ROM when using
> HAB, right?
> 

Yes.

> >   
> > >  
> > > >
> > > > Or is it just the function executed by ROM on the very
> > > > beginning to load SPL?  
> > > > >
> > > > > If I switch to FIT, I need to use FIT to wrap a container
> > > > > image, it does not make sense to me.  
> > > >
> > > > Please correct me if I'm wrong, but isn't the container image
> > > > only needed to wrap SPL?  
> > >
> > > Container image will wrap SPL to make ROM could load SPL, Kick
> > > SPL and authenticate SPL.  
> > 
> > Ok. So it is needed in the ROM "part" of security.
> >   
> > >
> > > When SPL booting U-Boot, SPL could use FIT to load and boot uboot.
> > > But when SPL need to authenticate U-Boot with AHAB on i.MX8, a
> > > container format header/image needs to be passed to
> > > sc_seco_authenticate API, the API internal implementation is it
> > > will parse the container header/image.  
> > 
> > Ok. So every time we want to use the sc_seco_authenticate API the
> > provided image for checking needs to be wrapped into the "container"
> > iMX8 specific format.  
> 
> Yes. Otherwise sc_seco_authenticate will return failure. I could not
> think out better solution, another approach is let uboot generating a
> container header, and use FIT to wrap the header and other payload
> images, but I think directly generating a container image is simpler,
> because we already have SPL been wrapped into container format.
> 

I just wanted to understand the issue and help to get the simplest
possible solution.

> Thanks,
> Peng.
> 
> >   
> > >
> > > So in vendor tree, uboot/atf/optee are wrapped into a container
> > > format image.  
> > 
> > Ok.
> >   
> > >  
> > > >
> > > > In which other cases the container image is needed in U-Boot
> > > > proper or Linux kernel?  
> > >
> > > When uboot authenticate kernel, we also wrap kernel image into a
> > > container format file using CST. I do not know how Linux kernel
> > > itself authenticate others.
> > >
> > > Thanks,
> > > Peng.
> > >  
> > > >  
> > > > >
> > > > > Thanks,
> > > > > Peng.  
> > > > > >  
> > > > > > >  
> > > > > > > >  
> > > > > > > > > For authentication, we always let ROM to authenticate
> > > > > > > > > including SPL authenticating U-Boot, so we need pass
> > > > > > > > > an image to ROM that ROM could recognize when SPL
> > > > > > > > > booting 2nd image.  
> > > > > > > >
> > > > > > > > Shouldn't the CPU have some sort of facility, like a
> > > > > > > > crypto engine, which authenticates whatever blob with
> > > > > > > > the right signature against a key burned into the CPU ?
> > > > > > > > If so, then you would just implement a crypto driver
> > > > > > > > and pass the blob and signature to it. I suspect that's
> > > > > > > > how it should work, how else would Linux be able to
> > > > > > > > make use of these secure bits if it cannot call the
> > > > > > > > bootrom anymore ?  
> > > > > > >
> > > > > > > sc_seco_authenticate on i.MX8 will always be available.
> > > > > > > It is exported by a runtime firmware running on a
> > > > > > > Cortex-M core inside i.MX8. The API will do
> > > > > > > authentication, its accepts container format image as
> > > > > > > input and no other format.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Peng.
> > > > > > >  
> > > > > > > >
> > > > > > > > --
> > > > > > > > Best regards,
> > > > > > > > Marek Vasut  
> > > > > > > _______________________________________________
> > > > > > > U-Boot mailing list
> > > > > > > U-Boot at lists.denx.de
> > > > > > > https://lists.denx.de/listinfo/u-boot  
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Best regards,
> > > > > >
> > > > > > Lukasz Majewski
> > > > > >
> > > > > > --
> > > > > >
> > > > > > DENX Software Engineering GmbH,      Managing Director:  
> > Wolfgang  
> > > > > > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194
> > > > > > Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax:
> > > > > > (+49)-8142-66989-80 Email: lukma at denx.de  
> > > >
> > > >
> > > >
> > > >
> > > > Best regards,
> > > >
> > > > Lukasz Majewski
> > > >
> > > > --
> > > >
> > > > DENX Software Engineering GmbH,      Managing Director: Wolfgang
> > > > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194
> > > > Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax:
> > > > (+49)-8142-66989-80 Email: lukma at denx.de  
> > 
> > 
> > 
> > 
> > Best regards,
> > 
> > Lukasz Majewski
> > 
> > --
> > 
> > DENX Software Engineering GmbH,      Managing Director: Wolfgang
> > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> > lukma at denx.de  




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190522/c0ff8fef/attachment.sig>

[U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Marek Vasut]

On 5/22/19 9:34 AM, Lukasz Majewski wrote:
[...]
>>>>>>> By using above approach we do have the NXP's "container"
>>>>>>> format only seen in the SPL (which is OK, as for example
>>>>>>> Samsung does similar thing with FBL/BL1). When SPL is
>>>>>>> "trused" we may use available facilities.  
>>>>>>
>>>>>> The issue to me is that sc_seco_authenticate could not take a
>>>>>> FIT image as input.  
>>>>>
>>>>> Is the sc_seco_authenticate an API accessible from SPL, U-Boot
>>>>> proper or Linux crypro engine driver?  
>>>>
>>>> Yes, it is an API accessible in SPL/U-Boot stage. I do not know
>>>> about Linux crypto driver.  
>>>
>>> Maybe it would be worth to check how Linux handle this? Maybe it
>>> would shed some more light on it?  
>>
>> I am not familiar with that, so might be stupid question below.
>> Does it really matter? 
> 
> I would check it just out of curiosity.

Yes, it matters, because there should be such API. How would Linux
authenticate e.g. userspace binaries if there wasn't one, surely not by
wrapping every single object into the custom vendor-specific container ?
And if there is one, you can use it to authenticate raw binaries from
U-Boot SPL too, e.g. fitImage blobs with an associated signature.

[...]

-- 
Best regards,
Marek Vasut

[U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Ye Li]

Hi Marek,

On 2019/5/22 19:41, Marek Vasut wrote:
> Caution: EXT Email
> 
> On 5/22/19 9:34 AM, Lukasz Majewski wrote:
> [...]
>>>>>>>> By using above approach we do have the NXP's "container"
>>>>>>>> format only seen in the SPL (which is OK, as for example
>>>>>>>> Samsung does similar thing with FBL/BL1). When SPL is
>>>>>>>> "trused" we may use available facilities.
>>>>>>>
>>>>>>> The issue to me is that sc_seco_authenticate could not take a
>>>>>>> FIT image as input.
>>>>>>
>>>>>> Is the sc_seco_authenticate an API accessible from SPL, U-Boot
>>>>>> proper or Linux crypro engine driver?
>>>>>
>>>>> Yes, it is an API accessible in SPL/U-Boot stage. I do not know
>>>>> about Linux crypto driver.
>>>>
>>>> Maybe it would be worth to check how Linux handle this? Maybe it
>>>> would shed some more light on it?
>>>
>>> I am not familiar with that, so might be stupid question below.
>>> Does it really matter?
>>
>> I would check it just out of curiosity.
> 
> Yes, it matters, because there should be such API. How would Linux
> authenticate e.g. userspace binaries if there wasn't one, surely not by
> wrapping every single object into the custom vendor-specific container ?
> And if there is one, you can use it to authenticate raw binaries from
> U-Boot SPL too, e.g. fitImage blobs with an associated signature.
> 

iMX8 AHAB uses RSA key pair for authentication, the on-chip thing we called SRK is a array of public
key hash which is dedicated for AHAB. It is not a real key. The real public key is in container. 
AHAB will check the public key with the on-chip SRK before using it to authenticate the image. 
Seco which contains the crypto engine on imx8 does not allow to use the SRK by user. No such API exported. 
And the fuse of SRK is locked, can't be read directly.

Actually on imx6/imx7/imx8m, the SPL and u-boot are already using ROM HAB to implement the trust chain, like
SPL authenticates u-boot, u-boot authenticatse kernel. We just follow this same way on imx8, the difference
is imx8 needs container format for signed image. We prefer directly loading container image than fit image.
If we pack fit image into container, obviously this will cause one more copy.
As a boot loader, isn't it better to have more image format supported? We don't force to use container, just 
set it as default. Users still can choose fit or raw image.


> [...]
> 
> --
> Best regards,
> Marek Vasut
> 

[U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Peng Fan]

Hi Marek, Lukasz,

> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
> container format file
> 
> Hi Marek,
> 
> On 2019/5/22 19:41, Marek Vasut wrote:
> > Caution: EXT Email
> >
> > On 5/22/19 9:34 AM, Lukasz Majewski wrote:
> > [...]
> >>>>>>>> By using above approach we do have the NXP's "container"
> >>>>>>>> format only seen in the SPL (which is OK, as for example
> >>>>>>>> Samsung does similar thing with FBL/BL1). When SPL is "trused"
> >>>>>>>> we may use available facilities.
> >>>>>>>
> >>>>>>> The issue to me is that sc_seco_authenticate could not take a
> >>>>>>> FIT image as input.
> >>>>>>
> >>>>>> Is the sc_seco_authenticate an API accessible from SPL, U-Boot
> >>>>>> proper or Linux crypro engine driver?
> >>>>>
> >>>>> Yes, it is an API accessible in SPL/U-Boot stage. I do not know
> >>>>> about Linux crypto driver.
> >>>>
> >>>> Maybe it would be worth to check how Linux handle this? Maybe it
> >>>> would shed some more light on it?
> >>>
> >>> I am not familiar with that, so might be stupid question below.
> >>> Does it really matter?
> >>
> >> I would check it just out of curiosity.
> >
> > Yes, it matters, because there should be such API. How would Linux
> > authenticate e.g. userspace binaries if there wasn't one, surely not
> > by wrapping every single object into the custom vendor-specific container ?
> > And if there is one, you can use it to authenticate raw binaries from
> > U-Boot SPL too, e.g. fitImage blobs with an associated signature.
> >
> 
> iMX8 AHAB uses RSA key pair for authentication, the on-chip thing we called
> SRK is a array of public key hash which is dedicated for AHAB. It is not a real
> key. The real public key is in container.
> AHAB will check the public key with the on-chip SRK before using it to
> authenticate the image.
> Seco which contains the crypto engine on imx8 does not allow to use the SRK
> by user. No such API exported.
> And the fuse of SRK is locked, can't be read directly.
> 
> Actually on imx6/imx7/imx8m, the SPL and u-boot are already using ROM
> HAB to implement the trust chain, like SPL authenticates u-boot, u-boot
> authenticatse kernel. We just follow this same way on imx8, the difference is
> imx8 needs container format for signed image. We prefer directly loading
> container image than fit image.
> If we pack fit image into container, obviously this will cause one more copy.
> As a boot loader, isn't it better to have more image format supported? We
> don't force to use container, just set it as default. Users still can choose fit or
> raw image.


Do you have more comment?

Thanks,
Peng.

> 
> 
> > [...]
> >
> > --
> > Best regards,
> > Marek Vasut
> >
> 
> 

[U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Marek Vasut]

On 5/27/19 11:49 AM, Peng Fan wrote:
> Hi Marek, Lukasz,
> 
>> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
>> container format file
>>
>> Hi Marek,
>>
>> On 2019/5/22 19:41, Marek Vasut wrote:
>>> Caution: EXT Email
>>>
>>> On 5/22/19 9:34 AM, Lukasz Majewski wrote:
>>> [...]
>>>>>>>>>> By using above approach we do have the NXP's "container"
>>>>>>>>>> format only seen in the SPL (which is OK, as for example
>>>>>>>>>> Samsung does similar thing with FBL/BL1). When SPL is "trused"
>>>>>>>>>> we may use available facilities.
>>>>>>>>>
>>>>>>>>> The issue to me is that sc_seco_authenticate could not take a
>>>>>>>>> FIT image as input.
>>>>>>>>
>>>>>>>> Is the sc_seco_authenticate an API accessible from SPL, U-Boot
>>>>>>>> proper or Linux crypro engine driver?
>>>>>>>
>>>>>>> Yes, it is an API accessible in SPL/U-Boot stage. I do not know
>>>>>>> about Linux crypto driver.
>>>>>>
>>>>>> Maybe it would be worth to check how Linux handle this? Maybe it
>>>>>> would shed some more light on it?
>>>>>
>>>>> I am not familiar with that, so might be stupid question below.
>>>>> Does it really matter?
>>>>
>>>> I would check it just out of curiosity.
>>>
>>> Yes, it matters, because there should be such API. How would Linux
>>> authenticate e.g. userspace binaries if there wasn't one, surely not
>>> by wrapping every single object into the custom vendor-specific container ?
>>> And if there is one, you can use it to authenticate raw binaries from
>>> U-Boot SPL too, e.g. fitImage blobs with an associated signature.
>>>
>>
>> iMX8 AHAB uses RSA key pair for authentication, the on-chip thing we called
>> SRK is a array of public key hash which is dedicated for AHAB. It is not a real
>> key. The real public key is in container.
>> AHAB will check the public key with the on-chip SRK before using it to
>> authenticate the image.
>> Seco which contains the crypto engine on imx8 does not allow to use the SRK
>> by user. No such API exported.
>> And the fuse of SRK is locked, can't be read directly.
>>
>> Actually on imx6/imx7/imx8m, the SPL and u-boot are already using ROM
>> HAB to implement the trust chain, like SPL authenticates u-boot, u-boot
>> authenticatse kernel. We just follow this same way on imx8, the difference is
>> imx8 needs container format for signed image. We prefer directly loading
>> container image than fit image.
>> If we pack fit image into container, obviously this will cause one more copy.
>> As a boot loader, isn't it better to have more image format supported?

If the functionality of the new image format is a subset of already
present image format, then no, that's called a duplication.

>> We
>> don't force to use container, just set it as default. Users still can choose fit or
>> raw image.

They can. however they cannot authenticate the fitImage because the
firmware doesn't provide the necessary API for that ?

> 
> Do you have more comment?

How could Linux use this iMX8 chain of trust stuff to authenticate e.g.
userspace binaries ? It's the same thing as authenticating blob in a
fitImage.

-- 
Best regards,
Marek Vasut

[U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Ye Li]

On 2019/5/27 19:31, Marek Vasut wrote:
> Caution: EXT Email
> 
> On 5/27/19 11:49 AM, Peng Fan wrote:
>> Hi Marek, Lukasz,
>>
>>> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
>>> container format file
>>>
>>> Hi Marek,
>>>
>>> On 2019/5/22 19:41, Marek Vasut wrote:
>>>> Caution: EXT Email
>>>>
>>>> On 5/22/19 9:34 AM, Lukasz Majewski wrote:
>>>> [...]
>>>>>>>>>>> By using above approach we do have the NXP's "container"
>>>>>>>>>>> format only seen in the SPL (which is OK, as for example
>>>>>>>>>>> Samsung does similar thing with FBL/BL1). When SPL is "trused"
>>>>>>>>>>> we may use available facilities.
>>>>>>>>>>
>>>>>>>>>> The issue to me is that sc_seco_authenticate could not take a
>>>>>>>>>> FIT image as input.
>>>>>>>>>
>>>>>>>>> Is the sc_seco_authenticate an API accessible from SPL, U-Boot
>>>>>>>>> proper or Linux crypro engine driver?
>>>>>>>>
>>>>>>>> Yes, it is an API accessible in SPL/U-Boot stage. I do not know
>>>>>>>> about Linux crypto driver.
>>>>>>>
>>>>>>> Maybe it would be worth to check how Linux handle this? Maybe it
>>>>>>> would shed some more light on it?
>>>>>>
>>>>>> I am not familiar with that, so might be stupid question below.
>>>>>> Does it really matter?
>>>>>
>>>>> I would check it just out of curiosity.
>>>>
>>>> Yes, it matters, because there should be such API. How would Linux
>>>> authenticate e.g. userspace binaries if there wasn't one, surely not
>>>> by wrapping every single object into the custom vendor-specific container ?
>>>> And if there is one, you can use it to authenticate raw binaries from
>>>> U-Boot SPL too, e.g. fitImage blobs with an associated signature.
>>>>
>>>
>>> iMX8 AHAB uses RSA key pair for authentication, the on-chip thing we called
>>> SRK is a array of public key hash which is dedicated for AHAB. It is not a real
>>> key. The real public key is in container.
>>> AHAB will check the public key with the on-chip SRK before using it to
>>> authenticate the image.
>>> Seco which contains the crypto engine on imx8 does not allow to use the SRK
>>> by user. No such API exported.
>>> And the fuse of SRK is locked, can't be read directly.
>>>
>>> Actually on imx6/imx7/imx8m, the SPL and u-boot are already using ROM
>>> HAB to implement the trust chain, like SPL authenticates u-boot, u-boot
>>> authenticatse kernel. We just follow this same way on imx8, the difference is
>>> imx8 needs container format for signed image. We prefer directly loading
>>> container image than fit image.
>>> If we pack fit image into container, obviously this will cause one more copy.
>>> As a boot loader, isn't it better to have more image format supported?
> 
> If the functionality of the new image format is a subset of already
> present image format, then no, that's called a duplication.
> 
>>> We
>>> don't force to use container, just set it as default. Users still can choose fit or
>>> raw image.
> 
> They can. however they cannot authenticate the fitImage because the
> firmware doesn't provide the necessary API for that ?
> 
>>
>> Do you have more comment?
> 
> How could Linux use this iMX8 chain of trust stuff to authenticate e.g.
> userspace binaries ? It's the same thing as authenticating blob in a
> fitImage.
> 

Userspace binaries don't use the same key pair. They are signed by software vendors' key. The private 
key for chip secure boot is only hold by device manufacturer.
For example, android needs to authenticate a signed APK. Its public key (Key A) is in system FS. 
iMX trust chain only reaches to kernel + ramdisk. Then the chain hands over to android. 
In ramdisk, android puts another public Key (Key B) used by dm-verify for system FS. So once 
system FS is verified ok, then the public key A becomes trusted. Finally we can use public key A for 
APK authentication.


Best regards,
Ye Li

> --
> Best regards,
> Marek Vasut
> 

[U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Marek Vasut]

On 5/30/19 9:06 AM, Ye Li wrote:
> On 2019/5/27 19:31, Marek Vasut wrote:
>> Caution: EXT Email
>>
>> On 5/27/19 11:49 AM, Peng Fan wrote:
>>> Hi Marek, Lukasz,
>>>
>>>> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
>>>> container format file
>>>>
>>>> Hi Marek,
>>>>
>>>> On 2019/5/22 19:41, Marek Vasut wrote:
>>>>> Caution: EXT Email
>>>>>
>>>>> On 5/22/19 9:34 AM, Lukasz Majewski wrote:
>>>>> [...]
>>>>>>>>>>>> By using above approach we do have the NXP's "container"
>>>>>>>>>>>> format only seen in the SPL (which is OK, as for example
>>>>>>>>>>>> Samsung does similar thing with FBL/BL1). When SPL is "trused"
>>>>>>>>>>>> we may use available facilities.
>>>>>>>>>>>
>>>>>>>>>>> The issue to me is that sc_seco_authenticate could not take a
>>>>>>>>>>> FIT image as input.
>>>>>>>>>>
>>>>>>>>>> Is the sc_seco_authenticate an API accessible from SPL, U-Boot
>>>>>>>>>> proper or Linux crypro engine driver?
>>>>>>>>>
>>>>>>>>> Yes, it is an API accessible in SPL/U-Boot stage. I do not know
>>>>>>>>> about Linux crypto driver.
>>>>>>>>
>>>>>>>> Maybe it would be worth to check how Linux handle this? Maybe it
>>>>>>>> would shed some more light on it?
>>>>>>>
>>>>>>> I am not familiar with that, so might be stupid question below.
>>>>>>> Does it really matter?
>>>>>>
>>>>>> I would check it just out of curiosity.
>>>>>
>>>>> Yes, it matters, because there should be such API. How would Linux
>>>>> authenticate e.g. userspace binaries if there wasn't one, surely not
>>>>> by wrapping every single object into the custom vendor-specific container ?
>>>>> And if there is one, you can use it to authenticate raw binaries from
>>>>> U-Boot SPL too, e.g. fitImage blobs with an associated signature.
>>>>>
>>>>
>>>> iMX8 AHAB uses RSA key pair for authentication, the on-chip thing we called
>>>> SRK is a array of public key hash which is dedicated for AHAB. It is not a real
>>>> key. The real public key is in container.
>>>> AHAB will check the public key with the on-chip SRK before using it to
>>>> authenticate the image.
>>>> Seco which contains the crypto engine on imx8 does not allow to use the SRK
>>>> by user. No such API exported.
>>>> And the fuse of SRK is locked, can't be read directly.
>>>>
>>>> Actually on imx6/imx7/imx8m, the SPL and u-boot are already using ROM
>>>> HAB to implement the trust chain, like SPL authenticates u-boot, u-boot
>>>> authenticatse kernel. We just follow this same way on imx8, the difference is
>>>> imx8 needs container format for signed image. We prefer directly loading
>>>> container image than fit image.
>>>> If we pack fit image into container, obviously this will cause one more copy.
>>>> As a boot loader, isn't it better to have more image format supported?
>>
>> If the functionality of the new image format is a subset of already
>> present image format, then no, that's called a duplication.
>>
>>>> We
>>>> don't force to use container, just set it as default. Users still can choose fit or
>>>> raw image.
>>
>> They can. however they cannot authenticate the fitImage because the
>> firmware doesn't provide the necessary API for that ?
>>
>>>
>>> Do you have more comment?
>>
>> How could Linux use this iMX8 chain of trust stuff to authenticate e.g.
>> userspace binaries ? It's the same thing as authenticating blob in a
>> fitImage.
>>
> 
> Userspace binaries don't use the same key pair. They are signed by software vendors' key. The private 
> key for chip secure boot is only hold by device manufacturer.
> For example, android needs to authenticate a signed APK. Its public key (Key A) is in system FS. 
> iMX trust chain only reaches to kernel + ramdisk. Then the chain hands over to android. 
> In ramdisk, android puts another public Key (Key B) used by dm-verify for system FS. So once 
> system FS is verified ok, then the public key A becomes trusted. Finally we can use public key A for 
> APK authentication.

So can we put a public key into the SPL and use it to verify a fitImage ?

-- 
Best regards,
Marek Vasut

[U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Peng Fan]

> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
> container format file
> 
> On 5/30/19 9:06 AM, Ye Li wrote:
> > On 2019/5/27 19:31, Marek Vasut wrote:
> >> Caution: EXT Email
> >>
> >> On 5/27/19 11:49 AM, Peng Fan wrote:
> >>> Hi Marek, Lukasz,
> >>>
> >>>> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support
> >>>> loading i.MX container format file
> >>>>
> >>>> Hi Marek,
> >>>>
> >>>> On 2019/5/22 19:41, Marek Vasut wrote:
> >>>>> Caution: EXT Email
> >>>>>
> >>>>> On 5/22/19 9:34 AM, Lukasz Majewski wrote:
> >>>>> [...]
> >>>>>>>>>>>> By using above approach we do have the NXP's "container"
> >>>>>>>>>>>> format only seen in the SPL (which is OK, as for example
> >>>>>>>>>>>> Samsung does similar thing with FBL/BL1). When SPL is
> "trused"
> >>>>>>>>>>>> we may use available facilities.
> >>>>>>>>>>>
> >>>>>>>>>>> The issue to me is that sc_seco_authenticate could not take
> >>>>>>>>>>> a FIT image as input.
> >>>>>>>>>>
> >>>>>>>>>> Is the sc_seco_authenticate an API accessible from SPL,
> >>>>>>>>>> U-Boot proper or Linux crypro engine driver?
> >>>>>>>>>
> >>>>>>>>> Yes, it is an API accessible in SPL/U-Boot stage. I do not
> >>>>>>>>> know about Linux crypto driver.
> >>>>>>>>
> >>>>>>>> Maybe it would be worth to check how Linux handle this? Maybe
> >>>>>>>> it would shed some more light on it?
> >>>>>>>
> >>>>>>> I am not familiar with that, so might be stupid question below.
> >>>>>>> Does it really matter?
> >>>>>>
> >>>>>> I would check it just out of curiosity.
> >>>>>
> >>>>> Yes, it matters, because there should be such API. How would Linux
> >>>>> authenticate e.g. userspace binaries if there wasn't one, surely
> >>>>> not by wrapping every single object into the custom vendor-specific
> container ?
> >>>>> And if there is one, you can use it to authenticate raw binaries
> >>>>> from U-Boot SPL too, e.g. fitImage blobs with an associated signature.
> >>>>>
> >>>>
> >>>> iMX8 AHAB uses RSA key pair for authentication, the on-chip thing
> >>>> we called SRK is a array of public key hash which is dedicated for
> >>>> AHAB. It is not a real key. The real public key is in container.
> >>>> AHAB will check the public key with the on-chip SRK before using it
> >>>> to authenticate the image.
> >>>> Seco which contains the crypto engine on imx8 does not allow to use
> >>>> the SRK by user. No such API exported.
> >>>> And the fuse of SRK is locked, can't be read directly.
> >>>>
> >>>> Actually on imx6/imx7/imx8m, the SPL and u-boot are already using
> >>>> ROM HAB to implement the trust chain, like SPL authenticates
> >>>> u-boot, u-boot authenticatse kernel. We just follow this same way
> >>>> on imx8, the difference is
> >>>> imx8 needs container format for signed image. We prefer directly
> >>>> loading container image than fit image.
> >>>> If we pack fit image into container, obviously this will cause one more
> copy.
> >>>> As a boot loader, isn't it better to have more image format supported?
> >>
> >> If the functionality of the new image format is a subset of already
> >> present image format, then no, that's called a duplication.
> >>
> >>>> We
> >>>> don't force to use container, just set it as default. Users still
> >>>> can choose fit or raw image.
> >>
> >> They can. however they cannot authenticate the fitImage because the
> >> firmware doesn't provide the necessary API for that ?
> >>
> >>>
> >>> Do you have more comment?
> >>
> >> How could Linux use this iMX8 chain of trust stuff to authenticate e.g.
> >> userspace binaries ? It's the same thing as authenticating blob in a
> >> fitImage.
> >>
> >
> > Userspace binaries don't use the same key pair. They are signed by
> > software vendors' key. The private key for chip secure boot is only hold by
> device manufacturer.
> > For example, android needs to authenticate a signed APK. Its public key (Key
> A) is in system FS.
> > iMX trust chain only reaches to kernel + ramdisk. Then the chain hands over
> to android.
> > In ramdisk, android puts another public Key (Key B) used by dm-verify
> > for system FS. So once system FS is verified ok, then the public key A
> > becomes trusted. Finally we can use public key A for APK authentication.
> 
> So can we put a public key into the SPL and use it to verify a fitImage ?

Technically doable. But compared with the current approach that reuse
ROM public API, Using crypto driver in SPL will be complicated and code
size larger without calling ROM API.

I do not understand the problem the SPL loading NXP i.MX8 container format.
SPL should only support raw and fit format? vendor format is not
allowed and not accepted?

Stefano, Simon, Tom

Any comments?

Thanks,
Peng.

> 
> --
> Best regards,
> Marek Vasut

[U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Marek Vasut]

On 6/4/19 5:27 AM, Peng Fan wrote:
>> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
>> container format file
>>
>> On 5/30/19 9:06 AM, Ye Li wrote:
>>> On 2019/5/27 19:31, Marek Vasut wrote:
>>>> Caution: EXT Email
>>>>
>>>> On 5/27/19 11:49 AM, Peng Fan wrote:
>>>>> Hi Marek, Lukasz,
>>>>>
>>>>>> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support
>>>>>> loading i.MX container format file
>>>>>>
>>>>>> Hi Marek,
>>>>>>
>>>>>> On 2019/5/22 19:41, Marek Vasut wrote:
>>>>>>> Caution: EXT Email
>>>>>>>
>>>>>>> On 5/22/19 9:34 AM, Lukasz Majewski wrote:
>>>>>>> [...]
>>>>>>>>>>>>>> By using above approach we do have the NXP's "container"
>>>>>>>>>>>>>> format only seen in the SPL (which is OK, as for example
>>>>>>>>>>>>>> Samsung does similar thing with FBL/BL1). When SPL is
>> "trused"
>>>>>>>>>>>>>> we may use available facilities.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The issue to me is that sc_seco_authenticate could not take
>>>>>>>>>>>>> a FIT image as input.
>>>>>>>>>>>>
>>>>>>>>>>>> Is the sc_seco_authenticate an API accessible from SPL,
>>>>>>>>>>>> U-Boot proper or Linux crypro engine driver?
>>>>>>>>>>>
>>>>>>>>>>> Yes, it is an API accessible in SPL/U-Boot stage. I do not
>>>>>>>>>>> know about Linux crypto driver.
>>>>>>>>>>
>>>>>>>>>> Maybe it would be worth to check how Linux handle this? Maybe
>>>>>>>>>> it would shed some more light on it?
>>>>>>>>>
>>>>>>>>> I am not familiar with that, so might be stupid question below.
>>>>>>>>> Does it really matter?
>>>>>>>>
>>>>>>>> I would check it just out of curiosity.
>>>>>>>
>>>>>>> Yes, it matters, because there should be such API. How would Linux
>>>>>>> authenticate e.g. userspace binaries if there wasn't one, surely
>>>>>>> not by wrapping every single object into the custom vendor-specific
>> container ?
>>>>>>> And if there is one, you can use it to authenticate raw binaries
>>>>>>> from U-Boot SPL too, e.g. fitImage blobs with an associated signature.
>>>>>>>
>>>>>>
>>>>>> iMX8 AHAB uses RSA key pair for authentication, the on-chip thing
>>>>>> we called SRK is a array of public key hash which is dedicated for
>>>>>> AHAB. It is not a real key. The real public key is in container.
>>>>>> AHAB will check the public key with the on-chip SRK before using it
>>>>>> to authenticate the image.
>>>>>> Seco which contains the crypto engine on imx8 does not allow to use
>>>>>> the SRK by user. No such API exported.
>>>>>> And the fuse of SRK is locked, can't be read directly.
>>>>>>
>>>>>> Actually on imx6/imx7/imx8m, the SPL and u-boot are already using
>>>>>> ROM HAB to implement the trust chain, like SPL authenticates
>>>>>> u-boot, u-boot authenticatse kernel. We just follow this same way
>>>>>> on imx8, the difference is
>>>>>> imx8 needs container format for signed image. We prefer directly
>>>>>> loading container image than fit image.
>>>>>> If we pack fit image into container, obviously this will cause one more
>> copy.
>>>>>> As a boot loader, isn't it better to have more image format supported?
>>>>
>>>> If the functionality of the new image format is a subset of already
>>>> present image format, then no, that's called a duplication.
>>>>
>>>>>> We
>>>>>> don't force to use container, just set it as default. Users still
>>>>>> can choose fit or raw image.
>>>>
>>>> They can. however they cannot authenticate the fitImage because the
>>>> firmware doesn't provide the necessary API for that ?
>>>>
>>>>>
>>>>> Do you have more comment?
>>>>
>>>> How could Linux use this iMX8 chain of trust stuff to authenticate e.g.
>>>> userspace binaries ? It's the same thing as authenticating blob in a
>>>> fitImage.
>>>>
>>>
>>> Userspace binaries don't use the same key pair. They are signed by
>>> software vendors' key. The private key for chip secure boot is only hold by
>> device manufacturer.
>>> For example, android needs to authenticate a signed APK. Its public key (Key
>> A) is in system FS.
>>> iMX trust chain only reaches to kernel + ramdisk. Then the chain hands over
>> to android.
>>> In ramdisk, android puts another public Key (Key B) used by dm-verify
>>> for system FS. So once system FS is verified ok, then the public key A
>>> becomes trusted. Finally we can use public key A for APK authentication.
>>
>> So can we put a public key into the SPL and use it to verify a fitImage ?
> 
> Technically doable. But compared with the current approach that reuse
> ROM public API, Using crypto driver in SPL will be complicated and code
> size larger without calling ROM API.
> 
> I do not understand the problem the SPL loading NXP i.MX8 container format.
> SPL should only support raw and fit format? vendor format is not
> allowed and not accepted?

The problem I have is with the duplication of functionality -- the iMX8
custom format does exactly the same as fitImage, except differently and
with smaller user base, thus with less users and reviewers and thus with
less potential bugfixes, which I think in crypto code is important.

-- 
Best regards,
Marek Vasut

[U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Peng Fan]

> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
> container format file
> 
> On 6/4/19 5:27 AM, Peng Fan wrote:
> >> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading
> >> i.MX container format file
> >>
> >> On 5/30/19 9:06 AM, Ye Li wrote:
> >>> On 2019/5/27 19:31, Marek Vasut wrote:
> >>>> Caution: EXT Email
> >>>>
> >>>> On 5/27/19 11:49 AM, Peng Fan wrote:
> >>>>> Hi Marek, Lukasz,
> >>>>>
> >>>>>> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support
> >>>>>> loading i.MX container format file
> >>>>>>
> >>>>>> Hi Marek,
> >>>>>>
> >>>>>> On 2019/5/22 19:41, Marek Vasut wrote:
> >>>>>>> Caution: EXT Email
> >>>>>>>
> >>>>>>> On 5/22/19 9:34 AM, Lukasz Majewski wrote:
> >>>>>>> [...]
> >>>>>>>>>>>>>> By using above approach we do have the NXP's "container"
> >>>>>>>>>>>>>> format only seen in the SPL (which is OK, as for example
> >>>>>>>>>>>>>> Samsung does similar thing with FBL/BL1). When SPL is
> >> "trused"
> >>>>>>>>>>>>>> we may use available facilities.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> The issue to me is that sc_seco_authenticate could not
> >>>>>>>>>>>>> take a FIT image as input.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Is the sc_seco_authenticate an API accessible from SPL,
> >>>>>>>>>>>> U-Boot proper or Linux crypro engine driver?
> >>>>>>>>>>>
> >>>>>>>>>>> Yes, it is an API accessible in SPL/U-Boot stage. I do not
> >>>>>>>>>>> know about Linux crypto driver.
> >>>>>>>>>>
> >>>>>>>>>> Maybe it would be worth to check how Linux handle this? Maybe
> >>>>>>>>>> it would shed some more light on it?
> >>>>>>>>>
> >>>>>>>>> I am not familiar with that, so might be stupid question below.
> >>>>>>>>> Does it really matter?
> >>>>>>>>
> >>>>>>>> I would check it just out of curiosity.
> >>>>>>>
> >>>>>>> Yes, it matters, because there should be such API. How would
> >>>>>>> Linux authenticate e.g. userspace binaries if there wasn't one,
> >>>>>>> surely not by wrapping every single object into the custom
> >>>>>>> vendor-specific
> >> container ?
> >>>>>>> And if there is one, you can use it to authenticate raw binaries
> >>>>>>> from U-Boot SPL too, e.g. fitImage blobs with an associated
> signature.
> >>>>>>>
> >>>>>>
> >>>>>> iMX8 AHAB uses RSA key pair for authentication, the on-chip thing
> >>>>>> we called SRK is a array of public key hash which is dedicated
> >>>>>> for AHAB. It is not a real key. The real public key is in container.
> >>>>>> AHAB will check the public key with the on-chip SRK before using
> >>>>>> it to authenticate the image.
> >>>>>> Seco which contains the crypto engine on imx8 does not allow to
> >>>>>> use the SRK by user. No such API exported.
> >>>>>> And the fuse of SRK is locked, can't be read directly.
> >>>>>>
> >>>>>> Actually on imx6/imx7/imx8m, the SPL and u-boot are already using
> >>>>>> ROM HAB to implement the trust chain, like SPL authenticates
> >>>>>> u-boot, u-boot authenticatse kernel. We just follow this same way
> >>>>>> on imx8, the difference is
> >>>>>> imx8 needs container format for signed image. We prefer directly
> >>>>>> loading container image than fit image.
> >>>>>> If we pack fit image into container, obviously this will cause
> >>>>>> one more
> >> copy.
> >>>>>> As a boot loader, isn't it better to have more image format supported?
> >>>>
> >>>> If the functionality of the new image format is a subset of already
> >>>> present image format, then no, that's called a duplication.
> >>>>
> >>>>>> We
> >>>>>> don't force to use container, just set it as default. Users still
> >>>>>> can choose fit or raw image.
> >>>>
> >>>> They can. however they cannot authenticate the fitImage because the
> >>>> firmware doesn't provide the necessary API for that ?
> >>>>
> >>>>>
> >>>>> Do you have more comment?
> >>>>
> >>>> How could Linux use this iMX8 chain of trust stuff to authenticate e.g.
> >>>> userspace binaries ? It's the same thing as authenticating blob in
> >>>> a fitImage.
> >>>>
> >>>
> >>> Userspace binaries don't use the same key pair. They are signed by
> >>> software vendors' key. The private key for chip secure boot is only
> >>> hold by
> >> device manufacturer.
> >>> For example, android needs to authenticate a signed APK. Its public
> >>> key (Key
> >> A) is in system FS.
> >>> iMX trust chain only reaches to kernel + ramdisk. Then the chain
> >>> hands over
> >> to android.
> >>> In ramdisk, android puts another public Key (Key B) used by
> >>> dm-verify for system FS. So once system FS is verified ok, then the
> >>> public key A becomes trusted. Finally we can use public key A for APK
> authentication.
> >>
> >> So can we put a public key into the SPL and use it to verify a fitImage ?
> >
> > Technically doable. But compared with the current approach that reuse
> > ROM public API, Using crypto driver in SPL will be complicated and
> > code size larger without calling ROM API.
> >
> > I do not understand the problem the SPL loading NXP i.MX8 container
> format.
> > SPL should only support raw and fit format? vendor format is not
> > allowed and not accepted?
> 
> The problem I have is with the duplication of functionality -- the iMX8 custom
> format does exactly the same as fitImage, except differently and with smaller
> user base, thus with less users and reviewers and thus with less potential
> bugfixes, which I think in crypto code is important.

The change to spl mmc common code is as below:
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index bf53a1dadf..6320af055b 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -79,6 +79,16 @@ int mmc_load_image_raw_sector(struct spl_image_info *spl_image,
                load.bl_len = mmc->read_bl_len;
                load.read = h_spl_load_read;
                ret = spl_load_simple_fit(spl_image, &load, sector, header);
+       } else if (IS_ENABLED(CONFIG_SPL_LOAD_IMX_CONTAINER)) {
+               struct spl_load_info load;
+
+               load.dev = mmc;
+               load.priv = NULL;
+               load.filename = NULL;
+               load.bl_len = mmc->read_bl_len;
+               load.read = h_spl_load_read;
+
+               ret = spl_load_imx_container(spl_image, &load, sector);
        } else {

If IMX_CONTAINER is not preferred, I'll change it to CONFIG_SPL_LOAD_VENDOR_FORMAT.
In this way, only i.MX users need to take care container format, non i.MX users no need
to care about that.

It is not duplication of FIT. Container support the similar function of FIT image, but it is not
only that.

Thanks,
Peng.

> 
> --
> Best regards,
> Marek Vasut

[U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Marek Vasut]

On 6/5/19 3:18 AM, Peng Fan wrote:
>> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
>> container format file
>>
>> On 6/4/19 5:27 AM, Peng Fan wrote:
>>>> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading
>>>> i.MX container format file
>>>>
>>>> On 5/30/19 9:06 AM, Ye Li wrote:
>>>>> On 2019/5/27 19:31, Marek Vasut wrote:
>>>>>> Caution: EXT Email
>>>>>>
>>>>>> On 5/27/19 11:49 AM, Peng Fan wrote:
>>>>>>> Hi Marek, Lukasz,
>>>>>>>
>>>>>>>> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support
>>>>>>>> loading i.MX container format file
>>>>>>>>
>>>>>>>> Hi Marek,
>>>>>>>>
>>>>>>>> On 2019/5/22 19:41, Marek Vasut wrote:
>>>>>>>>> Caution: EXT Email
>>>>>>>>>
>>>>>>>>> On 5/22/19 9:34 AM, Lukasz Majewski wrote:
>>>>>>>>> [...]
>>>>>>>>>>>>>>>> By using above approach we do have the NXP's "container"
>>>>>>>>>>>>>>>> format only seen in the SPL (which is OK, as for example
>>>>>>>>>>>>>>>> Samsung does similar thing with FBL/BL1). When SPL is
>>>> "trused"
>>>>>>>>>>>>>>>> we may use available facilities.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The issue to me is that sc_seco_authenticate could not
>>>>>>>>>>>>>>> take a FIT image as input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Is the sc_seco_authenticate an API accessible from SPL,
>>>>>>>>>>>>>> U-Boot proper or Linux crypro engine driver?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes, it is an API accessible in SPL/U-Boot stage. I do not
>>>>>>>>>>>>> know about Linux crypto driver.
>>>>>>>>>>>>
>>>>>>>>>>>> Maybe it would be worth to check how Linux handle this? Maybe
>>>>>>>>>>>> it would shed some more light on it?
>>>>>>>>>>>
>>>>>>>>>>> I am not familiar with that, so might be stupid question below.
>>>>>>>>>>> Does it really matter?
>>>>>>>>>>
>>>>>>>>>> I would check it just out of curiosity.
>>>>>>>>>
>>>>>>>>> Yes, it matters, because there should be such API. How would
>>>>>>>>> Linux authenticate e.g. userspace binaries if there wasn't one,
>>>>>>>>> surely not by wrapping every single object into the custom
>>>>>>>>> vendor-specific
>>>> container ?
>>>>>>>>> And if there is one, you can use it to authenticate raw binaries
>>>>>>>>> from U-Boot SPL too, e.g. fitImage blobs with an associated
>> signature.
>>>>>>>>>
>>>>>>>>
>>>>>>>> iMX8 AHAB uses RSA key pair for authentication, the on-chip thing
>>>>>>>> we called SRK is a array of public key hash which is dedicated
>>>>>>>> for AHAB. It is not a real key. The real public key is in container.
>>>>>>>> AHAB will check the public key with the on-chip SRK before using
>>>>>>>> it to authenticate the image.
>>>>>>>> Seco which contains the crypto engine on imx8 does not allow to
>>>>>>>> use the SRK by user. No such API exported.
>>>>>>>> And the fuse of SRK is locked, can't be read directly.
>>>>>>>>
>>>>>>>> Actually on imx6/imx7/imx8m, the SPL and u-boot are already using
>>>>>>>> ROM HAB to implement the trust chain, like SPL authenticates
>>>>>>>> u-boot, u-boot authenticatse kernel. We just follow this same way
>>>>>>>> on imx8, the difference is
>>>>>>>> imx8 needs container format for signed image. We prefer directly
>>>>>>>> loading container image than fit image.
>>>>>>>> If we pack fit image into container, obviously this will cause
>>>>>>>> one more
>>>> copy.
>>>>>>>> As a boot loader, isn't it better to have more image format supported?
>>>>>>
>>>>>> If the functionality of the new image format is a subset of already
>>>>>> present image format, then no, that's called a duplication.
>>>>>>
>>>>>>>> We
>>>>>>>> don't force to use container, just set it as default. Users still
>>>>>>>> can choose fit or raw image.
>>>>>>
>>>>>> They can. however they cannot authenticate the fitImage because the
>>>>>> firmware doesn't provide the necessary API for that ?
>>>>>>
>>>>>>>
>>>>>>> Do you have more comment?
>>>>>>
>>>>>> How could Linux use this iMX8 chain of trust stuff to authenticate e.g.
>>>>>> userspace binaries ? It's the same thing as authenticating blob in
>>>>>> a fitImage.
>>>>>>
>>>>>
>>>>> Userspace binaries don't use the same key pair. They are signed by
>>>>> software vendors' key. The private key for chip secure boot is only
>>>>> hold by
>>>> device manufacturer.
>>>>> For example, android needs to authenticate a signed APK. Its public
>>>>> key (Key
>>>> A) is in system FS.
>>>>> iMX trust chain only reaches to kernel + ramdisk. Then the chain
>>>>> hands over
>>>> to android.
>>>>> In ramdisk, android puts another public Key (Key B) used by
>>>>> dm-verify for system FS. So once system FS is verified ok, then the
>>>>> public key A becomes trusted. Finally we can use public key A for APK
>> authentication.
>>>>
>>>> So can we put a public key into the SPL and use it to verify a fitImage ?
>>>
>>> Technically doable. But compared with the current approach that reuse
>>> ROM public API, Using crypto driver in SPL will be complicated and
>>> code size larger without calling ROM API.
>>>
>>> I do not understand the problem the SPL loading NXP i.MX8 container
>> format.
>>> SPL should only support raw and fit format? vendor format is not
>>> allowed and not accepted?
>>
>> The problem I have is with the duplication of functionality -- the iMX8 custom
>> format does exactly the same as fitImage, except differently and with smaller
>> user base, thus with less users and reviewers and thus with less potential
>> bugfixes, which I think in crypto code is important.
> 
> The change to spl mmc common code is as below:
> diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> index bf53a1dadf..6320af055b 100644
> --- a/common/spl/spl_mmc.c
> +++ b/common/spl/spl_mmc.c
> @@ -79,6 +79,16 @@ int mmc_load_image_raw_sector(struct spl_image_info *spl_image,
>                 load.bl_len = mmc->read_bl_len;
>                 load.read = h_spl_load_read;
>                 ret = spl_load_simple_fit(spl_image, &load, sector, header);
> +       } else if (IS_ENABLED(CONFIG_SPL_LOAD_IMX_CONTAINER)) {
> +               struct spl_load_info load;
> +
> +               load.dev = mmc;
> +               load.priv = NULL;
> +               load.filename = NULL;
> +               load.bl_len = mmc->read_bl_len;
> +               load.read = h_spl_load_read;
> +
> +               ret = spl_load_imx_container(spl_image, &load, sector);
>         } else {
> 
> If IMX_CONTAINER is not preferred

I never implied that.

>, I'll change it to CONFIG_SPL_LOAD_VENDOR_FORMAT.
> In this way, only i.MX users need to take care container format, non i.MX users no need
> to care about that.

That would make it even worse, since if we follow this course of
development, I suspect iMX9 will have another different container format
and the list will grow on.

> It is not duplication of FIT. Container support the similar function of FIT image, but it is not
> only that.

So what is it ?

I don't think I get it. Why would I, as an iMX8 user, want to pick
custom new vendor-specific format over years-proven generic fitImage?
What is the selling point here ?

-- 
Best regards,
Marek Vasut

[U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Peng Fan]

> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
> container format file
> 
> On 6/5/19 3:18 AM, Peng Fan wrote:
> >> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading
> >> i.MX container format file
> >>
> >> On 6/4/19 5:27 AM, Peng Fan wrote:
> >>>> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support
> >>>> loading i.MX container format file
> >>>>
> >>>> On 5/30/19 9:06 AM, Ye Li wrote:
> >>>>> On 2019/5/27 19:31, Marek Vasut wrote:
> >>>>>> Caution: EXT Email
> >>>>>>
> >>>>>> On 5/27/19 11:49 AM, Peng Fan wrote:
> >>>>>>> Hi Marek, Lukasz,
> >>>>>>>
> >>>>>>>> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support
> >>>>>>>> loading i.MX container format file
> >>>>>>>>
> >>>>>>>> Hi Marek,
> >>>>>>>>
> >>>>>>>> On 2019/5/22 19:41, Marek Vasut wrote:
> >>>>>>>>> Caution: EXT Email
> >>>>>>>>>
> >>>>>>>>> On 5/22/19 9:34 AM, Lukasz Majewski wrote:
> >>>>>>>>> [...]
> >>>>>>>>>>>>>>>> By using above approach we do have the NXP's
> "container"
> >>>>>>>>>>>>>>>> format only seen in the SPL (which is OK, as for
> >>>>>>>>>>>>>>>> example Samsung does similar thing with FBL/BL1).
> When
> >>>>>>>>>>>>>>>> SPL is
> >>>> "trused"
> >>>>>>>>>>>>>>>> we may use available facilities.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> The issue to me is that sc_seco_authenticate could not
> >>>>>>>>>>>>>>> take a FIT image as input.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Is the sc_seco_authenticate an API accessible from SPL,
> >>>>>>>>>>>>>> U-Boot proper or Linux crypro engine driver?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Yes, it is an API accessible in SPL/U-Boot stage. I do not
> >>>>>>>>>>>>> know about Linux crypto driver.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Maybe it would be worth to check how Linux handle this?
> >>>>>>>>>>>> Maybe it would shed some more light on it?
> >>>>>>>>>>>
> >>>>>>>>>>> I am not familiar with that, so might be stupid question below.
> >>>>>>>>>>> Does it really matter?
> >>>>>>>>>>
> >>>>>>>>>> I would check it just out of curiosity.
> >>>>>>>>>
> >>>>>>>>> Yes, it matters, because there should be such API. How would
> >>>>>>>>> Linux authenticate e.g. userspace binaries if there wasn't
> >>>>>>>>> one, surely not by wrapping every single object into the
> >>>>>>>>> custom vendor-specific
> >>>> container ?
> >>>>>>>>> And if there is one, you can use it to authenticate raw
> >>>>>>>>> binaries from U-Boot SPL too, e.g. fitImage blobs with an
> >>>>>>>>> associated
> >> signature.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> iMX8 AHAB uses RSA key pair for authentication, the on-chip
> >>>>>>>> thing we called SRK is a array of public key hash which is
> >>>>>>>> dedicated for AHAB. It is not a real key. The real public key is in
> container.
> >>>>>>>> AHAB will check the public key with the on-chip SRK before
> >>>>>>>> using it to authenticate the image.
> >>>>>>>> Seco which contains the crypto engine on imx8 does not allow to
> >>>>>>>> use the SRK by user. No such API exported.
> >>>>>>>> And the fuse of SRK is locked, can't be read directly.
> >>>>>>>>
> >>>>>>>> Actually on imx6/imx7/imx8m, the SPL and u-boot are already
> >>>>>>>> using ROM HAB to implement the trust chain, like SPL
> >>>>>>>> authenticates u-boot, u-boot authenticatse kernel. We just
> >>>>>>>> follow this same way on imx8, the difference is
> >>>>>>>> imx8 needs container format for signed image. We prefer
> >>>>>>>> directly loading container image than fit image.
> >>>>>>>> If we pack fit image into container, obviously this will cause
> >>>>>>>> one more
> >>>> copy.
> >>>>>>>> As a boot loader, isn't it better to have more image format
> supported?
> >>>>>>
> >>>>>> If the functionality of the new image format is a subset of
> >>>>>> already present image format, then no, that's called a duplication.
> >>>>>>
> >>>>>>>> We
> >>>>>>>> don't force to use container, just set it as default. Users
> >>>>>>>> still can choose fit or raw image.
> >>>>>>
> >>>>>> They can. however they cannot authenticate the fitImage because
> >>>>>> the firmware doesn't provide the necessary API for that ?
> >>>>>>
> >>>>>>>
> >>>>>>> Do you have more comment?
> >>>>>>
> >>>>>> How could Linux use this iMX8 chain of trust stuff to authenticate e.g.
> >>>>>> userspace binaries ? It's the same thing as authenticating blob
> >>>>>> in a fitImage.
> >>>>>>
> >>>>>
> >>>>> Userspace binaries don't use the same key pair. They are signed by
> >>>>> software vendors' key. The private key for chip secure boot is
> >>>>> only hold by
> >>>> device manufacturer.
> >>>>> For example, android needs to authenticate a signed APK. Its
> >>>>> public key (Key
> >>>> A) is in system FS.
> >>>>> iMX trust chain only reaches to kernel + ramdisk. Then the chain
> >>>>> hands over
> >>>> to android.
> >>>>> In ramdisk, android puts another public Key (Key B) used by
> >>>>> dm-verify for system FS. So once system FS is verified ok, then
> >>>>> the public key A becomes trusted. Finally we can use public key A
> >>>>> for APK
> >> authentication.
> >>>>
> >>>> So can we put a public key into the SPL and use it to verify a fitImage ?
> >>>
> >>> Technically doable. But compared with the current approach that
> >>> reuse ROM public API, Using crypto driver in SPL will be complicated
> >>> and code size larger without calling ROM API.
> >>>
> >>> I do not understand the problem the SPL loading NXP i.MX8 container
> >> format.
> >>> SPL should only support raw and fit format? vendor format is not
> >>> allowed and not accepted?
> >>
> >> The problem I have is with the duplication of functionality -- the
> >> iMX8 custom format does exactly the same as fitImage, except
> >> differently and with smaller user base, thus with less users and
> >> reviewers and thus with less potential bugfixes, which I think in crypto
> code is important.
> >
> > The change to spl mmc common code is as below:
> > diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c index
> > bf53a1dadf..6320af055b 100644
> > --- a/common/spl/spl_mmc.c
> > +++ b/common/spl/spl_mmc.c
> > @@ -79,6 +79,16 @@ int mmc_load_image_raw_sector(struct
> spl_image_info *spl_image,
> >                 load.bl_len = mmc->read_bl_len;
> >                 load.read = h_spl_load_read;
> >                 ret = spl_load_simple_fit(spl_image, &load, sector,
> > header);
> > +       } else if (IS_ENABLED(CONFIG_SPL_LOAD_IMX_CONTAINER)) {
> > +               struct spl_load_info load;
> > +
> > +               load.dev = mmc;
> > +               load.priv = NULL;
> > +               load.filename = NULL;
> > +               load.bl_len = mmc->read_bl_len;
> > +               load.read = h_spl_load_read;
> > +
> > +               ret = spl_load_imx_container(spl_image, &load,
> > + sector);
> >         } else {
> >
> > If IMX_CONTAINER is not preferred
> 
> I never implied that.
> 
> >, I'll change it to CONFIG_SPL_LOAD_VENDOR_FORMAT.
> > In this way, only i.MX users need to take care container format, non
> >i.MX users no need  to care about that.
> 
> That would make it even worse, since if we follow this course of development,
> I suspect iMX9 will have another different container format and the list will
> grow on.

Let me summary the previous SoC that NXP is actively maintaining
i.MX6/7/7ULP/8M use IVT
i.MX8/8X use container

I could not disclose information about future i.MX SoC.

> 
> > It is not duplication of FIT. Container support the similar function
> > of FIT image, but it is not only that.
> 
> So what is it ?

https://www.nxp.com/docs/en/reference-manual/IMX8DQXPRM.pdf
Chapter 5 has information about container set and container.

> 
> I don't think I get it. Why would I, as an iMX8 user, want to pick custom new
> vendor-specific format over years-proven generic fitImage?

We not against FIT, we already use FIT on i.MX8M, to let spl
to authenticate FIT image using ROM HAB, not using crypto driver.

> What is the selling point here ?

We would not introduce cypto driver in SPL stage, that means HAB FIT and
AHAB container needs to be dropped when SPL loading other images.
ROM already provides API for bootloader to authenticate images, introducing
complex crypto driver in SPL could enlarge code size and make things
complicated.

Thanks,
Peng.

> 
> --
> Best regards,
> Marek Vasut

[U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Marek Vasut]

On 6/5/19 3:59 AM, Peng Fan wrote:
>> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
>> container format file
>>
>> On 6/5/19 3:18 AM, Peng Fan wrote:
>>>> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading
>>>> i.MX container format file
>>>>
>>>> On 6/4/19 5:27 AM, Peng Fan wrote:
>>>>>> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support
>>>>>> loading i.MX container format file
>>>>>>
>>>>>> On 5/30/19 9:06 AM, Ye Li wrote:
>>>>>>> On 2019/5/27 19:31, Marek Vasut wrote:
>>>>>>>> Caution: EXT Email
>>>>>>>>
>>>>>>>> On 5/27/19 11:49 AM, Peng Fan wrote:
>>>>>>>>> Hi Marek, Lukasz,
>>>>>>>>>
>>>>>>>>>> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support
>>>>>>>>>> loading i.MX container format file
>>>>>>>>>>
>>>>>>>>>> Hi Marek,
>>>>>>>>>>
>>>>>>>>>> On 2019/5/22 19:41, Marek Vasut wrote:
>>>>>>>>>>> Caution: EXT Email
>>>>>>>>>>>
>>>>>>>>>>> On 5/22/19 9:34 AM, Lukasz Majewski wrote:
>>>>>>>>>>> [...]
>>>>>>>>>>>>>>>>>> By using above approach we do have the NXP's
>> "container"
>>>>>>>>>>>>>>>>>> format only seen in the SPL (which is OK, as for
>>>>>>>>>>>>>>>>>> example Samsung does similar thing with FBL/BL1).
>> When
>>>>>>>>>>>>>>>>>> SPL is
>>>>>> "trused"
>>>>>>>>>>>>>>>>>> we may use available facilities.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The issue to me is that sc_seco_authenticate could not
>>>>>>>>>>>>>>>>> take a FIT image as input.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Is the sc_seco_authenticate an API accessible from SPL,
>>>>>>>>>>>>>>>> U-Boot proper or Linux crypro engine driver?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yes, it is an API accessible in SPL/U-Boot stage. I do not
>>>>>>>>>>>>>>> know about Linux crypto driver.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Maybe it would be worth to check how Linux handle this?
>>>>>>>>>>>>>> Maybe it would shed some more light on it?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I am not familiar with that, so might be stupid question below.
>>>>>>>>>>>>> Does it really matter?
>>>>>>>>>>>>
>>>>>>>>>>>> I would check it just out of curiosity.
>>>>>>>>>>>
>>>>>>>>>>> Yes, it matters, because there should be such API. How would
>>>>>>>>>>> Linux authenticate e.g. userspace binaries if there wasn't
>>>>>>>>>>> one, surely not by wrapping every single object into the
>>>>>>>>>>> custom vendor-specific
>>>>>> container ?
>>>>>>>>>>> And if there is one, you can use it to authenticate raw
>>>>>>>>>>> binaries from U-Boot SPL too, e.g. fitImage blobs with an
>>>>>>>>>>> associated
>>>> signature.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> iMX8 AHAB uses RSA key pair for authentication, the on-chip
>>>>>>>>>> thing we called SRK is a array of public key hash which is
>>>>>>>>>> dedicated for AHAB. It is not a real key. The real public key is in
>> container.
>>>>>>>>>> AHAB will check the public key with the on-chip SRK before
>>>>>>>>>> using it to authenticate the image.
>>>>>>>>>> Seco which contains the crypto engine on imx8 does not allow to
>>>>>>>>>> use the SRK by user. No such API exported.
>>>>>>>>>> And the fuse of SRK is locked, can't be read directly.
>>>>>>>>>>
>>>>>>>>>> Actually on imx6/imx7/imx8m, the SPL and u-boot are already
>>>>>>>>>> using ROM HAB to implement the trust chain, like SPL
>>>>>>>>>> authenticates u-boot, u-boot authenticatse kernel. We just
>>>>>>>>>> follow this same way on imx8, the difference is
>>>>>>>>>> imx8 needs container format for signed image. We prefer
>>>>>>>>>> directly loading container image than fit image.
>>>>>>>>>> If we pack fit image into container, obviously this will cause
>>>>>>>>>> one more
>>>>>> copy.
>>>>>>>>>> As a boot loader, isn't it better to have more image format
>> supported?
>>>>>>>>
>>>>>>>> If the functionality of the new image format is a subset of
>>>>>>>> already present image format, then no, that's called a duplication.
>>>>>>>>
>>>>>>>>>> We
>>>>>>>>>> don't force to use container, just set it as default. Users
>>>>>>>>>> still can choose fit or raw image.
>>>>>>>>
>>>>>>>> They can. however they cannot authenticate the fitImage because
>>>>>>>> the firmware doesn't provide the necessary API for that ?
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Do you have more comment?
>>>>>>>>
>>>>>>>> How could Linux use this iMX8 chain of trust stuff to authenticate e.g.
>>>>>>>> userspace binaries ? It's the same thing as authenticating blob
>>>>>>>> in a fitImage.
>>>>>>>>
>>>>>>>
>>>>>>> Userspace binaries don't use the same key pair. They are signed by
>>>>>>> software vendors' key. The private key for chip secure boot is
>>>>>>> only hold by
>>>>>> device manufacturer.
>>>>>>> For example, android needs to authenticate a signed APK. Its
>>>>>>> public key (Key
>>>>>> A) is in system FS.
>>>>>>> iMX trust chain only reaches to kernel + ramdisk. Then the chain
>>>>>>> hands over
>>>>>> to android.
>>>>>>> In ramdisk, android puts another public Key (Key B) used by
>>>>>>> dm-verify for system FS. So once system FS is verified ok, then
>>>>>>> the public key A becomes trusted. Finally we can use public key A
>>>>>>> for APK
>>>> authentication.
>>>>>>
>>>>>> So can we put a public key into the SPL and use it to verify a fitImage ?
>>>>>
>>>>> Technically doable. But compared with the current approach that
>>>>> reuse ROM public API, Using crypto driver in SPL will be complicated
>>>>> and code size larger without calling ROM API.
>>>>>
>>>>> I do not understand the problem the SPL loading NXP i.MX8 container
>>>> format.
>>>>> SPL should only support raw and fit format? vendor format is not
>>>>> allowed and not accepted?
>>>>
>>>> The problem I have is with the duplication of functionality -- the
>>>> iMX8 custom format does exactly the same as fitImage, except
>>>> differently and with smaller user base, thus with less users and
>>>> reviewers and thus with less potential bugfixes, which I think in crypto
>> code is important.
>>>
>>> The change to spl mmc common code is as below:
>>> diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c index
>>> bf53a1dadf..6320af055b 100644
>>> --- a/common/spl/spl_mmc.c
>>> +++ b/common/spl/spl_mmc.c
>>> @@ -79,6 +79,16 @@ int mmc_load_image_raw_sector(struct
>> spl_image_info *spl_image,
>>>                 load.bl_len = mmc->read_bl_len;
>>>                 load.read = h_spl_load_read;
>>>                 ret = spl_load_simple_fit(spl_image, &load, sector,
>>> header);
>>> +       } else if (IS_ENABLED(CONFIG_SPL_LOAD_IMX_CONTAINER)) {
>>> +               struct spl_load_info load;
>>> +
>>> +               load.dev = mmc;
>>> +               load.priv = NULL;
>>> +               load.filename = NULL;
>>> +               load.bl_len = mmc->read_bl_len;
>>> +               load.read = h_spl_load_read;
>>> +
>>> +               ret = spl_load_imx_container(spl_image, &load,
>>> + sector);
>>>         } else {
>>>
>>> If IMX_CONTAINER is not preferred
>>
>> I never implied that.
>>
>>> , I'll change it to CONFIG_SPL_LOAD_VENDOR_FORMAT.
>>> In this way, only i.MX users need to take care container format, non
>>> i.MX users no need  to care about that.
>>
>> That would make it even worse, since if we follow this course of development,
>> I suspect iMX9 will have another different container format and the list will
>> grow on.
> 
> Let me summary the previous SoC that NXP is actively maintaining
> i.MX6/7/7ULP/8M use IVT
> i.MX8/8X use container
> 
> I could not disclose information about future i.MX SoC.

My assumption is that the future iMX SoC will use yet another different
container format.

>>> It is not duplication of FIT. Container support the similar function
>>> of FIT image, but it is not only that.
>>
>> So what is it ?
> 
> https://www.nxp.com/docs/en/reference-manual/IMX8DQXPRM.pdf
> Chapter 5 has information about container set and container.

Thanks, any specific part of those 80 pages ?

>> I don't think I get it. Why would I, as an iMX8 user, want to pick custom new
>> vendor-specific format over years-proven generic fitImage?
> 
> We not against FIT, we already use FIT on i.MX8M, to let spl
> to authenticate FIT image using ROM HAB, not using crypto driver.

Great

>> What is the selling point here ?
> 
> We would not introduce cypto driver in SPL stage, that means HAB FIT and
> AHAB container needs to be dropped when SPL loading other images.
> ROM already provides API for bootloader to authenticate images, introducing
> complex crypto driver in SPL could enlarge code size and make things
> complicated.

Ah I see, so it's all making the whole crypto simpler by offloading the
hard parts into the firmware, which just magically handles everything ,
without having much extra code in the SPL ?

-- 
Best regards,
Marek Vasut

[U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Peng Fan]

> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
> container format file
> 
> On 6/5/19 3:59 AM, Peng Fan wrote:
> >> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading
> >> i.MX container format file
> >>
> >> On 6/5/19 3:18 AM, Peng Fan wrote:
> >>>> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support
> >>>> loading i.MX container format file
> >>>>
> >>>> On 6/4/19 5:27 AM, Peng Fan wrote:
> >>>>>> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support
> >>>>>> loading i.MX container format file
> >>>>>>
> >>>>>> On 5/30/19 9:06 AM, Ye Li wrote:
> >>>>>>> On 2019/5/27 19:31, Marek Vasut wrote:
> >>>>>>>> Caution: EXT Email
> >>>>>>>>
> >>>>>>>> On 5/27/19 11:49 AM, Peng Fan wrote:
> >>>>>>>>> Hi Marek, Lukasz,
> >>>>>>>>>
> >>>>>>>>>> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support
> >>>>>>>>>> loading i.MX container format file
> >>>>>>>>>>
> >>>>>>>>>> Hi Marek,
> >>>>>>>>>>
> >>>>>>>>>> On 2019/5/22 19:41, Marek Vasut wrote:
> >>>>>>>>>>> Caution: EXT Email
> >>>>>>>>>>>
> >>>>>>>>>>> On 5/22/19 9:34 AM, Lukasz Majewski wrote:
> >>>>>>>>>>> [...]
> >>>>>>>>>>>>>>>>>> By using above approach we do have the NXP's
> >> "container"
> >>>>>>>>>>>>>>>>>> format only seen in the SPL (which is OK, as for
> >>>>>>>>>>>>>>>>>> example Samsung does similar thing with FBL/BL1).
> >> When
> >>>>>>>>>>>>>>>>>> SPL is
> >>>>>> "trused"
> >>>>>>>>>>>>>>>>>> we may use available facilities.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> The issue to me is that sc_seco_authenticate could not
> >>>>>>>>>>>>>>>>> take a FIT image as input.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Is the sc_seco_authenticate an API accessible from SPL,
> >>>>>>>>>>>>>>>> U-Boot proper or Linux crypro engine driver?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Yes, it is an API accessible in SPL/U-Boot stage. I do
> >>>>>>>>>>>>>>> not know about Linux crypto driver.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Maybe it would be worth to check how Linux handle this?
> >>>>>>>>>>>>>> Maybe it would shed some more light on it?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I am not familiar with that, so might be stupid question
> below.
> >>>>>>>>>>>>> Does it really matter?
> >>>>>>>>>>>>
> >>>>>>>>>>>> I would check it just out of curiosity.
> >>>>>>>>>>>
> >>>>>>>>>>> Yes, it matters, because there should be such API. How would
> >>>>>>>>>>> Linux authenticate e.g. userspace binaries if there wasn't
> >>>>>>>>>>> one, surely not by wrapping every single object into the
> >>>>>>>>>>> custom vendor-specific
> >>>>>> container ?
> >>>>>>>>>>> And if there is one, you can use it to authenticate raw
> >>>>>>>>>>> binaries from U-Boot SPL too, e.g. fitImage blobs with an
> >>>>>>>>>>> associated
> >>>> signature.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> iMX8 AHAB uses RSA key pair for authentication, the on-chip
> >>>>>>>>>> thing we called SRK is a array of public key hash which is
> >>>>>>>>>> dedicated for AHAB. It is not a real key. The real public key
> >>>>>>>>>> is in
> >> container.
> >>>>>>>>>> AHAB will check the public key with the on-chip SRK before
> >>>>>>>>>> using it to authenticate the image.
> >>>>>>>>>> Seco which contains the crypto engine on imx8 does not allow
> >>>>>>>>>> to use the SRK by user. No such API exported.
> >>>>>>>>>> And the fuse of SRK is locked, can't be read directly.
> >>>>>>>>>>
> >>>>>>>>>> Actually on imx6/imx7/imx8m, the SPL and u-boot are already
> >>>>>>>>>> using ROM HAB to implement the trust chain, like SPL
> >>>>>>>>>> authenticates u-boot, u-boot authenticatse kernel. We just
> >>>>>>>>>> follow this same way on imx8, the difference is
> >>>>>>>>>> imx8 needs container format for signed image. We prefer
> >>>>>>>>>> directly loading container image than fit image.
> >>>>>>>>>> If we pack fit image into container, obviously this will
> >>>>>>>>>> cause one more
> >>>>>> copy.
> >>>>>>>>>> As a boot loader, isn't it better to have more image format
> >> supported?
> >>>>>>>>
> >>>>>>>> If the functionality of the new image format is a subset of
> >>>>>>>> already present image format, then no, that's called a duplication.
> >>>>>>>>
> >>>>>>>>>> We
> >>>>>>>>>> don't force to use container, just set it as default. Users
> >>>>>>>>>> still can choose fit or raw image.
> >>>>>>>>
> >>>>>>>> They can. however they cannot authenticate the fitImage because
> >>>>>>>> the firmware doesn't provide the necessary API for that ?
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Do you have more comment?
> >>>>>>>>
> >>>>>>>> How could Linux use this iMX8 chain of trust stuff to authenticate
> e.g.
> >>>>>>>> userspace binaries ? It's the same thing as authenticating blob
> >>>>>>>> in a fitImage.
> >>>>>>>>
> >>>>>>>
> >>>>>>> Userspace binaries don't use the same key pair. They are signed
> >>>>>>> by software vendors' key. The private key for chip secure boot
> >>>>>>> is only hold by
> >>>>>> device manufacturer.
> >>>>>>> For example, android needs to authenticate a signed APK. Its
> >>>>>>> public key (Key
> >>>>>> A) is in system FS.
> >>>>>>> iMX trust chain only reaches to kernel + ramdisk. Then the chain
> >>>>>>> hands over
> >>>>>> to android.
> >>>>>>> In ramdisk, android puts another public Key (Key B) used by
> >>>>>>> dm-verify for system FS. So once system FS is verified ok, then
> >>>>>>> the public key A becomes trusted. Finally we can use public key
> >>>>>>> A for APK
> >>>> authentication.
> >>>>>>
> >>>>>> So can we put a public key into the SPL and use it to verify a
> fitImage ?
> >>>>>
> >>>>> Technically doable. But compared with the current approach that
> >>>>> reuse ROM public API, Using crypto driver in SPL will be
> >>>>> complicated and code size larger without calling ROM API.
> >>>>>
> >>>>> I do not understand the problem the SPL loading NXP i.MX8
> >>>>> container
> >>>> format.
> >>>>> SPL should only support raw and fit format? vendor format is not
> >>>>> allowed and not accepted?
> >>>>
> >>>> The problem I have is with the duplication of functionality -- the
> >>>> iMX8 custom format does exactly the same as fitImage, except
> >>>> differently and with smaller user base, thus with less users and
> >>>> reviewers and thus with less potential bugfixes, which I think in
> >>>> crypto
> >> code is important.
> >>>
> >>> The change to spl mmc common code is as below:
> >>> diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c index
> >>> bf53a1dadf..6320af055b 100644
> >>> --- a/common/spl/spl_mmc.c
> >>> +++ b/common/spl/spl_mmc.c
> >>> @@ -79,6 +79,16 @@ int mmc_load_image_raw_sector(struct
> >> spl_image_info *spl_image,
> >>>                 load.bl_len = mmc->read_bl_len;
> >>>                 load.read = h_spl_load_read;
> >>>                 ret = spl_load_simple_fit(spl_image, &load, sector,
> >>> header);
> >>> +       } else if (IS_ENABLED(CONFIG_SPL_LOAD_IMX_CONTAINER)) {
> >>> +               struct spl_load_info load;
> >>> +
> >>> +               load.dev = mmc;
> >>> +               load.priv = NULL;
> >>> +               load.filename = NULL;
> >>> +               load.bl_len = mmc->read_bl_len;
> >>> +               load.read = h_spl_load_read;
> >>> +
> >>> +               ret = spl_load_imx_container(spl_image, &load,
> >>> + sector);
> >>>         } else {
> >>>
> >>> If IMX_CONTAINER is not preferred
> >>
> >> I never implied that.
> >>
> >>> , I'll change it to CONFIG_SPL_LOAD_VENDOR_FORMAT.
> >>> In this way, only i.MX users need to take care container format, non
> >>> i.MX users no need  to care about that.
> >>
> >> That would make it even worse, since if we follow this course of
> >> development, I suspect iMX9 will have another different container
> >> format and the list will grow on.
> >
> > Let me summary the previous SoC that NXP is actively maintaining
> > i.MX6/7/7ULP/8M use IVT i.MX8/8X use container
> >
> > I could not disclose information about future i.MX SoC.
> 
> My assumption is that the future iMX SoC will use yet another different
> container format.
> 
> >>> It is not duplication of FIT. Container support the similar function
> >>> of FIT image, but it is not only that.
> >>
> >> So what is it ?
> >
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> >
> nxp.com%2Fdocs%2Fen%2Freference-manual%2FIMX8DQXPRM.pdf&da
> ta=02%7C
> >
> 01%7Cpeng.fan%40nxp.com%7C72216052f4234a93ad1f08d6e95ed782%7C6
> 86ea1d3b
> >
> c2b4c6fa92cd99c5c301635%7C0%7C1%7C636952990895125305&sdat
> a=KO%2B0e
> >
> E3v%2FkHuJ%2BhR7mBgc4NWXxbMUupfubXXu%2BueIWo%3D&reserv
> ed=0
> > Chapter 5 has information about container set and container.
> 
> Thanks, any specific part of those 80 pages ?

Figure 5-24. Container Format has a picture about a single container.
i.MX8 container also support container sets, support encrypt blob,
certificates, SRK management. Support signature to the whole container,
no need single image inside container.

> 
> >> I don't think I get it. Why would I, as an iMX8 user, want to pick
> >> custom new vendor-specific format over years-proven generic fitImage?
> >
> > We not against FIT, we already use FIT on i.MX8M, to let spl to
> > authenticate FIT image using ROM HAB, not using crypto driver.
> 
> Great
> 
> >> What is the selling point here ?
> >
> > We would not introduce cypto driver in SPL stage, that means HAB FIT
> > and AHAB container needs to be dropped when SPL loading other images.
> > ROM already provides API for bootloader to authenticate images,
> > introducing complex crypto driver in SPL could enlarge code size and
> > make things complicated.
> 
> Ah I see, so it's all making the whole crypto simpler by offloading the hard
> parts into the firmware, which just magically handles everything , without
> having much extra code in the SPL ?

Yes. Use what ROM provides will make things easier for U-Boot.

Thanks,
Peng.

> 
> --
> Best regards,
> Marek Vasut

[U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Marek Vasut]

On 6/5/19 5:03 AM, Peng Fan wrote:
[...]
>>>>> It is not duplication of FIT. Container support the similar function
>>>>> of FIT image, but it is not only that.
>>>>
>>>> So what is it ?
>>>
>>>
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
>>>
>> nxp.com%2Fdocs%2Fen%2Freference-manual%2FIMX8DQXPRM.pdf&da
>> ta=02%7C
>>>
>> 01%7Cpeng.fan%40nxp.com%7C72216052f4234a93ad1f08d6e95ed782%7C6
>> 86ea1d3b
>>>
>> c2b4c6fa92cd99c5c301635%7C0%7C1%7C636952990895125305&sdat
>> a=KO%2B0e
>>>
>> E3v%2FkHuJ%2BhR7mBgc4NWXxbMUupfubXXu%2BueIWo%3D&reserv
>> ed=0
>>> Chapter 5 has information about container set and container.
>>
>> Thanks, any specific part of those 80 pages ?
> 
> Figure 5-24. Container Format has a picture about a single container.
> i.MX8 container also support container sets, support encrypt blob,
> certificates, SRK management. Support signature to the whole container,
> no need single image inside container.

Isn't that all supported in fitImage too ?

>>
>>>> I don't think I get it. Why would I, as an iMX8 user, want to pick
>>>> custom new vendor-specific format over years-proven generic fitImage?
>>>
>>> We not against FIT, we already use FIT on i.MX8M, to let spl to
>>> authenticate FIT image using ROM HAB, not using crypto driver.
>>
>> Great
>>
>>>> What is the selling point here ?
>>>
>>> We would not introduce cypto driver in SPL stage, that means HAB FIT
>>> and AHAB container needs to be dropped when SPL loading other images.
>>> ROM already provides API for bootloader to authenticate images,
>>> introducing complex crypto driver in SPL could enlarge code size and
>>> make things complicated.
>>
>> Ah I see, so it's all making the whole crypto simpler by offloading the hard
>> parts into the firmware, which just magically handles everything , without
>> having much extra code in the SPL ?
> 
> Yes. Use what ROM provides will make things easier for U-Boot.

Is it possible to perform a security audit on the ROM as easily as on
U-Boot ? I mean, U-Boot is free software, the source is available, so
security researchers can easily scrutinize it. Is the ROM ?

-- 
Best regards,
Marek Vasut

[U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Tom Rini]

On Wed, Jun 05, 2019 at 03:24:40PM +0200, Marek Vasut wrote:
> On 6/5/19 5:03 AM, Peng Fan wrote:
> [...]
> >>>>> It is not duplication of FIT. Container support the similar function
> >>>>> of FIT image, but it is not only that.
> >>>>
> >>>> So what is it ?
> >>>
> >>>
> >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> >>>
> >> nxp.com%2Fdocs%2Fen%2Freference-manual%2FIMX8DQXPRM.pdf&da
> >> ta=02%7C
> >>>
> >> 01%7Cpeng.fan%40nxp.com%7C72216052f4234a93ad1f08d6e95ed782%7C6
> >> 86ea1d3b
> >>>
> >> c2b4c6fa92cd99c5c301635%7C0%7C1%7C636952990895125305&sdat
> >> a=KO%2B0e
> >>>
> >> E3v%2FkHuJ%2BhR7mBgc4NWXxbMUupfubXXu%2BueIWo%3D&reserv
> >> ed=0
> >>> Chapter 5 has information about container set and container.
> >>
> >> Thanks, any specific part of those 80 pages ?
> > 
> > Figure 5-24. Container Format has a picture about a single container.
> > i.MX8 container also support container sets, support encrypt blob,
> > certificates, SRK management. Support signature to the whole container,
> > no need single image inside container.
> 
> Isn't that all supported in fitImage too ?

This is neither the first nor last time functionality has been
essentially duplicated, sadly, for reasons.

> >>>> I don't think I get it. Why would I, as an iMX8 user, want to pick
> >>>> custom new vendor-specific format over years-proven generic fitImage?
> >>>
> >>> We not against FIT, we already use FIT on i.MX8M, to let spl to
> >>> authenticate FIT image using ROM HAB, not using crypto driver.
> >>
> >> Great
> >>
> >>>> What is the selling point here ?
> >>>
> >>> We would not introduce cypto driver in SPL stage, that means HAB FIT
> >>> and AHAB container needs to be dropped when SPL loading other images.
> >>> ROM already provides API for bootloader to authenticate images,
> >>> introducing complex crypto driver in SPL could enlarge code size and
> >>> make things complicated.
> >>
> >> Ah I see, so it's all making the whole crypto simpler by offloading the hard
> >> parts into the firmware, which just magically handles everything , without
> >> having much extra code in the SPL ?
> > 
> > Yes. Use what ROM provides will make things easier for U-Boot.
> 
> Is it possible to perform a security audit on the ROM as easily as on
> U-Boot ? I mean, U-Boot is free software, the source is available, so
> security researchers can easily scrutinize it. Is the ROM ?

So, here's my two cents (and it may or may not seem contradictory with
my opinions in the secure boot thread going on currently on the Linaro
Boot Architecture list).  Yes, it would and IMHO is better when we use
free and open software to solve our problems (and an aside to the RISC-V
folks as this is yet another area they can make the world a better place
in).  But I am a believe in dealing with the world as it stands at times
too.  The question isn't "can we get NXP to re-spin i.MX8 to use the FIT
image format?" as that's obviously going to be "No.".  The question is,
"can we support this format in a clean manner?" and the answer is
obviously "Yes.".  So please lets keep that in mind with reviewing the
code as at the end of the day it is more beneficial for this to be
supported in mainline U-Boot than only supported in the vendor tree.
Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190605/8c85ad54/attachment.sig>

[U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Marek Vasut]

On 6/5/19 3:52 PM, Tom Rini wrote:
> On Wed, Jun 05, 2019 at 03:24:40PM +0200, Marek Vasut wrote:
>> On 6/5/19 5:03 AM, Peng Fan wrote:
>> [...]
>>>>>>> It is not duplication of FIT. Container support the similar function
>>>>>>> of FIT image, but it is not only that.
>>>>>>
>>>>>> So what is it ?
>>>>>
>>>>>
>>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
>>>>>
>>>> nxp.com%2Fdocs%2Fen%2Freference-manual%2FIMX8DQXPRM.pdf&da
>>>> ta=02%7C
>>>>>
>>>> 01%7Cpeng.fan%40nxp.com%7C72216052f4234a93ad1f08d6e95ed782%7C6
>>>> 86ea1d3b
>>>>>
>>>> c2b4c6fa92cd99c5c301635%7C0%7C1%7C636952990895125305&sdat
>>>> a=KO%2B0e
>>>>>
>>>> E3v%2FkHuJ%2BhR7mBgc4NWXxbMUupfubXXu%2BueIWo%3D&reserv
>>>> ed=0
>>>>> Chapter 5 has information about container set and container.
>>>>
>>>> Thanks, any specific part of those 80 pages ?
>>>
>>> Figure 5-24. Container Format has a picture about a single container.
>>> i.MX8 container also support container sets, support encrypt blob,
>>> certificates, SRK management. Support signature to the whole container,
>>> no need single image inside container.
>>
>> Isn't that all supported in fitImage too ?
> 
> This is neither the first nor last time functionality has been
> essentially duplicated, sadly, for reasons.
> 
>>>>>> I don't think I get it. Why would I, as an iMX8 user, want to pick
>>>>>> custom new vendor-specific format over years-proven generic fitImage?
>>>>>
>>>>> We not against FIT, we already use FIT on i.MX8M, to let spl to
>>>>> authenticate FIT image using ROM HAB, not using crypto driver.
>>>>
>>>> Great
>>>>
>>>>>> What is the selling point here ?
>>>>>
>>>>> We would not introduce cypto driver in SPL stage, that means HAB FIT
>>>>> and AHAB container needs to be dropped when SPL loading other images.
>>>>> ROM already provides API for bootloader to authenticate images,
>>>>> introducing complex crypto driver in SPL could enlarge code size and
>>>>> make things complicated.
>>>>
>>>> Ah I see, so it's all making the whole crypto simpler by offloading the hard
>>>> parts into the firmware, which just magically handles everything , without
>>>> having much extra code in the SPL ?
>>>
>>> Yes. Use what ROM provides will make things easier for U-Boot.
>>
>> Is it possible to perform a security audit on the ROM as easily as on
>> U-Boot ? I mean, U-Boot is free software, the source is available, so
>> security researchers can easily scrutinize it. Is the ROM ?
> 
> So, here's my two cents (and it may or may not seem contradictory with
> my opinions in the secure boot thread going on currently on the Linaro
> Boot Architecture list).  Yes, it would and IMHO is better when we use
> free and open software to solve our problems (and an aside to the RISC-V
> folks as this is yet another area they can make the world a better place
> in).  But I am a believe in dealing with the world as it stands at times
> too.  The question isn't "can we get NXP to re-spin i.MX8 to use the FIT
> image format?" as that's obviously going to be "No.".  The question is,
> "can we support this format in a clean manner?" and the answer is
> obviously "Yes.".  So please lets keep that in mind with reviewing the
> code as at the end of the day it is more beneficial for this to be
> supported in mainline U-Boot than only supported in the vendor tree.

I agree with this. I would still like to have an open alternative
available though.

-- 
Best regards,
Marek Vasut

[U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Peng Fan]

> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
> container format file
> 
> On Wed, Jun 05, 2019 at 03:24:40PM +0200, Marek Vasut wrote:
> > On 6/5/19 5:03 AM, Peng Fan wrote:
> > [...]
> > >>>>> It is not duplication of FIT. Container support the similar
> > >>>>> function of FIT image, but it is not only that.
> > >>>>
> > >>>> So what is it ?
> > >>>
> > >>>
> > >>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > >>>
> > >>
> nxp.com%2Fdocs%2Fen%2Freference-manual%2FIMX8DQXPRM.pdf&da
> > >> ta=02%7C
> > >>>
> > >>
> 01%7Cpeng.fan%40nxp.com%7C72216052f4234a93ad1f08d6e95ed782%7C6
> > >> 86ea1d3b
> > >>>
> > >>
> c2b4c6fa92cd99c5c301635%7C0%7C1%7C636952990895125305&sdat
> > >> a=KO%2B0e
> > >>>
> > >>
> E3v%2FkHuJ%2BhR7mBgc4NWXxbMUupfubXXu%2BueIWo%3D&reserv
> > >> ed=0
> > >>> Chapter 5 has information about container set and container.
> > >>
> > >> Thanks, any specific part of those 80 pages ?
> > >
> > > Figure 5-24. Container Format has a picture about a single container.
> > > i.MX8 container also support container sets, support encrypt blob,
> > > certificates, SRK management. Support signature to the whole
> > > container, no need single image inside container.
> >
> > Isn't that all supported in fitImage too ?
> 
> This is neither the first nor last time functionality has been essentially
> duplicated, sadly, for reasons.

I'll share the fit things to our ROM stakeholders, but they take decision
on new SoC design.

> 
> > >>>> I don't think I get it. Why would I, as an iMX8 user, want to
> > >>>> pick custom new vendor-specific format over years-proven generic
> fitImage?
> > >>>
> > >>> We not against FIT, we already use FIT on i.MX8M, to let spl to
> > >>> authenticate FIT image using ROM HAB, not using crypto driver.
> > >>
> > >> Great
> > >>
> > >>>> What is the selling point here ?
> > >>>
> > >>> We would not introduce cypto driver in SPL stage, that means HAB
> > >>> FIT and AHAB container needs to be dropped when SPL loading other
> images.
> > >>> ROM already provides API for bootloader to authenticate images,
> > >>> introducing complex crypto driver in SPL could enlarge code size
> > >>> and make things complicated.
> > >>
> > >> Ah I see, so it's all making the whole crypto simpler by offloading
> > >> the hard parts into the firmware, which just magically handles
> > >> everything , without having much extra code in the SPL ?
> > >
> > > Yes. Use what ROM provides will make things easier for U-Boot.
> >
> > Is it possible to perform a security audit on the ROM as easily as on
> > U-Boot ? I mean, U-Boot is free software, the source is available, so
> > security researchers can easily scrutinize it. Is the ROM ?
> 
> So, here's my two cents (and it may or may not seem contradictory with my
> opinions in the secure boot thread going on currently on the Linaro Boot
> Architecture list).  Yes, it would and IMHO is better when we use free and
> open software to solve our problems (and an aside to the RISC-V folks as this
> is yet another area they can make the world a better place in).  But I am a
> believe in dealing with the world as it stands at times too.  The question isn't
> "can we get NXP to re-spin i.MX8 to use the FIT image format?" as that's
> obviously going to be "No.".  The question is, "can we support this format in
> a clean manner?" and the answer is obviously "Yes.".  So please lets keep
> that in mind with reviewing the code as at the end of the day it is more
> beneficial for this to be supported in mainline U-Boot than only supported in
> the vendor tree.

Thanks. So I think you agree the current approach. Could I get any A-b or R-b
tags from the list?

Thanks,
Peng.

> Thanks!
> 
> --
> Tom

[U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Lukasz Majewski]

On Thu, 6 Jun 2019 02:33:14 +0000
Peng Fan <peng.fan@nxp.com> wrote:

> > Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support
> > loading i.MX container format file
> > 
> > On Wed, Jun 05, 2019 at 03:24:40PM +0200, Marek Vasut wrote:  
> > > On 6/5/19 5:03 AM, Peng Fan wrote:
> > > [...]  
> > > >>>>> It is not duplication of FIT. Container support the similar
> > > >>>>> function of FIT image, but it is not only that.  
> > > >>>>
> > > >>>> So what is it ?  
> > > >>>
> > > >>>  
> > > >>  
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.  
> > > >>>  
> > > >>  
> > nxp.com%2Fdocs%2Fen%2Freference-manual%2FIMX8DQXPRM.pdf&amp;da  
> > > >> ta=02%7C  
> > > >>>  
> > > >>  
> > 01%7Cpeng.fan%40nxp.com%7C72216052f4234a93ad1f08d6e95ed782%7C6  
> > > >> 86ea1d3b  
> > > >>>  
> > > >>  
> > c2b4c6fa92cd99c5c301635%7C0%7C1%7C636952990895125305&amp;sdat  
> > > >> a=KO%2B0e  
> > > >>>  
> > > >>  
> > E3v%2FkHuJ%2BhR7mBgc4NWXxbMUupfubXXu%2BueIWo%3D&amp;reserv  
> > > >> ed=0  
> > > >>> Chapter 5 has information about container set and container.  
> > > >>
> > > >> Thanks, any specific part of those 80 pages ?  
> > > >
> > > > Figure 5-24. Container Format has a picture about a single
> > > > container. i.MX8 container also support container sets, support
> > > > encrypt blob, certificates, SRK management. Support signature
> > > > to the whole container, no need single image inside container.  
> > >
> > > Isn't that all supported in fitImage too ?  
> > 
> > This is neither the first nor last time functionality has been
> > essentially duplicated, sadly, for reasons.  
> 
> I'll share the fit things to our ROM stakeholders, but they take
> decision on new SoC design.
> 
> >   
> > > >>>> I don't think I get it. Why would I, as an iMX8 user, want to
> > > >>>> pick custom new vendor-specific format over years-proven
> > > >>>> generic  
> > fitImage?  
> > > >>>
> > > >>> We not against FIT, we already use FIT on i.MX8M, to let spl
> > > >>> to authenticate FIT image using ROM HAB, not using crypto
> > > >>> driver.  
> > > >>
> > > >> Great
> > > >>  
> > > >>>> What is the selling point here ?  
> > > >>>
> > > >>> We would not introduce cypto driver in SPL stage, that means
> > > >>> HAB FIT and AHAB container needs to be dropped when SPL
> > > >>> loading other  
> > images.  
> > > >>> ROM already provides API for bootloader to authenticate
> > > >>> images, introducing complex crypto driver in SPL could
> > > >>> enlarge code size and make things complicated.  
> > > >>
> > > >> Ah I see, so it's all making the whole crypto simpler by
> > > >> offloading the hard parts into the firmware, which just
> > > >> magically handles everything , without having much extra code
> > > >> in the SPL ?  
> > > >
> > > > Yes. Use what ROM provides will make things easier for U-Boot.  
> > >
> > > Is it possible to perform a security audit on the ROM as easily
> > > as on U-Boot ? I mean, U-Boot is free software, the source is
> > > available, so security researchers can easily scrutinize it. Is
> > > the ROM ?  
> > 
> > So, here's my two cents (and it may or may not seem contradictory
> > with my opinions in the secure boot thread going on currently on
> > the Linaro Boot Architecture list).  Yes, it would and IMHO is
> > better when we use free and open software to solve our problems
> > (and an aside to the RISC-V folks as this is yet another area they
> > can make the world a better place in).  But I am a believe in
> > dealing with the world as it stands at times too.  The question
> > isn't "can we get NXP to re-spin i.MX8 to use the FIT image
> > format?" as that's obviously going to be "No.".  The question is,
> > "can we support this format in a clean manner?" and the answer is
> > obviously "Yes.".  So please lets keep that in mind with reviewing
> > the code as at the end of the day it is more beneficial for this to
> > be supported in mainline U-Boot than only supported in the vendor
> > tree.  
> 
> Thanks. So I think you agree the current approach. Could I get any
> A-b or R-b tags from the list?

Just to add my 2 cents...

Please if possible provide a good (and as much verbose as possible)
entry to ./doc/README.imx_image (or something) regarding the i.MX8
format.

Thanks in advance,

> 
> Thanks,
> Peng.
> 
> > Thanks!
> > 
> > --
> > Tom  




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190606/f1e73b6d/attachment.sig>

[U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Marek Vasut]

On 6/6/19 4:33 AM, Peng Fan wrote:
>> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
>> container format file
>>
>> On Wed, Jun 05, 2019 at 03:24:40PM +0200, Marek Vasut wrote:
>>> On 6/5/19 5:03 AM, Peng Fan wrote:
>>> [...]
>>>>>>>> It is not duplication of FIT. Container support the similar
>>>>>>>> function of FIT image, but it is not only that.
>>>>>>>
>>>>>>> So what is it ?
>>>>>>
>>>>>>
>>>>>
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
>>>>>>
>>>>>
>> nxp.com%2Fdocs%2Fen%2Freference-manual%2FIMX8DQXPRM.pdf&da
>>>>> ta=02%7C
>>>>>>
>>>>>
>> 01%7Cpeng.fan%40nxp.com%7C72216052f4234a93ad1f08d6e95ed782%7C6
>>>>> 86ea1d3b
>>>>>>
>>>>>
>> c2b4c6fa92cd99c5c301635%7C0%7C1%7C636952990895125305&sdat
>>>>> a=KO%2B0e
>>>>>>
>>>>>
>> E3v%2FkHuJ%2BhR7mBgc4NWXxbMUupfubXXu%2BueIWo%3D&reserv
>>>>> ed=0
>>>>>> Chapter 5 has information about container set and container.
>>>>>
>>>>> Thanks, any specific part of those 80 pages ?
>>>>
>>>> Figure 5-24. Container Format has a picture about a single container.
>>>> i.MX8 container also support container sets, support encrypt blob,
>>>> certificates, SRK management. Support signature to the whole
>>>> container, no need single image inside container.
>>>
>>> Isn't that all supported in fitImage too ?
>>
>> This is neither the first nor last time functionality has been essentially
>> duplicated, sadly, for reasons.
> 
> I'll share the fit things to our ROM stakeholders, but they take decision
> on new SoC design.
> 
>>
>>>>>>> I don't think I get it. Why would I, as an iMX8 user, want to
>>>>>>> pick custom new vendor-specific format over years-proven generic
>> fitImage?
>>>>>>
>>>>>> We not against FIT, we already use FIT on i.MX8M, to let spl to
>>>>>> authenticate FIT image using ROM HAB, not using crypto driver.
>>>>>
>>>>> Great
>>>>>
>>>>>>> What is the selling point here ?
>>>>>>
>>>>>> We would not introduce cypto driver in SPL stage, that means HAB
>>>>>> FIT and AHAB container needs to be dropped when SPL loading other
>> images.
>>>>>> ROM already provides API for bootloader to authenticate images,
>>>>>> introducing complex crypto driver in SPL could enlarge code size
>>>>>> and make things complicated.
>>>>>
>>>>> Ah I see, so it's all making the whole crypto simpler by offloading
>>>>> the hard parts into the firmware, which just magically handles
>>>>> everything , without having much extra code in the SPL ?
>>>>
>>>> Yes. Use what ROM provides will make things easier for U-Boot.
>>>
>>> Is it possible to perform a security audit on the ROM as easily as on
>>> U-Boot ? I mean, U-Boot is free software, the source is available, so
>>> security researchers can easily scrutinize it. Is the ROM ?
>>
>> So, here's my two cents (and it may or may not seem contradictory with my
>> opinions in the secure boot thread going on currently on the Linaro Boot
>> Architecture list).  Yes, it would and IMHO is better when we use free and
>> open software to solve our problems (and an aside to the RISC-V folks as this
>> is yet another area they can make the world a better place in).  But I am a
>> believe in dealing with the world as it stands at times too.  The question isn't
>> "can we get NXP to re-spin i.MX8 to use the FIT image format?" as that's
>> obviously going to be "No.".  The question is, "can we support this format in
>> a clean manner?" and the answer is obviously "Yes.".  So please lets keep
>> that in mind with reviewing the code as at the end of the day it is more
>> beneficial for this to be supported in mainline U-Boot than only supported in
>> the vendor tree.
> 
> Thanks. So I think you agree the current approach. Could I get any A-b or R-b
> tags from the list?

I would still like an answer to my question about the security auditing
above.

-- 
Best regards,
Marek Vasut

[U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Peng Fan]

> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
> container format file
> 
> On Thu, 6 Jun 2019 02:33:14 +0000
> Peng Fan <peng.fan@nxp.com> wrote:
> 
> > > Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support
> > > loading i.MX container format file
> > >
> > > On Wed, Jun 05, 2019 at 03:24:40PM +0200, Marek Vasut wrote:
> > > > On 6/5/19 5:03 AM, Peng Fan wrote:
> > > > [...]
> > > > >>>>> It is not duplication of FIT. Container support the similar
> > > > >>>>> function of FIT image, but it is not only that.
> > > > >>>>
> > > > >>>> So what is it ?
> > > > >>>
> > > > >>>
> > > > >>
> > >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > > > >>>
> > > > >>
> > >
> nxp.com%2Fdocs%2Fen%2Freference-manual%2FIMX8DQXPRM.pdf&amp;da
> > > > >> ta=02%7C
> > > > >>>
> > > > >>
> > >
> 01%7Cpeng.fan%40nxp.com%7C72216052f4234a93ad1f08d6e95ed782%7C6
> > > > >> 86ea1d3b
> > > > >>>
> > > > >>
> > >
> c2b4c6fa92cd99c5c301635%7C0%7C1%7C636952990895125305&amp;sdat
> > > > >> a=KO%2B0e
> > > > >>>
> > > > >>
> > >
> E3v%2FkHuJ%2BhR7mBgc4NWXxbMUupfubXXu%2BueIWo%3D&amp;reserv
> > > > >> ed=0
> > > > >>> Chapter 5 has information about container set and container.
> > > > >>
> > > > >> Thanks, any specific part of those 80 pages ?
> > > > >
> > > > > Figure 5-24. Container Format has a picture about a single
> > > > > container. i.MX8 container also support container sets, support
> > > > > encrypt blob, certificates, SRK management. Support signature to
> > > > > the whole container, no need single image inside container.
> > > >
> > > > Isn't that all supported in fitImage too ?
> > >
> > > This is neither the first nor last time functionality has been
> > > essentially duplicated, sadly, for reasons.
> >
> > I'll share the fit things to our ROM stakeholders, but they take
> > decision on new SoC design.
> >
> > >
> > > > >>>> I don't think I get it. Why would I, as an iMX8 user, want to
> > > > >>>> pick custom new vendor-specific format over years-proven
> > > > >>>> generic
> > > fitImage?
> > > > >>>
> > > > >>> We not against FIT, we already use FIT on i.MX8M, to let spl
> > > > >>> to authenticate FIT image using ROM HAB, not using crypto
> > > > >>> driver.
> > > > >>
> > > > >> Great
> > > > >>
> > > > >>>> What is the selling point here ?
> > > > >>>
> > > > >>> We would not introduce cypto driver in SPL stage, that means
> > > > >>> HAB FIT and AHAB container needs to be dropped when SPL
> > > > >>> loading other
> > > images.
> > > > >>> ROM already provides API for bootloader to authenticate
> > > > >>> images, introducing complex crypto driver in SPL could enlarge
> > > > >>> code size and make things complicated.
> > > > >>
> > > > >> Ah I see, so it's all making the whole crypto simpler by
> > > > >> offloading the hard parts into the firmware, which just
> > > > >> magically handles everything , without having much extra code
> > > > >> in the SPL ?
> > > > >
> > > > > Yes. Use what ROM provides will make things easier for U-Boot.
> > > >
> > > > Is it possible to perform a security audit on the ROM as easily as
> > > > on U-Boot ? I mean, U-Boot is free software, the source is
> > > > available, so security researchers can easily scrutinize it. Is
> > > > the ROM ?
> > >
> > > So, here's my two cents (and it may or may not seem contradictory
> > > with my opinions in the secure boot thread going on currently on the
> > > Linaro Boot Architecture list).  Yes, it would and IMHO is better
> > > when we use free and open software to solve our problems (and an
> > > aside to the RISC-V folks as this is yet another area they can make
> > > the world a better place in).  But I am a believe in dealing with
> > > the world as it stands at times too.  The question isn't "can we get
> > > NXP to re-spin i.MX8 to use the FIT image format?" as that's
> > > obviously going to be "No.".  The question is, "can we support this
> > > format in a clean manner?" and the answer is obviously "Yes.".  So
> > > please lets keep that in mind with reviewing the code as at the end
> > > of the day it is more beneficial for this to be supported in
> > > mainline U-Boot than only supported in the vendor tree.
> >
> > Thanks. So I think you agree the current approach. Could I get any A-b
> > or R-b tags from the list?
> 
> Just to add my 2 cents...
> 
> Please if possible provide a good (and as much verbose as possible) entry
> to ./doc/README.imx_image (or something) regarding the i.MX8 format.

ok. I'll post out a separate patch for that.

Regards,
Peng.

> 
> Thanks in advance,
> 
> >
> > Thanks,
> > Peng.
> >
> > > Thanks!
> > >
> > > --
> > > Tom
> 
> 
> 
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> lukma at denx.de

[U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Peng Fan]

> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX
> container format file
> 
> On 6/6/19 4:33 AM, Peng Fan wrote:
> >> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading
> >> i.MX container format file
> >>
> >> On Wed, Jun 05, 2019 at 03:24:40PM +0200, Marek Vasut wrote:
> >>> On 6/5/19 5:03 AM, Peng Fan wrote:
> >>> [...]
> >>>>>>>> It is not duplication of FIT. Container support the similar
> >>>>>>>> function of FIT image, but it is not only that.
> >>>>>>>
> >>>>>>> So what is it ?
> >>>>>>
> >>>>>>
> >>>>>
> >>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> >>>>>>
> >>>>>
> >>
> nxp.com%2Fdocs%2Fen%2Freference-manual%2FIMX8DQXPRM.pdf&da
> >>>>> ta=02%7C
> >>>>>>
> >>>>>
> >>
> 01%7Cpeng.fan%40nxp.com%7C72216052f4234a93ad1f08d6e95ed782%7C6
> >>>>> 86ea1d3b
> >>>>>>
> >>>>>
> >>
> c2b4c6fa92cd99c5c301635%7C0%7C1%7C636952990895125305&sdat
> >>>>> a=KO%2B0e
> >>>>>>
> >>>>>
> >>
> E3v%2FkHuJ%2BhR7mBgc4NWXxbMUupfubXXu%2BueIWo%3D&reserv
> >>>>> ed=0
> >>>>>> Chapter 5 has information about container set and container.
> >>>>>
> >>>>> Thanks, any specific part of those 80 pages ?
> >>>>
> >>>> Figure 5-24. Container Format has a picture about a single container.
> >>>> i.MX8 container also support container sets, support encrypt blob,
> >>>> certificates, SRK management. Support signature to the whole
> >>>> container, no need single image inside container.
> >>>
> >>> Isn't that all supported in fitImage too ?
> >>
> >> This is neither the first nor last time functionality has been
> >> essentially duplicated, sadly, for reasons.
> >
> > I'll share the fit things to our ROM stakeholders, but they take
> > decision on new SoC design.
> >
> >>
> >>>>>>> I don't think I get it. Why would I, as an iMX8 user, want to
> >>>>>>> pick custom new vendor-specific format over years-proven generic
> >> fitImage?
> >>>>>>
> >>>>>> We not against FIT, we already use FIT on i.MX8M, to let spl to
> >>>>>> authenticate FIT image using ROM HAB, not using crypto driver.
> >>>>>
> >>>>> Great
> >>>>>
> >>>>>>> What is the selling point here ?
> >>>>>>
> >>>>>> We would not introduce cypto driver in SPL stage, that means HAB
> >>>>>> FIT and AHAB container needs to be dropped when SPL loading other
> >> images.
> >>>>>> ROM already provides API for bootloader to authenticate images,
> >>>>>> introducing complex crypto driver in SPL could enlarge code size
> >>>>>> and make things complicated.
> >>>>>
> >>>>> Ah I see, so it's all making the whole crypto simpler by
> >>>>> offloading the hard parts into the firmware, which just magically
> >>>>> handles everything , without having much extra code in the SPL ?
> >>>>
> >>>> Yes. Use what ROM provides will make things easier for U-Boot.
> >>>
> >>> Is it possible to perform a security audit on the ROM as easily as
> >>> on U-Boot ? I mean, U-Boot is free software, the source is
> >>> available, so security researchers can easily scrutinize it. Is the ROM ?
> >>
> >> So, here's my two cents (and it may or may not seem contradictory
> >> with my opinions in the secure boot thread going on currently on the
> >> Linaro Boot Architecture list).  Yes, it would and IMHO is better
> >> when we use free and open software to solve our problems (and an
> >> aside to the RISC-V folks as this is yet another area they can make
> >> the world a better place in).  But I am a believe in dealing with the
> >> world as it stands at times too.  The question isn't "can we get NXP
> >> to re-spin i.MX8 to use the FIT image format?" as that's obviously
> >> going to be "No.".  The question is, "can we support this format in a
> >> clean manner?" and the answer is obviously "Yes.".  So please lets
> >> keep that in mind with reviewing the code as at the end of the day it
> >> is more beneficial for this to be supported in mainline U-Boot than only
> supported in the vendor tree.
> >
> > Thanks. So I think you agree the current approach. Could I get any A-b
> > or R-b tags from the list?
> 
> I would still like an answer to my question about the security auditing above.

Sorry. Missed your thread. I not work on ROM stuff, but I think answer is
no to public. 

Thanks,
Peng.

> 
> --
> Best regards,
> Marek Vasut

[U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file

[Marek Vasut]

On 6/6/19 9:54 AM, Peng Fan wrote:

[...]

>>>>>>>> We would not introduce cypto driver in SPL stage, that means HAB
>>>>>>>> FIT and AHAB container needs to be dropped when SPL loading other
>>>> images.
>>>>>>>> ROM already provides API for bootloader to authenticate images,
>>>>>>>> introducing complex crypto driver in SPL could enlarge code size
>>>>>>>> and make things complicated.
>>>>>>>
>>>>>>> Ah I see, so it's all making the whole crypto simpler by
>>>>>>> offloading the hard parts into the firmware, which just magically
>>>>>>> handles everything , without having much extra code in the SPL ?
>>>>>>
>>>>>> Yes. Use what ROM provides will make things easier for U-Boot.
>>>>>
>>>>> Is it possible to perform a security audit on the ROM as easily as
>>>>> on U-Boot ? I mean, U-Boot is free software, the source is
>>>>> available, so security researchers can easily scrutinize it. Is the ROM ?
>>>>
>>>> So, here's my two cents (and it may or may not seem contradictory
>>>> with my opinions in the secure boot thread going on currently on the
>>>> Linaro Boot Architecture list).  Yes, it would and IMHO is better
>>>> when we use free and open software to solve our problems (and an
>>>> aside to the RISC-V folks as this is yet another area they can make
>>>> the world a better place in).  But I am a believe in dealing with the
>>>> world as it stands at times too.  The question isn't "can we get NXP
>>>> to re-spin i.MX8 to use the FIT image format?" as that's obviously
>>>> going to be "No.".  The question is, "can we support this format in a
>>>> clean manner?" and the answer is obviously "Yes.".  So please lets
>>>> keep that in mind with reviewing the code as at the end of the day it
>>>> is more beneficial for this to be supported in mainline U-Boot than only
>> supported in the vendor tree.
>>>
>>> Thanks. So I think you agree the current approach. Could I get any A-b
>>> or R-b tags from the list?
>>
>> I would still like an answer to my question about the security auditing above.
> 
> Sorry. Missed your thread. I not work on ROM stuff, but I think answer is
> no to public. 
I see.

-- 
Best regards,
Marek Vasut