[v2 0/6] Add Vendor Authorized Boot (VAB) support

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

[v2 0/6] Add Vendor Authorized Boot (VAB) support

Lim, Elly Siew Chin
This is the 2nd version of patchset to add Vendor Authorized Boot (VAB)
support for Intel Agilex SoC device.

Vendor Authorized Boot is a security feature for authenticating
the images such as U-Boot, ARM trusted Firmware, Linux kernel,
device tree blob and etc loaded from FIT. After those images are
loaded from FIT, the VAB certificate and signature block appended
at the end of each image are sent to Secure Device Manager (SDM)
for authentication. U-Boot will validate the SHA384 of the image
against the SHA384 hash stored in the VAB certificate before
sending the image to SDM for authentication.

Patch status:
Have changes: Patch 1, 2, 5, 6
Other patches unchanged.

Detail changelog can find in commit message.

v1->v2:
--------
Patch 1:
-  Create common macro TARGET_SOCFPGA_SOC64 for Stratix10 and Agilex.
   This is new patch in 2nd version of VAB series. This is code clean up
   without functionality change.

Patch 2:
- Renamed CONFIG_SECURE_VAB_AUTH* to CONFIG_SOCFPGA_SECURE_VAB_AUTH*
- Changes in secure_vab.c
  - Changed to use SZ_1K for 1024
  - Updated comment in secure_vab.c of "... the certificate for T"
  - The code will report error before end of the function if reach
    maximum retry.
  - In board_prep_linux function, only execute linux_qspi_enable
    command if it exists in enviroment variable. It is optional.

Patch 5:
- Move CONFIG_BOOTCOMMAND to defconfig.
   This is new patch in 2nd version of VAB series. This is code clean up
   without functionality change.

Patch 6:
- Renamed CONFIG_SECURE_VAB_AUTH to CONFIG_SOCFPGA_SECURE_VAB_AUTH
- Add CONFIG_BOOTCOMMAND in defconfig

History:
--------
[v1]: https://patchwork.ozlabs.org/project/uboot/cover/20201110070505.26935-1-elly.siew.chin.lim@.../

These patchsets have dependency on:
--------
Enable ARM Trusted Firmware for U-Boot
https://patchwork.ozlabs.org/project/uboot/cover/20201224102113.32972-1-elly.siew.chin.lim@.../

Siew Chin Lim (6):
  arm: socfpga: Move Stratix10 and Agilex to use TARGET_SOCFPGA_SOC64
  arm: socfpga: soc64: Support Vendor Authorized Boot (VAB)
  arm: socfpga: cmd: Support 'vab' command
  arm: socfpga: dts: soc64: Update filename in binman node of FIT image
    with VAB support
  configs: socfpga: soc64: Move CONFIG_BOOTCOMMAND to defconfig
  configs: socfpga: Add defconfig for Agilex with VAB support

 arch/arm/Kconfig                                   |   6 +-
 arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi         |  22 +++
 arch/arm/mach-socfpga/Kconfig                      |  20 +++
 arch/arm/mach-socfpga/Makefile                     |   3 +
 arch/arm/mach-socfpga/include/mach/mailbox_s10.h   |   1 +
 arch/arm/mach-socfpga/include/mach/reset_manager.h |   3 +-
 arch/arm/mach-socfpga/include/mach/secure_vab.h    |  63 +++++++
 .../arm/mach-socfpga/include/mach/system_manager.h |   3 +-
 arch/arm/mach-socfpga/secure_vab.c                 | 193 +++++++++++++++++++++
 arch/arm/mach-socfpga/vab.c                        |  37 ++++
 common/Kconfig.boot                                |   2 +-
 configs/socfpga_agilex_atf_defconfig               |   2 +
 configs/socfpga_agilex_defconfig                   |   2 +
 ..._atf_defconfig => socfpga_agilex_vab_defconfig} |   5 +-
 configs/socfpga_stratix10_atf_defconfig            |   2 +
 configs/socfpga_stratix10_defconfig                |   2 +
 drivers/ddr/altera/Kconfig                         |   6 +-
 drivers/fpga/Kconfig                               |   2 +-
 drivers/sysreset/Kconfig                           |   2 +-
 include/configs/socfpga_soc64_common.h             |   9 +-
 20 files changed, 363 insertions(+), 22 deletions(-)
 create mode 100644 arch/arm/mach-socfpga/include/mach/secure_vab.h
 create mode 100644 arch/arm/mach-socfpga/secure_vab.c
 create mode 100644 arch/arm/mach-socfpga/vab.c
 copy configs/{socfpga_agilex_atf_defconfig => socfpga_agilex_vab_defconfig} (91%)

--
2.13.0

Reply | Threaded
Open this post in threaded view
|

[v2 1/6] arm: socfpga: Move Stratix10 and Agilex to use TARGET_SOCFPGA_SOC64

Lim, Elly Siew Chin
Create common macro TARGET_SOCFPGA_SOC64 for Stratix10 and Agilex.

Signed-off-by: Siew Chin Lim <[hidden email]>

---
v2
---
- This is new patch in 2nd version of VAB series.
  This is code clean up without functional change.
---
 arch/arm/Kconfig                                    | 6 +++---
 arch/arm/mach-socfpga/Kconfig                       | 5 +++++
 arch/arm/mach-socfpga/include/mach/reset_manager.h  | 3 +--
 arch/arm/mach-socfpga/include/mach/system_manager.h | 3 +--
 drivers/ddr/altera/Kconfig                          | 6 +++---
 drivers/fpga/Kconfig                                | 2 +-
 drivers/sysreset/Kconfig                            | 2 +-
 7 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index fbe90875ae..7eea261fe9 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -974,7 +974,7 @@ config ARCH_SOCFPGA
  bool "Altera SOCFPGA family"
  select ARCH_EARLY_INIT_R
  select ARCH_MISC_INIT if !TARGET_SOCFPGA_ARRIA10
- select ARM64 if TARGET_SOCFPGA_STRATIX10 || TARGET_SOCFPGA_AGILEX
+ select ARM64 if TARGET_SOCFPGA_SOC64
  select CPU_V7A if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10
  select DM
  select DM_SERIAL
@@ -986,7 +986,7 @@ config ARCH_SOCFPGA
  select SPL_LIBGENERIC_SUPPORT
  select SPL_NAND_SUPPORT if SPL_NAND_DENALI
  select SPL_OF_CONTROL
- select SPL_SEPARATE_BSS if TARGET_SOCFPGA_STRATIX10 || TARGET_SOCFPGA_AGILEX
+ select SPL_SEPARATE_BSS if TARGET_SOCFPGA_SOC64
  select SPL_SERIAL_SUPPORT
  select SPL_SYSRESET
  select SPL_WATCHDOG_SUPPORT
@@ -995,7 +995,7 @@ config ARCH_SOCFPGA
  select SYS_THUMB_BUILD if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10
  select SYSRESET
  select SYSRESET_SOCFPGA if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10
- select SYSRESET_SOCFPGA_SOC64 if TARGET_SOCFPGA_STRATIX10 || TARGET_SOCFPGA_AGILEX
+ select SYSRESET_SOCFPGA_SOC64 if TARGET_SOCFPGA_SOC64
  imply CMD_DM
  imply CMD_MTDPARTS
  imply CRC32_VERIFY
diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index 4d4ff16337..9b1abdaabd 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -38,6 +38,7 @@ config TARGET_SOCFPGA_AGILEX
  select FPGA_INTEL_SDM_MAILBOX
  select NCORE_CACHE
  select SPL_CLK if SPL
+ select TARGET_SOCFPGA_SOC64
 
 config TARGET_SOCFPGA_ARRIA5
  bool
@@ -75,12 +76,16 @@ config TARGET_SOCFPGA_GEN5
  imply SPL_SYS_MALLOC_SIMPLE
  imply SPL_USE_TINY_PRINTF
 
+config TARGET_SOCFPGA_SOC64
+ bool
+
 config TARGET_SOCFPGA_STRATIX10
  bool
  select ARMV8_MULTIENTRY
  select ARMV8_SET_SMPEN
  select BINMAN if SPL_ATF
  select FPGA_INTEL_SDM_MAILBOX
+ select TARGET_SOCFPGA_SOC64
 
 choice
  prompt "Altera SOCFPGA board select"
diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager.h b/arch/arm/mach-socfpga/include/mach/reset_manager.h
index 7844ad14cb..8c25325e45 100644
--- a/arch/arm/mach-socfpga/include/mach/reset_manager.h
+++ b/arch/arm/mach-socfpga/include/mach/reset_manager.h
@@ -43,8 +43,7 @@ void socfpga_per_reset_all(void);
 #include <asm/arch/reset_manager_gen5.h>
 #elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
 #include <asm/arch/reset_manager_arria10.h>
-#elif defined(CONFIG_TARGET_SOCFPGA_STRATIX10) || \
- defined(CONFIG_TARGET_SOCFPGA_AGILEX)
+#elif defined(CONFIG_TARGET_SOCFPGA_SOC64)
 #include <asm/arch/reset_manager_soc64.h>
 #endif
 
diff --git a/arch/arm/mach-socfpga/include/mach/system_manager.h b/arch/arm/mach-socfpga/include/mach/system_manager.h
index f816954717..5603eaa3d0 100644
--- a/arch/arm/mach-socfpga/include/mach/system_manager.h
+++ b/arch/arm/mach-socfpga/include/mach/system_manager.h
@@ -8,8 +8,7 @@
 
 phys_addr_t socfpga_get_sysmgr_addr(void);
 
-#if defined(CONFIG_TARGET_SOCFPGA_STRATIX10) || \
- defined(CONFIG_TARGET_SOCFPGA_AGILEX)
+#if defined(CONFIG_TARGET_SOCFPGA_SOC64)
 #include <asm/arch/system_manager_soc64.h>
 #else
 #define SYSMGR_ROMCODEGRP_CTRL_WARMRSTCFGPINMUX BIT(0)
diff --git a/drivers/ddr/altera/Kconfig b/drivers/ddr/altera/Kconfig
index 8f590dc5f6..4660d20def 100644
--- a/drivers/ddr/altera/Kconfig
+++ b/drivers/ddr/altera/Kconfig
@@ -1,8 +1,8 @@
 config SPL_ALTERA_SDRAM
  bool "SoCFPGA DDR SDRAM driver in SPL"
  depends on SPL
- depends on TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10 || TARGET_SOCFPGA_STRATIX10 || TARGET_SOCFPGA_AGILEX
- select RAM if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_STRATIX10 || TARGET_SOCFPGA_AGILEX
- select SPL_RAM if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_STRATIX10 || TARGET_SOCFPGA_AGILEX
+ depends on TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10 || TARGET_SOCFPGA_SOC64
+ select RAM if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_SOC64
+ select SPL_RAM if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_SOC64
  help
   Enable DDR SDRAM controller for the SoCFPGA devices.
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 425b52a926..dc0b3dd31b 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -33,7 +33,7 @@ config FPGA_CYCLON2
 
 config FPGA_INTEL_SDM_MAILBOX
  bool "Enable Intel FPGA Full Reconfiguration SDM Mailbox driver"
- depends on TARGET_SOCFPGA_STRATIX10 || TARGET_SOCFPGA_AGILEX
+ depends on TARGET_SOCFPGA_SOC64
  select FPGA_ALTERA
  help
   Say Y here to enable the Intel FPGA Full Reconfig SDM Mailbox driver
diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
index 0e5c7c9971..52f874317b 100644
--- a/drivers/sysreset/Kconfig
+++ b/drivers/sysreset/Kconfig
@@ -88,7 +88,7 @@ config SYSRESET_SOCFPGA
 
 config SYSRESET_SOCFPGA_SOC64
  bool "Enable support for Intel SOCFPGA SoC64 family (Stratix10/Agilex)"
- depends on ARCH_SOCFPGA && (TARGET_SOCFPGA_STRATIX10 || TARGET_SOCFPGA_AGILEX)
+ depends on ARCH_SOCFPGA && TARGET_SOCFPGA_SOC64
  help
   This enables the system reset driver support for Intel SOCFPGA
   SoC64 SoCs.
--
2.13.0

Reply | Threaded
Open this post in threaded view
|

[v2 2/6] arm: socfpga: soc64: Support Vendor Authorized Boot (VAB)

Lim, Elly Siew Chin
In reply to this post by Lim, Elly Siew Chin
Vendor Authorized Boot is a security feature for authenticating
the images such as U-Boot, ARM trusted Firmware, Linux kernel,
device tree blob and etc loaded from FIT. After those images are
loaded from FIT, the VAB certificate and signature block appended
at the end of each image are sent to Secure Device Manager (SDM)
for authentication. U-Boot will validate the SHA384 of the image
against the SHA384 hash stored in the VAB certificate before
sending the image to SDM for authentication.

Signed-off-by: Siew Chin Lim <[hidden email]>

---
v2
---
- Renamed SECURE_VAB_AUTH* to SOCFPGA_SECURE_VAB_AUTH*
- Changes in secure_vab.c
  - Changed to use SZ_1K for 1024
  - Updated comment in secure_vab.c of "... the certificate for T"
  - The code will report error before end of the function if reach
    maximum retry.
  - In board_prep_linux function, only execute linux_qspi_enable
    command if it exists in enviroment variable. It is optional.
---
 arch/arm/mach-socfpga/Kconfig                    |  15 ++
 arch/arm/mach-socfpga/Makefile                   |   2 +
 arch/arm/mach-socfpga/include/mach/mailbox_s10.h |   1 +
 arch/arm/mach-socfpga/include/mach/secure_vab.h  |  63 ++++++++
 arch/arm/mach-socfpga/secure_vab.c               | 193 +++++++++++++++++++++++
 common/Kconfig.boot                              |   2 +-
 6 files changed, 275 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-socfpga/include/mach/secure_vab.h
 create mode 100644 arch/arm/mach-socfpga/secure_vab.c

diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index 9b1abdaabd..0c35406232 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -6,6 +6,21 @@ config ERR_PTR_OFFSET
 config NR_DRAM_BANKS
  default 1
 
+config SOCFPGA_SECURE_VAB_AUTH
+ bool "Enable boot image authentication with Secure Device Manager"
+ depends on TARGET_SOCFPGA_AGILEX
+ select FIT_IMAGE_POST_PROCESS
+ select SHA384
+ select SHA512_ALGO
+ select SPL_FIT_IMAGE_POST_PROCESS
+ help
+ All images loaded from FIT will be authenticated by Secure Device
+ Manager.
+
+config SOCFPGA_SECURE_VAB_AUTH_ALLOW_NON_FIT_IMAGE
+ bool "Allow non-FIT VAB signed images"
+ depends on SOCFPGA_SECURE_VAB_AUTH
+
 config SPL_SIZE_LIMIT
  default 0x10000 if TARGET_SOCFPGA_GEN5
 
diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index 82b681d870..1f1e21766d 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -4,6 +4,7 @@
 # Wolfgang Denk, DENX Software Engineering, [hidden email].
 #
 # Copyright (C) 2012-2017 Altera Corporation <www.altera.com>
+# Copyright (C) 2017-2020 Intel Corporation <www.intel.com>
 
 obj-y += board.o
 obj-y += clock_manager.o
@@ -47,6 +48,7 @@ obj-y += mailbox_s10.o
 obj-y += misc_s10.o
 obj-y += mmu-arm64_s10.o
 obj-y += reset_manager_s10.o
+obj-$(CONFIG_SOCFPGA_SECURE_VAB_AUTH) += secure_vab.o
 obj-y += system_manager_s10.o
 obj-y += timer_s10.o
 obj-y += wrap_pinmux_config_s10.o
diff --git a/arch/arm/mach-socfpga/include/mach/mailbox_s10.h b/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
index 4d783119ea..fbaf11597e 100644
--- a/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
+++ b/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
@@ -118,6 +118,7 @@ enum ALT_SDM_MBOX_RESP_CODE {
 #define MBOX_RECONFIG_MSEL 7
 #define MBOX_RECONFIG_DATA 8
 #define MBOX_RECONFIG_STATUS 9
+#define MBOX_VAB_SRC_CERT 11
 #define MBOX_QSPI_OPEN 50
 #define MBOX_QSPI_CLOSE 51
 #define MBOX_QSPI_DIRECT 59
diff --git a/arch/arm/mach-socfpga/include/mach/secure_vab.h b/arch/arm/mach-socfpga/include/mach/secure_vab.h
new file mode 100644
index 0000000000..42588588e8
--- /dev/null
+++ b/arch/arm/mach-socfpga/include/mach/secure_vab.h
@@ -0,0 +1,63 @@
+/* SPDX-License-Identifier: GPL-2.0
+ *
+ * Copyright (C) 2020 Intel Corporation <www.intel.com>
+ *
+ */
+
+#ifndef _SECURE_VAB_H_
+#define _SECURE_VAB_H_
+
+#include <linux/sizes.h>
+#include <linux/stddef.h>
+#include <u-boot/sha512.h>
+
+#define VAB_DATA_SZ 64
+
+#define SDM_CERT_MAGIC_NUM 0x25D04E7F
+#define FCS_HPS_VAB_MAGIC_NUM 0xD0564142
+
+#define MAX_CERT_SIZE (SZ_4K)
+
+/*
+ * struct fcs_hps_vab_certificate_data
+ * @vab_cert_magic_num: VAB Certificate Magic Word (0xD0564142)
+ * @flags: TBD
+ * @fcs_data: Data words being certificate signed.
+ * @cert_sign_keychain: Certificate Signing Keychain
+ */
+struct fcs_hps_vab_certificate_data {
+ u32 vab_cert_magic_num; /* offset 0x10 */
+ u32 flags;
+ u8 rsvd0_1[8];
+ u8 fcs_sha384[SHA384_SUM_LEN]; /* offset 0x20 */
+};
+
+/*
+ * struct fcs_hps_vab_certificate_header
+ * @cert_magic_num: Certificate Magic Word (0x25D04E7F)
+ * @cert_data_sz: size of this certificate header (0x80)
+ * Includes magic number all the way to the certificate
+ *      signing keychain (excludes cert. signing keychain)
+ * @cert_ver: Certificate Version
+ * @cert_type: Certificate Type
+ * @data: VAB HPS Image Certificate data
+ */
+struct fcs_hps_vab_certificate_header {
+ u32 cert_magic_num; /* offset 0 */
+ u32 cert_data_sz;
+ u32 cert_ver;
+ u32 cert_type;
+ struct fcs_hps_vab_certificate_data d; /* offset 0x10 */
+ /* keychain starts at offset 0x50 */
+};
+
+#define VAB_CERT_HEADER_SIZE sizeof(struct fcs_hps_vab_certificate_header)
+#define VAB_CERT_MAGIC_OFFSET offsetof \
+ (struct fcs_hps_vab_certificate_header, d)
+#define VAB_CERT_FIT_SHA384_OFFSET offsetof \
+ (struct fcs_hps_vab_certificate_data, \
+ fcs_sha384[0])
+
+int socfpga_vendor_authentication(void **p_image, size_t *p_size);
+
+#endif /* _SECURE_VAB_H_ */
diff --git a/arch/arm/mach-socfpga/secure_vab.c b/arch/arm/mach-socfpga/secure_vab.c
new file mode 100644
index 0000000000..ea1109611a
--- /dev/null
+++ b/arch/arm/mach-socfpga/secure_vab.c
@@ -0,0 +1,193 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Intel Corporation <www.intel.com>
+ *
+ */
+
+#include <common.h>
+#include <asm/arch/mailbox_s10.h>
+#include <asm/arch/secure_vab.h>
+#include <asm/arch/smc_api.h>
+#include <asm/unaligned.h>
+#include <exports.h>
+#include <hang.h>
+#include <image.h>
+#include <linux/errno.h>
+#include <linux/intel-smc.h>
+#include <log.h>
+
+#define CHUNKSZ_PER_WD_RESET (256 * SZ_1K)
+
+/*
+ * Read the length of the VAB certificate from the end of image
+ * and calculate the actual image size (excluding the VAB certificate).
+ */
+static size_t get_img_size(u8 *img_buf, size_t img_buf_sz)
+{
+ u8 *img_buf_end = img_buf + img_buf_sz;
+ u32 cert_sz = get_unaligned_le32(img_buf_end - sizeof(u32));
+ u8 *p = img_buf_end - cert_sz - sizeof(u32);
+
+ /* Ensure p is pointing within the img_buf */
+ if (p < img_buf || p > (img_buf_end - VAB_CERT_HEADER_SIZE))
+ return 0;
+
+ if (get_unaligned_le32(p) == SDM_CERT_MAGIC_NUM)
+ return (size_t)(p - img_buf);
+
+ return 0;
+}
+
+int socfpga_vendor_authentication(void **p_image, size_t *p_size)
+{
+ int retry_count = 20;
+ u8 hash384[SHA384_SUM_LEN];
+ u64 img_addr, mbox_data_addr;
+ size_t img_sz, mbox_data_sz;
+ u8 *cert_hash_ptr;
+ u32 backup_word;
+ u32 resp = 0, resp_len = 1;
+ int ret;
+
+ img_addr = (uintptr_t)*p_image;
+
+ debug("Authenticating image at address 0x%016llx (%ld bytes)\n",
+      img_addr, *p_size);
+
+ img_sz = get_img_size((u8 *)img_addr, *p_size);
+ debug("img_sz = %ld\n", img_sz);
+
+ if (!img_sz) {
+ puts("VAB certificate not found in image!\n");
+ return -ENOKEY;
+ }
+
+ if (!IS_ALIGNED(img_sz, sizeof(u32))) {
+ printf("Image size (%ld bytes) not aliged to 4 bytes!\n",
+       img_sz);
+ return -EBFONT;
+ }
+
+ /* Generate HASH384 from the image */
+ sha384_csum_wd((u8 *)img_addr, img_sz, hash384, CHUNKSZ_PER_WD_RESET);
+
+ cert_hash_ptr = (u8 *)(img_addr + img_sz + VAB_CERT_MAGIC_OFFSET +
+       VAB_CERT_FIT_SHA384_OFFSET);
+
+ /*
+ * Compare the SHA384 found in certificate against the SHA384
+ * calculated from image
+ */
+ if (memcmp(hash384, cert_hash_ptr, SHA384_SUM_LEN)) {
+ puts("SHA384 not match!\n");
+ return -EKEYREJECTED;
+ }
+
+ mbox_data_addr = img_addr + img_sz - sizeof(u32);
+ /* Size in word (32bits) */
+ mbox_data_sz = (ALIGN(*p_size - img_sz, 4)) >> 2;
+
+ debug("mbox_data_addr = 0x%016llx\n", mbox_data_addr);
+ debug("mbox_data_sz = %ld\n", mbox_data_sz);
+
+ /*
+ * Backup the 4 bytes before the certificate.
+ * We need to temporary overwrite the 4 bytes before
+ * send it as mailbox command to SDM. And,
+ * we will restore the 4 bytes after execute the
+ * mailbox command.
+ */
+ backup_word = *(u32 *)mbox_data_addr;
+ *(u32 *)mbox_data_addr = 0;
+
+ do {
+#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ATF)
+ /* Invoke SMC call to ATF to send the VAB certificate to SDM */
+ ret  = smc_send_mailbox(MBOX_VAB_SRC_CERT, mbox_data_sz,
+ (u32 *)mbox_data_addr, 0, &resp_len,
+ &resp);
+#else
+ /* Send the VAB certficate to SDM for authentication */
+ ret = mbox_send_cmd(MBOX_ID_UBOOT, MBOX_VAB_SRC_CERT,
+    MBOX_CMD_DIRECT, mbox_data_sz,
+    (u32 *)mbox_data_addr, 0, &resp_len,
+    &resp);
+#endif
+ /* If SDM is not available, just delay 50ms and retry again */
+ if (ret == MBOX_RESP_DEVICE_BUSY)
+ mdelay(50);
+ else
+ break;
+ } while (--retry_count);
+
+ /* Restore the original 4 bytes */
+ *(u32 *)mbox_data_addr = backup_word;
+
+ /* Exclude the size of the VAB certificate from image size */
+ *p_size = img_sz;
+
+ debug("ret = 0x%08x, resp = 0x%08x, resp_len = %d\n", ret, resp,
+      resp_len);
+
+ if (ret) {
+ /*
+ * Unsupported mailbox command or device not in the
+ * owned/secure state
+ */
+ if (ret == MBOX_RESP_UNKNOWN ||
+    ret == MBOX_RESP_NOT_ALLOWED_UNDER_SECURITY_SETTINGS) {
+ /* SDM bypass authentication */
+ printf("%s 0x%016llx (%ld bytes)\n",
+       "Image Authentication bypassed at address",
+       img_addr, img_sz);
+ return 0;
+ }
+ puts("VAB certificate authentication failed in SDM");
+ if (ret == MBOX_RESP_DEVICE_BUSY) {
+ puts("(SDM busy timeout)\n");
+ return -ETIMEDOUT;
+ }
+ puts("\n");
+ return -EKEYREJECTED;
+ } else {
+ /* If Certificate Process Status has error */
+ if (resp) {
+ puts("VAB certificate process failed\n");
+ return -ENOEXEC;
+ }
+ }
+
+ debug("Image Authentication passed\n");
+
+ return 0;
+}
+
+void board_fit_image_post_process(void **p_image, size_t *p_size)
+{
+ if (socfpga_vendor_authentication(p_image, p_size))
+ hang();
+}
+
+#ifndef CONFIG_SPL_BUILD
+void board_prep_linux(bootm_headers_t *images)
+{
+#ifndef CONFIG_SECURE_VAB_AUTH_ALLOW_NON_FIT_IMAGE
+ /*
+ * Ensure the OS is always booted from FIT and with
+ * VAB signed certificate
+ */
+ if (!images->fit_uname_cfg) {
+ printf("Please use FIT with VAB signed images!\n");
+ hang();
+ }
+
+ env_set_hex("fdt_addr", (ulong)images->ft_addr);
+ debug("images->ft_addr = 0x%08lx\n", (ulong)images->ft_addr);
+#endif
+
+#ifdef CONFIG_CADENCE_QSPI
+ if (env_get("linux_qspi_enable"))
+ run_command(env_get("linux_qspi_enable"), 0);
+#endif
+}
+#endif
diff --git a/common/Kconfig.boot b/common/Kconfig.boot
index 3f6d9c1a25..5ad44676ea 100644
--- a/common/Kconfig.boot
+++ b/common/Kconfig.boot
@@ -128,7 +128,7 @@ config FIT_BEST_MATCH
 
 config FIT_IMAGE_POST_PROCESS
  bool "Enable post-processing of FIT artifacts after loading by U-Boot"
- depends on TI_SECURE_DEVICE
+ depends on TI_SECURE_DEVICE || SOCFPGA_SECURE_VAB_AUTH
  help
   Allows doing any sort of manipulation to blobs after they got extracted
   from FIT images like stripping off headers or modifying the size of the
--
2.13.0

Reply | Threaded
Open this post in threaded view
|

[v2 3/6] arm: socfpga: cmd: Support 'vab' command

Lim, Elly Siew Chin
In reply to this post by Lim, Elly Siew Chin
Support 'vab' command to perform vendor authentication.

Command format: vab addr len
Authorize 'len' bytes starting at 'addr' via vendor public key

Signed-off-by: Siew Chin Lim <[hidden email]>
---
 arch/arm/mach-socfpga/Makefile |  1 +
 arch/arm/mach-socfpga/vab.c    | 37 +++++++++++++++++++++++++++++++++++++
 2 files changed, 38 insertions(+)
 create mode 100644 arch/arm/mach-socfpga/vab.c

diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index 1f1e21766d..9e63296b38 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -51,6 +51,7 @@ obj-y += reset_manager_s10.o
 obj-$(CONFIG_SOCFPGA_SECURE_VAB_AUTH) += secure_vab.o
 obj-y += system_manager_s10.o
 obj-y += timer_s10.o
+obj-$(CONFIG_SOCFPGA_SECURE_VAB_AUTH) += vab.o
 obj-y += wrap_pinmux_config_s10.o
 obj-y += wrap_pll_config_s10.o
 endif
diff --git a/arch/arm/mach-socfpga/vab.c b/arch/arm/mach-socfpga/vab.c
new file mode 100644
index 0000000000..4c592a87cf
--- /dev/null
+++ b/arch/arm/mach-socfpga/vab.c
@@ -0,0 +1,37 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Intel Corporation <www.intel.com>
+ *
+ */
+
+#include <asm/arch/secure_vab.h>
+#include <command.h>
+#include <common.h>
+#include <linux/ctype.h>
+
+static int do_vab(struct cmd_tbl *cmdtp, int flag, int argc,
+  char *const argv[])
+{
+ unsigned long addr, len;
+
+ if (argc < 3)
+ return CMD_RET_USAGE;
+
+ addr = simple_strtoul(argv[1], NULL, 16);
+ len = simple_strtoul(argv[2], NULL, 16);
+
+ if (socfpga_vendor_authentication((void *)&addr, (size_t *)&len) == 0)
+ printf("%s 0x%016lx (%ld bytes)\n",
+       "Image Authentication passed at address", addr, len);
+ else
+ return CMD_RET_FAILURE;
+
+ return 0;
+}
+
+U_BOOT_CMD(
+ vab, 3, 2, do_vab,
+ "perform vendor authorization",
+ "addr len   - authorize 'len' bytes starting at\n"
+ "                 'addr' via vendor public key"
+);
--
2.13.0

Reply | Threaded
Open this post in threaded view
|

[v2 4/6] arm: socfpga: dts: soc64: Update filename in binman node of FIT image with VAB support

Lim, Elly Siew Chin
In reply to this post by Lim, Elly Siew Chin
FIT image of Vendor Authentication Coot (VAB) contains signed images.

Signed-off-by: Siew Chin Lim <[hidden email]>
---
 arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi b/arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi
index cf365590a8..4b30473743 100644
--- a/arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi
+++ b/arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi
@@ -117,4 +117,26 @@
  };
 };
 
+#if defined(CONFIG_SOCFPGA_SECURE_VAB_AUTH)
+&uboot_blob {
+ filename = "signed-u-boot-nodtb.bin";
+};
+
+&atf_blob {
+ filename = "signed-bl31.bin";
+};
+
+&uboot_fdt_blob {
+ filename = "signed-u-boot.dtb";
+};
+
+&kernel_blob {
+ filename = "signed-Image";
+};
+
+&kernel_fdt_blob {
+ filename = "signed-linux.dtb";
+};
+#endif
+
 #endif
--
2.13.0

Reply | Threaded
Open this post in threaded view
|

[v2 5/6] configs: socfpga: soc64: Move CONFIG_BOOTCOMMAND to defconfig

Lim, Elly Siew Chin
In reply to this post by Lim, Elly Siew Chin
CONFIG_BOOTCOMMAND have been moved to Kconfig.boot. This patch
move the CONFIG_BOOTCOMMAND macro from socfpga_soc64_common.h to
*_defconfig file for both Stratix 10 and Agilex.

Signed-off-by: Siew Chin Lim <[hidden email]>

---
v2
---
- This is new patch in 2nd version of VAB series.
  This is code clean up without functionality change.
---
 configs/socfpga_agilex_atf_defconfig    | 2 ++
 configs/socfpga_agilex_defconfig        | 2 ++
 configs/socfpga_stratix10_atf_defconfig | 2 ++
 configs/socfpga_stratix10_defconfig     | 2 ++
 include/configs/socfpga_soc64_common.h  | 9 +--------
 5 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/configs/socfpga_agilex_atf_defconfig b/configs/socfpga_agilex_atf_defconfig
index ad87a8098f..704a9d56b9 100644
--- a/configs/socfpga_agilex_atf_defconfig
+++ b/configs/socfpga_agilex_atf_defconfig
@@ -19,6 +19,8 @@ CONFIG_SPL_LOAD_FIT_ADDRESS=0x02000000
 CONFIG_BOOTDELAY=5
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="earlycon"
+CONFIG_USE_BOOTCOMMAND=y
+CONFIG_BOOTCOMMAND="run fatscript; run mmcfitload; run linux_qspi_enable; run mmcfitboot"
 CONFIG_SPL_CACHE=y
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_SYS_SPI_U_BOOT_OFFS=0x02000000
diff --git a/configs/socfpga_agilex_defconfig b/configs/socfpga_agilex_defconfig
index 230d3c2ce5..3d5d39fe0f 100644
--- a/configs/socfpga_agilex_defconfig
+++ b/configs/socfpga_agilex_defconfig
@@ -18,6 +18,8 @@ CONFIG_DEFAULT_DEVICE_TREE="socfpga_agilex_socdk"
 CONFIG_BOOTDELAY=5
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="earlycon"
+CONFIG_USE_BOOTCOMMAND=y
+CONFIG_BOOTCOMMAND="run fatscript; run mmcload; run linux_qspi_enable; run mmcboot"
 CONFIG_SPL_CACHE=y
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_HUSH_PARSER=y
diff --git a/configs/socfpga_stratix10_atf_defconfig b/configs/socfpga_stratix10_atf_defconfig
index 1005ba979e..344277a6cc 100644
--- a/configs/socfpga_stratix10_atf_defconfig
+++ b/configs/socfpga_stratix10_atf_defconfig
@@ -19,6 +19,8 @@ CONFIG_SPL_LOAD_FIT_ADDRESS=0x02000000
 CONFIG_BOOTDELAY=5
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="earlycon"
+CONFIG_USE_BOOTCOMMAND=y
+CONFIG_BOOTCOMMAND="run fatscript; run mmcfitload; run linux_qspi_enable; run mmcfitboot"
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_SYS_SPI_U_BOOT_OFFS=0x02000000
 CONFIG_SPL_ATF=y
diff --git a/configs/socfpga_stratix10_defconfig b/configs/socfpga_stratix10_defconfig
index 3df44bb88d..2d145e1a5f 100644
--- a/configs/socfpga_stratix10_defconfig
+++ b/configs/socfpga_stratix10_defconfig
@@ -20,6 +20,8 @@ CONFIG_SPL_OPTIMIZE_INLINING=y
 CONFIG_BOOTDELAY=5
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="earlycon"
+CONFIG_USE_BOOTCOMMAND=y
+CONFIG_BOOTCOMMAND="run fatscript; run mmcload; run linux_qspi_enable; run mmcboot"
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="SOCFPGA_STRATIX10 # "
diff --git a/include/configs/socfpga_soc64_common.h b/include/configs/socfpga_soc64_common.h
index fdcd7d3e9a..35200833f1 100644
--- a/include/configs/socfpga_soc64_common.h
+++ b/include/configs/socfpga_soc64_common.h
@@ -79,19 +79,12 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
 #endif /* CONFIG_CADENCE_QSPI */
 
 /*
- * Boot arguments passed to the boot command. The value of
- * CONFIG_BOOTARGS goes into the environment value "bootargs".
- * Do note the value will override also the chosen node in FDT blob.
+ * Enviroment variable
  */
-
 #ifdef CONFIG_FIT
 #define CONFIG_BOOTFILE "kernel.itb"
-#define CONFIG_BOOTCOMMAND "run fatscript; run mmcfitload;run linux_qspi_enable;" \
-   "run mmcfitboot"
 #else
 #define CONFIG_BOOTFILE "Image"
-#define CONFIG_BOOTCOMMAND "run fatscript; run mmcload;run linux_qspi_enable;" \
-   "run mmcboot"
 #endif
 
 #define CONFIG_EXTRA_ENV_SETTINGS \
--
2.13.0

Reply | Threaded
Open this post in threaded view
|

[v2 6/6] configs: socfpga: Add defconfig for Agilex with VAB support

Lim, Elly Siew Chin
In reply to this post by Lim, Elly Siew Chin
Booting Agilex with Vendor Authorized Boot.

Signed-off-by: Siew Chin Lim <[hidden email]>

---
v2
---
- Renamed CONFIG_SECURE_VAB_AUTH to CONFIG_SOCFPGA_SECURE_VAB_AUTH
- Add BOOTCOMMAND macro in defconfig
---
 .../{socfpga_agilex_atf_defconfig => socfpga_agilex_vab_defconfig}   | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
 copy configs/{socfpga_agilex_atf_defconfig => socfpga_agilex_vab_defconfig} (92%)

diff --git a/configs/socfpga_agilex_atf_defconfig b/configs/socfpga_agilex_vab_defconfig
similarity index 92%
copy from configs/socfpga_agilex_atf_defconfig
copy to configs/socfpga_agilex_vab_defconfig
index 704a9d56b9..1e28efea5e 100644
--- a/configs/socfpga_agilex_atf_defconfig
+++ b/configs/socfpga_agilex_vab_defconfig
@@ -1,5 +1,4 @@
 CONFIG_ARM=y
-CONFIG_ARM_SMCCC=y
 CONFIG_SPL_LDSCRIPT="arch/arm/mach-socfpga/u-boot-spl-soc64.lds"
 CONFIG_ARCH_SOCFPGA=y
 CONFIG_SYS_TEXT_BASE=0x200000
@@ -8,6 +7,7 @@ CONFIG_ENV_SIZE=0x1000
 CONFIG_ENV_OFFSET=0x200
 CONFIG_DM_GPIO=y
 CONFIG_NR_DRAM_BANKS=2
+CONFIG_SOCFPGA_SECURE_VAB_AUTH=y
 CONFIG_TARGET_SOCFPGA_AGILEX_SOCDK=y
 CONFIG_IDENT_STRING="socfpga_agilex"
 CONFIG_SPL_FS_FAT=y
@@ -15,12 +15,13 @@ CONFIG_SPL_TEXT_BASE=0xFFE00000
 CONFIG_FIT=y
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_SPL_LOAD_FIT_ADDRESS=0x02000000
+# CONFIG_LEGACY_IMAGE_FORMAT is not set
 # CONFIG_USE_SPL_FIT_GENERATOR is not set
 CONFIG_BOOTDELAY=5
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="earlycon"
 CONFIG_USE_BOOTCOMMAND=y
-CONFIG_BOOTCOMMAND="run fatscript; run mmcfitload; run linux_qspi_enable; run mmcfitboot"
+CONFIG_BOOTCOMMAND="run fatscript; run mmcfitload; run mmcfitboot"
 CONFIG_SPL_CACHE=y
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_SYS_SPI_U_BOOT_OFFS=0x02000000
--
2.13.0

Reply | Threaded
Open this post in threaded view
|

Re: [v2 2/6] arm: socfpga: soc64: Support Vendor Authorized Boot (VAB)

Simon Glass-3
In reply to this post by Lim, Elly Siew Chin
On Thu, 7 Jan 2021 at 03:03, Siew Chin Lim <[hidden email]> wrote:

>
> Vendor Authorized Boot is a security feature for authenticating
> the images such as U-Boot, ARM trusted Firmware, Linux kernel,
> device tree blob and etc loaded from FIT. After those images are
> loaded from FIT, the VAB certificate and signature block appended
> at the end of each image are sent to Secure Device Manager (SDM)
> for authentication. U-Boot will validate the SHA384 of the image
> against the SHA384 hash stored in the VAB certificate before
> sending the image to SDM for authentication.
>
> Signed-off-by: Siew Chin Lim <[hidden email]>
>
> ---
> v2
> ---
> - Renamed SECURE_VAB_AUTH* to SOCFPGA_SECURE_VAB_AUTH*
> - Changes in secure_vab.c
>   - Changed to use SZ_1K for 1024
>   - Updated comment in secure_vab.c of "... the certificate for T"
>   - The code will report error before end of the function if reach
>     maximum retry.
>   - In board_prep_linux function, only execute linux_qspi_enable
>     command if it exists in enviroment variable. It is optional.
> ---
>  arch/arm/mach-socfpga/Kconfig                    |  15 ++
>  arch/arm/mach-socfpga/Makefile                   |   2 +
>  arch/arm/mach-socfpga/include/mach/mailbox_s10.h |   1 +
>  arch/arm/mach-socfpga/include/mach/secure_vab.h  |  63 ++++++++
>  arch/arm/mach-socfpga/secure_vab.c               | 193 +++++++++++++++++++++++
>  common/Kconfig.boot                              |   2 +-
>  6 files changed, 275 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/mach-socfpga/include/mach/secure_vab.h
>  create mode 100644 arch/arm/mach-socfpga/secure_vab.c

I think this could use a few more function comments. Also try to use
if() instead of #if

Regards,
Simon
Reply | Threaded
Open this post in threaded view
|

Re: [v2 4/6] arm: socfpga: dts: soc64: Update filename in binman node of FIT image with VAB support

Simon Glass-3
In reply to this post by Lim, Elly Siew Chin
On Thu, 7 Jan 2021 at 03:03, Siew Chin Lim <[hidden email]> wrote:
>
> FIT image of Vendor Authentication Coot (VAB) contains signed images.
>
> Signed-off-by: Siew Chin Lim <[hidden email]>
> ---
>  arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
>

I'm not quite sure what is happening here, but consider using two
separate files rather than what looks like a patch over an existing
one.



> diff --git a/arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi b/arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi
> index cf365590a8..4b30473743 100644
> --- a/arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi
> +++ b/arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi
> @@ -117,4 +117,26 @@
>         };
>  };
>
> +#if defined(CONFIG_SOCFPGA_SECURE_VAB_AUTH)
> +&uboot_blob {
> +       filename = "signed-u-boot-nodtb.bin";
> +};
> +
> +&atf_blob {
> +       filename = "signed-bl31.bin";
> +};
> +
> +&uboot_fdt_blob {
> +       filename = "signed-u-boot.dtb";
> +};
> +
> +&kernel_blob {
> +       filename = "signed-Image";
> +};
> +
> +&kernel_fdt_blob {
> +       filename = "signed-linux.dtb";
> +};
> +#endif
> +
>  #endif
> --
> 2.13.0
>
Reply | Threaded
Open this post in threaded view
|

Re: [v2 3/6] arm: socfpga: cmd: Support 'vab' command

Simon Glass-3
In reply to this post by Lim, Elly Siew Chin
On Thu, 7 Jan 2021 at 03:03, Siew Chin Lim <[hidden email]> wrote:

>
> Support 'vab' command to perform vendor authentication.
>
> Command format: vab addr len
> Authorize 'len' bytes starting at 'addr' via vendor public key
>
> Signed-off-by: Siew Chin Lim <[hidden email]>
> ---
>  arch/arm/mach-socfpga/Makefile |  1 +
>  arch/arm/mach-socfpga/vab.c    | 37 +++++++++++++++++++++++++++++++++++++
>  2 files changed, 38 insertions(+)
>  create mode 100644 arch/arm/mach-socfpga/vab.c

Reviewed-by: Simon Glass <[hidden email]>

This feature needs some documentation somewhere, or at least a pointer to it.
Reply | Threaded
Open this post in threaded view
|

RE: [v2 4/6] arm: socfpga: dts: soc64: Update filename in binman node of FIT image with VAB support

Lim, Elly Siew Chin
In reply to this post by Simon Glass-3
Hi Simon,

> -----Original Message-----
> From: Simon Glass <[hidden email]>
> Sent: Thursday, January 7, 2021 8:37 PM
> To: Lim, Elly Siew Chin <[hidden email]>
> Cc: U-Boot Mailing List <[hidden email]>; Marek Vasut
> <[hidden email]>; Tan, Ley Foon <[hidden email]>; See, Chin Liang
> <[hidden email]>; Simon Goldschmidt
> <[hidden email]>; Chee, Tien Fong
> <[hidden email]>; Westergreen, Dalon
> <[hidden email]>; Gan, Yau Wai <[hidden email]>
> Subject: Re: [v2 4/6] arm: socfpga: dts: soc64: Update filename in binman node
> of FIT image with VAB support
>
> On Thu, 7 Jan 2021 at 03:03, Siew Chin Lim <[hidden email]>
> wrote:
> >
> > FIT image of Vendor Authentication Coot (VAB) contains signed images.
> >
> > Signed-off-by: Siew Chin Lim <[hidden email]>
> > ---
> >  arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi | 22
> > ++++++++++++++++++++++
> >  1 file changed, 22 insertions(+)
> >
>
> I'm not quite sure what is happening here, but consider using two separate files
> rather than what looks like a patch over an existing one.
>

There are two boot flow will use binman (socfpga_soc64_fit-u-boot.dtsi) to generate u-boot.fit and kernel.fit:
    1. socfpga_agilex_atf_defconfig (boot via ATF)
    2. socfpga_agilex_vab_defconfig (boot via ATF with VAB enabled, support authentication on bl31, u-boot, Linux images)

The binman node settings are the same for both flows. With VAB enabled, all inputs file need to be signed before generate FIT image. We would like to use different input file name to remind user that they need to sign all bl31, u-boot, Linux images when using binman to generate FIT image.

Due to the binman node settings are identical and only the file name need to be different, so we prefer to share the same socfpga_soc64_fit-u-boot.dtsi for both flows.

Thanks,
Siew Chin

>
>
> > diff --git a/arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi
> > b/arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi
> > index cf365590a8..4b30473743 100644
> > --- a/arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi
> > +++ b/arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi
> > @@ -117,4 +117,26 @@
> >         };
> >  };
> >
> > +#if defined(CONFIG_SOCFPGA_SECURE_VAB_AUTH)
> > +&uboot_blob {
> > +       filename = "signed-u-boot-nodtb.bin"; };
> > +
> > +&atf_blob {
> > +       filename = "signed-bl31.bin";
> > +};
> > +
> > +&uboot_fdt_blob {
> > +       filename = "signed-u-boot.dtb"; };
> > +
> > +&kernel_blob {
> > +       filename = "signed-Image";
> > +};
> > +
> > +&kernel_fdt_blob {
> > +       filename = "signed-linux.dtb"; }; #endif
> > +
> >  #endif
> > --
> > 2.13.0
> >
Reply | Threaded
Open this post in threaded view
|

Re: [v2 4/6] arm: socfpga: dts: soc64: Update filename in binman node of FIT image with VAB support

Simon Glass-3
Hi Siew Chin,

On Thu, 7 Jan 2021 at 07:13, Lim, Elly Siew Chin
<[hidden email]> wrote:

>
> Hi Simon,
>
> > -----Original Message-----
> > From: Simon Glass <[hidden email]>
> > Sent: Thursday, January 7, 2021 8:37 PM
> > To: Lim, Elly Siew Chin <[hidden email]>
> > Cc: U-Boot Mailing List <[hidden email]>; Marek Vasut
> > <[hidden email]>; Tan, Ley Foon <[hidden email]>; See, Chin Liang
> > <[hidden email]>; Simon Goldschmidt
> > <[hidden email]>; Chee, Tien Fong
> > <[hidden email]>; Westergreen, Dalon
> > <[hidden email]>; Gan, Yau Wai <[hidden email]>
> > Subject: Re: [v2 4/6] arm: socfpga: dts: soc64: Update filename in binman node
> > of FIT image with VAB support
> >
> > On Thu, 7 Jan 2021 at 03:03, Siew Chin Lim <[hidden email]>
> > wrote:
> > >
> > > FIT image of Vendor Authentication Coot (VAB) contains signed images.
> > >
> > > Signed-off-by: Siew Chin Lim <[hidden email]>
> > > ---
> > >  arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi | 22
> > > ++++++++++++++++++++++
> > >  1 file changed, 22 insertions(+)
> > >
> >
> > I'm not quite sure what is happening here, but consider using two separate files
> > rather than what looks like a patch over an existing one.
> >
>
> There are two boot flow will use binman (socfpga_soc64_fit-u-boot.dtsi) to generate u-boot.fit and kernel.fit:
>     1. socfpga_agilex_atf_defconfig (boot via ATF)
>     2. socfpga_agilex_vab_defconfig (boot via ATF with VAB enabled, support authentication on bl31, u-boot, Linux images)
>
> The binman node settings are the same for both flows. With VAB enabled, all inputs file need to be signed before generate FIT image. We would like to use different input file name to remind user that they need to sign all bl31, u-boot, Linux images when using binman to generate FIT image.
>
> Due to the binman node settings are identical and only the file name need to be different, so we prefer to share the same socfpga_soc64_fit-u-boot.dtsi for both flows.

Reviewed-by: Simon Glass <[hidden email]>

OK I see.

Who does the signing of the inputs? Is that something binman could/should do?

Regards,
Simon
Reply | Threaded
Open this post in threaded view
|

RE: [v2 4/6] arm: socfpga: dts: soc64: Update filename in binman node of FIT image with VAB support

Lim, Elly Siew Chin
Hi Simon,

> -----Original Message-----
> From: Simon Glass <[hidden email]>
> Sent: Friday, January 8, 2021 12:22 AM
> To: Lim, Elly Siew Chin <[hidden email]>
> Cc: U-Boot Mailing List <[hidden email]>; Marek Vasut
> <[hidden email]>; Tan, Ley Foon <[hidden email]>; See, Chin Liang
> <[hidden email]>; Simon Goldschmidt
> <[hidden email]>; Chee, Tien Fong
> <[hidden email]>; Westergreen, Dalon
> <[hidden email]>; Gan, Yau Wai <[hidden email]>
> Subject: Re: [v2 4/6] arm: socfpga: dts: soc64: Update filename in binman node
> of FIT image with VAB support
>
> Hi Siew Chin,
>
> On Thu, 7 Jan 2021 at 07:13, Lim, Elly Siew Chin <[hidden email]>
> wrote:
> >
> > Hi Simon,
> >
> > > -----Original Message-----
> > > From: Simon Glass <[hidden email]>
> > > Sent: Thursday, January 7, 2021 8:37 PM
> > > To: Lim, Elly Siew Chin <[hidden email]>
> > > Cc: U-Boot Mailing List <[hidden email]>; Marek Vasut
> > > <[hidden email]>; Tan, Ley Foon <[hidden email]>; See, Chin
> > > Liang <[hidden email]>; Simon Goldschmidt
> > > <[hidden email]>; Chee, Tien Fong
> > > <[hidden email]>; Westergreen, Dalon
> > > <[hidden email]>; Gan, Yau Wai <[hidden email]>
> > > Subject: Re: [v2 4/6] arm: socfpga: dts: soc64: Update filename in
> > > binman node of FIT image with VAB support
> > >
> > > On Thu, 7 Jan 2021 at 03:03, Siew Chin Lim
> > > <[hidden email]>
> > > wrote:
> > > >
> > > > FIT image of Vendor Authentication Coot (VAB) contains signed images.
> > > >
> > > > Signed-off-by: Siew Chin Lim <[hidden email]>
> > > > ---
> > > >  arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi | 22
> > > > ++++++++++++++++++++++
> > > >  1 file changed, 22 insertions(+)
> > > >
> > >
> > > I'm not quite sure what is happening here, but consider using two
> > > separate files rather than what looks like a patch over an existing one.
> > >
> >
> > There are two boot flow will use binman (socfpga_soc64_fit-u-boot.dtsi) to
> generate u-boot.fit and kernel.fit:
> >     1. socfpga_agilex_atf_defconfig (boot via ATF)
> >     2. socfpga_agilex_vab_defconfig (boot via ATF with VAB enabled,
> > support authentication on bl31, u-boot, Linux images)
> >
> > The binman node settings are the same for both flows. With VAB enabled, all
> inputs file need to be signed before generate FIT image. We would like to use
> different input file name to remind user that they need to sign all bl31, u-boot,
> Linux images when using binman to generate FIT image.
> >
> > Due to the binman node settings are identical and only the file name need to
> be different, so we prefer to share the same socfpga_soc64_fit-u-boot.dtsi for
> both flows.
>
> Reviewed-by: Simon Glass <[hidden email]>
>
> OK I see.
>
> Who does the signing of the inputs? Is that something binman could/should do?

In our case, we will provide user Intel proprietary tools to sign the image, and we have our signature format.
User need to follow the steps and sign the Images, and call binman to convert into FIT image.
I think maybe it is not suitable to incorporate any external proprietary tools into binman.

Thanks,
Siew Chin

>
> Regards,
> Simon
Reply | Threaded
Open this post in threaded view
|

RE: [v2 2/6] arm: socfpga: soc64: Support Vendor Authorized Boot (VAB)

Lim, Elly Siew Chin
In reply to this post by Simon Glass-3
Hi Simon,

> -----Original Message-----
> From: Simon Glass <[hidden email]>
> Sent: Thursday, January 7, 2021 8:36 PM
> To: Lim, Elly Siew Chin <[hidden email]>
> Cc: U-Boot Mailing List <[hidden email]>; Marek Vasut
> <[hidden email]>; Tan, Ley Foon <[hidden email]>; See, Chin Liang
> <[hidden email]>; Simon Goldschmidt
> <[hidden email]>; Chee, Tien Fong
> <[hidden email]>; Westergreen, Dalon
> <[hidden email]>; Gan, Yau Wai <[hidden email]>
> Subject: Re: [v2 2/6] arm: socfpga: soc64: Support Vendor Authorized Boot
> (VAB)
>
> On Thu, 7 Jan 2021 at 03:03, Siew Chin Lim <[hidden email]>
> wrote:
> >
> > Vendor Authorized Boot is a security feature for authenticating the
> > images such as U-Boot, ARM trusted Firmware, Linux kernel, device tree
> > blob and etc loaded from FIT. After those images are loaded from FIT,
> > the VAB certificate and signature block appended at the end of each
> > image are sent to Secure Device Manager (SDM) for authentication.
> > U-Boot will validate the SHA384 of the image against the SHA384 hash
> > stored in the VAB certificate before sending the image to SDM for
> > authentication.
> >
> > Signed-off-by: Siew Chin Lim <[hidden email]>
> >
> > ---
> > v2
> > ---
> > - Renamed SECURE_VAB_AUTH* to SOCFPGA_SECURE_VAB_AUTH*
> > - Changes in secure_vab.c
> >   - Changed to use SZ_1K for 1024
> >   - Updated comment in secure_vab.c of "... the certificate for T"
> >   - The code will report error before end of the function if reach
> >     maximum retry.
> >   - In board_prep_linux function, only execute linux_qspi_enable
> >     command if it exists in enviroment variable. It is optional.
> > ---
> >  arch/arm/mach-socfpga/Kconfig                    |  15 ++
> >  arch/arm/mach-socfpga/Makefile                   |   2 +
> >  arch/arm/mach-socfpga/include/mach/mailbox_s10.h |   1 +
> >  arch/arm/mach-socfpga/include/mach/secure_vab.h  |  63 ++++++++
> >  arch/arm/mach-socfpga/secure_vab.c               | 193
> +++++++++++++++++++++++
> >  common/Kconfig.boot                              |   2 +-
> >  6 files changed, 275 insertions(+), 1 deletion(-)  create mode 100644
> > arch/arm/mach-socfpga/include/mach/secure_vab.h
> >  create mode 100644 arch/arm/mach-socfpga/secure_vab.c
>
> I think this could use a few more function comments. Also try to use
> if() instead of #if

Noted. I will change #if in *.c to " if (IS_ENABLED(CONFIG...))".

Besides, can you please help to elaborate more about  "I think this could use a few more function comments."?

Thanks,
Siew Chin

>
> Regards,
> Simon
Reply | Threaded
Open this post in threaded view
|

Re: [v2 2/6] arm: socfpga: soc64: Support Vendor Authorized Boot (VAB)

Simon Glass-3
Hi,

On Thu, 7 Jan 2021 at 18:11, Lim, Elly Siew Chin
<[hidden email]> wrote:

>
> Hi Simon,
>
> > -----Original Message-----
> > From: Simon Glass <[hidden email]>
> > Sent: Thursday, January 7, 2021 8:36 PM
> > To: Lim, Elly Siew Chin <[hidden email]>
> > Cc: U-Boot Mailing List <[hidden email]>; Marek Vasut
> > <[hidden email]>; Tan, Ley Foon <[hidden email]>; See, Chin Liang
> > <[hidden email]>; Simon Goldschmidt
> > <[hidden email]>; Chee, Tien Fong
> > <[hidden email]>; Westergreen, Dalon
> > <[hidden email]>; Gan, Yau Wai <[hidden email]>
> > Subject: Re: [v2 2/6] arm: socfpga: soc64: Support Vendor Authorized Boot
> > (VAB)
> >
> > On Thu, 7 Jan 2021 at 03:03, Siew Chin Lim <[hidden email]>
> > wrote:
> > >
> > > Vendor Authorized Boot is a security feature for authenticating the
> > > images such as U-Boot, ARM trusted Firmware, Linux kernel, device tree
> > > blob and etc loaded from FIT. After those images are loaded from FIT,
> > > the VAB certificate and signature block appended at the end of each
> > > image are sent to Secure Device Manager (SDM) for authentication.
> > > U-Boot will validate the SHA384 of the image against the SHA384 hash
> > > stored in the VAB certificate before sending the image to SDM for
> > > authentication.
> > >
> > > Signed-off-by: Siew Chin Lim <[hidden email]>
> > >
> > > ---
> > > v2
> > > ---
> > > - Renamed SECURE_VAB_AUTH* to SOCFPGA_SECURE_VAB_AUTH*
> > > - Changes in secure_vab.c
> > >   - Changed to use SZ_1K for 1024
> > >   - Updated comment in secure_vab.c of "... the certificate for T"
> > >   - The code will report error before end of the function if reach
> > >     maximum retry.
> > >   - In board_prep_linux function, only execute linux_qspi_enable
> > >     command if it exists in enviroment variable. It is optional.
> > > ---
> > >  arch/arm/mach-socfpga/Kconfig                    |  15 ++
> > >  arch/arm/mach-socfpga/Makefile                   |   2 +
> > >  arch/arm/mach-socfpga/include/mach/mailbox_s10.h |   1 +
> > >  arch/arm/mach-socfpga/include/mach/secure_vab.h  |  63 ++++++++
> > >  arch/arm/mach-socfpga/secure_vab.c               | 193
> > +++++++++++++++++++++++
> > >  common/Kconfig.boot                              |   2 +-
> > >  6 files changed, 275 insertions(+), 1 deletion(-)  create mode 100644
> > > arch/arm/mach-socfpga/include/mach/secure_vab.h
> > >  create mode 100644 arch/arm/mach-socfpga/secure_vab.c
> >
> > I think this could use a few more function comments. Also try to use
> > if() instead of #if
>
> Noted. I will change #if in *.c to " if (IS_ENABLED(CONFIG...))".
>
> Besides, can you please help to elaborate more about  "I think this could use a few more function comments."?

Non-trivial functions should have a comment in the standard style that
explains their purpose/action and documents input and output args and
return value.

Regards,
Simon
Reply | Threaded
Open this post in threaded view
|

Re: [v2 4/6] arm: socfpga: dts: soc64: Update filename in binman node of FIT image with VAB support

Simon Glass-3
In reply to this post by Lim, Elly Siew Chin
Hi Slew Elly,

On Thu, 7 Jan 2021 at 17:57, Lim, Elly Siew Chin
<[hidden email]> wrote:

>
> Hi Simon,
>
> > -----Original Message-----
> > From: Simon Glass <[hidden email]>
> > Sent: Friday, January 8, 2021 12:22 AM
> > To: Lim, Elly Siew Chin <[hidden email]>
> > Cc: U-Boot Mailing List <[hidden email]>; Marek Vasut
> > <[hidden email]>; Tan, Ley Foon <[hidden email]>; See, Chin Liang
> > <[hidden email]>; Simon Goldschmidt
> > <[hidden email]>; Chee, Tien Fong
> > <[hidden email]>; Westergreen, Dalon
> > <[hidden email]>; Gan, Yau Wai <[hidden email]>
> > Subject: Re: [v2 4/6] arm: socfpga: dts: soc64: Update filename in binman node
> > of FIT image with VAB support
> >
> > Hi Siew Chin,
> >
> > On Thu, 7 Jan 2021 at 07:13, Lim, Elly Siew Chin <[hidden email]>
> > wrote:
> > >
> > > Hi Simon,
> > >
> > > > -----Original Message-----
> > > > From: Simon Glass <[hidden email]>
> > > > Sent: Thursday, January 7, 2021 8:37 PM
> > > > To: Lim, Elly Siew Chin <[hidden email]>
> > > > Cc: U-Boot Mailing List <[hidden email]>; Marek Vasut
> > > > <[hidden email]>; Tan, Ley Foon <[hidden email]>; See, Chin
> > > > Liang <[hidden email]>; Simon Goldschmidt
> > > > <[hidden email]>; Chee, Tien Fong
> > > > <[hidden email]>; Westergreen, Dalon
> > > > <[hidden email]>; Gan, Yau Wai <[hidden email]>
> > > > Subject: Re: [v2 4/6] arm: socfpga: dts: soc64: Update filename in
> > > > binman node of FIT image with VAB support
> > > >
> > > > On Thu, 7 Jan 2021 at 03:03, Siew Chin Lim
> > > > <[hidden email]>
> > > > wrote:
> > > > >
> > > > > FIT image of Vendor Authentication Coot (VAB) contains signed images.
> > > > >
> > > > > Signed-off-by: Siew Chin Lim <[hidden email]>
> > > > > ---
> > > > >  arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi | 22
> > > > > ++++++++++++++++++++++
> > > > >  1 file changed, 22 insertions(+)
> > > > >
> > > >
> > > > I'm not quite sure what is happening here, but consider using two
> > > > separate files rather than what looks like a patch over an existing one.
> > > >
> > >
> > > There are two boot flow will use binman (socfpga_soc64_fit-u-boot.dtsi) to
> > generate u-boot.fit and kernel.fit:
> > >     1. socfpga_agilex_atf_defconfig (boot via ATF)
> > >     2. socfpga_agilex_vab_defconfig (boot via ATF with VAB enabled,
> > > support authentication on bl31, u-boot, Linux images)
> > >
> > > The binman node settings are the same for both flows. With VAB enabled, all
> > inputs file need to be signed before generate FIT image. We would like to use
> > different input file name to remind user that they need to sign all bl31, u-boot,
> > Linux images when using binman to generate FIT image.
> > >
> > > Due to the binman node settings are identical and only the file name need to
> > be different, so we prefer to share the same socfpga_soc64_fit-u-boot.dtsi for
> > both flows.
> >
> > Reviewed-by: Simon Glass <[hidden email]>
> >
> > OK I see.
> >
> > Who does the signing of the inputs? Is that something binman could/should do?
>
> In our case, we will provide user Intel proprietary tools to sign the image, and we have our signature format.
> User need to follow the steps and sign the Images, and call binman to convert into FIT image.
> I think maybe it is not suitable to incorporate any external proprietary tools into binman.

Possibly, although we already have quite a few. Is the tool secret or
can it be downloaded from somewhere? If the latter, see how cbfstool
is handled.

Regards,
Simon
Reply | Threaded
Open this post in threaded view
|

RE: [v2 2/6] arm: socfpga: soc64: Support Vendor Authorized Boot (VAB)

Lim, Elly Siew Chin
In reply to this post by Simon Glass-3
Hi Simon,

> -----Original Message-----
> From: Simon Glass <[hidden email]>
> Sent: Friday, January 8, 2021 11:24 AM
> To: Lim, Elly Siew Chin <[hidden email]>
> Cc: U-Boot Mailing List <[hidden email]>; Marek Vasut
> <[hidden email]>; Tan, Ley Foon <[hidden email]>; See, Chin Liang
> <[hidden email]>; Simon Goldschmidt
> <[hidden email]>; Chee, Tien Fong
> <[hidden email]>; Westergreen, Dalon
> <[hidden email]>; Gan, Yau Wai <[hidden email]>
> Subject: Re: [v2 2/6] arm: socfpga: soc64: Support Vendor Authorized Boot
> (VAB)
>
> Hi,
>
> On Thu, 7 Jan 2021 at 18:11, Lim, Elly Siew Chin <[hidden email]>
> wrote:
> >
> > Hi Simon,
> >
> > > -----Original Message-----
> > > From: Simon Glass <[hidden email]>
> > > Sent: Thursday, January 7, 2021 8:36 PM
> > > To: Lim, Elly Siew Chin <[hidden email]>
> > > Cc: U-Boot Mailing List <[hidden email]>; Marek Vasut
> > > <[hidden email]>; Tan, Ley Foon <[hidden email]>; See, Chin
> > > Liang <[hidden email]>; Simon Goldschmidt
> > > <[hidden email]>; Chee, Tien Fong
> > > <[hidden email]>; Westergreen, Dalon
> > > <[hidden email]>; Gan, Yau Wai <[hidden email]>
> > > Subject: Re: [v2 2/6] arm: socfpga: soc64: Support Vendor Authorized
> > > Boot
> > > (VAB)
> > >
> > > On Thu, 7 Jan 2021 at 03:03, Siew Chin Lim
> > > <[hidden email]>
> > > wrote:
> > > >
> > > > Vendor Authorized Boot is a security feature for authenticating
> > > > the images such as U-Boot, ARM trusted Firmware, Linux kernel,
> > > > device tree blob and etc loaded from FIT. After those images are
> > > > loaded from FIT, the VAB certificate and signature block appended
> > > > at the end of each image are sent to Secure Device Manager (SDM) for
> authentication.
> > > > U-Boot will validate the SHA384 of the image against the SHA384
> > > > hash stored in the VAB certificate before sending the image to SDM
> > > > for authentication.
> > > >
> > > > Signed-off-by: Siew Chin Lim <[hidden email]>
> > > >
> > > > ---
> > > > v2
> > > > ---
> > > > - Renamed SECURE_VAB_AUTH* to SOCFPGA_SECURE_VAB_AUTH*
> > > > - Changes in secure_vab.c
> > > >   - Changed to use SZ_1K for 1024
> > > >   - Updated comment in secure_vab.c of "... the certificate for T"
> > > >   - The code will report error before end of the function if reach
> > > >     maximum retry.
> > > >   - In board_prep_linux function, only execute linux_qspi_enable
> > > >     command if it exists in enviroment variable. It is optional.
> > > > ---
> > > >  arch/arm/mach-socfpga/Kconfig                    |  15 ++
> > > >  arch/arm/mach-socfpga/Makefile                   |   2 +
> > > >  arch/arm/mach-socfpga/include/mach/mailbox_s10.h |   1 +
> > > >  arch/arm/mach-socfpga/include/mach/secure_vab.h  |  63 ++++++++
> > > >  arch/arm/mach-socfpga/secure_vab.c               | 193
> > > +++++++++++++++++++++++
> > > >  common/Kconfig.boot                              |   2 +-
> > > >  6 files changed, 275 insertions(+), 1 deletion(-)  create mode
> > > > 100644 arch/arm/mach-socfpga/include/mach/secure_vab.h
> > > >  create mode 100644 arch/arm/mach-socfpga/secure_vab.c
> > >
> > > I think this could use a few more function comments. Also try to use
> > > if() instead of #if
> >
> > Noted. I will change #if in *.c to " if (IS_ENABLED(CONFIG...))".
> >
> > Besides, can you please help to elaborate more about  "I think this could use a
> few more function comments."?

Noted, I will review this. Thanks.
>
> Non-trivial functions should have a comment in the standard style that explains
> their purpose/action and documents input and output args and return value.
>
> Regards,
> Simon
Reply | Threaded
Open this post in threaded view
|

RE: [v2 4/6] arm: socfpga: dts: soc64: Update filename in binman node of FIT image with VAB support

Lim, Elly Siew Chin
In reply to this post by Simon Glass-3
Hi Simon,

> -----Original Message-----
> From: Simon Glass <[hidden email]>
> Sent: Friday, January 8, 2021 11:24 AM
> To: Lim, Elly Siew Chin <[hidden email]>
> Cc: U-Boot Mailing List <[hidden email]>; Marek Vasut
> <[hidden email]>; Tan, Ley Foon <[hidden email]>; See, Chin Liang
> <[hidden email]>; Simon Goldschmidt
> <[hidden email]>; Chee, Tien Fong
> <[hidden email]>; Westergreen, Dalon
> <[hidden email]>; Gan, Yau Wai <[hidden email]>
> Subject: Re: [v2 4/6] arm: socfpga: dts: soc64: Update filename in binman node
> of FIT image with VAB support
>
> Hi Slew Elly,
>
> On Thu, 7 Jan 2021 at 17:57, Lim, Elly Siew Chin <[hidden email]>
> wrote:
> >
> > Hi Simon,
> >
> > > -----Original Message-----
> > > From: Simon Glass <[hidden email]>
> > > Sent: Friday, January 8, 2021 12:22 AM
> > > To: Lim, Elly Siew Chin <[hidden email]>
> > > Cc: U-Boot Mailing List <[hidden email]>; Marek Vasut
> > > <[hidden email]>; Tan, Ley Foon <[hidden email]>; See, Chin
> > > Liang <[hidden email]>; Simon Goldschmidt
> > > <[hidden email]>; Chee, Tien Fong
> > > <[hidden email]>; Westergreen, Dalon
> > > <[hidden email]>; Gan, Yau Wai <[hidden email]>
> > > Subject: Re: [v2 4/6] arm: socfpga: dts: soc64: Update filename in
> > > binman node of FIT image with VAB support
> > >
> > > Hi Siew Chin,
> > >
> > > On Thu, 7 Jan 2021 at 07:13, Lim, Elly Siew Chin
> > > <[hidden email]>
> > > wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > > -----Original Message-----
> > > > > From: Simon Glass <[hidden email]>
> > > > > Sent: Thursday, January 7, 2021 8:37 PM
> > > > > To: Lim, Elly Siew Chin <[hidden email]>
> > > > > Cc: U-Boot Mailing List <[hidden email]>; Marek Vasut
> > > > > <[hidden email]>; Tan, Ley Foon <[hidden email]>; See,
> > > > > Chin Liang <[hidden email]>; Simon Goldschmidt
> > > > > <[hidden email]>; Chee, Tien Fong
> > > > > <[hidden email]>; Westergreen, Dalon
> > > > > <[hidden email]>; Gan, Yau Wai
> > > > > <[hidden email]>
> > > > > Subject: Re: [v2 4/6] arm: socfpga: dts: soc64: Update filename
> > > > > in binman node of FIT image with VAB support
> > > > >
> > > > > On Thu, 7 Jan 2021 at 03:03, Siew Chin Lim
> > > > > <[hidden email]>
> > > > > wrote:
> > > > > >
> > > > > > FIT image of Vendor Authentication Coot (VAB) contains signed images.
> > > > > >
> > > > > > Signed-off-by: Siew Chin Lim <[hidden email]>
> > > > > > ---
> > > > > >  arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi | 22
> > > > > > ++++++++++++++++++++++
> > > > > >  1 file changed, 22 insertions(+)
> > > > > >
> > > > >
> > > > > I'm not quite sure what is happening here, but consider using
> > > > > two separate files rather than what looks like a patch over an existing
> one.
> > > > >
> > > >
> > > > There are two boot flow will use binman
> > > > (socfpga_soc64_fit-u-boot.dtsi) to
> > > generate u-boot.fit and kernel.fit:
> > > >     1. socfpga_agilex_atf_defconfig (boot via ATF)
> > > >     2. socfpga_agilex_vab_defconfig (boot via ATF with VAB
> > > > enabled, support authentication on bl31, u-boot, Linux images)
> > > >
> > > > The binman node settings are the same for both flows. With VAB
> > > > enabled, all
> > > inputs file need to be signed before generate FIT image. We would
> > > like to use different input file name to remind user that they need
> > > to sign all bl31, u-boot, Linux images when using binman to generate FIT
> image.
> > > >
> > > > Due to the binman node settings are identical and only the file
> > > > name need to
> > > be different, so we prefer to share the same
> > > socfpga_soc64_fit-u-boot.dtsi for both flows.
> > >
> > > Reviewed-by: Simon Glass <[hidden email]>
> > >
> > > OK I see.
> > >
> > > Who does the signing of the inputs? Is that something binman could/should
> do?
> >
> > In our case, we will provide user Intel proprietary tools to sign the image, and
> we have our signature format.
> > User need to follow the steps and sign the Images, and call binman to convert
> into FIT image.
> > I think maybe it is not suitable to incorporate any external proprietary tools
> into binman.
>
> Possibly, although we already have quite a few. Is the tool secret or can it be
> downloaded from somewhere? If the latter, see how cbfstool is handled.

It is licensed software.

>
> Regards,
> Simon
Reply | Threaded
Open this post in threaded view
|

Re: [v2 4/6] arm: socfpga: dts: soc64: Update filename in binman node of FIT image with VAB support

Simon Glass-3
Hi Siew Chin,

On Thu, 7 Jan 2021 at 22:19, Lim, Elly Siew Chin
<[hidden email]> wrote:

>
> Hi Simon,
>
> > -----Original Message-----
> > From: Simon Glass <[hidden email]>
> > Sent: Friday, January 8, 2021 11:24 AM
> > To: Lim, Elly Siew Chin <[hidden email]>
> > Cc: U-Boot Mailing List <[hidden email]>; Marek Vasut
> > <[hidden email]>; Tan, Ley Foon <[hidden email]>; See, Chin Liang
> > <[hidden email]>; Simon Goldschmidt
> > <[hidden email]>; Chee, Tien Fong
> > <[hidden email]>; Westergreen, Dalon
> > <[hidden email]>; Gan, Yau Wai <[hidden email]>
> > Subject: Re: [v2 4/6] arm: socfpga: dts: soc64: Update filename in binman node
> > of FIT image with VAB support
> >
> > Hi Slew Elly,
> >
> > On Thu, 7 Jan 2021 at 17:57, Lim, Elly Siew Chin <[hidden email]>
> > wrote:
> > >
> > > Hi Simon,
> > >
> > > > -----Original Message-----
> > > > From: Simon Glass <[hidden email]>
> > > > Sent: Friday, January 8, 2021 12:22 AM
> > > > To: Lim, Elly Siew Chin <[hidden email]>
> > > > Cc: U-Boot Mailing List <[hidden email]>; Marek Vasut
> > > > <[hidden email]>; Tan, Ley Foon <[hidden email]>; See, Chin
> > > > Liang <[hidden email]>; Simon Goldschmidt
> > > > <[hidden email]>; Chee, Tien Fong
> > > > <[hidden email]>; Westergreen, Dalon
> > > > <[hidden email]>; Gan, Yau Wai <[hidden email]>
> > > > Subject: Re: [v2 4/6] arm: socfpga: dts: soc64: Update filename in
> > > > binman node of FIT image with VAB support
> > > >
> > > > Hi Siew Chin,
> > > >
> > > > On Thu, 7 Jan 2021 at 07:13, Lim, Elly Siew Chin
> > > > <[hidden email]>
> > > > wrote:
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Simon Glass <[hidden email]>
> > > > > > Sent: Thursday, January 7, 2021 8:37 PM
> > > > > > To: Lim, Elly Siew Chin <[hidden email]>
> > > > > > Cc: U-Boot Mailing List <[hidden email]>; Marek Vasut
> > > > > > <[hidden email]>; Tan, Ley Foon <[hidden email]>; See,
> > > > > > Chin Liang <[hidden email]>; Simon Goldschmidt
> > > > > > <[hidden email]>; Chee, Tien Fong
> > > > > > <[hidden email]>; Westergreen, Dalon
> > > > > > <[hidden email]>; Gan, Yau Wai
> > > > > > <[hidden email]>
> > > > > > Subject: Re: [v2 4/6] arm: socfpga: dts: soc64: Update filename
> > > > > > in binman node of FIT image with VAB support
> > > > > >
> > > > > > On Thu, 7 Jan 2021 at 03:03, Siew Chin Lim
> > > > > > <[hidden email]>
> > > > > > wrote:
> > > > > > >
> > > > > > > FIT image of Vendor Authentication Coot (VAB) contains signed images.
> > > > > > >
> > > > > > > Signed-off-by: Siew Chin Lim <[hidden email]>
> > > > > > > ---
> > > > > > >  arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi | 22
> > > > > > > ++++++++++++++++++++++
> > > > > > >  1 file changed, 22 insertions(+)
> > > > > > >
> > > > > >
> > > > > > I'm not quite sure what is happening here, but consider using
> > > > > > two separate files rather than what looks like a patch over an existing
> > one.
> > > > > >
> > > > >
> > > > > There are two boot flow will use binman
> > > > > (socfpga_soc64_fit-u-boot.dtsi) to
> > > > generate u-boot.fit and kernel.fit:
> > > > >     1. socfpga_agilex_atf_defconfig (boot via ATF)
> > > > >     2. socfpga_agilex_vab_defconfig (boot via ATF with VAB
> > > > > enabled, support authentication on bl31, u-boot, Linux images)
> > > > >
> > > > > The binman node settings are the same for both flows. With VAB
> > > > > enabled, all
> > > > inputs file need to be signed before generate FIT image. We would
> > > > like to use different input file name to remind user that they need
> > > > to sign all bl31, u-boot, Linux images when using binman to generate FIT
> > image.
> > > > >
> > > > > Due to the binman node settings are identical and only the file
> > > > > name need to
> > > > be different, so we prefer to share the same
> > > > socfpga_soc64_fit-u-boot.dtsi for both flows.
> > > >
> > > > Reviewed-by: Simon Glass <[hidden email]>
> > > >
> > > > OK I see.
> > > >
> > > > Who does the signing of the inputs? Is that something binman could/should
> > do?
> > >
> > > In our case, we will provide user Intel proprietary tools to sign the image, and
> > we have our signature format.
> > > User need to follow the steps and sign the Images, and call binman to convert
> > into FIT image.
> > > I think maybe it is not suitable to incorporate any external proprietary tools
> > into binman.
> >
> > Possibly, although we already have quite a few. Is the tool secret or can it be
> > downloaded from somewhere? If the latter, see how cbfstool is handled.
>
> It is licensed software.

I suggest releasing an open-source, command-line tool as has happened
with various other Intel innovations. It is hard for people to include
private binary tools in their automated build flow. If it is required
to actually boot on the device, then it will be hard for people to
incorporate the hardware in test labs.

Regards,
Simon