obscure microsd detection issue between U-Boot and kernel
Greetings, I'm seeing an issue on an imx8mm board (imx8mm-venice-gw73xx) where for a specific set of microsd cards if I have accessed the microsd in U-Boot with UHS/1.8V the kernel will not recognize that microsd when scanning. The issue does not occur with all microsd cards but seems to appear with a large sample size of a specific card/model (Kingston SDC32 32GB SDR104 card). I do not see a signal integrity issue on the scope. Instrumenting the kernel the issue is that the host reports a CRC error as soon as the first mmc_send_if_cond call which occurs in mmc_rescan_try_freq. I can avoid the issue by either not accessing the microsd in U-Boot or by disabling UHS/1.8V mode in U-Boot therefore what I think is happening is that U-Boot leaves the card in UHS/1.8V signalling mode and when the kernel scans it sets the voltage back to 3.3V standard/default and default timings then issues its clock cycles to 'reset' the card and the card does not recognize the reset. I'm wondering if this is because the reset is done via clock cycles after the kernel has set the I/O voltage back to 3.3V when perhaps the card is still in 1.8V mode (although I don't see how that would cause an issue)? Is there some sort of MMC 'reset' I can/should do in U-Boot before booting the kernel? Has anyone encountered anything like this before? Best Regards, Tim
[RESEND PATCH v4 3/3] venice: show emmc boot hardware partition
To aid in understanding what emmc hardware partition is being
used to boot on power-up, display the hardware partition name in the
SPL.
Signed-off-by: Tim Harvey
---
v4: new patch for this series
---
board/gateworks/venice/spl.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/board/gateworks/venice/spl.c b/board/gateworks/venice/spl.c
index 6f6dea84feee..ad3af93143d9 100644
--- a/board/gateworks/venice/spl.c
+++ b/board/gateworks/venice/spl.c
@@ -366,16 +366,24 @@ unsigned long board_spl_mmc_get_uboot_raw_sector(struct
mmc *mmc, unsigned long
const char *spl_board_loader_name(u32 boot_device)
{
+ static char name[16];
+ struct mmc *mmc;
+
switch (boot_device) {
/* SDHC2 */
case BOOT_DEVICE_MMC1:
- return "eMMC";
+ mmc_init_device(0);
+ mmc = find_mmc_device(0);
+ mmc_init(mmc);
+ snprintf(name, sizeof(name), "eMMC %s",
emmc_hwpart_names[EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config)]);
+ return name;
/* SDHC3 */
case BOOT_DEVICE_MMC2:
- return "SD card";
- default:
- return NULL;
+ sprintf(name, "SD card");
+ return name;
}
+
+ return NULL;
}
void spl_board_init(void)
--
2.25.1
[RESEND PATCH v4 1/3] mmc: use an enumerated type to represent PARTITION_CONFIG fields
Modern eMMC v4+ devices have multiple hardware partitions per the JEDEC
specification described as:
Boot Area Partition 1
Boot Area Partition 2
RPMB Partition
General Purpose Partition 1
General Purpose Partition 2
General Purpose Partition 3
General Purpose Partition 4
User Data Area
These are referenced by fields in the PARTITION_CONFIG register
(Extended CSD Register 179) which is defined as:
bit 7: reserved
bit 6: BOOT_ACK
0x0: No boot acknowledge sent (default
0x1: Boot acknowledge sent during boot operation Bit
bit 5:3: BOOT_PARTITION_ENABLE
0x0: Device not boot enabled (default)
0x1: Boot Area partition 1 enabled for boot
0x2: Boot Area partition 2 enabled for boot
0x3-0x6: Reserved
0x7: User area enabled for boot
bit 2:0 PARTITION_ACCESS
0x0: No access to boot partition (default)
0x1: Boot Area partition 1
0x2: Boot Area partition 2
0x3: Replay Protected Memory Block (RPMB)
0x4: Access to General Purpose partition 1
0x5: Access to General Purpose partition 2
0x6: Access to General Purpose partition 3
0x7: Access to General Purpose partition 4
Note that setting PARTITION_ACCESS to 0x0 results in selecting the User
Data Area partition.
You can see above that the two fields BOOT_PARTITION_ENABLE and
PARTITION_ACCESS do not use the same enumerated values.
U-Boot uses a set of macros to access fields of the PARTITION_CONFIG
register:
There are various places in U-Boot where the BOOT_PARTITION_ENABLE field
is accessed via EXT_CSD_EXTRACT_PARTITION_ACCESS and converted to a
hardware partition consistent with the definition of the
PARTITION_ACCESS field which is also the value used to specify the
hardware partition of the various mmc_switch incarnations.
To add some sanity to the distinction between BOOT_PARTITION_ENABLE
(used to specify the active device on power-cycle) and PARTITION_ACCESS
(used to switch between hardware partitions) create two enumerated types
and use them wherever struct mmc * part_config is used or the above
macros are used.
This represents no code changes.
Signed-off-by: Tim Harvey
---
v4: new patch (split to series)
---
arch/arm/mach-imx/image-container.c | 10 +-
arch/arm/mach-sunxi/board.c | 2 +-
board/gateworks/venice/spl.c| 4 ++--
board/gateworks/venice/venice.c | 22 +++---
board/purism/librem5/librem5.c | 4 ++--
board/storopack/smegw01/smegw01.c | 4 ++--
cmd/mvebu/bubt.c| 4 ++--
common/spl/spl_mmc.c| 4 ++--
include/mmc.h | 20
9 files changed, 47 insertions(+), 27 deletions(-)
diff --git a/arch/arm/mach-imx/image-container.c
b/arch/arm/mach-imx/image-container.c
index 35da0ae04258..bcd40889f0fa 100644
--- a/arch/arm/mach-imx/image-container.c
+++ b/arch/arm/mach-imx/image-container.c
@@ -205,7 +205,7 @@ static unsigned long get_boot_device_offset(void *dev, int
dev_type)
} else {
u8 part = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
- if (part == 1 || part == 2) {
+ if (part == EMMC_BOOT_PART_BOOT1 || part ==
EMMC_BOOT_PART_BOOT2) {
if (is_imx8qxp() && is_soc_rev(CHIP_REV_B))
offset = CONTAINER_HDR_MMCSD_OFFSET;
else
@@ -294,15 +294,15 @@ int spl_mmc_emmc_boot_partition(struct mmc *mmc)
int part;
part = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
- if (part == 1 || part == 2) {
+ if (part == EMMC_BOOT_PART_BOOT1 || part == EMMC_BOOT_PART_BOOT2) {
unsigned long sec_set_off = 0;
bool sec_boot = false;
sec_boot = check_secondary_cnt_set(_set_off);
if (sec_boot)
- part = (part == 1) ? 2 : 1;
- } else if (part == 7) {
- part = 0;
+ part = (part == EMMC_BOOT_PART_BOOT1) ?
EMMC_HWPART_BOOT2 : EMMC_HWPART_BOOT1;
+ } else if (part == EMMC_BOOT_PART_USER) {
+ part = EMMC_HWPART_DEFAULT;
}
return part;
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index 0140b07d32a6..860e7058b69c 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -396,7 +396,7 @@ static bool sunxi_valid_emmc_boot(struct mmc *mmc)
return false;
/* Partition 0 is the user data partition, bootpart must be 1 or 2. */
- if (bootpart != 1 && bootpart != 2)
+ if (bootpart != EMMC_BOOT_PART_BOOT1 && bootpart !=
EMMC_BOOT_PART_BOOT2)
return false;
/* Failure to switch to the boot partition is fatal. */
diff --git a/board/gateworks/venice/spl.c b/board/gateworks/venice/spl.c
index 3b0f11f2fd0f..6f6dea84feee 100644
--- a/board/gateworks/venice/spl.c
+++ b/board/gateworks/venice/spl.c
@@
[RESEND PATCH v4 2/3] mmc: allow use of hardware partition names for mmc partconf
eMMC v4+ devices have hardware partitions that are accessed via the
PARTITION_CONFIG (Extended CSD Register 179) PARTITION_ACCESS
and BOOT_PARTITION_ENABLE fields defined as:
bit 5:3: BOOT_PARTITION_ENABLE
0x0: Device not boot enabled (default)
0x1: Boot Area partition 1 enabled for boot
0x2: Boot Area partition 2 enabled for boot
0x3-0x6: Reserved
0x7: User area enabled for boot
bit 2:0 PARTITION_ACCESS
0x0: No access to boot partition (default)
0x1: Boot Area partition 1
0x2: Boot Area partition 2
0x3: Replay Protected Memory Block (RPMB)
0x4: Access to General Purpose partition 1
0x5: Access to General Purpose partition 2
0x6: Access to General Purpose partition 3
0x7: Access to General Purpose partition 4
Add char arrays to provide names for these values.
Use these names which displaying or setting the PARTITION_CONFIG
register via the 'mmc partconf' command.
Before:
u-boot=> mmc partconf 2 1 1 0 && mmc partconf 2
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x1
BOOT_PARTITION_ENABLE: 0x2
PARTITION_ACCESS: 0x0
After:
u-boot=> mmc partconf 2 1 1 0 && mmc partconf 2
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x1
BOOT_PARTITION_ENABLE: 0x1 (boot0)
PARTITION_ACCESS: 0x0 (user)
u-boot=> mmc partconf 2 1 boot1 0 && mmc partconf 2
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x1
BOOT_PARTITION_ENABLE: 0x2 (boot1)
PARTITION_ACCESS: 0x0 (user)
Signed-off-by: Tim Harvey
---
v4:
- split patch into series
- use static arrays so we can use ARRAY_SIZE when evaluating
- differentiate between PARTITION_CONFIG BOOT_PARTITION_ENABLE and
PARTITION_ACCESS field values and meanings
v3:
- define partition names and values in mmc.h/mmc.c for others to use
v2:
- fix typo in subject
- add names for gp1..gp4
---
cmd/mmc.c | 27 +++
drivers/mmc/mmc.c | 35 +++
include/mmc.h | 6 ++
3 files changed, 64 insertions(+), 4 deletions(-)
diff --git a/cmd/mmc.c b/cmd/mmc.c
index 2d5430a53079..02316796ba4e 100644
--- a/cmd/mmc.c
+++ b/cmd/mmc.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
static int curr_device = -1;
@@ -918,8 +919,9 @@ static int mmc_partconf_print(struct mmc *mmc, const char
*varname)
printf("EXT_CSD[179], PARTITION_CONFIG:\n"
"BOOT_ACK: 0x%x\n"
- "BOOT_PARTITION_ENABLE: 0x%x\n"
- "PARTITION_ACCESS: 0x%x\n", ack, part, access);
+ "BOOT_PARTITION_ENABLE: 0x%x (%s)\n"
+ "PARTITION_ACCESS: 0x%x (%s)\n", ack, part,
emmc_boot_part_names[part],
+ access, emmc_hwpart_names[access]);
return CMD_RET_SUCCESS;
}
@@ -948,9 +950,26 @@ static int do_mmc_partconf(struct cmd_tbl *cmdtp, int flag,
if (argc == 2 || argc == 3)
return mmc_partconf_print(mmc, cmd_arg2(argc, argv));
+ /* BOOT_ACK */
ack = dectoul(argv[2], NULL);
- part_num = dectoul(argv[3], NULL);
- access = dectoul(argv[4], NULL);
+ /* BOOT_PARTITION_ENABLE */
+ if (!isdigit(*argv[3])) {
+ for (part_num = ARRAY_SIZE(emmc_boot_part_names) - 1; part_num
> 0; part_num--) {
+ if (!strcmp(argv[3], emmc_boot_part_names[part_num]))
+ break;
+ }
+ } else {
+ part_num = dectoul(argv[3], NULL);
+ }
+ /* PARTITION_ACCESS */
+ if (!isdigit(*argv[4])) {
+ for (access = ARRAY_SIZE(emmc_hwpart_names) - 1; access > 0;
access--) {
+ if (!strcmp(argv[4], emmc_hwpart_names[access]))
+ break;
+ }
+ } else {
+ access = dectoul(argv[4], NULL);
+ }
/* acknowledge to be sent during boot operation */
ret = mmc_set_part_conf(mmc, ack, part_num, access);
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 7b068c71ff37..bfbf47a73009 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -29,6 +29,41 @@
#define DEFAULT_CMD6_TIMEOUT_MS 500
+/**
+ * names of emmc BOOT_PARTITION_ENABLE values
+ *
+ * Boot Area Partitions - name consistent with Linux
+ */
+const char *emmc_boot_part_names[] = {
+ "default", /* EMMC_BOOT_PART_DEFAULT */
+ "boot0",/* EMMC_BOOT_PART_BOOT1 */
+ "boot1",/* EMMC_BOOT_PART_BOOT2 */
+ "",
+ "",
+ "",
+ "",
+ "user", /* EMMC_BOOT_PART_USER */
+};
+
+/**
+ * names of emmc 'hardware partitions' consistent with:
+ * - value used in mmc_switch()
+ * - value used by PARTITION_CONFIG PARTITION_ACCESS field
+ *
+ * Boot Area Partitions - name consistent with Linux
+ * General Perpose Partitions - name consistent with 'mmc hwpartition' usage
+ */
+const char *emmc
[RESEND PATCH v4 0/3] provide names for emmc hardware partitions
Modern eMMC v4+ devices have multiple hardware partitions per the JEDEC specification described as: Boot Area Partition 1 Boot Area Partition 2 RPMB Partition General Purpose Partition 1 General Purpose Partition 2 General Purpose Partition 3 General Purpose Partition 4 User Data Area These are referenced by fields in the PARTITION_CONFIG register (Extended CSD Register 179) which is defined as: bit 7: reserved bit 6: BOOT_ACK 0x0: No boot acknowledge sent (default 0x1: Boot acknowledge sent during boot operation Bit bit 5:3: BOOT_PARTITION_ENABLE 0x0: Device not boot enabled (default) 0x1: Boot Area partition 1 enabled for boot 0x2: Boot Area partition 2 enabled for boot 0x3-0x6: Reserved 0x7: User area enabled for boot bit 2:0 PARTITION_ACCESS 0x0: No access to boot partition (default) 0x1: Boot Area partition 1 0x2: Boot Area partition 2 0x3: Replay Protected Memory Block (RPMB) 0x4: Access to General Purpose partition 1 0x5: Access to General Purpose partition 2 0x6: Access to General Purpose partition 3 0x7: Access to General Purpose partition 4 Note that setting PARTITION_ACCESS to 0x0 results in selecting the User Data Area partition. You can see above that the two fields BOOT_PARTITION_ENABLE and PARTITION_ACCESS do not use the same enumerated values. U-Boot uses a set of macros to access fields of the PARTITION_CONFIG register: EXT_CSD_BOOT_ACK_ENABLE (1 << 6) EXT_CSD_BOOT_PARTITION_ENABLE (1 << 3) EXT_CSD_PARTITION_ACCESS_ENABLE (1 << 0) EXT_CSD_PARTITION_ACCESS_DISABLE(0 << 0) EXT_CSD_BOOT_ACK(x) (x << 6) EXT_CSD_BOOT_PART_NUM(x)(x << 3) EXT_CSD_PARTITION_ACCESS(x) (x << 0) EXT_CSD_EXTRACT_BOOT_ACK(x) (((x) >> 6) & 0x1) EXT_CSD_EXTRACT_BOOT_PART(x) (((x) >> 3) & 0x7) EXT_CSD_EXTRACT_PARTITION_ACCESS(x) ((x) & 0x7) There are various places in U-Boot where the BOOT_PARTITION_ENABLE field is accessed via EXT_CSD_EXTRACT_PARTITION_ACCESS and converted to a hardware partition consistent with the definition of the PARTITION_ACCESS field used by the various mmc_switch incarnations. To add some sanity to the distinction between BOOT_PARTITION_ENABLE (used to specify the active device on power-cycle) and PARTITION_ACCESS (used to switch between hardware partitions) create two enumerated types and use them wherever struct mmc * part_config is used or the above macros are used. Additionally provide arrays of the field names and allow those to be used in the 'mmc partconf' command and in board support files. The first patch adds enumerated types and makes use of them which represents no compiled code change. The 2nd patch adds the array of names and uses them in the 'mmc partconf' command. The 3rd patch uses the array of hardware partition names in a board support file to show what emmc hardware partition U-Boot is being loaded from. I'm sending this as a series this time around as previously it was repsented as two different patches. Tim Harvey (3): mmc: use an enumerated type to represent PARTITION_CONFIG fields mmc: allow use of hardware partition names for mmc partconf venice: show emmc boot hardware partition arch/arm/mach-imx/image-container.c | 10 - arch/arm/mach-sunxi/board.c | 2 +- board/gateworks/venice/spl.c| 20 - board/gateworks/venice/venice.c | 22 +- board/purism/librem5/librem5.c | 4 ++-- board/storopack/smegw01/smegw01.c | 4 ++-- cmd/mmc.c | 27 ++ cmd/mvebu/bubt.c| 4 ++-- common/spl/spl_mmc.c| 4 ++-- drivers/mmc/mmc.c | 35 + include/mmc.h | 26 + 11 files changed, 123 insertions(+), 35 deletions(-) -- 2.25.1
[PATCH v5 3/3] use fdt_kaslrseed function to de-duplicate code
Use the fdt_kaslrseed function to deduplicate code doing the same thing.
Note that the kalsrseed command (CMD_KASLRSEED) is likely pointless now
but left in place in case boot scripts exist that rely on this command
existing and returning success. An informational message is printed to
alert users of this command that it is likely no longer needed.
Note that the Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for
randomization and completely ignores the kaslr-seed for its own
randomness needs (i.e the randomization of the physical placement of
the kernel). It gets weeded out from the DTB that gets handed over via
efi_install_fdt() as it would also mess up the measured boot DTB TPM
measurements as well.
Signed-off-by: Tim Harvey
Cc: Michal Simek
Cc: Andy Yan
Cc: Akash Gajjar
Cc: Ilias Apalodimas
Cc: Simon Glass
Cc: Patrick Delaunay
Cc: Patrice Chotard
Cc: Devarsh Thakkar
Cc: Heinrich Schuchardt
Cc: Hugo Villeneuve
Cc: Marek Vasut
Cc: Tom Rini
Cc: Chris Morgan
---
v5:
- fixed typo in commit message s/it's/its/
- use cmd_process_error per Michal's suggestion
v4:
- add missing /n to notice in kaslrseed cmd
- combine ints in declaration
- remove unused vars from board/xilinx/common/board.c ft_board_setup
v3:
- skip if CONFIG_MEASURED_BOOT
- fix skip for CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT
- pass in rng index and bool to specify overwrite
- remove duplicate error strings printed outside of fdt_kaslrseed
- added note to commit log about how EFI STUB weeds out kalsr-seed
v2:
- fix typo in commit msg
- use stack for seed to avoid unecessary malloc/free
- move to a library function and deduplicate code by using it
elsewhere
---
board/xilinx/common/board.c | 40 --
boot/pxe_utils.c| 34 +
cmd/kaslrseed.c | 49 ++---
3 files changed, 8 insertions(+), 115 deletions(-)
diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
index b47d2d23f913..098738017bab 100644
--- a/board/xilinx/common/board.c
+++ b/board/xilinx/common/board.c
@@ -702,11 +702,6 @@ phys_addr_t board_get_usable_ram_top(phys_size_t
total_size)
#define MAX_RAND_SIZE 8
int ft_board_setup(void *blob, struct bd_info *bd)
{
- size_t n = MAX_RAND_SIZE;
- struct udevice *dev;
- u8 buf[MAX_RAND_SIZE];
- int nodeoffset, ret;
-
static const struct node_info nodes[] = {
{ "arm,pl353-nand-r2p1", MTD_DEV_TYPE_NAND, },
};
@@ -714,41 +709,6 @@ int ft_board_setup(void *blob, struct bd_info *bd)
if (IS_ENABLED(CONFIG_FDT_FIXUP_PARTITIONS) &&
IS_ENABLED(CONFIG_NAND_ZYNQ))
fdt_fixup_mtdparts(blob, nodes, ARRAY_SIZE(nodes));
- if (uclass_get_device(UCLASS_RNG, 0, ) || !dev) {
- debug("No RNG device\n");
- return 0;
- }
-
- if (dm_rng_read(dev, buf, n)) {
- debug("Reading RNG failed\n");
- return 0;
- }
-
- if (!blob) {
- debug("No FDT memory address configured. Please configure\n"
- "the FDT address via \"fdt addr \" command.\n"
- "Aborting!\n");
- return 0;
- }
-
- ret = fdt_check_header(blob);
- if (ret < 0) {
- debug("fdt_chosen: %s\n", fdt_strerror(ret));
- return ret;
- }
-
- nodeoffset = fdt_find_or_add_subnode(blob, 0, "chosen");
- if (nodeoffset < 0) {
- debug("Reading chosen node failed\n");
- return nodeoffset;
- }
-
- ret = fdt_setprop(blob, nodeoffset, "kaslr-seed", buf, sizeof(buf));
- if (ret < 0) {
- debug("Unable to set kaslr-seed on chosen node: %s\n",
fdt_strerror(ret));
- return ret;
- }
-
return 0;
}
#endif
diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c
index 5c1c962ff4c1..38ca9b81a42d 100644
--- a/boot/pxe_utils.c
+++ b/boot/pxe_utils.c
@@ -324,10 +324,6 @@ static void label_boot_kaslrseed(void)
#if CONFIG_IS_ENABLED(DM_RNG)
ulong fdt_addr;
struct fdt_header *working_fdt;
- size_t n = 0x8;
- struct udevice *dev;
- u64 *buf;
- int nodeoffset;
int err;
/* Get the main fdt and map it */
@@ -343,35 +339,7 @@ static void label_boot_kaslrseed(void)
if (err <= 0)
return;
- if (uclass_get_device(UCLASS_RNG, 0, ) || !dev) {
- printf("No RNG device\n");
- return;
- }
-
- nodeoffset = fdt_find_or_add_subnode(working_fdt, 0, "chosen");
- if (nodeoffset < 0) {
- printf("Reading chosen node failed\n");
- return;
- }
-
- buf = malloc(n);
- if (!buf) {
- pr
[PATCH v5 2/3] fdt: automatically add /chosen/kaslr-seed if DM_RNG is enabled
If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
randomize the virtual address at which the kernel image is loaded, it
expects entropy to be provided by the bootloader by populating
/chosen/kaslr-seed with a 64-bit value from source of entropy at boot.
If we have DM_RNG enabled populate this value automatically when
fdt_chosen is called. We skip this if ARMV8_SEC_FIRMWARE_SUPPORT
is enabled as its implementation uses a different source of entropy
that is not yet implemented as DM_RNG. We also skip this if
MEASURED_BOOT is enabled as in that case any modifications to the
dt will cause measured boot to fail (although there are many other
places the dt is altered).
Note that the Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for
randomization and completely ignores the kaslr-seed for its own
randomness needs (i.e the randomization of the physical placement of
the kernel). It gets weeded out from the DTB that gets handed over via
efi_install_fdt() as it would also mess up the measured boot DTB TPM
measurements as well.
Signed-off-by: Tim Harvey
Cc: Michal Simek
Cc: Andy Yan
Cc: Akash Gajjar
Cc: Ilias Apalodimas
Cc: Simon Glass
Cc: Patrick Delaunay
Cc: Patrice Chotard
Cc: Devarsh Thakkar
Cc: Heinrich Schuchardt
Cc: Hugo Villeneuve
Cc: Marek Vasut
Cc: Tom Rini
Cc: Chris Morgan
---
v5:
- fixed typo in commit message s/it's/its/
- split patch into 3 parts
v4:
- add missing /n to notice in kaslrseed cmd
- combine ints in declaration
- remove unused vars from board/xilinx/common/board.c ft_board_setup
v3:
- skip if CONFIG_MEASURED_BOOT
- fix skip for CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT
- pass in rng index and bool to specify overwrite
- remove duplicate error strings printed outside of fdt_kaslrseed
- added note to commit log about how EFI STUB weeds out kalsr-seed
v2:
- fix typo in commit msg
- use stack for seed to avoid unecessary malloc/free
- move to a library function and deduplicate code by using it
elsewhere
---
boot/fdt_support.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/boot/fdt_support.c b/boot/fdt_support.c
index b1b2679dea0c..4559adcd5e2e 100644
--- a/boot/fdt_support.c
+++ b/boot/fdt_support.c
@@ -345,6 +345,15 @@ int fdt_chosen(void *fdt)
if (nodeoffset < 0)
return nodeoffset;
+ /* if DM_RNG enabled automatically inject kaslr-seed node unless:
+* CONFIG_MEASURED_BOOT enabled: as dt modifications break measured boot
+* CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT enabled: as that implementation
does not use dm yet
+*/
+ if (IS_ENABLED(CONFIG_DM_RNG) &&
+ !IS_ENABLED(CONFIG_MEASURED_BOOT) &&
+ !IS_ENABLED(CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT))
+ fdt_kaslrseed(fdt, false);
+
if (IS_ENABLED(CONFIG_BOARD_RNG_SEED) && !board_rng_seed()) {
err = fdt_setprop(fdt, nodeoffset, "rng-seed",
abuf_data(), abuf_size());
--
2.25.1
[PATCH v5 1/3] Add fdt_kaslrseed function to add kaslr-seed to chosen node
If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
randomize the virtual address at which the kernel image is loaded, it
expects entropy to be provided by the bootloader by populating
/chosen/kaslr-seed with a 64-bit value from source of entropy at boot.
Add a fdt_kaslrseed function to accommodate this allowing an existing
node to be overwritten if present. For now use the first rng device
but it would be good to enhance this in the future to allow some sort
of selection or policy in choosing the rng device used.
Signed-off-by: Tim Harvey
Cc: Michal Simek
Cc: Andy Yan
Cc: Akash Gajjar
Cc: Ilias Apalodimas
Cc: Simon Glass
Cc: Patrick Delaunay
Cc: Patrice Chotard
Cc: Devarsh Thakkar
Cc: Heinrich Schuchardt
Cc: Hugo Villeneuve
Cc: Marek Vasut
Cc: Tom Rini
Cc: Chris Morgan
---
v5:
- move function to boot/fdt_support.c
- remove ability to select rng index and note in the commit log
something like this as a future enhancement.
- fixed typo in commit message s/it's/its/
- use cmd_process_error per Michal's suggestion
v4:
- add missing /n to notice in kaslrseed cmd
- combine ints in declaration
- remove unused vars from board/xilinx/common/board.c ft_board_setup
v3:
- skip if CONFIG_MEASURED_BOOT
- fix skip for CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT
- pass in rng index and bool to specify overwrite
- remove duplicate error strings printed outside of fdt_kaslrseed
- added note to commit log about how EFI STUB weeds out kalsr-seed
v2:
- fix typo in commit msg
- use stack for seed to avoid unecessary malloc/free
- move to a library function and deduplicate code by using it
elsewhere
---
boot/fdt_support.c| 44 +++
include/fdt_support.h | 10 ++
2 files changed, 54 insertions(+)
diff --git a/boot/fdt_support.c b/boot/fdt_support.c
index 2bd80a9dfb18..b1b2679dea0c 100644
--- a/boot/fdt_support.c
+++ b/boot/fdt_support.c
@@ -7,12 +7,15 @@
*/
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
+#include
#include
#include
#include
@@ -274,6 +277,47 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong
initrd_end)
return 0;
}
+int fdt_kaslrseed(void *fdt, bool overwrite)
+{
+ int len, err, nodeoffset;
+ struct udevice *dev;
+ const u64 *orig;
+ u64 data = 0;
+
+ err = fdt_check_header(fdt);
+ if (err < 0)
+ return err;
+
+ /* find or create "/chosen" node. */
+ nodeoffset = fdt_find_or_add_subnode(fdt, 0, "chosen");
+ if (nodeoffset < 0)
+ return nodeoffset;
+
+ /* return without error if we are not overwriting and existing non-zero
node */
+ orig = fdt_getprop(fdt, nodeoffset, "kaslr-seed", );
+ if (orig && len == sizeof(*orig))
+ data = fdt64_to_cpu(*orig);
+ if (data && !overwrite) {
+ debug("not overwriting existing kaslr-seed\n");
+ return 0;
+ }
+ err = uclass_get_device(UCLASS_RNG, 0, );
+ if (err) {
+ printf("No RNG device\n");
+ return err;
+ }
+ err = dm_rng_read(dev, , sizeof(data));
+ if (err) {
+ dev_err(dev, "dm_rng_read failed: %d\n", err);
+ return err;
+ }
+ err = fdt_setprop(fdt, nodeoffset, "kaslr-seed", , sizeof(data));
+ if (err < 0)
+ printf("WARNING: could not set kaslr-seed %s.\n",
fdt_strerror(err));
+
+ return err;
+}
+
/**
* board_fdt_chosen_bootargs - boards may override this function to use
* alternative kernel command line arguments
diff --git a/include/fdt_support.h b/include/fdt_support.h
index 4b71b8948d99..741e2360c224 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -463,4 +463,14 @@ void fdt_fixup_board_enet(void *blob);
#ifdef CONFIG_CMD_PSTORE
void fdt_fixup_pstore(void *blob);
#endif
+
+/**
+ * fdt_kaslrseed() - create a 'kaslr-seed' node in chosen
+ *
+ * @blob: fdt blob
+ * @overwrite: do not overwrite existing non-zero node unless true
+ * Return: 0 if OK, -ve on error
+ */
+int fdt_kaslrseed(void *blob, bool overwrite);
+
#endif /* ifndef __FDT_SUPPORT_H */
--
2.25.1
[PATCH v5 0/3] automatically add /chosen/kaslr-seed and deduplicate code
This series will automatically add /chosen/kaslr-seed to the dt if DM_RNG is enabled during the boot process. If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to randomize the virtual address at which the kernel image is loaded, it expects entropy to be provided by the bootloader by populating /chosen/kaslr-seed with a 64-bit value from source of entropy at boot. If we have DM_RNG enabled populate this value automatically when fdt_chosen is called. We skip this if ARMV8_SEC_FIRMWARE_SUPPORT is enabled as its implementation uses a different source of entropy that is not yet implemented as DM_RNG. We also skip this if MEASURED_BOOT is enabled as in that case any modifications to the dt will cause measured boot to fail (although there are many other places the dt is altered). As this fdt node is added elsewhere create a library function and use it to deduplicate code. We will provide a parameter to overwrite the node if present. For our automatic injection, we will use the first rng device and not overwrite if already present with a non-zero value (which may have been populated by an earlier boot stage). This way if a board specific ft_board_setup() function wants to customize this behavior it can call fdt_kaslrseed with a rng device index of its choosing and set overwrite true. Note that the kalsrseed command (CMD_KASLRSEED) is likely pointless now but left in place in case boot scripts exist that rely on this command existing and returning success. An informational message is printed to alert users of this command that it is likely no longer needed. Note that the Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for randomization and completely ignores the kaslr-seed for its own randomness needs (i.e the randomization of the physical placement of the kernel). It gets weeded out from the DTB that gets handed over via efi_install_fdt() as it would also mess up the measured boot DTB TPM measurements as well. v5: - fixed typo in commit message s/it's/its/ - use cmd_process_error per Michal's suggestion - split into separate patches - remove the rng device index noting it as a future enhancement v4: - add missing /n to notice in kaslrseed cmd - combine ints in declaration - remove unused vars from board/xilinx/common/board.c ft_board_setup v3: - skip if CONFIG_MEASURED_BOOT - fix skip for CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT - pass in rng index and bool to specify overwrite - remove duplicate error strings printed outside of fdt_kaslrseed - added note to commit log about how EFI STUB weeds out kalsr-seed v2: - fix typo in commit msg - use stack for seed to avoid unecessary malloc/free - move to a library function and deduplicate code by using it elsewhere Tim Harvey (3): Add fdt_kaslrseed function to add kaslr-seed to chosen node fdt: automatically add /chosen/kaslr-seed if DM_RNG is enabled use fdt_kaslrseed function to de-duplicate code board/xilinx/common/board.c | 40 boot/fdt_support.c | 53 + boot/pxe_utils.c| 34 +--- cmd/kaslrseed.c | 49 +- include/fdt_support.h | 10 +++ 5 files changed, 71 insertions(+), 115 deletions(-) -- 2.25.1
Re: [PATCH v4] fdt: automatically add /chosen/kaslr-seed if DM_RNG is enabled
On Wed, May 29, 2024 at 6:39 PM Marek Vasut wrote: > > On 5/29/24 7:05 PM, Simon Glass wrote: > > [...] > > that is not yet implemented as DM_RNG. We also skip this if > MEASURED_BOOT is enabled as in that case any modifications to the > dt will cause measured boot to fail (although there are many other > places the dt is altered). > > As this fdt node is added elsewhere create a library function and > use it to deduplicate code. We will provide a parameter to specify the > index of the rng device as well as a boolean to overwrite if present. > > For our automatic injection, we will use the first rng device and > not overwrite if already present with a non-zero value (which may > have been populated by an earlier boot stage). This way if a board > specific ft_board_setup() function wants to customize this behavior > it can call fdt_kaslrseed with a rng device index of its choosing and > set overwrite true. > >>> > >>> I suggest creating a sysinfo driver which can provide the RNG device. > >> > >> I'm not really clear what you mean but that seems out of scope for > >> this patch. If/when someone needs to extend the functionality of > >> specifying one of many RNG's perhaps they can follow that approach. > > > > The thing is, you are creating a way to specify the RNG which will > > presumably lead to different vendors all doing it a different way. > > > > Specifically, fdt_kaslrseed() takes a device number (would be better > > to take a struct udevice, BTW). > > > > Instead, I think you should define the standard way that the chosen > > RNG should be specified by the board. The sysinfo driver can provide a > > way to do this. Then boards can handle this themselves, using sysinfo, > > rather than directly calling a function in the fixup. After all, we > > want the fixup flow to be as generic as possible. > > I think this patch simply picks up the first RNG that is available, > pulls a number out of it, and uses that as the KASLR seed in DT. That's > what the implementation(s) seems to be doing so far, this patch is a > deduplication only, so maybe we should retain the original behavior > first, and do architectural changes in follow up patch(es) ? Marek, Thank you - I had a draft saying exactly the same thing that I hadn't sent out yet. This is an incremental improvement... for sure there are follow-on improvements that can be made and should be made but the sysinfo and policy creation are something I don't have time for at the moment and may not be the right person to implement that. I'm happy to accept something to add to my series though! So the question is, if we can agree that improvements can continue to be made later should I do one more revision that split this out into three patches and fixes the typo in the commit? Best Regards, Tim
Re: [PATCH v4] fdt: automatically add /chosen/kaslr-seed if DM_RNG is enabled
On Wed, May 29, 2024 at 9:30 AM Simon Glass wrote: > > Hi Tim, > > On Sat, 25 May 2024 at 14:02, Tim Harvey wrote: > > > > If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to > > randomize the virtual address at which the kernel image is loaded, it > > expects entropy to be provided by the bootloader by populating > > /chosen/kaslr-seed with a 64-bit value from source of entropy at boot. > > > > If we have DM_RNG enabled populate this value automatically when > > fdt_chosen is called. We skip this if ARMV8_SEC_FIRMWARE_SUPPORT > > is enabled as it's implementation uses a different source of entropy > > its > Hi Simon, Thanks for the review. I can fix that. > > that is not yet implemented as DM_RNG. We also skip this if > > MEASURED_BOOT is enabled as in that case any modifications to the > > dt will cause measured boot to fail (although there are many other > > places the dt is altered). > > > > As this fdt node is added elsewhere create a library function and > > use it to deduplicate code. We will provide a parameter to specify the > > index of the rng device as well as a boolean to overwrite if present. > > > > For our automatic injection, we will use the first rng device and > > not overwrite if already present with a non-zero value (which may > > have been populated by an earlier boot stage). This way if a board > > specific ft_board_setup() function wants to customize this behavior > > it can call fdt_kaslrseed with a rng device index of its choosing and > > set overwrite true. > > I suggest creating a sysinfo driver which can provide the RNG device. I'm not really clear what you mean but that seems out of scope for this patch. If/when someone needs to extend the functionality of specifying one of many RNG's perhaps they can follow that approach. > > > > > Note that the kalsrseed command (CMD_KASLRSEED) is likely pointless now > > but left in place in case boot scripts exist that rely on this command > > existing and returning success. An informational message is printed to > > alert users of this command that it is likely no longer needed. > > > > Note that the Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for > > randomization and completely ignores the kaslr-seed for its own > > randomness needs (i.e the randomization of the physical placement of > > the kernel). It gets weeded out from the DTB that gets handed over via > > efi_install_fdt() as it would also mess up the measured boot DTB TPM > > measurements as well. > > > > Signed-off-by: Tim Harvey > > Cc: Michal Simek > > Cc: Andy Yan > > Cc: Akash Gajjar > > Cc: Ilias Apalodimas > > Cc: Simon Glass > > Cc: Patrick Delaunay > > Cc: Patrice Chotard > > Cc: Devarsh Thakkar > > Cc: Heinrich Schuchardt > > Cc: Hugo Villeneuve > > Cc: Marek Vasut > > Cc: Tom Rini > > Cc: Chris Morgan > > --- > > v4: > > - add missing /n to notice in kaslrseed cmd > > - combine ints in declaration > > - remove unused vars from board/xilinx/common/board.c ft_board_setup > > v3: > > - skip if CONFIG_MEASURED_BOOT > > - fix skip for CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT > > - pass in rng index and bool to specify overwrite > > - remove duplicate error strings printed outside of fdt_kaslrseed > > - added note to commit log about how EFI STUB weeds out kalsr-seed > > v2: > > - fix typo in commit msg > > - use stack for seed to avoid unecessary malloc/free > > - move to a library function and deduplicate code by using it > >elsewhere > > --- > > board/xilinx/common/board.c | 40 -- > > boot/fdt_support.c | 6 + > > boot/pxe_utils.c| 35 ++ > > cmd/kaslrseed.c | 45 +- > > include/kaslrseed.h | 19 ++ > > lib/Makefile| 1 + > > lib/kaslrseed.c | 49 + > > 7 files changed, 83 insertions(+), 112 deletions(-) > > create mode 100644 include/kaslrseed.h > > create mode 100644 lib/kaslrseed.c > > Are you able to split this patch into a few patches, one of which > handles the refactoring first? as in the following? 1/3 Add fdt_kaslrseed function to add kaslr-seed to chosen node 2/3 fdt: automatically add /chosen/kaslr-seed if DM_RNG is enabled 3/3 Use fdt_kaslrseed function to de-duplicate code > > > > > diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c > > index 30a813
Re: [PATCH v4] fdt: automatically add /chosen/kaslr-seed if DM_RNG is enabled
On Mon, May 27, 2024 at 1:30 AM Michal Simek wrote:
>
>
>
> On 5/25/24 22:02, Tim Harvey wrote:
> > If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
> > randomize the virtual address at which the kernel image is loaded, it
> > expects entropy to be provided by the bootloader by populating
> > /chosen/kaslr-seed with a 64-bit value from source of entropy at boot.
> >
> > If we have DM_RNG enabled populate this value automatically when
> > fdt_chosen is called. We skip this if ARMV8_SEC_FIRMWARE_SUPPORT
> > is enabled as it's implementation uses a different source of entropy
> > that is not yet implemented as DM_RNG. We also skip this if
> > MEASURED_BOOT is enabled as in that case any modifications to the
> > dt will cause measured boot to fail (although there are many other
> > places the dt is altered).
> >
> > As this fdt node is added elsewhere create a library function and
> > use it to deduplicate code. We will provide a parameter to specify the
> > index of the rng device as well as a boolean to overwrite if present.
> >
> > For our automatic injection, we will use the first rng device and
> > not overwrite if already present with a non-zero value (which may
> > have been populated by an earlier boot stage). This way if a board
> > specific ft_board_setup() function wants to customize this behavior
> > it can call fdt_kaslrseed with a rng device index of its choosing and
> > set overwrite true.
> >
> > Note that the kalsrseed command (CMD_KASLRSEED) is likely pointless now
> > but left in place in case boot scripts exist that rely on this command
> > existing and returning success. An informational message is printed to
> > alert users of this command that it is likely no longer needed.
> >
> > Note that the Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for
> > randomization and completely ignores the kaslr-seed for its own
> > randomness needs (i.e the randomization of the physical placement of
> > the kernel). It gets weeded out from the DTB that gets handed over via
> > efi_install_fdt() as it would also mess up the measured boot DTB TPM
> > measurements as well.
> >
> > Signed-off-by: Tim Harvey
> > Cc: Michal Simek
> > Cc: Andy Yan
> > Cc: Akash Gajjar
> > Cc: Ilias Apalodimas
> > Cc: Simon Glass
> > Cc: Patrick Delaunay
> > Cc: Patrice Chotard
> > Cc: Devarsh Thakkar
> > Cc: Heinrich Schuchardt
> > Cc: Hugo Villeneuve
> > Cc: Marek Vasut
> > Cc: Tom Rini
> > Cc: Chris Morgan
> > ---
> > v4:
> > - add missing /n to notice in kaslrseed cmd
> > - combine ints in declaration
> > - remove unused vars from board/xilinx/common/board.c ft_board_setup
> > v3:
> > - skip if CONFIG_MEASURED_BOOT
> > - fix skip for CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT
> > - pass in rng index and bool to specify overwrite
> > - remove duplicate error strings printed outside of fdt_kaslrseed
> > - added note to commit log about how EFI STUB weeds out kalsr-seed
> > v2:
> > - fix typo in commit msg
> > - use stack for seed to avoid unecessary malloc/free
> > - move to a library function and deduplicate code by using it
> > elsewhere
> > ---
> > board/xilinx/common/board.c | 40 --
> > boot/fdt_support.c | 6 +
> > boot/pxe_utils.c| 35 ++
> > cmd/kaslrseed.c | 45 +-
> > include/kaslrseed.h | 19 ++
> > lib/Makefile| 1 +
> > lib/kaslrseed.c | 49 +
> > 7 files changed, 83 insertions(+), 112 deletions(-)
> > create mode 100644 include/kaslrseed.h
> > create mode 100644 lib/kaslrseed.c
> >
> > diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
> > index 30a81376ac41..0b43407b9e94 100644
> > --- a/board/xilinx/common/board.c
> > +++ b/board/xilinx/common/board.c
> > @@ -701,11 +701,6 @@ phys_addr_t board_get_usable_ram_top(phys_size_t
> > total_size)
> > #define MAX_RAND_SIZE 8
> > int ft_board_setup(void *blob, struct bd_info *bd)
> > {
> > - size_t n = MAX_RAND_SIZE;
> > - struct udevice *dev;
> > - u8 buf[MAX_RAND_SIZE];
> > - int nodeoffset, ret;
> > -
> > static const struct node_info nodes[] = {
> > { "arm,pl353-nand-r2p1", MTD_DEV_TYPE_NAND, },
> > };
> > @@ -713,41 +708,6 @@ int ft
[PATCH v4] fdt: automatically add /chosen/kaslr-seed if DM_RNG is enabled
If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
randomize the virtual address at which the kernel image is loaded, it
expects entropy to be provided by the bootloader by populating
/chosen/kaslr-seed with a 64-bit value from source of entropy at boot.
If we have DM_RNG enabled populate this value automatically when
fdt_chosen is called. We skip this if ARMV8_SEC_FIRMWARE_SUPPORT
is enabled as it's implementation uses a different source of entropy
that is not yet implemented as DM_RNG. We also skip this if
MEASURED_BOOT is enabled as in that case any modifications to the
dt will cause measured boot to fail (although there are many other
places the dt is altered).
As this fdt node is added elsewhere create a library function and
use it to deduplicate code. We will provide a parameter to specify the
index of the rng device as well as a boolean to overwrite if present.
For our automatic injection, we will use the first rng device and
not overwrite if already present with a non-zero value (which may
have been populated by an earlier boot stage). This way if a board
specific ft_board_setup() function wants to customize this behavior
it can call fdt_kaslrseed with a rng device index of its choosing and
set overwrite true.
Note that the kalsrseed command (CMD_KASLRSEED) is likely pointless now
but left in place in case boot scripts exist that rely on this command
existing and returning success. An informational message is printed to
alert users of this command that it is likely no longer needed.
Note that the Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for
randomization and completely ignores the kaslr-seed for its own
randomness needs (i.e the randomization of the physical placement of
the kernel). It gets weeded out from the DTB that gets handed over via
efi_install_fdt() as it would also mess up the measured boot DTB TPM
measurements as well.
Signed-off-by: Tim Harvey
Cc: Michal Simek
Cc: Andy Yan
Cc: Akash Gajjar
Cc: Ilias Apalodimas
Cc: Simon Glass
Cc: Patrick Delaunay
Cc: Patrice Chotard
Cc: Devarsh Thakkar
Cc: Heinrich Schuchardt
Cc: Hugo Villeneuve
Cc: Marek Vasut
Cc: Tom Rini
Cc: Chris Morgan
---
v4:
- add missing /n to notice in kaslrseed cmd
- combine ints in declaration
- remove unused vars from board/xilinx/common/board.c ft_board_setup
v3:
- skip if CONFIG_MEASURED_BOOT
- fix skip for CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT
- pass in rng index and bool to specify overwrite
- remove duplicate error strings printed outside of fdt_kaslrseed
- added note to commit log about how EFI STUB weeds out kalsr-seed
v2:
- fix typo in commit msg
- use stack for seed to avoid unecessary malloc/free
- move to a library function and deduplicate code by using it
elsewhere
---
board/xilinx/common/board.c | 40 --
boot/fdt_support.c | 6 +
boot/pxe_utils.c| 35 ++
cmd/kaslrseed.c | 45 +-
include/kaslrseed.h | 19 ++
lib/Makefile| 1 +
lib/kaslrseed.c | 49 +
7 files changed, 83 insertions(+), 112 deletions(-)
create mode 100644 include/kaslrseed.h
create mode 100644 lib/kaslrseed.c
diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
index 30a81376ac41..0b43407b9e94 100644
--- a/board/xilinx/common/board.c
+++ b/board/xilinx/common/board.c
@@ -701,11 +701,6 @@ phys_addr_t board_get_usable_ram_top(phys_size_t
total_size)
#define MAX_RAND_SIZE 8
int ft_board_setup(void *blob, struct bd_info *bd)
{
- size_t n = MAX_RAND_SIZE;
- struct udevice *dev;
- u8 buf[MAX_RAND_SIZE];
- int nodeoffset, ret;
-
static const struct node_info nodes[] = {
{ "arm,pl353-nand-r2p1", MTD_DEV_TYPE_NAND, },
};
@@ -713,41 +708,6 @@ int ft_board_setup(void *blob, struct bd_info *bd)
if (IS_ENABLED(CONFIG_FDT_FIXUP_PARTITIONS) &&
IS_ENABLED(CONFIG_NAND_ZYNQ))
fdt_fixup_mtdparts(blob, nodes, ARRAY_SIZE(nodes));
- if (uclass_get_device(UCLASS_RNG, 0, ) || !dev) {
- debug("No RNG device\n");
- return 0;
- }
-
- if (dm_rng_read(dev, buf, n)) {
- debug("Reading RNG failed\n");
- return 0;
- }
-
- if (!blob) {
- debug("No FDT memory address configured. Please configure\n"
- "the FDT address via \"fdt addr \" command.\n"
- "Aborting!\n");
- return 0;
- }
-
- ret = fdt_check_header(blob);
- if (ret < 0) {
- debug("fdt_chosen: %s\n", fdt_strerror(ret));
- return ret;
- }
-
- nodeoffset = fdt_find_or_add_subnode(blob, 0, "chosen");
- if (nodeoffset < 0) {
- debug(&
[PATCH v5 1/2] tpm-v2: add support for mapping algorithm names to algos
replace tpm2_supported_algorithms with an array of structures
relating algorithm names, to TCG id's, digest length and mask values.
While at it fix the tpm2_algorithm_to_mask to return the proper value.
Fixes: 97707f12fdab ("tpm: Support boot measurements")
Signed-off-by: Tim Harvey
Reviewed-by: Ilias Apalodimas
Cc: Eddie James
Cc: Ilias Apalodimas
---
v5:
- use hash_len from struct vs calling more expensive tpm2_algorithm_to_mask
function
- collected rb tag
v4:
- new patch
merge: replace various calls to tomp2_algorithm_to_mask to struct dereference
---
include/tpm-v2.h | 77 ++--
lib/efi_loader/efi_tcg2.c | 6 +--
lib/tpm-v2.c | 82 +--
3 files changed, 129 insertions(+), 36 deletions(-)
diff --git a/include/tpm-v2.h b/include/tpm-v2.h
index 33dd103767c4..c9d5cb6d3e5a 100644
--- a/include/tpm-v2.h
+++ b/include/tpm-v2.h
@@ -386,7 +386,54 @@ enum tpm2_algorithms {
TPM2_ALG_SM3_256= 0x12,
};
-extern const enum tpm2_algorithms tpm2_supported_algorithms[4];
+/**
+ * struct digest_info - details of supported digests
+ *
+ * @hash_name: hash name
+ * @hash_alg: hash algorithm id
+ * @hash_mask: hash registry mask
+ * @hash_len: hash digest length
+ */
+struct digest_info {
+ const char *hash_name;
+ u16 hash_alg;
+ u32 hash_mask;
+ u16 hash_len;
+};
+
+/* Algorithm Registry */
+#define TCG2_BOOT_HASH_ALG_SHA10x0001
+#define TCG2_BOOT_HASH_ALG_SHA256 0x0002
+#define TCG2_BOOT_HASH_ALG_SHA384 0x0004
+#define TCG2_BOOT_HASH_ALG_SHA512 0x0008
+#define TCG2_BOOT_HASH_ALG_SM3_256 0x0010
+
+static const struct digest_info hash_algo_list[] = {
+ {
+ "sha1",
+ TPM2_ALG_SHA1,
+ TCG2_BOOT_HASH_ALG_SHA1,
+ TPM2_SHA1_DIGEST_SIZE,
+ },
+ {
+ "sha256",
+ TPM2_ALG_SHA256,
+ TCG2_BOOT_HASH_ALG_SHA256,
+ TPM2_SHA256_DIGEST_SIZE,
+ },
+ {
+ "sha384",
+ TPM2_ALG_SHA384,
+ TCG2_BOOT_HASH_ALG_SHA384,
+ TPM2_SHA384_DIGEST_SIZE,
+ },
+ {
+ "sha512",
+ TPM2_ALG_SHA512,
+ TCG2_BOOT_HASH_ALG_SHA512,
+ TPM2_SHA512_DIGEST_SIZE,
+ },
+};
static inline u16 tpm2_algorithm_to_len(enum tpm2_algorithms a)
{
@@ -404,8 +451,6 @@ static inline u16 tpm2_algorithm_to_len(enum
tpm2_algorithms a)
}
}
-#define tpm2_algorithm_to_mask(a) (1 << (a))
-
/* NV index attributes */
enum tpm_index_attrs {
TPMA_NV_PPWRITE = 1UL << 0,
@@ -965,4 +1010,30 @@ u32 tpm2_enable_nvcommits(struct udevice *dev, uint
vendor_cmd,
*/
u32 tpm2_auto_start(struct udevice *dev);
+/**
+ * tpm2_name_to_algorithm() - Return an algorithm id given a supported
+ * algorithm name
+ *
+ * @name: algorithm name
+ * Return: enum tpm2_algorithms or -EINVAL
+ */
+enum tpm2_algorithms tpm2_name_to_algorithm(const char *name);
+
+/**
+ * tpm2_algorithm_name() - Return an algorithm name string for a
+ *supported algorithm id
+ *
+ * @algorithm_id: algorithm defined in enum tpm2_algorithms
+ * Return: algorithm name string or ""
+ */
+const char *tpm2_algorithm_name(enum tpm2_algorithms);
+
+/**
+ * tpm2_algorithm_to_mask() - Get a TCG hash mask for algorithm
+ *
+ * @hash_alg: TCG defined algorithm
+ * Return: TCG hashing algorithm bitmaps (or 0 if algo not supported)
+ */
+u32 tpm2_algorithm_to_mask(enum tpm2_algorithms);
+
#endif /* __TPM_V2_H */
diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index b07e0099c27e..945aafb847d8 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -414,10 +414,10 @@ static efi_status_t tcg2_hash_pe_image(void *efi, u64
efi_size,
}
digest_list->count = 0;
- for (i = 0; i < ARRAY_SIZE(tpm2_supported_algorithms); i++) {
- u16 hash_alg = tpm2_supported_algorithms[i];
+ for (i = 0; i < ARRAY_SIZE(hash_algo_list); i++) {
+ u16 hash_alg = hash_algo_list[i].hash_alg;
- if (!(active & tpm2_algorithm_to_mask(hash_alg)))
+ if (!(active & hash_algo_list[i].hash_mask))
continue;
switch (hash_alg) {
case TPM2_ALG_SHA1:
diff --git a/lib/tpm-v2.c b/lib/tpm-v2.c
index 68eaaa639f89..a67daed2f3c1 100644
--- a/lib/tpm-v2.c
+++ b/lib/tpm-v2.c
@@ -22,13 +22,6 @@
#include "tpm-utils.h"
-const enum tpm2_algorithms tpm2_supported_algorithms[4] = {
- TPM2_ALG_SHA1,
- TPM2_ALG_SHA256,
- TPM2_ALG_SHA384,
- TPM2_ALG_SHA512,
-};
-
int tcg2_get_active_pcr_banks(struct udevice *dev, u32
[PATCH v5 2/2] tpm-v2: allow algorithm name to be configured for pcr_read and pcr_extend
For pcr_read and pcr_extend commands allow the digest algorithm to be
specified by an additional argument. If not specified it will default to
SHA256 for backwards compatibility.
Additionally update test_tpm2.py for the changes in output in pcr_read
which now shows the algo and algo length in the output.
A follow-on to this could be to extend all PCR banks with the detected
algo when the argument is 'auto'.
Signed-off-by: Tim Harvey
Reviewed-by: Ilias Apalodimas
---
v5:
- fix typo in commit description
- collected rb tag
v4:
- update test_tpm2.py as required by changes in pcr_read output
- split out moving algos to an array of structs to its own patch
and encorporate a fix for tpm2_algorithm_to_mask
v3:
- replace tpm2_supported_algorithms with struct and use this to
relate hash algoirthm details
v2:
- use tpm2_algorithm_to_len
- use enum tpm2_algorithms
- make function names and parameter names more consistent with existing
tpm-v2 functions
- fix various spelling errors
---
cmd/tpm-v2.c | 49 +++---
test/py/tests/test_tpm2.py | 2 +-
2 files changed, 36 insertions(+), 15 deletions(-)
diff --git a/cmd/tpm-v2.c b/cmd/tpm-v2.c
index 7e479b9dfe36..2343b4d9cb9e 100644
--- a/cmd/tpm-v2.c
+++ b/cmd/tpm-v2.c
@@ -99,11 +99,19 @@ static int do_tpm2_pcr_extend(struct cmd_tbl *cmdtp, int
flag, int argc,
struct tpm_chip_priv *priv;
u32 index = simple_strtoul(argv[1], NULL, 0);
void *digest = map_sysmem(simple_strtoul(argv[2], NULL, 0), 0);
+ int algo = TPM2_ALG_SHA256;
+ int algo_len;
int ret;
u32 rc;
- if (argc != 3)
+ if (argc < 3 || argc > 4)
return CMD_RET_USAGE;
+ if (argc == 4) {
+ algo = tpm2_name_to_algorithm(argv[3]);
+ if (algo < 0)
+ return CMD_RET_FAILURE;
+ }
+ algo_len = tpm2_algorithm_to_len(algo);
ret = get_tpm();
if (ret)
@@ -116,8 +124,12 @@ static int do_tpm2_pcr_extend(struct cmd_tbl *cmdtp, int
flag, int argc,
if (index >= priv->pcr_count)
return -EINVAL;
- rc = tpm2_pcr_extend(dev, index, TPM2_ALG_SHA256, digest,
-TPM2_DIGEST_LEN);
+ rc = tpm2_pcr_extend(dev, index, algo, digest, algo_len);
+ if (!rc) {
+ printf("PCR #%u extended with %d byte %s digest\n", index,
+ algo_len, tpm2_algorithm_name(algo));
+ print_byte_string(digest, algo_len);
+ }
unmap_sysmem(digest);
@@ -127,15 +139,23 @@ static int do_tpm2_pcr_extend(struct cmd_tbl *cmdtp, int
flag, int argc,
static int do_tpm_pcr_read(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
{
+ enum tpm2_algorithms algo = TPM2_ALG_SHA256;
struct udevice *dev;
struct tpm_chip_priv *priv;
u32 index, rc;
+ int algo_len;
unsigned int updates;
void *data;
int ret;
- if (argc != 3)
+ if (argc < 3 || argc > 4)
return CMD_RET_USAGE;
+ if (argc == 4) {
+ algo = tpm2_name_to_algorithm(argv[3]);
+ if (algo < 0)
+ return CMD_RET_FAILURE;
+ }
+ algo_len = tpm2_algorithm_to_len(algo);
ret = get_tpm();
if (ret)
@@ -151,11 +171,12 @@ static int do_tpm_pcr_read(struct cmd_tbl *cmdtp, int
flag, int argc,
data = map_sysmem(simple_strtoul(argv[2], NULL, 0), 0);
- rc = tpm2_pcr_read(dev, index, priv->pcr_select_min, TPM2_ALG_SHA256,
- data, TPM2_DIGEST_LEN, );
+ rc = tpm2_pcr_read(dev, index, priv->pcr_select_min, algo,
+ data, algo_len, );
if (!rc) {
- printf("PCR #%u content (%u known updates):\n", index, updates);
- print_byte_string(data, TPM2_DIGEST_LEN);
+ printf("PCR #%u %s %d byte content (%u known updates):\n",
index,
+ tpm2_algorithm_name(algo), algo_len, updates);
+ print_byte_string(data, algo_len);
}
unmap_sysmem(data);
@@ -415,14 +436,14 @@ U_BOOT_CMD(tpm2, CONFIG_SYS_MAXARGS, 1, do_tpm, "Issue a
TPMv2.x command",
" is one of:\n"
"* TPM2_RH_LOCKOUT\n"
"* TPM2_RH_PLATFORM\n"
-"pcr_extend \n"
-"Extend PCR # with digest at .\n"
+"pcr_extend []\n"
+"Extend PCR # with digest at with digest_algo.\n"
": index of the PCR\n"
-": address of a 32-byte SHA256 digest\n"
-"pcr_read \n"
-"Read PCR # to memory address .\n"
+": address of digest of digest_algo type (defaults to
SHA256)\n"
+"pcr_read []\n"
+"Read PCR # to memory address with .
Re: [PATCH 1/2 v4] tpm-v2: add support for mapping algorithm names to algos
On Wed, May 22, 2024 at 3:33 AM Ilias Apalodimas
wrote:
>
> Hi Tim
>
> Thanks for fixing this.
>
> Can we replace tpm2_algorithm_to_mask() with hash_algo_list[i].hash_mask in
> - lib/tpm-v2.c lines 80, 205 250
> - lib/efi_loader/efi_tcg2.c line 420
Yes, that makes sense. I'll also remove the unnecessary variable from
the stack in those cases:
diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index cf5d8de018a7..945aafb847d8 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -417,7 +417,7 @@ static efi_status_t tcg2_hash_pe_image(void *efi,
u64 efi_size,
for (i = 0; i < ARRAY_SIZE(hash_algo_list); i++) {
u16 hash_alg = hash_algo_list[i].hash_alg;
- if (!(active & tpm2_algorithm_to_mask(hash_alg)))
+ if (!(active & hash_algo_list[i].hash_mask))
continue;
switch (hash_alg) {
case TPM2_ALG_SHA1:
diff --git a/lib/tpm-v2.c b/lib/tpm-v2.c
index 2fc680a8adf8..a67daed2f3c1 100644
--- a/lib/tpm-v2.c
+++ b/lib/tpm-v2.c
@@ -76,10 +76,7 @@ int tcg2_create_digest(struct udevice *dev, const
u8 *input, u32 length,
digest_list->count = 0;
for (i = 0; i < ARRAY_SIZE(hash_algo_list); ++i) {
- u32 mask =
- tpm2_algorithm_to_mask(hash_algo_list[i].hash_alg);
-
- if (!(active & mask))
+ if (!(active & hash_algo_list[i].hash_mask))
continue;
switch (hash_algo_list[i].hash_alg) {
@@ -191,7 +188,6 @@ static int tcg2_log_init(struct udevice *dev,
struct tcg2_event_log *elog)
u32 count = 0;
u32 log_size;
u32 active;
- u32 mask;
size_t i;
u16 len;
int rc;
@@ -202,9 +198,7 @@ static int tcg2_log_init(struct udevice *dev,
struct tcg2_event_log *elog)
event_size = offsetof(struct tcg_efi_spec_id_event, digest_sizes);
for (i = 0; i < ARRAY_SIZE(hash_algo_list); ++i) {
- mask = tpm2_algorithm_to_mask(hash_algo_list[i].hash_alg);
-
- if (!(active & mask))
+ if (!(active & hash_algo_list[i].hash_mask))
continue;
switch (hash_algo_list[i].hash_alg) {
@@ -247,9 +241,7 @@ static int tcg2_log_init(struct udevice *dev,
struct tcg2_event_log *elog)
count = 0;
for (i = 0; i < ARRAY_SIZE(hash_algo_list); ++i) {
- mask = tpm2_algorithm_to_mask(hash_algo_list[i].hash_alg);
-
- if (!(active & mask))
+ if (!(active & hash_algo_list[i].hash_mask))
continue;
len = hash_algo_list[i].hash_len;
>
> With these changes
> Reviewed-by: Ilias Apalodimas
>
Thanks,
Tim
>
> On Wed, 22 May 2024 at 00:38, Tim Harvey wrote:
> >
> > replace tpm2_supported_algorithms with an array of structures
> > relating algorithm names, to TCG id's, digest length and mask values.
> >
> > While at it fix the tpm2_algorithm_to_mask to return the proper value.
> >
> > Fixes: 97707f12fdab ("tpm: Support boot measurements")
> > Signed-off-by: Tim Harvey
> > Cc: Eddie James
> > Cc: Ilias Apalodimas
> > ---
> > v4:
> > - new patch
> > ---
> > include/tpm-v2.h | 77 +--
> > lib/efi_loader/efi_tcg2.c | 4 +-
> > lib/tpm-v2.c | 74 ++---
> > 3 files changed, 128 insertions(+), 27 deletions(-)
> >
> > diff --git a/include/tpm-v2.h b/include/tpm-v2.h
> > index 33dd103767c4..c9d5cb6d3e5a 100644
> > --- a/include/tpm-v2.h
> > +++ b/include/tpm-v2.h
> > @@ -386,7 +386,54 @@ enum tpm2_algorithms {
> > TPM2_ALG_SM3_256= 0x12,
> > };
> >
> > -extern const enum tpm2_algorithms tpm2_supported_algorithms[4];
> > +/**
> > + * struct digest_info - details of supported digests
> > + *
> > + * @hash_name: hash name
> > + * @hash_alg: hash algorithm id
> > + * @hash_mask: hash registry mask
> > + * @hash_len: hash digest length
> > + */
> > +struct digest_info {
> > + const char *hash_name;
> > + u16 hash_alg;
> > + u32 hash_mask;
> > + u16 hash_len;
> > +};
> > +
> > +/* Algorithm Registry */
> > +#define TCG2_BOOT_HASH_ALG_SHA10x0001
> > +#define TCG2_BOOT_HASH_ALG_SHA256 0x0002
> > +#define TCG2_BOOT_HASH_ALG_SHA384 0x0004
> > +#define TCG2_BOOT_HASH_ALG_SHA512 0x0008
> > +#define TCG2_BOOT_HASH_ALG_SM3_256 0x0010
> > +
> >
Re: [PATCH v3] fdt: automatically add /chosen/kaslr-seed if DM_RNG is enabled
On Wed, May 22, 2024 at 12:47 AM Michal Simek wrote: > > > > On 5/21/24 22:59, Tim Harvey wrote: > > If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to > > randomize the virtual address at which the kernel image is loaded, it > > expects entropy to be provided by the bootloader by populating > > /chosen/kaslr-seed with a 64-bit value from source of entropy at boot. > > > > If we have DM_RNG enabled populate this value automatically when > > fdt_chosen is called. We skip this if ARMV8_SEC_FIRMWARE_SUPPORT > > is enabled as it's implementation uses a different source of entropy > > that is not yet implemented as DM_RNG. We also skip this if > > MEASURED_BOOT is enabled as in that case any modifications to the > > dt will cause measured boot to fail (although there are many other > > places the dt is altered). > > > > As this fdt node is added elsewhere create a library function and > > use it to deduplicate code. We will provide a parameter to specify the > > index of the rng device as well as a boolean to overwrite if present. > > > > For our automatic injection, we will use the first rng device and > > not overwrite if already present with a non-zero value (which may > > have been populated by an earlier boot stage). This way if a board > > specific ft_board_setup() function wants to customize this behavior > > it can call fdt_kaslrseed with a rng device index of its choosing and > > set overwrite true. > > > > Note that the kalsrseed command (CMD_KASLRSEED) is likely pointless now > > but left in place in case boot scripts exist that rely on this command > > existing and returning success. An informational message is printed to > > alert users of this command that it is likely no longer needed. > > > > Note that the Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for > > randomization and completely ignores the kaslr-seed for its own > > randomness needs (i.e the randomization of the physical placement of > > the kernel). It gets weeded out from the DTB that gets handed over via > > efi_install_fdt() as it would also mess up the measured boot DTB TPM > > measurements as well. > > > > Signed-off-by: Tim Harvey > > Cc: Michal Simek > > Cc: Andy Yan > > Cc: Akash Gajjar > > Cc: Ilias Apalodimas > > Cc: Simon Glass > > Cc: Patrick Delaunay > > Cc: Patrice Chotard > > Cc: Devarsh Thakkar > > Cc: Heinrich Schuchardt > > Cc: Hugo Villeneuve > > Cc: Marek Vasut > > Cc: Tom Rini > > Cc: Chris Morgan > > --- > > v3: > > - skip if CONFIG_MEASURED_BOOT > > - fix skip for CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT > > - pass in rng index and bool to specify overwrite > > - remove duplicate error strings printed outside of fdt_kaslrseed > > - added note to commit log about how EFI STUB weeds out kalsr-seed > > > > v2: > > - fix typo in commit msg > > - use stack for seed to avoid unecessary malloc/free > > - move to a library function and deduplicate code by using it > > elsewhere > > --- > > board/xilinx/common/board.c | 35 - > > boot/fdt_support.c | 6 + > > boot/pxe_utils.c| 35 ++--- > > cmd/kaslrseed.c | 45 +--- > > include/kaslrseed.h | 19 ++ > > lib/Makefile| 1 + > > lib/kaslrseed.c | 51 + > > 7 files changed, 85 insertions(+), 107 deletions(-) > > create mode 100644 include/kaslrseed.h > > create mode 100644 lib/kaslrseed.c > > > > diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c > > index 30a81376ac41..f741e8957818 100644 > > --- a/board/xilinx/common/board.c > > +++ b/board/xilinx/common/board.c > > @@ -713,41 +713,6 @@ int ft_board_setup(void *blob, struct bd_info *bd) > > if (IS_ENABLED(CONFIG_FDT_FIXUP_PARTITIONS) && > > IS_ENABLED(CONFIG_NAND_ZYNQ)) > > fdt_fixup_mtdparts(blob, nodes, ARRAY_SIZE(nodes)); > > > > one more thing here. Please also removed unused variables. > > board/xilinx/common/board.c: In function 'ft_board_setup': > board/xilinx/common/board.c:707:25: warning: unused variable 'ret' > [-Wunused-variable] >707 | int nodeoffset, ret; >| ^~~ > board/xilinx/common/board.c:707:13: warning: unused variable 'nodeoffset' > [-Wunused-variable] >707 | int nodeoffset, ret; >| ^~~~
[PATCH 1/2 v4] tpm-v2: add support for mapping algorithm names to algos
replace tpm2_supported_algorithms with an array of structures
relating algorithm names, to TCG id's, digest length and mask values.
While at it fix the tpm2_algorithm_to_mask to return the proper value.
Fixes: 97707f12fdab ("tpm: Support boot measurements")
Signed-off-by: Tim Harvey
Cc: Eddie James
Cc: Ilias Apalodimas
---
v4:
- new patch
---
include/tpm-v2.h | 77 +--
lib/efi_loader/efi_tcg2.c | 4 +-
lib/tpm-v2.c | 74 ++---
3 files changed, 128 insertions(+), 27 deletions(-)
diff --git a/include/tpm-v2.h b/include/tpm-v2.h
index 33dd103767c4..c9d5cb6d3e5a 100644
--- a/include/tpm-v2.h
+++ b/include/tpm-v2.h
@@ -386,7 +386,54 @@ enum tpm2_algorithms {
TPM2_ALG_SM3_256= 0x12,
};
-extern const enum tpm2_algorithms tpm2_supported_algorithms[4];
+/**
+ * struct digest_info - details of supported digests
+ *
+ * @hash_name: hash name
+ * @hash_alg: hash algorithm id
+ * @hash_mask: hash registry mask
+ * @hash_len: hash digest length
+ */
+struct digest_info {
+ const char *hash_name;
+ u16 hash_alg;
+ u32 hash_mask;
+ u16 hash_len;
+};
+
+/* Algorithm Registry */
+#define TCG2_BOOT_HASH_ALG_SHA10x0001
+#define TCG2_BOOT_HASH_ALG_SHA256 0x0002
+#define TCG2_BOOT_HASH_ALG_SHA384 0x0004
+#define TCG2_BOOT_HASH_ALG_SHA512 0x0008
+#define TCG2_BOOT_HASH_ALG_SM3_256 0x0010
+
+static const struct digest_info hash_algo_list[] = {
+ {
+ "sha1",
+ TPM2_ALG_SHA1,
+ TCG2_BOOT_HASH_ALG_SHA1,
+ TPM2_SHA1_DIGEST_SIZE,
+ },
+ {
+ "sha256",
+ TPM2_ALG_SHA256,
+ TCG2_BOOT_HASH_ALG_SHA256,
+ TPM2_SHA256_DIGEST_SIZE,
+ },
+ {
+ "sha384",
+ TPM2_ALG_SHA384,
+ TCG2_BOOT_HASH_ALG_SHA384,
+ TPM2_SHA384_DIGEST_SIZE,
+ },
+ {
+ "sha512",
+ TPM2_ALG_SHA512,
+ TCG2_BOOT_HASH_ALG_SHA512,
+ TPM2_SHA512_DIGEST_SIZE,
+ },
+};
static inline u16 tpm2_algorithm_to_len(enum tpm2_algorithms a)
{
@@ -404,8 +451,6 @@ static inline u16 tpm2_algorithm_to_len(enum
tpm2_algorithms a)
}
}
-#define tpm2_algorithm_to_mask(a) (1 << (a))
-
/* NV index attributes */
enum tpm_index_attrs {
TPMA_NV_PPWRITE = 1UL << 0,
@@ -965,4 +1010,30 @@ u32 tpm2_enable_nvcommits(struct udevice *dev, uint
vendor_cmd,
*/
u32 tpm2_auto_start(struct udevice *dev);
+/**
+ * tpm2_name_to_algorithm() - Return an algorithm id given a supported
+ * algorithm name
+ *
+ * @name: algorithm name
+ * Return: enum tpm2_algorithms or -EINVAL
+ */
+enum tpm2_algorithms tpm2_name_to_algorithm(const char *name);
+
+/**
+ * tpm2_algorithm_name() - Return an algorithm name string for a
+ *supported algorithm id
+ *
+ * @algorithm_id: algorithm defined in enum tpm2_algorithms
+ * Return: algorithm name string or ""
+ */
+const char *tpm2_algorithm_name(enum tpm2_algorithms);
+
+/**
+ * tpm2_algorithm_to_mask() - Get a TCG hash mask for algorithm
+ *
+ * @hash_alg: TCG defined algorithm
+ * Return: TCG hashing algorithm bitmaps (or 0 if algo not supported)
+ */
+u32 tpm2_algorithm_to_mask(enum tpm2_algorithms);
+
#endif /* __TPM_V2_H */
diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index b07e0099c27e..cf5d8de018a7 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -414,8 +414,8 @@ static efi_status_t tcg2_hash_pe_image(void *efi, u64
efi_size,
}
digest_list->count = 0;
- for (i = 0; i < ARRAY_SIZE(tpm2_supported_algorithms); i++) {
- u16 hash_alg = tpm2_supported_algorithms[i];
+ for (i = 0; i < ARRAY_SIZE(hash_algo_list); i++) {
+ u16 hash_alg = hash_algo_list[i].hash_alg;
if (!(active & tpm2_algorithm_to_mask(hash_alg)))
continue;
diff --git a/lib/tpm-v2.c b/lib/tpm-v2.c
index 68eaaa639f89..2fc680a8adf8 100644
--- a/lib/tpm-v2.c
+++ b/lib/tpm-v2.c
@@ -22,13 +22,6 @@
#include "tpm-utils.h"
-const enum tpm2_algorithms tpm2_supported_algorithms[4] = {
- TPM2_ALG_SHA1,
- TPM2_ALG_SHA256,
- TPM2_ALG_SHA384,
- TPM2_ALG_SHA512,
-};
-
int tcg2_get_active_pcr_banks(struct udevice *dev, u32 *active_pcr_banks)
{
u32 supported = 0;
@@ -82,14 +75,14 @@ int tcg2_create_digest(struct udevice *dev, const u8
*input, u32 length,
return rc;
digest_list->count = 0;
- for (i = 0; i < ARRAY_SIZE(tpm2_supported_algorithms); ++i) {
+ for (i = 0; i < ARRAY_SIZE(hash_algo_list); ++i)
[PATCH 2/2 v4] tpm-v2: allow algoirthm name to be configured for pcr_read and pcr_extend
For pcr_read and pcr_extend commands allow the digest algorithm to be
specified by an additional argument. If not specified it will default to
SHA256 for backwards compatibility.
Additionally update test_tpm2.py for the changes in output in pcr_read
which now shows the algo and algo length in the output.
A follow-on to this could be to extend all PCR banks with the detected
algo when the argument is 'auto'.
Signed-off-by: Tim Harvey
---
v4:
- update test_tpm2.py as required by changes in pcr_read output
- split out moving algos to an array of structs to its own patch
and encorporate a fix for tpm2_algorithm_to_mask
v3:
- replace tpm2_supported_algorithms with struct and use this to
relate hash algoirthm details
v2:
- use tpm2_algorithm_to_len
- use enum tpm2_algorithms
- make function names and parameter names more consistent with existing
tpm-v2 functions
- fix various spelling errors
---
cmd/tpm-v2.c | 49 +++---
test/py/tests/test_tpm2.py | 2 +-
2 files changed, 36 insertions(+), 15 deletions(-)
diff --git a/cmd/tpm-v2.c b/cmd/tpm-v2.c
index 7e479b9dfe36..2343b4d9cb9e 100644
--- a/cmd/tpm-v2.c
+++ b/cmd/tpm-v2.c
@@ -99,11 +99,19 @@ static int do_tpm2_pcr_extend(struct cmd_tbl *cmdtp, int
flag, int argc,
struct tpm_chip_priv *priv;
u32 index = simple_strtoul(argv[1], NULL, 0);
void *digest = map_sysmem(simple_strtoul(argv[2], NULL, 0), 0);
+ int algo = TPM2_ALG_SHA256;
+ int algo_len;
int ret;
u32 rc;
- if (argc != 3)
+ if (argc < 3 || argc > 4)
return CMD_RET_USAGE;
+ if (argc == 4) {
+ algo = tpm2_name_to_algorithm(argv[3]);
+ if (algo < 0)
+ return CMD_RET_FAILURE;
+ }
+ algo_len = tpm2_algorithm_to_len(algo);
ret = get_tpm();
if (ret)
@@ -116,8 +124,12 @@ static int do_tpm2_pcr_extend(struct cmd_tbl *cmdtp, int
flag, int argc,
if (index >= priv->pcr_count)
return -EINVAL;
- rc = tpm2_pcr_extend(dev, index, TPM2_ALG_SHA256, digest,
-TPM2_DIGEST_LEN);
+ rc = tpm2_pcr_extend(dev, index, algo, digest, algo_len);
+ if (!rc) {
+ printf("PCR #%u extended with %d byte %s digest\n", index,
+ algo_len, tpm2_algorithm_name(algo));
+ print_byte_string(digest, algo_len);
+ }
unmap_sysmem(digest);
@@ -127,15 +139,23 @@ static int do_tpm2_pcr_extend(struct cmd_tbl *cmdtp, int
flag, int argc,
static int do_tpm_pcr_read(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
{
+ enum tpm2_algorithms algo = TPM2_ALG_SHA256;
struct udevice *dev;
struct tpm_chip_priv *priv;
u32 index, rc;
+ int algo_len;
unsigned int updates;
void *data;
int ret;
- if (argc != 3)
+ if (argc < 3 || argc > 4)
return CMD_RET_USAGE;
+ if (argc == 4) {
+ algo = tpm2_name_to_algorithm(argv[3]);
+ if (algo < 0)
+ return CMD_RET_FAILURE;
+ }
+ algo_len = tpm2_algorithm_to_len(algo);
ret = get_tpm();
if (ret)
@@ -151,11 +171,12 @@ static int do_tpm_pcr_read(struct cmd_tbl *cmdtp, int
flag, int argc,
data = map_sysmem(simple_strtoul(argv[2], NULL, 0), 0);
- rc = tpm2_pcr_read(dev, index, priv->pcr_select_min, TPM2_ALG_SHA256,
- data, TPM2_DIGEST_LEN, );
+ rc = tpm2_pcr_read(dev, index, priv->pcr_select_min, algo,
+ data, algo_len, );
if (!rc) {
- printf("PCR #%u content (%u known updates):\n", index, updates);
- print_byte_string(data, TPM2_DIGEST_LEN);
+ printf("PCR #%u %s %d byte content (%u known updates):\n",
index,
+ tpm2_algorithm_name(algo), algo_len, updates);
+ print_byte_string(data, algo_len);
}
unmap_sysmem(data);
@@ -415,14 +436,14 @@ U_BOOT_CMD(tpm2, CONFIG_SYS_MAXARGS, 1, do_tpm, "Issue a
TPMv2.x command",
" is one of:\n"
"* TPM2_RH_LOCKOUT\n"
"* TPM2_RH_PLATFORM\n"
-"pcr_extend \n"
-"Extend PCR # with digest at .\n"
+"pcr_extend []\n"
+"Extend PCR # with digest at with digest_algo.\n"
": index of the PCR\n"
-": address of a 32-byte SHA256 digest\n"
-"pcr_read \n"
-"Read PCR # to memory address .\n"
+": address of digest of digest_algo type (defaults to
SHA256)\n"
+"pcr_read []\n"
+"Read PCR # to memory address with .\n"
": index of the PCR\n"
-": address to store the a 32-byte
[PATCH v3] fdt: automatically add /chosen/kaslr-seed if DM_RNG is enabled
If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
randomize the virtual address at which the kernel image is loaded, it
expects entropy to be provided by the bootloader by populating
/chosen/kaslr-seed with a 64-bit value from source of entropy at boot.
If we have DM_RNG enabled populate this value automatically when
fdt_chosen is called. We skip this if ARMV8_SEC_FIRMWARE_SUPPORT
is enabled as it's implementation uses a different source of entropy
that is not yet implemented as DM_RNG. We also skip this if
MEASURED_BOOT is enabled as in that case any modifications to the
dt will cause measured boot to fail (although there are many other
places the dt is altered).
As this fdt node is added elsewhere create a library function and
use it to deduplicate code. We will provide a parameter to specify the
index of the rng device as well as a boolean to overwrite if present.
For our automatic injection, we will use the first rng device and
not overwrite if already present with a non-zero value (which may
have been populated by an earlier boot stage). This way if a board
specific ft_board_setup() function wants to customize this behavior
it can call fdt_kaslrseed with a rng device index of its choosing and
set overwrite true.
Note that the kalsrseed command (CMD_KASLRSEED) is likely pointless now
but left in place in case boot scripts exist that rely on this command
existing and returning success. An informational message is printed to
alert users of this command that it is likely no longer needed.
Note that the Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for
randomization and completely ignores the kaslr-seed for its own
randomness needs (i.e the randomization of the physical placement of
the kernel). It gets weeded out from the DTB that gets handed over via
efi_install_fdt() as it would also mess up the measured boot DTB TPM
measurements as well.
Signed-off-by: Tim Harvey
Cc: Michal Simek
Cc: Andy Yan
Cc: Akash Gajjar
Cc: Ilias Apalodimas
Cc: Simon Glass
Cc: Patrick Delaunay
Cc: Patrice Chotard
Cc: Devarsh Thakkar
Cc: Heinrich Schuchardt
Cc: Hugo Villeneuve
Cc: Marek Vasut
Cc: Tom Rini
Cc: Chris Morgan
---
v3:
- skip if CONFIG_MEASURED_BOOT
- fix skip for CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT
- pass in rng index and bool to specify overwrite
- remove duplicate error strings printed outside of fdt_kaslrseed
- added note to commit log about how EFI STUB weeds out kalsr-seed
v2:
- fix typo in commit msg
- use stack for seed to avoid unecessary malloc/free
- move to a library function and deduplicate code by using it
elsewhere
---
board/xilinx/common/board.c | 35 -
boot/fdt_support.c | 6 +
boot/pxe_utils.c| 35 ++---
cmd/kaslrseed.c | 45 +---
include/kaslrseed.h | 19 ++
lib/Makefile| 1 +
lib/kaslrseed.c | 51 +
7 files changed, 85 insertions(+), 107 deletions(-)
create mode 100644 include/kaslrseed.h
create mode 100644 lib/kaslrseed.c
diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
index 30a81376ac41..f741e8957818 100644
--- a/board/xilinx/common/board.c
+++ b/board/xilinx/common/board.c
@@ -713,41 +713,6 @@ int ft_board_setup(void *blob, struct bd_info *bd)
if (IS_ENABLED(CONFIG_FDT_FIXUP_PARTITIONS) &&
IS_ENABLED(CONFIG_NAND_ZYNQ))
fdt_fixup_mtdparts(blob, nodes, ARRAY_SIZE(nodes));
- if (uclass_get_device(UCLASS_RNG, 0, ) || !dev) {
- debug("No RNG device\n");
- return 0;
- }
-
- if (dm_rng_read(dev, buf, n)) {
- debug("Reading RNG failed\n");
- return 0;
- }
-
- if (!blob) {
- debug("No FDT memory address configured. Please configure\n"
- "the FDT address via \"fdt addr \" command.\n"
- "Aborting!\n");
- return 0;
- }
-
- ret = fdt_check_header(blob);
- if (ret < 0) {
- debug("fdt_chosen: %s\n", fdt_strerror(ret));
- return ret;
- }
-
- nodeoffset = fdt_find_or_add_subnode(blob, 0, "chosen");
- if (nodeoffset < 0) {
- debug("Reading chosen node failed\n");
- return nodeoffset;
- }
-
- ret = fdt_setprop(blob, nodeoffset, "kaslr-seed", buf, sizeof(buf));
- if (ret < 0) {
- debug("Unable to set kaslr-seed on chosen node: %s\n",
fdt_strerror(ret));
- return ret;
- }
-
return 0;
}
#endif
diff --git a/boot/fdt_support.c b/boot/fdt_support.c
index 874ca4d6f5af..b64cdd34825a 100644
--- a/boot/fdt_support.c
+++ b/boot/fdt_support.c
@@ -8,6 +8,7 @@
#include
#include
+#include
#i
Re: [PATCH v2] fdt: automatically add /chosen/kaslr-seed if DM_RNG is enabled
On Tue, May 21, 2024 at 11:59 AM Ilias Apalodimas
wrote:
>
> On Tue, 21 May 2024 at 21:05, Tim Harvey wrote:
> >
> > On Tue, May 21, 2024 at 10:29 AM Ilias Apalodimas
> > wrote:
> > >
> > > On Tue, 21 May 2024 at 20:06, Tim Harvey wrote:
> > > >
> > > > On Tue, May 21, 2024 at 9:54 AM Ilias Apalodimas
> > > > wrote:
> > > > >
> > > > > Hi Tim,
> > > > >
> > > > > On Tue, 21 May 2024 at 19:37, Tim Harvey
> > > > > wrote:
> > > > > >
> > > > > > On Tue, May 21, 2024 at 5:05 AM Ilias Apalodimas
> > > > > > wrote:
> > > > > > >
> > > > > > > Hi Tim
> > > > > > >
> > > > > > > On Wed, 15 May 2024 at 23:50, Tim Harvey
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > If RANDOMIZE_BASE is enabled in the Linux kernel instructing it
> > > > > > > > to
> > > > > > > > randomize the virtual address at which the kernel image is
> > > > > > > > loaded, it
> > > > > > > > expects entropy to be provided by the bootloader by populating
> > > > > > > > /chosen/kaslr-seed with a 64-bit value from source of entropy
> > > > > > > > at boot.
> > > > > > >
> > > > > > > Since you'll send a v2, mind adding some description for UEFI on
> > > > > > > the
> > > > > > > commit message?
> > > > > > > efi_try_purge_kaslr_seed() has a comment of the behaviour
> > > > > > >
> > > > > >
> > > > > > Hi Ilias,
> > > > > >
> > > > > > Ok, I will add the following to the commit log for clarity:
> > > > > > Note that the Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for
> > > > > > randomization and completely ignores the kaslr-seed for its own
> > > > > > randomness needs (i.e the randomization of the physical placement of
> > > > > > the kernel). It gets weeded out from the DTB that gets handed over
> > > > > > via
> > > > > > efi_install_fdt() as it would also mess up the measured boot DTB TPM
> > > > > > measurements as well.
> > > > > >
> > > > > > Does the above mean that I don't need to worry about protecting the
> > > > > > call to fdt_kaslrseed() with a check for MEASURED BOOT as
> > > > > > efi_install_fdt/efi_try_purge_kaslr_seed always gets called in that
> > > > > > case?
> > > > >
> > > > > There are 2 ways to do measured boot. One is via the bootm command and
> > > > > the other is via the EFI protocols.
> > > > > CONFIG_MEASURED_BOOT only applies to bootm.
> > > > > OTOH kaslr-seed might still have value if EFI_RNG is disabled, even
> > > > > when booting with EFI, since the kernel will randomize the virtual
> > > > > placement if it finds that.
> > > > >
> > > > > But in any case, a kaslr-seed entry can't be present in the DTB if you
> > > > > plan to measure it.
> > > >
> > > > ok, sounds like I need to use:
> > > >
> > > > if (IS_ENABLED(CONFIG_DM_RNG) &&
> > > > !IS_ENABLED(ARMV8_SEC_FIRMWARE_SUPPORT)) &&
> > > > !IS_ENABLED(CONFIG_MEASURED_BOOT) {
> > > > fdt_kaslrseed...
> > > > }
> > > >
> > >
> > > Can't we measure the DT *before* adding the kaslr-seed?
> > >
> >
> > You tell me... I'm deferring to you regarding what is needed for this
> > patch for measured boot.
> >
> > What changes do I need to make and why?
>
> Ok, thinking it a bit more we can't reliably measure the DT before a
> kaslr-seed gets injected, simply because an earlier stage bootloader
> might have injected it That's why we had a config option (and at
> least we mention it in aa2d3945ce6df43903d76cadde1c0669d6d5d43b but
> not in great detail).
> However, for a user that's far from ideal since he needs to be aware
> of those details before enabling measurements for the DT.
>
> Looking at our EFI code we *try* to purge the kaslr-seed before
> measuring the DT, but that doesn't guarantee it won't be there -- it
> will be purged only if EFI_RNG is installed. But th
Re: [PATCH v2] fdt: automatically add /chosen/kaslr-seed if DM_RNG is enabled
On Tue, May 21, 2024 at 10:29 AM Ilias Apalodimas
wrote:
>
> On Tue, 21 May 2024 at 20:06, Tim Harvey wrote:
> >
> > On Tue, May 21, 2024 at 9:54 AM Ilias Apalodimas
> > wrote:
> > >
> > > Hi Tim,
> > >
> > > On Tue, 21 May 2024 at 19:37, Tim Harvey wrote:
> > > >
> > > > On Tue, May 21, 2024 at 5:05 AM Ilias Apalodimas
> > > > wrote:
> > > > >
> > > > > Hi Tim
> > > > >
> > > > > On Wed, 15 May 2024 at 23:50, Tim Harvey
> > > > > wrote:
> > > > > >
> > > > > > If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
> > > > > > randomize the virtual address at which the kernel image is loaded,
> > > > > > it
> > > > > > expects entropy to be provided by the bootloader by populating
> > > > > > /chosen/kaslr-seed with a 64-bit value from source of entropy at
> > > > > > boot.
> > > > >
> > > > > Since you'll send a v2, mind adding some description for UEFI on the
> > > > > commit message?
> > > > > efi_try_purge_kaslr_seed() has a comment of the behaviour
> > > > >
> > > >
> > > > Hi Ilias,
> > > >
> > > > Ok, I will add the following to the commit log for clarity:
> > > > Note that the Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for
> > > > randomization and completely ignores the kaslr-seed for its own
> > > > randomness needs (i.e the randomization of the physical placement of
> > > > the kernel). It gets weeded out from the DTB that gets handed over via
> > > > efi_install_fdt() as it would also mess up the measured boot DTB TPM
> > > > measurements as well.
> > > >
> > > > Does the above mean that I don't need to worry about protecting the
> > > > call to fdt_kaslrseed() with a check for MEASURED BOOT as
> > > > efi_install_fdt/efi_try_purge_kaslr_seed always gets called in that
> > > > case?
> > >
> > > There are 2 ways to do measured boot. One is via the bootm command and
> > > the other is via the EFI protocols.
> > > CONFIG_MEASURED_BOOT only applies to bootm.
> > > OTOH kaslr-seed might still have value if EFI_RNG is disabled, even
> > > when booting with EFI, since the kernel will randomize the virtual
> > > placement if it finds that.
> > >
> > > But in any case, a kaslr-seed entry can't be present in the DTB if you
> > > plan to measure it.
> >
> > ok, sounds like I need to use:
> >
> > if (IS_ENABLED(CONFIG_DM_RNG) &&
> > !IS_ENABLED(ARMV8_SEC_FIRMWARE_SUPPORT)) &&
> > !IS_ENABLED(CONFIG_MEASURED_BOOT) {
> > fdt_kaslrseed...
> > }
> >
>
> Can't we measure the DT *before* adding the kaslr-seed?
>
You tell me... I'm deferring to you regarding what is needed for this
patch for measured boot.
What changes do I need to make and why?
Best Regards,
Tim
> Cheers
> /Ilias
> > Thanks,
> >
> > I'll send a v3 hopefully later today.
> >
> > Tim
> >
> > >
> > > Cheers
> > > /Ilias
> > >
> > > >
> > > > Best Regards,
> > > >
> > > > Tim
> > > >
> > > > > Thanks
> > > > > /Ilias
> > > > > >
> > > > > > If we have DM_RNG enabled populate this value automatically when
> > > > > > fdt_chosen is called unless ARMV8_SEC_FIRMWARE_SUPPORT is enabled as
> > > > > > it's implementation uses a different source of entropy.
> > > > > >
> > > > > > As this fdt node is added elsewhere create a library function and
> > > > > > use it to deduplicate code.
> > > > > >
> > > > > > Note that the kalsrseed command (CMD_KASLRSEED) is likely pointless
> > > > > > now
> > > > > > but left in place in case boot scripts exist that rely on this
> > > > > > command
> > > > > > existing and returning success. An informational message is printed
> > > > > > to
> > > > > > alert users of this command that it is likely no longer needed.
> > > > > >
> > > > > > Signed-off-by: Tim Harvey
> > > > > > ---
> > > > > > v2:
> > > > > > - fix typo in commit
Re: [PATCH v2] fdt: automatically add /chosen/kaslr-seed if DM_RNG is enabled
On Tue, May 21, 2024 at 9:54 AM Ilias Apalodimas
wrote:
>
> Hi Tim,
>
> On Tue, 21 May 2024 at 19:37, Tim Harvey wrote:
> >
> > On Tue, May 21, 2024 at 5:05 AM Ilias Apalodimas
> > wrote:
> > >
> > > Hi Tim
> > >
> > > On Wed, 15 May 2024 at 23:50, Tim Harvey wrote:
> > > >
> > > > If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
> > > > randomize the virtual address at which the kernel image is loaded, it
> > > > expects entropy to be provided by the bootloader by populating
> > > > /chosen/kaslr-seed with a 64-bit value from source of entropy at boot.
> > >
> > > Since you'll send a v2, mind adding some description for UEFI on the
> > > commit message?
> > > efi_try_purge_kaslr_seed() has a comment of the behaviour
> > >
> >
> > Hi Ilias,
> >
> > Ok, I will add the following to the commit log for clarity:
> > Note that the Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for
> > randomization and completely ignores the kaslr-seed for its own
> > randomness needs (i.e the randomization of the physical placement of
> > the kernel). It gets weeded out from the DTB that gets handed over via
> > efi_install_fdt() as it would also mess up the measured boot DTB TPM
> > measurements as well.
> >
> > Does the above mean that I don't need to worry about protecting the
> > call to fdt_kaslrseed() with a check for MEASURED BOOT as
> > efi_install_fdt/efi_try_purge_kaslr_seed always gets called in that
> > case?
>
> There are 2 ways to do measured boot. One is via the bootm command and
> the other is via the EFI protocols.
> CONFIG_MEASURED_BOOT only applies to bootm.
> OTOH kaslr-seed might still have value if EFI_RNG is disabled, even
> when booting with EFI, since the kernel will randomize the virtual
> placement if it finds that.
>
> But in any case, a kaslr-seed entry can't be present in the DTB if you
> plan to measure it.
ok, sounds like I need to use:
if (IS_ENABLED(CONFIG_DM_RNG) &&
!IS_ENABLED(ARMV8_SEC_FIRMWARE_SUPPORT)) &&
!IS_ENABLED(CONFIG_MEASURED_BOOT) {
fdt_kaslrseed...
}
Thanks,
I'll send a v3 hopefully later today.
Tim
>
> Cheers
> /Ilias
>
> >
> > Best Regards,
> >
> > Tim
> >
> > > Thanks
> > > /Ilias
> > > >
> > > > If we have DM_RNG enabled populate this value automatically when
> > > > fdt_chosen is called unless ARMV8_SEC_FIRMWARE_SUPPORT is enabled as
> > > > it's implementation uses a different source of entropy.
> > > >
> > > > As this fdt node is added elsewhere create a library function and
> > > > use it to deduplicate code.
> > > >
> > > > Note that the kalsrseed command (CMD_KASLRSEED) is likely pointless now
> > > > but left in place in case boot scripts exist that rely on this command
> > > > existing and returning success. An informational message is printed to
> > > > alert users of this command that it is likely no longer needed.
> > > >
> > > > Signed-off-by: Tim Harvey
> > > > ---
> > > > v2:
> > > > - fix typo in commit msg
> > > > - use stack for seed to avoid unecessary malloc/free
> > > > - move to a library function and deduplicate code by using it elsewhere
> > > > ---
> > > > board/xilinx/common/board.c | 35 -
> > > > boot/fdt_support.c | 10 +
> > > > boot/pxe_utils.c| 35 +++--
> > > > cmd/kaslrseed.c | 45 ++---
> > > > include/kaslrseed.h | 17 ++
> > > > lib/Makefile| 1 +
> > > > lib/kaslrseed.c | 34
> > > > 7 files changed, 72 insertions(+), 105 deletions(-)
> > > > create mode 100644 include/kaslrseed.h
> > > > create mode 100644 lib/kaslrseed.c
> > > >
> > > > diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
> > > > index 30a81376ac41..f741e8957818 100644
> > > > --- a/board/xilinx/common/board.c
> > > > +++ b/board/xilinx/common/board.c
> > > > @@ -713,41 +713,6 @@ int ft_board_setup(void *blob, struct bd_info *bd)
> > > > if (IS_ENABLED(CONFIG_FDT_FIXUP_PARTITIONS) &&
> > > > IS_ENABLED(CONFIG_NAND_ZYNQ))
> > > > fdt_fixup_mtdparts(b
Re: [PATCH v2] fdt: automatically add /chosen/kaslr-seed if DM_RNG is enabled
On Tue, May 21, 2024 at 5:05 AM Ilias Apalodimas
wrote:
>
> Hi Tim
>
> On Wed, 15 May 2024 at 23:50, Tim Harvey wrote:
> >
> > If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
> > randomize the virtual address at which the kernel image is loaded, it
> > expects entropy to be provided by the bootloader by populating
> > /chosen/kaslr-seed with a 64-bit value from source of entropy at boot.
>
> Since you'll send a v2, mind adding some description for UEFI on the
> commit message?
> efi_try_purge_kaslr_seed() has a comment of the behaviour
>
Hi Ilias,
Ok, I will add the following to the commit log for clarity:
Note that the Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for
randomization and completely ignores the kaslr-seed for its own
randomness needs (i.e the randomization of the physical placement of
the kernel). It gets weeded out from the DTB that gets handed over via
efi_install_fdt() as it would also mess up the measured boot DTB TPM
measurements as well.
Does the above mean that I don't need to worry about protecting the
call to fdt_kaslrseed() with a check for MEASURED BOOT as
efi_install_fdt/efi_try_purge_kaslr_seed always gets called in that
case?
Best Regards,
Tim
> Thanks
> /Ilias
> >
> > If we have DM_RNG enabled populate this value automatically when
> > fdt_chosen is called unless ARMV8_SEC_FIRMWARE_SUPPORT is enabled as
> > it's implementation uses a different source of entropy.
> >
> > As this fdt node is added elsewhere create a library function and
> > use it to deduplicate code.
> >
> > Note that the kalsrseed command (CMD_KASLRSEED) is likely pointless now
> > but left in place in case boot scripts exist that rely on this command
> > existing and returning success. An informational message is printed to
> > alert users of this command that it is likely no longer needed.
> >
> > Signed-off-by: Tim Harvey
> > ---
> > v2:
> > - fix typo in commit msg
> > - use stack for seed to avoid unecessary malloc/free
> > - move to a library function and deduplicate code by using it elsewhere
> > ---
> > board/xilinx/common/board.c | 35 -
> > boot/fdt_support.c | 10 +
> > boot/pxe_utils.c| 35 +++--
> > cmd/kaslrseed.c | 45 ++---
> > include/kaslrseed.h | 17 ++
> > lib/Makefile| 1 +
> > lib/kaslrseed.c | 34
> > 7 files changed, 72 insertions(+), 105 deletions(-)
> > create mode 100644 include/kaslrseed.h
> > create mode 100644 lib/kaslrseed.c
> >
> > diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
> > index 30a81376ac41..f741e8957818 100644
> > --- a/board/xilinx/common/board.c
> > +++ b/board/xilinx/common/board.c
> > @@ -713,41 +713,6 @@ int ft_board_setup(void *blob, struct bd_info *bd)
> > if (IS_ENABLED(CONFIG_FDT_FIXUP_PARTITIONS) &&
> > IS_ENABLED(CONFIG_NAND_ZYNQ))
> > fdt_fixup_mtdparts(blob, nodes, ARRAY_SIZE(nodes));
> >
> > - if (uclass_get_device(UCLASS_RNG, 0, ) || !dev) {
> > - debug("No RNG device\n");
> > - return 0;
> > - }
> > -
> > - if (dm_rng_read(dev, buf, n)) {
> > - debug("Reading RNG failed\n");
> > - return 0;
> > - }
> > -
> > - if (!blob) {
> > - debug("No FDT memory address configured. Please configure\n"
> > - "the FDT address via \"fdt addr \"
> > command.\n"
> > - "Aborting!\n");
> > - return 0;
> > - }
> > -
> > - ret = fdt_check_header(blob);
> > - if (ret < 0) {
> > - debug("fdt_chosen: %s\n", fdt_strerror(ret));
> > - return ret;
> > - }
> > -
> > - nodeoffset = fdt_find_or_add_subnode(blob, 0, "chosen");
> > - if (nodeoffset < 0) {
> > - debug("Reading chosen node failed\n");
> > - return nodeoffset;
> > - }
> > -
> > - ret = fdt_setprop(blob, nodeoffset, "kaslr-seed", buf, sizeof(buf));
> > - if (ret < 0) {
> > - debug("Unable to set kaslr-seed on chosen node: %s\n",
> > fdt_strerror(ret));
> > - return ret;
> > - }
> > -
> >
Re: [PATCH v2] fdt: automatically add /chosen/kaslr-seed if DM_RNG is enabled
On Mon, May 20, 2024 at 1:29 AM Michal Simek wrote:
>
> Hi Tim,
>
> On 5/16/24 17:58, Tim Harvey wrote:
> > On Wed, May 15, 2024 at 1:50 PM Tim Harvey wrote:
> >>
> >> If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
> >> randomize the virtual address at which the kernel image is loaded, it
> >> expects entropy to be provided by the bootloader by populating
> >> /chosen/kaslr-seed with a 64-bit value from source of entropy at boot.
> >>
> >> If we have DM_RNG enabled populate this value automatically when
> >> fdt_chosen is called unless ARMV8_SEC_FIRMWARE_SUPPORT is enabled as
> >> it's implementation uses a different source of entropy.
> >>
> >> As this fdt node is added elsewhere create a library function and
> >> use it to deduplicate code.
> >>
> >> Note that the kalsrseed command (CMD_KASLRSEED) is likely pointless now
> >> but left in place in case boot scripts exist that rely on this command
> >> existing and returning success. An informational message is printed to
> >> alert users of this command that it is likely no longer needed.
> >>
> >> Signed-off-by: Tim Harvey
> >> ---
> >> v2:
> >> - fix typo in commit msg
> >> - use stack for seed to avoid unecessary malloc/free
> >> - move to a library function and deduplicate code by using it elsewhere
> >> ---
> >> board/xilinx/common/board.c | 35 -
> >> boot/fdt_support.c | 10 +
> >> boot/pxe_utils.c| 35 +++--
> >> cmd/kaslrseed.c | 45 ++---
> >> include/kaslrseed.h | 17 ++
> >> lib/Makefile| 1 +
> >> lib/kaslrseed.c | 34
> >> 7 files changed, 72 insertions(+), 105 deletions(-)
> >> create mode 100644 include/kaslrseed.h
> >> create mode 100644 lib/kaslrseed.c
> >>
> >> diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
> >> index 30a81376ac41..f741e8957818 100644
> >> --- a/board/xilinx/common/board.c
> >> +++ b/board/xilinx/common/board.c
> >> @@ -713,41 +713,6 @@ int ft_board_setup(void *blob, struct bd_info *bd)
> >> if (IS_ENABLED(CONFIG_FDT_FIXUP_PARTITIONS) &&
> >> IS_ENABLED(CONFIG_NAND_ZYNQ))
> >> fdt_fixup_mtdparts(blob, nodes, ARRAY_SIZE(nodes));
> >>
> >> - if (uclass_get_device(UCLASS_RNG, 0, ) || !dev) {
> >> - debug("No RNG device\n");
> >> - return 0;
> >> - }
> >> -
> >> - if (dm_rng_read(dev, buf, n)) {
> >> - debug("Reading RNG failed\n");
> >> - return 0;
> >> - }
> >> -
> >> - if (!blob) {
> >> - debug("No FDT memory address configured. Please
> >> configure\n"
> >> - "the FDT address via \"fdt addr \"
> >> command.\n"
> >> - "Aborting!\n");
> >> - return 0;
> >> - }
> >> -
> >> - ret = fdt_check_header(blob);
> >> - if (ret < 0) {
> >> - debug("fdt_chosen: %s\n", fdt_strerror(ret));
> >> - return ret;
> >> - }
> >> -
> >> - nodeoffset = fdt_find_or_add_subnode(blob, 0, "chosen");
> >> - if (nodeoffset < 0) {
> >> - debug("Reading chosen node failed\n");
> >> - return nodeoffset;
> >> - }
> >> -
> >> - ret = fdt_setprop(blob, nodeoffset, "kaslr-seed", buf,
> >> sizeof(buf));
> >> - if (ret < 0) {
> >> - debug("Unable to set kaslr-seed on chosen node: %s\n",
> >> fdt_strerror(ret));
> >> - return ret;
> >> - }
> >> -
> >> return 0;
> >> }
> >> #endif
> >> diff --git a/boot/fdt_support.c b/boot/fdt_support.c
> >> index 874ca4d6f5af..3455d60d69dc 100644
> >> --- a/boot/fdt_support.c
> >> +++ b/boot/fdt_support.c
> >> @@ -8,6 +8,7 @@
> >>
> >> #include
> >> #include
> >> +#include
> >> #include
> >> #include
>
Re: [PATCH v3 4/4] imx: hab: Use nxp_imx8mcst etype for i.MX8M flash.bin signing
On Thu, May 16, 2024 at 6:31 PM Marek Vasut wrote:
>
> On 5/16/24 11:40 PM, Tim Harvey wrote:
>
> [...]
>
> >> -The entire script is available in doc/imx/habv4/csf_examples/mx8m/csf.sh
> >> -and can be used as follows to modify flash.bin to be signed
> >> -(adjust paths as needed):
> >> -```
> >> -export CST_DIR=/usr/src/cst-3.3.1/
> >> -export CSF_KEY=$CST_DIR/crts/CSF1_1_sha256_4096_65537_v3_usr_crt.pem
> >> -export IMG_KEY=$CST_DIR/crts/IMG1_1_sha256_4096_65537_v3_usr_crt.pem
> >> -export SRK_TABLE=$CST_DIR/crts/SRK_1_2_3_4_table.bin
> >> -export PATH=$CST_DIR/linux64/bin:$PATH
> >
> > Hi Marek,
> >
> > I thought you were going to leave the above env setting examples in
> > the documentation.
> >
> > I suggest showing how to specify using env (by just leaving the above
> > in) as well as by copying them directly to the build directory if
> > wanted.. otherwise the documentation is lacking.
>
> If the tool can do env vars now, I would like to avoid copying key
> material around. So what about this:
>
> diff --git a/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> b/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> index 1eb1fb0aa61..257ffb45656 100644
> --- a/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> +++ b/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> @@ -144,6 +144,8 @@ The signing is activated by wrapping SPL and
> fitImage sections into nxp-imx8mcst
> etype, which is done automatically in
> arch/arm/dts/imx8m{m,n,p,q}-u-boot.dtsi
> in case CONFIG_IMX_HAB Kconfig symbol is enabled.
>
> +Build of flash.bin target then produces a signed flash.bin automatically.
> +
> The nxp-imx8mcst etype is configurable using either DT properties or
> environment
> variables. The following DT properties and environment variables are
> supported.
> Note that environment variables override DT properties.
> @@ -160,7 +162,15 @@ Note that environment variables override DT properties.
> | nxp,img-crt| IMG_KEY | full path to the IMG Key
> IMG1_1_sha256_4096_65537_v3_usr_crt.pem |
>
> ++---+--+
>
> -Build of flash.bin target then produces a signed flash.bin automatically.
> +Environment variables can be set as follows to point the build process
> +to external key material:
> +```
> +export CST_DIR=/usr/src/cst-3.3.1/
> +export CSF_KEY=$CST_DIR/crts/CSF1_1_sha256_4096_65537_v3_usr_crt.pem
> +export IMG_KEY=$CST_DIR/crts/IMG1_1_sha256_4096_65537_v3_usr_crt.pem
> +export SRK_TABLE=$CST_DIR/crts/SRK_1_2_3_4_table.bin
> +make flash.bin
> +```
>
> 1.4 Closing the device
> ---
>
Hi Marek,
Yes, with that change you can add for the series:
Reviewed-by: Tim Harvey
Best Regards,
Tim
Re: [PATCH v3 4/4] imx: hab: Use nxp_imx8mcst etype for i.MX8M flash.bin signing
On Thu, May 16, 2024 at 2:31 PM Marek Vasut wrote:
>
> Update documentation and use nxp_imx8mcst binman etype for signing
> of flash.bin instead of previous horrible shell scripting.
>
> Signed-off-by: Marek Vasut
> ---
> Cc: "NXP i.MX U-Boot Team"
> Cc: Adam Ford
> Cc: Alper Nebi Yasak
> Cc: Andrejs Cainikovs
> Cc: Angus Ainslie
> Cc: Emanuele Ghidoli
> Cc: Fabio Estevam
> Cc: Francesco Dolcini
> Cc: Marcel Ziswiler
> Cc: Rasmus Villemoes
> Cc: Simon Glass
> Cc: Stefan Eichenberger
> Cc: Stefano Babic
> Cc: Tim Harvey
> Cc: Tom Rini
> Cc: ker...@puri.sm
> Cc: u-b...@dh-electronics.com
> Cc: u-boot@lists.denx.de
> ---
> V2: Document the automatic signing in case CONFIG_IMX_HAB is enabled
> V3: Document configuration of imx8mcst
> ---
> doc/imx/habv4/csf_examples/mx8m/csf.sh| 92 --
> doc/imx/habv4/csf_examples/mx8m/csf_fit.txt | 30 -
> doc/imx/habv4/csf_examples/mx8m/csf_spl.txt | 33 -
> doc/imx/habv4/guides/mx8m_spl_secure_boot.txt | 116 +-
> 4 files changed, 30 insertions(+), 241 deletions(-)
> delete mode 100644 doc/imx/habv4/csf_examples/mx8m/csf.sh
> delete mode 100644 doc/imx/habv4/csf_examples/mx8m/csf_fit.txt
> delete mode 100644 doc/imx/habv4/csf_examples/mx8m/csf_spl.txt
>
> diff --git a/doc/imx/habv4/csf_examples/mx8m/csf.sh
> b/doc/imx/habv4/csf_examples/mx8m/csf.sh
> deleted file mode 100644
> index cd3b2614a2f..000
> --- a/doc/imx/habv4/csf_examples/mx8m/csf.sh
> +++ /dev/null
> @@ -1,92 +0,0 @@
> -#!/bin/sh
> -
> -# 0) Generate keys
> -#
> -# WARNING: ECDSA keys are only supported by HAB 4.5 and newer (i.e. i.MX8M
> Plus)
> -#
> -# cd /path/to/cst-3.3.1/keys/
> -#./hab4_pki_tree.sh -existing-ca n -use-ecc n -kl 4096 -duration 10
> -num-srk 4 -srk-ca y
> -# cd /path/to/cst-3.3.1/crts/
> -# ../linux64/bin/srktool -h 4 -t SRK_1_2_3_4_table.bin -e
> SRK_1_2_3_4_fuse.bin -d sha256 -c
> ./SRK1_sha256_4096_65537_v3_ca_crt.pem,./SRK2_sha256_4096_65537_v3_ca_crt.pem,./SRK3_sha256_4096_65537_v3_ca_crt.pem,./SRK4_sha256_4096_65537_v3_ca_crt.pem
> -f 1
> -
> -# 1) Build U-Boot (e.g. for i.MX8MM)
> -#
> -# cp -Lv /path/to/arm-trusted-firmware/build/imx8mm/release/bl31.bin .
> -# cp -Lv /path/to/firmware-imx-8.14/firmware/ddr/synopsys/ddr3* .
> -# make -j imx8mm_board_defconfig
> -# make -j`nproc` flash.bin
> -
> -# 2) Sign SPL and DRAM blobs
> -
> -cp doc/imx/habv4/csf_examples/mx8m/csf_spl.txt csf_spl.tmp
> -cp doc/imx/habv4/csf_examples/mx8m/csf_fit.txt csf_fit.tmp
> -
> -# update File Paths from env vars
> -if ! [ -r $CSF_KEY ]; then
> - echo "Error: \$CSF_KEY not found"
> - exit 1
> -fi
> -if ! [ -r $IMG_KEY ]; then
> - echo "Error: \$IMG_KEY not found"
> - exit 1
> -fi
> -if ! [ -r $SRK_TABLE ]; then
> - echo "Error: \$SRK_TABLE not found"
> - exit 1
> -fi
> -sed -i "s:\$CSF_KEY:$CSF_KEY:" csf_spl.tmp
> -sed -i "s:\$IMG_KEY:$IMG_KEY:" csf_spl.tmp
> -sed -i "s:\$SRK_TABLE:$SRK_TABLE:" csf_spl.tmp
> -sed -i "s:\$CSF_KEY:$CSF_KEY:" csf_fit.tmp
> -sed -i "s:\$IMG_KEY:$IMG_KEY:" csf_fit.tmp
> -sed -i "s:\$SRK_TABLE:$SRK_TABLE:" csf_fit.tmp
> -
> -# update SPL Blocks
> -spl_block_base=$(printf "0x%x" $(( $(sed -n "/CONFIG_SPL_TEXT_BASE=/
> s@.*=@@p" .config) - 0x40)) )
> -spl_block_size=$(printf "0x%x" $(stat -tc %s u-boot-spl-ddr.bin))
> -sed -i "/Blocks = / s@.*@ Blocks = $spl_block_base 0x0 $spl_block_size
> \"flash.bin\"@" csf_spl.tmp
> -
> -# Generate CSF blob
> -cst -i csf_spl.tmp -o csf_spl.bin
> -
> -# Patch CSF blob into flash.bin
> -spl_csf_offset=$(xxd -s 24 -l 4 -e flash.bin | cut -d " " -f 2 | sed
> "s@^@0x@")
> -spl_bin_offset=$(xxd -s 4 -l 4 -e flash.bin | cut -d " " -f 2 | sed
> "s@^@0x@")
> -spl_dd_offset=$((${spl_csf_offset} - ${spl_bin_offset} + 0x40))
> -dd if=csf_spl.bin of=flash.bin bs=1 seek=${spl_dd_offset} conv=notrunc
> -
> -# 3) Sign u-boot.itb
> -
> -# fitImage
> -fit_block_base=$(printf "0x%x" $(sed -n "/CONFIG_SPL_LOAD_FIT_ADDRESS=/
> s@.*=@@p" .config) )
> -fit_block_offset=$(printf "0x%s" $(fdtget -t x u-boot.dtb
> /binman/imx-boot/uboot offset))
> -fit_block_size=$(printf "0x%x" $(( ( ( $(stat -tc %s u-boot.itb) + 0x1000 -
> 0x1 ) & ~(0x1000 - 0x1)) + 0x20 )) )
> -sed -i "/Blocks = / s@.*@ Blocks = $fit_block_base $fit_block_offset
> $fit_block_size \"flash.bin\"@" csf_fit.tmp
> -
> -# IVT
> -ivt_ptr_base=$(printf "
Re: [PATCH v2] fdt: automatically add /chosen/kaslr-seed if DM_RNG is enabled
On Wed, May 15, 2024 at 1:50 PM Tim Harvey wrote:
>
> If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
> randomize the virtual address at which the kernel image is loaded, it
> expects entropy to be provided by the bootloader by populating
> /chosen/kaslr-seed with a 64-bit value from source of entropy at boot.
>
> If we have DM_RNG enabled populate this value automatically when
> fdt_chosen is called unless ARMV8_SEC_FIRMWARE_SUPPORT is enabled as
> it's implementation uses a different source of entropy.
>
> As this fdt node is added elsewhere create a library function and
> use it to deduplicate code.
>
> Note that the kalsrseed command (CMD_KASLRSEED) is likely pointless now
> but left in place in case boot scripts exist that rely on this command
> existing and returning success. An informational message is printed to
> alert users of this command that it is likely no longer needed.
>
> Signed-off-by: Tim Harvey
> ---
> v2:
> - fix typo in commit msg
> - use stack for seed to avoid unecessary malloc/free
> - move to a library function and deduplicate code by using it elsewhere
> ---
> board/xilinx/common/board.c | 35 -
> boot/fdt_support.c | 10 +
> boot/pxe_utils.c| 35 +++--
> cmd/kaslrseed.c | 45 ++---
> include/kaslrseed.h | 17 ++
> lib/Makefile| 1 +
> lib/kaslrseed.c | 34
> 7 files changed, 72 insertions(+), 105 deletions(-)
> create mode 100644 include/kaslrseed.h
> create mode 100644 lib/kaslrseed.c
>
> diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
> index 30a81376ac41..f741e8957818 100644
> --- a/board/xilinx/common/board.c
> +++ b/board/xilinx/common/board.c
> @@ -713,41 +713,6 @@ int ft_board_setup(void *blob, struct bd_info *bd)
> if (IS_ENABLED(CONFIG_FDT_FIXUP_PARTITIONS) &&
> IS_ENABLED(CONFIG_NAND_ZYNQ))
> fdt_fixup_mtdparts(blob, nodes, ARRAY_SIZE(nodes));
>
> - if (uclass_get_device(UCLASS_RNG, 0, ) || !dev) {
> - debug("No RNG device\n");
> - return 0;
> - }
> -
> - if (dm_rng_read(dev, buf, n)) {
> - debug("Reading RNG failed\n");
> - return 0;
> - }
> -
> - if (!blob) {
> - debug("No FDT memory address configured. Please configure\n"
> - "the FDT address via \"fdt addr \" command.\n"
> - "Aborting!\n");
> - return 0;
> - }
> -
> - ret = fdt_check_header(blob);
> - if (ret < 0) {
> - debug("fdt_chosen: %s\n", fdt_strerror(ret));
> - return ret;
> - }
> -
> - nodeoffset = fdt_find_or_add_subnode(blob, 0, "chosen");
> - if (nodeoffset < 0) {
> - debug("Reading chosen node failed\n");
> - return nodeoffset;
> - }
> -
> - ret = fdt_setprop(blob, nodeoffset, "kaslr-seed", buf, sizeof(buf));
> - if (ret < 0) {
> - debug("Unable to set kaslr-seed on chosen node: %s\n",
> fdt_strerror(ret));
> - return ret;
> - }
> -
> return 0;
> }
> #endif
> diff --git a/boot/fdt_support.c b/boot/fdt_support.c
> index 874ca4d6f5af..3455d60d69dc 100644
> --- a/boot/fdt_support.c
> +++ b/boot/fdt_support.c
> @@ -8,6 +8,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -300,6 +301,15 @@ int fdt_chosen(void *fdt)
> if (nodeoffset < 0)
> return nodeoffset;
>
> + if (IS_ENABLED(CONFIG_DM_RNG) &&
> !IS_ENABLED(ARMV8_SEC_FIRMWARE_SUPPORT)) {
> + err = fdt_kaslrseed(fdt);
> + if (err) {
> + printf("WARNING: could not set kaslr-seed %s.\n",
> + fdt_strerror(err));
> + return err;
> + }
> + }
> +
> if (IS_ENABLED(CONFIG_BOARD_RNG_SEED) && !board_rng_seed()) {
> err = fdt_setprop(fdt, nodeoffset, "rng-seed",
> abuf_data(), abuf_size());
> diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c
> index 4b22bb6f525a..8d70233fc08d 100644
> --- a/boot/pxe_utils.c
> +++ b/boot/pxe_utils.c
> @@ -8,6 +8,7 @@
> #include
> #include
> #include
> +#include
> #i
Re: [PATCH v2 4/4] imx: hab: Use nxp_imx8mcst etype for i.MX8M flash.bin signing
On Wed, May 15, 2024 at 6:53 PM Marek Vasut wrote:
>
> On 5/16/24 12:31 AM, Tim Harvey wrote:
>
> Hi,
>
> > (this is a resend... apologies if its a duplicate. I got some strange
> > bounce that mime types were included so I'm resending with the otuput
> > of strace cliped out)
> >
> > strace was a good idea and showed me what was going on.
> >
> > The previous documentation stated to pass your keys via env vars that
> > were full paths to key certificates. Using strace shows me that it
> > will use the directory the KEY certificate is in and try to open up
> > ../keys/*_usr_key.pem if the key path is specified. So apparently the
> > 'File' in the CST config file is used indirectly. Pointing to the
> > usr_key.pem isn't enough either by the way, it seems to need both of
> > these:
> >
> > so if I hack the path to my certs in like this it works:diff --git
> > a/tools/binman/etype/nxp_imx8mcst.py
> > b/tools/binman/etype/nxp_imx8mcst.py
> > index 132127ad4827..b432200960df 100644
> > --- a/tools/binman/etype/nxp_imx8mcst.py
> > +++ b/tools/binman/etype/nxp_imx8mcst.py
> > @@ -67,10 +67,11 @@ class Entry_nxp_imx8mcst(Entry_mkimage):
> >
> > def ReadNode(self):
> > super().ReadNode()
> > +self.certpath =3D '/usr/src/nxp/cst-3.3.2/crts/';
>
> =3D , seems like your email is acting funny today indeed.
>
> > self.loader_address =3D fdt_util.GetInt(self._node,
> > 'nxp,loader-ad=
> > dress')
> > self.srk_table =3D fdt_util.GetString(self._node,
> > 'nxp,srk-table', 'SRK_1_2_3_4_table.bin')
> > -self.csf_crt =3D fdt_util.GetString(self._node, 'nxp,csf-crt',
> > 'CSF1_1_sha256_4096_65537_v3_usr_crt.pem')
> > -self.img_crt =3D fdt_util.GetString(self._node, 'nxp,img-crt',
> > 'IMG1_1_sha256_4096_65537_v3_usr_crt.pem')
> > +self.csf_crt =3D fdt_util.GetString(self._node, 'nxp,csf-crt',
> > self.certpath + '/CSF1_1_sha256_4096_65537_v3_usr_crt.pem')
> > +self.img_crt =3D fdt_util.GetString(self._node, 'nxp,img-crt',
> > self.certpath + '/IMG1_1_sha256_4096_65537_v3_usr_crt.pem')
>
> What about this:
>
> diff --git a/tools/binman/etype/nxp_imx8mcst.py
> b/tools/binman/etype/nxp_imx8mcst.py
> index 132127ad482..9ead7488a2d 100644
> --- a/tools/binman/etype/nxp_imx8mcst.py
> +++ b/tools/binman/etype/nxp_imx8mcst.py
> @@ -68,9 +68,9 @@ class Entry_nxp_imx8mcst(Entry_mkimage):
> def ReadNode(self):
> super().ReadNode()
> self.loader_address = fdt_util.GetInt(self._node,
> 'nxp,loader-address')
> -self.srk_table = fdt_util.GetString(self._node,
> 'nxp,srk-table', 'SRK_1_2_3_4_table.bin')
> -self.csf_crt = fdt_util.GetString(self._node, 'nxp,csf-crt',
> 'CSF1_1_sha256_4096_65537_v3_usr_crt.pem')
> -self.img_crt = fdt_util.GetString(self._node, 'nxp,img-crt',
> 'IMG1_1_sha256_4096_65537_v3_usr_crt.pem')
> +self.srk_table = os.getenv('SRK_TABLE',
> fdt_util.GetString(self._node, 'nxp,srk-table', 'SRK_1_2_3_4_table.bin'))
> +self.csf_crt = os.getenv('CSF_KEY',
> fdt_util.GetString(self._node, 'nxp,csf-crt',
> 'CSF1_1_sha256_4096_65537_v3_usr_crt.pem'))
> +self.img_crt = os.getenv('IMG_KEY',
> fdt_util.GetString(self._node, 'nxp,img-crt',
> 'IMG1_1_sha256_4096_65537_v3_usr_crt.pem'))
> self.unlock = fdt_util.GetBool(self._node, 'nxp,unlock')
> self.ReadEntries()
>
> Then you can also use the old behavior with keys supplied via env vars.
>
> This might in fact be useful for build systems too.
>
yes, I like that (with an added 'import os')
> > self.unlock =3D fdt_util.GetBool(self._node, 'nxp,unlock')
> > self.ReadEntries()
> >
> > $ make -j8
> >BINMAN .binman_stamp
> >OFCHK .config
> >
> > Strace indicatest the following with the above patch:
> > openat(AT_FDCWD,
> > "/usr/src/nxp/cst-3.3.2/crts//IMG1_1_sha256_4096_65537_v3_usr_crt.pem",
> > O_RDONLY)
> > ...
> > openat(AT_FDCWD,
> > "/usr/src/nxp/cst-3.3.2/keys//IMG1_1_sha256_4096_65537_v3_usr_key.pem",
> > O_RDONLY)
> > ^^^ look how it sneakily changes the PATH!
> >
> > And without the above patch using a key file without a path:
> > openat(AT_FDCWD, "IMG1_1_sha256_4096_65537_v3_usr_crt.pem", O_RDONLY)
> > ...
> > openat(AT_FDCWD, "IMG1_1_sha256_4096_65537_v3_usr_key.pem", O_RDONLY)
> > ENOENT (No such file or directory)
> > ^^^ fails
> >
> > Simply copying both usr_crt.pem and usr_key.pem to the build directory
> > still fails:
> >
Re: [PATCH v3] tpm-v2: allow algoirthm name to be configured for pcr_read and pcr_extend
On Fri, Apr 19, 2024 at 1:04 PM Ilias Apalodimas
wrote:
>
> On Fri, 19 Apr 2024 at 20:52, Tim Harvey wrote:
> >
> > On Fri, Apr 19, 2024 at 10:37 AM Ilias Apalodimas
> > wrote:
> > >
> > > Also quickly looking at this, you need a new function for
> > > tpm2_algorithm_to_mask() (look below)
> > >
> > > On Fri, 19 Apr 2024 at 20:20, Ilias Apalodimas
> > > wrote:
> > > >
> > > > Hi Tim,
> > > >
> > > > On Fri, 19 Apr 2024 at 20:13, Tim Harvey wrote:
> > > > >
> > > > > On Sat, Apr 6, 2024 at 9:33 AM Ilias Apalodimas
> > > > > wrote:
> > > > > >
> > > > > > Hi Tim,
> > > > > >
> > > > > > Thanks for the patch
> > > > > >
> > > > > > I'll be away next week, I'll try to find time and take a closer
> > > > > > look.
> > > > > > The pipeline [0] shows some TPM related failures
> > > > > >
> > > > > > [0]
> > > > > > https://source.denx.de/u-boot/custodians/u-boot-tpm/-/commit/9b4be64e41454e17269a968397933eeff300c380
> > > > > >
> > > > >
> > > > > Hi Ilias,
> > > > >
> > > > > I changed the output of 'tpm pcr_read' so that it shows the algo and
> > > > > size causing the test in test/py/tests/test_tpm2.py to fail:
> > > > > @@ -151,11 +171,12 @@ static int do_tpm_pcr_read(struct cmd_tbl
> > > > > *cmdtp, int flag, int argc,
> > > > >
> > > > > data = map_sysmem(simple_strtoul(argv[2], NULL, 0), 0);
> > > > >
> > > > > - rc = tpm2_pcr_read(dev, index, priv->pcr_select_min,
> > > > > TPM2_ALG_SHA256,
> > > > > - data, TPM2_DIGEST_LEN, );
> > > > > + rc = tpm2_pcr_read(dev, index, priv->pcr_select_min, algo,
> > > > > + data, algo_len, );
> > > > > if (!rc) {
> > > > > - printf("PCR #%u content (%u known updates):\n",
> > > > > index, updates);
> > > > > - print_byte_string(data, TPM2_DIGEST_LEN);
> > > > > + printf("PCR #%u %s %d byte content (%u known
> > > > > updates):\n", index,
> > > > > + tpm2_algorithm_name(algo), algo_len, updates);
> > > > > + print_byte_string(data, algo_len);
> > > > > }
> > > > >
> > > > > failure:
> > > > > E AssertionError: assert 'PCR #10 content' in 'PCR #10 sha256 32
> > > > > byte content (723 known updates):\r\r\n 00 00 00 00 00 00 00 00 00 00
> > > > > 00 00 00 00 00 00\r\r\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > > > 00'
> > > > >
> > > > > So I suppose I need to update test/py/tests/test_tpm2.py as well.
> > > >
> > > > Yes
> > > >
> > > > >
> > > > > Would I update test/py/tests/test_tpm2.py in the same patch as the one
> > > > > that causes the failure?
> > > >
> > > > Yes please, I'd like patches merged that won't break the CI
> > > >
> > > > >
> > > > > How do I go about running the tests manually to make sure I've
> > > > > addressed it?
> > > >
> > > > You can send a PR against U-Boots repo (in github)
> > > >
> > > > Cheers
> > > > /Ilias
> > > > >
> > > > > Best Regards,
> > > > >
> > > > > Tim
> > > > >
> > > > > > Cheers
> > > > > > /Ilias
> > > > > >
> > > > > > On Fri, 5 Apr 2024 at 03:17, Tim Harvey
> > > > > > wrote:
> > > > > > >
> > > > > > > For pcr_read and pcr_extend commands allow the digest algorithm
> > > > > > > to be
> > > > > > > specified by an additional argument. If not specified it will
> > > > > > > default to
> > > > > > > SHA256 for backwards compatibility.
> > > > > > >
> > > > > > > A follow-on to this could be to extend all PCR banks with the
> > > > > > > detected
> > > > > > &g
[PATCH v3] tpm: display warning if using gpio reset with TPM
Instead of displaying what looks like an error message if a
gpio-reset dt prop is missing for a TPM display a warning that
having a gpio reset on a TPM should not be used for a secure production
device.
TCG TIS spec [1] says:
"The TPM_Init (LRESET#/SPI_RST#) signal MUST be connected to the
platform CPU Reset signal such that it complies with the requirements
specified in section 1.2.7 HOST Platform Reset in the PC Client
Implementation Specification for Conventional BIOS."
The reasoning is that you should not be able to toggle a GPIO and reset
the TPM without resetting the CPU as well because if an attacker can
break into your OS via an OS level security flaw they can then reset the
TPM via GPIO and replay the measurements required to unseal keys
that you have otherwise protected.
Additionally restructure the code for improved readability allowing for
removal of the init label.
Before:
- board with no reset gpio
u-boot=> tpm init && tpm info
tpm_tis_spi_probe: missing reset GPIO
tpm@1 v2.0: VendorID 0x1114, DeviceID 0x3205, RevisionID 0x01 [open]
- board with a reset gpio
u-boot=> tpm init && tpm info
tpm@1 v2.0: VendorID 0x1114, DeviceID 0x3205, RevisionID 0x01 [open]
After:
- board with no reset gpio
u-boot=> tpm init && tpm info
tpm@1 v2.0: VendorID 0x1114, DeviceID 0x3205, RevisionID 0x01 [open]
- board with a reset gpio
u-boot=> tpm init && tpm info
tpm@1: TPM gpio reset should not be used on secure production devices
tpm@1 v2.0: VendorID 0x1114, DeviceID 0x3205, RevisionID 0x01 [open]
[1]
https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientTPMInterfaceSpecification_TIS__1-3_27_03212013.pdf
Signed-off-by: Tim Harvey
---
v3: restructure code for improved readability (recommended by Miquel)
v2: change the message to a warning
---
drivers/tpm/tpm2_tis_spi.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/tpm/tpm2_tis_spi.c b/drivers/tpm/tpm2_tis_spi.c
index 28079b5039a3..b0fe97ab1d08 100644
--- a/drivers/tpm/tpm2_tis_spi.c
+++ b/drivers/tpm/tpm2_tis_spi.c
@@ -237,19 +237,22 @@ static int tpm_tis_spi_probe(struct udevice *dev)
/* legacy reset */
ret = gpio_request_by_name(dev, "gpio-reset", 0,
_gpio, GPIOD_IS_OUT);
- if (ret) {
+ if (!ret) {
log(LOGC_NONE, LOGL_NOTICE,
- "%s: missing reset GPIO\n", __func__);
- goto init;
+ "%s: gpio-reset is deprecated\n", __func__);
}
- log(LOGC_NONE, LOGL_NOTICE,
- "%s: gpio-reset is deprecated\n", __func__);
}
- dm_gpio_set_value(_gpio, 1);
- mdelay(1);
- dm_gpio_set_value(_gpio, 0);
+
+ if (!ret) {
+ log(LOGC_NONE, LOGL_WARNING,
+ "%s: TPM gpio reset should not be used on secure
production devices\n",
+ dev->name);
+ dm_gpio_set_value(_gpio, 1);
+ mdelay(1);
+ dm_gpio_set_value(_gpio, 0);
+ }
}
-init:
+
/* Ensure a minimum amount of time elapsed since reset of the TPM */
mdelay(drv_data->time_before_first_cmd_ms);
--
2.25.1
Re: [PATCH] imx: hab: add documentation about the required keys/certs
On Tue, May 14, 2024 at 11:50 AM Tim Harvey wrote:
>
> On Sun, May 12, 2024 at 10:08 PM Marek Vasut wrote:
> >
> > On 5/8/24 9:23 AM, Claudius Heine wrote:
> > > Hi Marek,
> >
> > Hi,
> >
> > > On 2024-05-07 3:28 pm, Marek Vasut wrote:
> > >> On 5/7/24 3:06 PM, Claudius Heine wrote:
> > >>> For CST to find the certificates and keys for signing, some keys and
> > >>> certs need to be copied into the u-boot build directory.
> > >>
> > >> Make sure to CC "NXP i.MX U-Boot Team" , else NXP is not informed. Use
> > >> scripts/get_maintainer to get the full list or just reuse the CC list
> > >> from patches in this thread.
> > >
> > > I send the patch with `--to-cmd scripts/get_maintainer.pl`, maybe I
> > > should have used `--cc-cmd`, but that would not change the list of
> > > recipients.
> >
> > Should now be fixed in
> > [PATCH] ARM: imx: Add doc/imx/ to i.MX MAINTAINERS entry
> >
> > >>> diff --git a/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> > >>> b/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> > >>> index ce1de659d8..42214df21a 100644
> > >>> --- a/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> > >>> +++ b/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> > >>> @@ -144,6 +144,22 @@ The signing is activated by wrapping SPL and
> > >>> fitImage sections into nxp-imx8mcst
> > >>> etype, which is done automatically in
> > >>> arch/arm/dts/imx8m{m,n,p,q}-u-boot.dtsi
> > >>> in case CONFIG_IMX_HAB Kconfig symbol is enabled.
> > >>> +Per default the HAB keys and certificates need to be located in the
> > >>> build
> > >>> +directory, this means copying the following files from the HAB keys
> > >>> directory
> > >>> +flat (e.g. removing the `keys` and `cert` subdirectory) into the
> > >>> u-boot build
> > >>> +directory for the CST Code Signing Tool to locate them:
> > >>
> > >> Do symlink(s) work too ?
> > >
> > > I have not tested it, but I don't see any reason why it would not. I
> > > also don't see a reason for mentioning it. I want to keep it simple, if
> > > the dev whats to do things differently, they are free to do so.
> >
> > "
> > Per default the HAB keys and certificates need to be located in the
> > build directory, this means {+creating a symbolic link or +}copying the
> > following...
> > "
> >
> > Please test it and add it in V2 if it works, I think symlink is better
> > than bluntly copying files around, esp. for crypto material.
>
> Hi Marek and Claudius,
>
> Yes, this documentation is needed as well but I'm still unclear why
> the old method before this series did not require the usr_key.pem
> files, why I don't have the *usr_key.pem files in my crts dir created
> (long ago) with cst-3.3.1 and cst-3.3.2, and what I need to do to
> generate them now that they are apparently needed.
>
> Best Regards,
>
> Tim
>
> >
> > >>> +- `crts/SRK_1_2_3_4_table.bin`
> > >>> +- `crts/CSF1_1_sha256_4096_65537_v3_usr_crt.pem`
> > >>> +- `keys/CSF1_1_sha256_4096_65537_v3_usr_key.pem`
> > >>> +- `crts/IMG1_1_sha256_4096_65537_v3_usr_crt.pem`
> > >>> +- `keys/IMG1_1_sha256_4096_65537_v3_usr_key.pem`
> > >>> +- `keys/key_pass.txt`
> > >>> +
> > >>> +The paths to the SRK table and the certificates can be modified via
> > >>> changes to
> > >>> +the nxp_imx8mcst device tree node
> > >>
> > >> "nodes", plural, there are two, one for SPL and one for fitImage.
> > >
> > > Well, I was thinking here more generally about the node type and was
> > > assuming that the person reading this knows how many they have of that
> > > type. But I can add a `s` in v2.
> >
> > Use "node(s)" which covers both options.
> >
> > >> It would be good to mention the DT properties which govern the crypto
> > >> material paths -- nxp,srk-table, nxp,csf-crt, nxp,img-crt -- somewhere
> > >> around this sentence.
> > >
> > > This is something that should be documented with the changes where that
> > > code was added, IMO. I only documented here what I found out and have
> > > used myself, I haven't used those.
> > >
> > > I would be interested in reading how to best overwrite
Re: [PATCH v2 4/4] imx: hab: Use nxp_imx8mcst etype for i.MX8M flash.bin signing
On Tue, May 14, 2024 at 1:58 PM Marek Vasut wrote:
>
> On 5/14/24 8:34 PM, Tim Harvey wrote:
>
> Hi,
>
> >> diff --git a/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> >> b/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> >> index e16e5410bd9..ce1de659d8c 100644
> >> --- a/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> >> +++ b/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> >> @@ -121,6 +121,9 @@ build configuration:
> >> - Defconfig:
> >>
> >> CONFIG_IMX_HAB=y
> >> + CONFIG_FSL_CAAM=y
> >> + CONFIG_ARCH_MISC_INIT=y
> >> + CONFIG_SPL_CRYPTO=y
> >>
> >
> > Hi Marek,
> >
> > Thanks for wrapping the dts bits with a config item.
> >
> > Is there any other reason to build with CONFIG_IMX_HAB than to use a
> > signed image? I see that there are several ARCH_MX6 and ARCH_MX7
> > configs that have this enabled (not ARCH_IMX8M so this certainly
> > doesn't break anything) and I'm not sure what the value of that is.
>
> I think those few either enabled in preemptively in anticipation of
> possibly using HAB, or are wrong. I suspect it should be disabled for
> those, as it only adds to the board boot time and I am not even sure if
> those machines would boot correctly.
>
> Francesco, maybe you do have MX7 Colibri ?
>
> > I notice that FSL_CAAM is selected when you select IMX_HAB... is there
> > any reason why ARCH_MISC_INIT and SPL_CRYPTO should not be selected by
> > IMX_HAB as well (future patch perhaps)?
>
> ARCH_MISC_INIT should be selected by SoC Kconfig on MX7 and maybe CAAM
> on MX8M I think . As for SPL_CRYPTO, that should be selected by
> SPL_FSL_CAAM I think.
>
> >> - Kconfig:
> >>
> >
> > We definitely need to describe the additional requirements here. Maybe
> > something like:
> >
> > - Tools:
> > cst - NXP code-signing-tool (eg apt install imx-code-signing-tool)
> >
> > - Files: (created with NXP IMX_CST_TOOL)
> > SRK_1_2_3_4_table.bin (specified by nxp,srk-table node): fuse table
> > CSF1_1_sha256_4096_65537_v3_usr_crt.pem (specified by nxp,csf-crt node):
> > CSF_KEY
> > IMG1_1_sha256_4096_65537_v3_usr_crt.pem (specified by nxp,img-crt node):
> > IMG_KEY
> >
> > The following works fine for me on v2024.01
> > export CST_DIR=/usr/src/nxp/cst-3.3.2/
> > export CSF_KEY=$CST_DIR/crts/CSF1_1_sha256_4096_65537_v3_usr_crt.pem
> > export IMG_KEY=$CST_DIR/crts/IMG1_1_sha256_4096_65537_v3_usr_crt.pem
> > export SRK_TABLE=$CST_DIR/crts/SRK_1_2_3_4_table.bin
> > export PATH=$CST_DIR/linux64/bin:$PATH
> > make && /bin/sh doc/imx/habv4/csf_examples/mx8m/csf.sh
> >
> > But with the above defines and your series this fails:
> > ln -sf $SRK_TABLE SRK_1_2_3_4_table.bin
> > ln -sf $CSF_KEY CSF1_1_sha256_4096_65537_v3_usr_crt.pem
> > ln -sf $IMG_KEY IMG1_1_sha256_4096_65537_v3_usr_crt.pem
> > make
> >BINMAN .binman_stamp
> > Wrote map file './image.map' to show errors
> > binman: Error 1 running 'cst -i
> > ./nxp.csf-config-txt.section.nxp-imx8mcst@0 -o
> > ./nxp.csf-output-blob.section.nxp-imx8mcst@0': Error:
> > Cannot open key file IMG1_1_sha256_4096_65537_v3_usr_key.pem
> > 0:error:02001002:system library:fopen:No such file or
> > directory:crypto/bio/bss_file.c:288:fopen('IMG1_1_sha256_4096_65537_v3_usr_key.
> > pem','r')
> > 0:error:20074002:BIO routines:file_ctrl:system
> > lib:crypto/bio/bss_file.c:290:
> >
> > make: *** [Makefile:1126: .binman_stamp] Error 1
> >
> > So how is it that the default for nxp,img-crt
> > IMG1_1_sha256_4096_65537_v3_usr_crt.pem is now looking for
> > IMG1_1_sha256_4096_65537_v3_usr_key? It fails also if I cp the files
> > vs ln them.
> >
> > So what am I missing here?
>
> I think CST is using both the certificate and the key files. Try and run
> strace on the CST to test that:
>
> $ strace cst -i ./nxp.csf-config-txt.section.nxp-imx8mcst@0 -o
> ./nxp.csf-output-blob.section.nxp-imx8mcst@0
Hi Marek,
(this is a resend... apologies if its a duplicate. I got some strange
bounce that mime types were included so I'm resending with the otuput
of strace cliped out)
strace was a good idea and showed me what was going on.
The previous documentation stated to pass your keys via env vars that
were full paths to key certificates. Using strace shows me that it
will use the directory the KEY certificate is in and try to open up
../keys/*_usr_key.pem if the key path is specified. So apparently the
'File' in the CST config file is used indirectly. Pointing to the
usr_key.pem isn't enough either by the way, it seems
Re: [PATCH v2 4/4] imx: hab: Use nxp_imx8mcst etype for i.MX8M flash.bin signing
On Tue, May 14, 2024 at 1:58 PM Marek Vasut wrote:
>
> On 5/14/24 8:34 PM, Tim Harvey wrote:
>
> Hi,
>
> >> diff --git a/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> >> b/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> >> index e16e5410bd9..ce1de659d8c 100644
> >> --- a/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> >> +++ b/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> >> @@ -121,6 +121,9 @@ build configuration:
> >> - Defconfig:
> >>
> >> CONFIG_IMX_HAB=y
> >> + CONFIG_FSL_CAAM=y
> >> + CONFIG_ARCH_MISC_INIT=y
> >> + CONFIG_SPL_CRYPTO=y
> >>
> >
> > Hi Marek,
> >
> > Thanks for wrapping the dts bits with a config item.
> >
> > Is there any other reason to build with CONFIG_IMX_HAB than to use a
> > signed image? I see that there are several ARCH_MX6 and ARCH_MX7
> > configs that have this enabled (not ARCH_IMX8M so this certainly
> > doesn't break anything) and I'm not sure what the value of that is.
>
> I think those few either enabled in preemptively in anticipation of
> possibly using HAB, or are wrong. I suspect it should be disabled for
> those, as it only adds to the board boot time and I am not even sure if
> those machines would boot correctly.
>
> Francesco, maybe you do have MX7 Colibri ?
>
> > I notice that FSL_CAAM is selected when you select IMX_HAB... is there
> > any reason why ARCH_MISC_INIT and SPL_CRYPTO should not be selected by
> > IMX_HAB as well (future patch perhaps)?
>
> ARCH_MISC_INIT should be selected by SoC Kconfig on MX7 and maybe CAAM
> on MX8M I think . As for SPL_CRYPTO, that should be selected by
> SPL_FSL_CAAM I think.
>
> >> - Kconfig:
> >>
> >
> > We definitely need to describe the additional requirements here. Maybe
> > something like:
> >
> > - Tools:
> > cst - NXP code-signing-tool (eg apt install imx-code-signing-tool)
> >
> > - Files: (created with NXP IMX_CST_TOOL)
> > SRK_1_2_3_4_table.bin (specified by nxp,srk-table node): fuse table
> > CSF1_1_sha256_4096_65537_v3_usr_crt.pem (specified by nxp,csf-crt node):
> > CSF_KEY
> > IMG1_1_sha256_4096_65537_v3_usr_crt.pem (specified by nxp,img-crt node):
> > IMG_KEY
> >
> > The following works fine for me on v2024.01
> > export CST_DIR=/usr/src/nxp/cst-3.3.2/
> > export CSF_KEY=$CST_DIR/crts/CSF1_1_sha256_4096_65537_v3_usr_crt.pem
> > export IMG_KEY=$CST_DIR/crts/IMG1_1_sha256_4096_65537_v3_usr_crt.pem
> > export SRK_TABLE=$CST_DIR/crts/SRK_1_2_3_4_table.bin
> > export PATH=$CST_DIR/linux64/bin:$PATH
> > make && /bin/sh doc/imx/habv4/csf_examples/mx8m/csf.sh
> >
> > But with the above defines and your series this fails:
> > ln -sf $SRK_TABLE SRK_1_2_3_4_table.bin
> > ln -sf $CSF_KEY CSF1_1_sha256_4096_65537_v3_usr_crt.pem
> > ln -sf $IMG_KEY IMG1_1_sha256_4096_65537_v3_usr_crt.pem
> > make
> >BINMAN .binman_stamp
> > Wrote map file './image.map' to show errors
> > binman: Error 1 running 'cst -i
> > ./nxp.csf-config-txt.section.nxp-imx8mcst@0 -o
> > ./nxp.csf-output-blob.section.nxp-imx8mcst@0': Error:
> > Cannot open key file IMG1_1_sha256_4096_65537_v3_usr_key.pem
> > 0:error:02001002:system library:fopen:No such file or
> > directory:crypto/bio/bss_file.c:288:fopen('IMG1_1_sha256_4096_65537_v3_usr_key.
> > pem','r')
> > 0:error:20074002:BIO routines:file_ctrl:system
> > lib:crypto/bio/bss_file.c:290:
> >
> > make: *** [Makefile:1126: .binman_stamp] Error 1
> >
> > So how is it that the default for nxp,img-crt
> > IMG1_1_sha256_4096_65537_v3_usr_crt.pem is now looking for
> > IMG1_1_sha256_4096_65537_v3_usr_key? It fails also if I cp the files
> > vs ln them.
> >
> > So what am I missing here?
>
> I think CST is using both the certificate and the key files. Try and run
> strace on the CST to test that:
>
> $ strace cst -i ./nxp.csf-config-txt.section.nxp-imx8mcst@0 -o
> ./nxp.csf-output-blob.section.nxp-imx8mcst@0
Hi Marek,
strace was a good idea and showed me what was going on.
The previous documentation stated to pass your keys via env vars that
were full paths to key certificates. Using strace shows me that it
will use the directory the KEY certificate is in and try to open up
../keys/*_usr_key.pem if the key path is specified. So apparently the
'File' in the CST config file is used indirectly. Pointing to the
usr_key.pem isn't enough either by the way, it seems to need both of
these:
so if I hack the path to my certs in like this it works:
diff --git a/tools/binman/etype/nxp_imx8mcst.py
b/tools/b
Re: [PATCH v2] fdt: automatically add /chosen/kaslr-seed if DM_RNG is enabled
On Wed, May 15, 2024 at 2:06 PM Marek Vasut wrote:
>
> On 5/15/24 10:50 PM, Tim Harvey wrote:
>
> [...]
>
> > diff --git a/boot/fdt_support.c b/boot/fdt_support.c
> > index 874ca4d6f5af..3455d60d69dc 100644
> > --- a/boot/fdt_support.c
> > +++ b/boot/fdt_support.c
> > @@ -8,6 +8,7 @@
> >
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -300,6 +301,15 @@ int fdt_chosen(void *fdt)
> > if (nodeoffset < 0)
> > return nodeoffset;
> >
> > + if (IS_ENABLED(CONFIG_DM_RNG) &&
> > !IS_ENABLED(ARMV8_SEC_FIRMWARE_SUPPORT)) {
> > + err = fdt_kaslrseed(fdt);
> > + if (err) {
> > + printf("WARNING: could not set kaslr-seed %s.\n",
> > +fdt_strerror(err));
> > + return err;
>
> Is this warning really a critical boot-breaking error ?
no, and in fact I'm printing a warning inside of fdt_kaslrseed so I
can remove the duplication of error prints in the various other places
it's called as well.
Thanks for pointing that out!
Best Regards,
Tim
>
> > + }
> > + }
> > +
> > if (IS_ENABLED(CONFIG_BOARD_RNG_SEED) && !board_rng_seed()) {
> > err = fdt_setprop(fdt, nodeoffset, "rng-seed",
> > abuf_data(), abuf_size());
>
> [...]
>
> The rest looks good !
[PATCH v2] fdt: automatically add /chosen/kaslr-seed if DM_RNG is enabled
If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
randomize the virtual address at which the kernel image is loaded, it
expects entropy to be provided by the bootloader by populating
/chosen/kaslr-seed with a 64-bit value from source of entropy at boot.
If we have DM_RNG enabled populate this value automatically when
fdt_chosen is called unless ARMV8_SEC_FIRMWARE_SUPPORT is enabled as
it's implementation uses a different source of entropy.
As this fdt node is added elsewhere create a library function and
use it to deduplicate code.
Note that the kalsrseed command (CMD_KASLRSEED) is likely pointless now
but left in place in case boot scripts exist that rely on this command
existing and returning success. An informational message is printed to
alert users of this command that it is likely no longer needed.
Signed-off-by: Tim Harvey
---
v2:
- fix typo in commit msg
- use stack for seed to avoid unecessary malloc/free
- move to a library function and deduplicate code by using it elsewhere
---
board/xilinx/common/board.c | 35 -
boot/fdt_support.c | 10 +
boot/pxe_utils.c| 35 +++--
cmd/kaslrseed.c | 45 ++---
include/kaslrseed.h | 17 ++
lib/Makefile| 1 +
lib/kaslrseed.c | 34
7 files changed, 72 insertions(+), 105 deletions(-)
create mode 100644 include/kaslrseed.h
create mode 100644 lib/kaslrseed.c
diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
index 30a81376ac41..f741e8957818 100644
--- a/board/xilinx/common/board.c
+++ b/board/xilinx/common/board.c
@@ -713,41 +713,6 @@ int ft_board_setup(void *blob, struct bd_info *bd)
if (IS_ENABLED(CONFIG_FDT_FIXUP_PARTITIONS) &&
IS_ENABLED(CONFIG_NAND_ZYNQ))
fdt_fixup_mtdparts(blob, nodes, ARRAY_SIZE(nodes));
- if (uclass_get_device(UCLASS_RNG, 0, ) || !dev) {
- debug("No RNG device\n");
- return 0;
- }
-
- if (dm_rng_read(dev, buf, n)) {
- debug("Reading RNG failed\n");
- return 0;
- }
-
- if (!blob) {
- debug("No FDT memory address configured. Please configure\n"
- "the FDT address via \"fdt addr \" command.\n"
- "Aborting!\n");
- return 0;
- }
-
- ret = fdt_check_header(blob);
- if (ret < 0) {
- debug("fdt_chosen: %s\n", fdt_strerror(ret));
- return ret;
- }
-
- nodeoffset = fdt_find_or_add_subnode(blob, 0, "chosen");
- if (nodeoffset < 0) {
- debug("Reading chosen node failed\n");
- return nodeoffset;
- }
-
- ret = fdt_setprop(blob, nodeoffset, "kaslr-seed", buf, sizeof(buf));
- if (ret < 0) {
- debug("Unable to set kaslr-seed on chosen node: %s\n",
fdt_strerror(ret));
- return ret;
- }
-
return 0;
}
#endif
diff --git a/boot/fdt_support.c b/boot/fdt_support.c
index 874ca4d6f5af..3455d60d69dc 100644
--- a/boot/fdt_support.c
+++ b/boot/fdt_support.c
@@ -8,6 +8,7 @@
#include
#include
+#include
#include
#include
#include
@@ -300,6 +301,15 @@ int fdt_chosen(void *fdt)
if (nodeoffset < 0)
return nodeoffset;
+ if (IS_ENABLED(CONFIG_DM_RNG) &&
!IS_ENABLED(ARMV8_SEC_FIRMWARE_SUPPORT)) {
+ err = fdt_kaslrseed(fdt);
+ if (err) {
+ printf("WARNING: could not set kaslr-seed %s.\n",
+ fdt_strerror(err));
+ return err;
+ }
+ }
+
if (IS_ENABLED(CONFIG_BOARD_RNG_SEED) && !board_rng_seed()) {
err = fdt_setprop(fdt, nodeoffset, "rng-seed",
abuf_data(), abuf_size());
diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c
index 4b22bb6f525a..8d70233fc08d 100644
--- a/boot/pxe_utils.c
+++ b/boot/pxe_utils.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -323,10 +324,6 @@ static void label_boot_kaslrseed(void)
#if CONFIG_IS_ENABLED(DM_RNG)
ulong fdt_addr;
struct fdt_header *working_fdt;
- size_t n = 0x8;
- struct udevice *dev;
- u64 *buf;
- int nodeoffset;
int err;
/* Get the main fdt and map it */
@@ -342,35 +339,9 @@ static void label_boot_kaslrseed(void)
if (err <= 0)
return;
- if (uclass_get_device(UCLASS_RNG, 0, ) || !dev) {
- printf("No RNG device\n");
- return;
- }
-
- nodeoffset = fdt_find_or_add_subnode(working_fdt
Re: [PATCH] fdt: add kaslr-seed if DM_RNG is enabled
On Tue, May 14, 2024 at 10:17 PM Heinrich Schuchardt wrote:
>
> On 5/15/24 02:50, Marek Vasut wrote:
> > On 5/15/24 2:22 AM, Tim Harvey wrote:
> >> If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
> >> randomize the virtual address at which the kernel image is loaded, it
> >> expects entropy to be provided by the bootloader by populating
> >> /chosen/kaslr-seed with a 64-bit value from source of entropy at boot.
> >
> > Thanks for working on this one, this is really nice.
>
> The general direction of always supplying a seed for KASLR is right. But
> there are some items to observe:
>
> We already have multiple places where /chosen/kaslr-seed is set, e.g.
> arch/arm/cpu/armv8/sec_firmware.c and board/xilinx/common/board.c.
>
Hi Heinrich,
Yes, Marek pointed out the same thing about de-duplicating code. I can
add a lib/kaslrseed.c with a fdt_kaslrseed function to deduplicate the
usage.
> Some boards are using the kaslrseed command to initialize
> /chosen/kaslr-seed from DM_RNG.
>
> It does not make sense to set it multiple times from different sources
> of randomness. I am missing the necessary clean-up in this patch.
>
> For CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT=y the right way forward could be
> moving sec_firmware_get_random() into the driver model. Tom is the
> maintainer for this code.
ok, I will not address arch/arm/cpu/armv8/sec_firmware.c and will
protect my implementation with 'if (IS_ENABLED(CONFIG_DM_RNG) &&
!IS_ENABLED(ARMV8_SEC_FIRMWARE_SUPPORT))'
>
> For Xilinx boards your patch obsoletes part of the code in
> ft_board_setup() of board/xilinx/common/board.c. CCing Michal as maintainer.
>
yes, I can remove that code to deduplicate as they are using
dm_rng_read() thus users of that must have CONFIG_DM_RNG enabled.
> The kaslrseed command similarly becomes obsolete with your patch and
> should be removed. 'git grep -n CMD_KASLR' indicates which defconfigs
> would be impacted.
>
There are several users of this command currently:
$ git grep CMD_KASLR configs/
configs/evb-rk3308_defconfig:CONFIG_CMD_KASLRSEED=y
configs/imx8mm_data_modul_edm_sbc_defconfig:CONFIG_CMD_KASLRSEED=y
configs/imx8mp_data_modul_edm_sbc_defconfig:CONFIG_CMD_KASLRSEED=y
configs/imx8mp_dhcom_pdk2_defconfig:CONFIG_CMD_KASLRSEED=y
configs/imx8mp_dhcom_pdk3_defconfig:CONFIG_CMD_KASLRSEED=y
configs/roc-cc-rk3308_defconfig:CONFIG_CMD_KASLRSEED=y
configs/rock-pi-s-rk3308_defconfig:CONFIG_CMD_KASLRSEED=y
configs/xilinx_versal_net_virt_defconfig:CONFIG_CMD_KASLRSEED=y
configs/xilinx_versal_virt_defconfig:CONFIG_CMD_KASLRSEED=y
configs/xilinx_zynqmp_kria_defconfig:CONFIG_CMD_KASLRSEED=y
configs/xilinx_zynqmp_virt_defconfig:CONFIG_CMD_KASLRSEED=y
While I can deduplicate code by calling a shared function in that
command I don't feel like I should remove that command until the
maintainers of the boards above agree on removing it from their
defconfigs as they could have bootscripts that fail with the command
missing.
I could add a warning print in the kaslrseed command indicating that
the use of this command is no longer needed.
> label_boot_kaslrseed() needs review too.
>
yes, this can be deduplicated
> kaslr-seed is not compatible with measured boot if the device-tree is
> measured. When booting via EFI in efi_try_purge_kaslr_seed() we can
> safely remove the value because it is not used anyway; we provide the
> EFI_RNG_PROTOCOL instead. We also support measured boot via the legacy
> Linux entry point. See patch dec166d6b2c2 ("bootm: Support boot
> measurement"). We should not populate kaslr-seed if
> CONFIG_MEASURE_DEVICETREE=y. CCing Eddie and Ilias as they have been
> working on measured boot.
>
board/raspberrypi/rpi/rpi.c:ft_board_setup copies /chosen/kaslr-seed
from an fdt apparently passed in from a lower level firmware stage.
should I check to see if /chosen/kaslr-seed exists and never overwrite
it or just let this get overwritten?
> >
> >> If we have DM_RNG enabled poulate this value automatically when
>
> nits
>
> %s/poulate/populate/
>
yes, I will fix that as well.
Thanks for the review!
Best Regards,
Tim
Re: [PATCH] fdt: add kaslr-seed if DM_RNG is enabled
On Tue, May 14, 2024 at 5:50 PM Marek Vasut wrote:
>
> On 5/15/24 2:22 AM, Tim Harvey wrote:
> > If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
> > randomize the virtual address at which the kernel image is loaded, it
> > expects entropy to be provided by the bootloader by populating
> > /chosen/kaslr-seed with a 64-bit value from source of entropy at boot.
>
> Thanks for working on this one, this is really nice.
>
> > If we have DM_RNG enabled poulate this value automatically when
> > fdt_chosen is called.
Hi Marek,
Just noticed a typo in the commit log - I'll s/poulate/populate/ in v2
> >
> > Signed-off-by: Tim Harvey
> > ---
> > boot/fdt_support.c | 23 +++
> > 1 file changed, 23 insertions(+)
> >
> > diff --git a/boot/fdt_support.c b/boot/fdt_support.c
> > index 874ca4d6f5af..cd3069baf450 100644
> > --- a/boot/fdt_support.c
> > +++ b/boot/fdt_support.c
> > @@ -7,10 +7,12 @@
> >*/
> >
> > #include
> > +#include
> > #include
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -300,6 +302,27 @@ int fdt_chosen(void *fdt)
> > if (nodeoffset < 0)
> > return nodeoffset;
> >
> > + if (IS_ENABLED(CONFIG_DM_RNG)) {
> > + struct udevice *dev;
> > + size_t len = 0x8;
> > + u64 *data;
> > +
> > + data = malloc(len);
>
> Can you allocate this 8 byte array on stack , i.e. u64 data[2]; ?
>
Sure... that makes sense - u64 data (just 1 64bit value)
> cmd/kaslrseed.c could use similar clean up (and
> lib/efi_loader/efi_dt_fixup.c and boot/pxe_utils.c ... uhhh). Maybe you
> can deduplicate this functionality into common code shared by all those
> duplicates before the duplication gets out of control ?
>
> lib/kaslrseed.c looks like a good place to put the common stuff.
Yes I started off making a function to do this but then I noticed we
had an fdt_chosen function and it fit there nicer as I didn't have to
find/create the chosen node. I also didn't know of a great place to
put it.
I will create a lib/kaslrseed.c with function for v2.
>
> > + if (!data)
> > + return -ENOMEM;
> > +
> > + err = uclass_get_device(UCLASS_RNG, 0, );
> > + if (!err)
> > + err = dm_rng_read(dev, data, len);
> > + if (!err)
> > + err = fdt_setprop(fdt, nodeoffset, "kaslr-seed",
> > data, len);
> > + if (err < 0) {
> > + printf("WARNING: could not set kaslr-seed %s.\n",
> > +fdt_strerror(err));
> > + return err;
> > + }
>
> You're missing free() here, but it shouldn't be needed if you allocate
> the array on stack, which is better/simpler.
Yes, I will avoid the malloc to fix that.
Thanks,
Tim
[PATCH] fdt: add kaslr-seed if DM_RNG is enabled
If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
randomize the virtual address at which the kernel image is loaded, it
expects entropy to be provided by the bootloader by populating
/chosen/kaslr-seed with a 64-bit value from source of entropy at boot.
If we have DM_RNG enabled poulate this value automatically when
fdt_chosen is called.
Signed-off-by: Tim Harvey
---
boot/fdt_support.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/boot/fdt_support.c b/boot/fdt_support.c
index 874ca4d6f5af..cd3069baf450 100644
--- a/boot/fdt_support.c
+++ b/boot/fdt_support.c
@@ -7,10 +7,12 @@
*/
#include
+#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -300,6 +302,27 @@ int fdt_chosen(void *fdt)
if (nodeoffset < 0)
return nodeoffset;
+ if (IS_ENABLED(CONFIG_DM_RNG)) {
+ struct udevice *dev;
+ size_t len = 0x8;
+ u64 *data;
+
+ data = malloc(len);
+ if (!data)
+ return -ENOMEM;
+
+ err = uclass_get_device(UCLASS_RNG, 0, );
+ if (!err)
+ err = dm_rng_read(dev, data, len);
+ if (!err)
+ err = fdt_setprop(fdt, nodeoffset, "kaslr-seed", data,
len);
+ if (err < 0) {
+ printf("WARNING: could not set kaslr-seed %s.\n",
+ fdt_strerror(err));
+ return err;
+ }
+ }
+
if (IS_ENABLED(CONFIG_BOARD_RNG_SEED) && !board_rng_seed()) {
err = fdt_setprop(fdt, nodeoffset, "rng-seed",
abuf_data(), abuf_size());
--
2.25.1
Re: [PATCH] imx: hab: add documentation about the required keys/certs
On Sun, May 12, 2024 at 10:08 PM Marek Vasut wrote:
>
> On 5/8/24 9:23 AM, Claudius Heine wrote:
> > Hi Marek,
>
> Hi,
>
> > On 2024-05-07 3:28 pm, Marek Vasut wrote:
> >> On 5/7/24 3:06 PM, Claudius Heine wrote:
> >>> For CST to find the certificates and keys for signing, some keys and
> >>> certs need to be copied into the u-boot build directory.
> >>
> >> Make sure to CC "NXP i.MX U-Boot Team" , else NXP is not informed. Use
> >> scripts/get_maintainer to get the full list or just reuse the CC list
> >> from patches in this thread.
> >
> > I send the patch with `--to-cmd scripts/get_maintainer.pl`, maybe I
> > should have used `--cc-cmd`, but that would not change the list of
> > recipients.
>
> Should now be fixed in
> [PATCH] ARM: imx: Add doc/imx/ to i.MX MAINTAINERS entry
>
> >>> diff --git a/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> >>> b/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> >>> index ce1de659d8..42214df21a 100644
> >>> --- a/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> >>> +++ b/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> >>> @@ -144,6 +144,22 @@ The signing is activated by wrapping SPL and
> >>> fitImage sections into nxp-imx8mcst
> >>> etype, which is done automatically in
> >>> arch/arm/dts/imx8m{m,n,p,q}-u-boot.dtsi
> >>> in case CONFIG_IMX_HAB Kconfig symbol is enabled.
> >>> +Per default the HAB keys and certificates need to be located in the
> >>> build
> >>> +directory, this means copying the following files from the HAB keys
> >>> directory
> >>> +flat (e.g. removing the `keys` and `cert` subdirectory) into the
> >>> u-boot build
> >>> +directory for the CST Code Signing Tool to locate them:
> >>
> >> Do symlink(s) work too ?
> >
> > I have not tested it, but I don't see any reason why it would not. I
> > also don't see a reason for mentioning it. I want to keep it simple, if
> > the dev whats to do things differently, they are free to do so.
>
> "
> Per default the HAB keys and certificates need to be located in the
> build directory, this means {+creating a symbolic link or +}copying the
> following...
> "
>
> Please test it and add it in V2 if it works, I think symlink is better
> than bluntly copying files around, esp. for crypto material.
Hi Marek and Claudius,
Yes, this documentation is needed as well but I'm still unclear why
the old method before this series did not require the usr_key.pem
files, why I don't have the *usr_key.pem files in my crts dir created
(long ago) with cst-3.3.1 and cst-3.3.2, and what I need to do to
generate them now that they are apparently needed.
Best Regards,
Tim
>
> >>> +- `crts/SRK_1_2_3_4_table.bin`
> >>> +- `crts/CSF1_1_sha256_4096_65537_v3_usr_crt.pem`
> >>> +- `keys/CSF1_1_sha256_4096_65537_v3_usr_key.pem`
> >>> +- `crts/IMG1_1_sha256_4096_65537_v3_usr_crt.pem`
> >>> +- `keys/IMG1_1_sha256_4096_65537_v3_usr_key.pem`
> >>> +- `keys/key_pass.txt`
> >>> +
> >>> +The paths to the SRK table and the certificates can be modified via
> >>> changes to
> >>> +the nxp_imx8mcst device tree node
> >>
> >> "nodes", plural, there are two, one for SPL and one for fitImage.
> >
> > Well, I was thinking here more generally about the node type and was
> > assuming that the person reading this knows how many they have of that
> > type. But I can add a `s` in v2.
>
> Use "node(s)" which covers both options.
>
> >> It would be good to mention the DT properties which govern the crypto
> >> material paths -- nxp,srk-table, nxp,csf-crt, nxp,img-crt -- somewhere
> >> around this sentence.
> >
> > This is something that should be documented with the changes where that
> > code was added, IMO. I only documented here what I found out and have
> > used myself, I haven't used those.
> >
> > I would be interested in reading how to best overwrite those paths and
> > the image structured from board u-boot.dtsi files myself.
> >
> > If you want to can pickup my patch and integrate it into your series and
> > extend it.
>
> I'll keep it in mind for V3.
Re: [PATCH v2 4/4] imx: hab: Use nxp_imx8mcst etype for i.MX8M flash.bin signing
On Thu, May 2, 2024 at 6:05 PM Marek Vasut wrote:
>
> Update documentation and use nxp_imx8mcst binman etype for signing
> of flash.bin instead of previous horrible shell scripting.
>
> Signed-off-by: Marek Vasut
> ---
> Cc: "NXP i.MX U-Boot Team"
> Cc: Adam Ford
> Cc: Alper Nebi Yasak
> Cc: Andrejs Cainikovs
> Cc: Angus Ainslie
> Cc: Emanuele Ghidoli
> Cc: Fabio Estevam
> Cc: Francesco Dolcini
> Cc: Marcel Ziswiler
> Cc: Rasmus Villemoes
> Cc: Simon Glass
> Cc: Stefan Eichenberger
> Cc: Stefano Babic
> Cc: Tim Harvey
> Cc: Tom Rini
> Cc: ker...@puri.sm
> Cc: u-b...@dh-electronics.com
> Cc: u-boot@lists.denx.de
> ---
> V2: Document the automatic signing in case CONFIG_IMX_HAB is enabled
> ---
> doc/imx/habv4/csf_examples/mx8m/csf.sh| 92
> doc/imx/habv4/csf_examples/mx8m/csf_fit.txt | 30 --
> doc/imx/habv4/csf_examples/mx8m/csf_spl.txt | 33 --
> doc/imx/habv4/guides/mx8m_spl_secure_boot.txt | 100 +++---
> 4 files changed, 14 insertions(+), 241 deletions(-)
> delete mode 100644 doc/imx/habv4/csf_examples/mx8m/csf.sh
> delete mode 100644 doc/imx/habv4/csf_examples/mx8m/csf_fit.txt
> delete mode 100644 doc/imx/habv4/csf_examples/mx8m/csf_spl.txt
>
> diff --git a/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> b/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> index e16e5410bd9..ce1de659d8c 100644
> --- a/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> +++ b/doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> @@ -121,6 +121,9 @@ build configuration:
> - Defconfig:
>
>CONFIG_IMX_HAB=y
> + CONFIG_FSL_CAAM=y
> + CONFIG_ARCH_MISC_INIT=y
> + CONFIG_SPL_CRYPTO=y
>
Hi Marek,
Thanks for wrapping the dts bits with a config item.
Is there any other reason to build with CONFIG_IMX_HAB than to use a
signed image? I see that there are several ARCH_MX6 and ARCH_MX7
configs that have this enabled (not ARCH_IMX8M so this certainly
doesn't break anything) and I'm not sure what the value of that is.
I notice that FSL_CAAM is selected when you select IMX_HAB... is there
any reason why ARCH_MISC_INIT and SPL_CRYPTO should not be selected by
IMX_HAB as well (future patch perhaps)?
> - Kconfig:
>
We definitely need to describe the additional requirements here. Maybe
something like:
- Tools:
cst - NXP code-signing-tool (eg apt install imx-code-signing-tool)
- Files: (created with NXP IMX_CST_TOOL)
SRK_1_2_3_4_table.bin (specified by nxp,srk-table node): fuse table
CSF1_1_sha256_4096_65537_v3_usr_crt.pem (specified by nxp,csf-crt node): CSF_KEY
IMG1_1_sha256_4096_65537_v3_usr_crt.pem (specified by nxp,img-crt node): IMG_KEY
The following works fine for me on v2024.01
export CST_DIR=/usr/src/nxp/cst-3.3.2/
export CSF_KEY=$CST_DIR/crts/CSF1_1_sha256_4096_65537_v3_usr_crt.pem
export IMG_KEY=$CST_DIR/crts/IMG1_1_sha256_4096_65537_v3_usr_crt.pem
export SRK_TABLE=$CST_DIR/crts/SRK_1_2_3_4_table.bin
export PATH=$CST_DIR/linux64/bin:$PATH
make && /bin/sh doc/imx/habv4/csf_examples/mx8m/csf.sh
But with the above defines and your series this fails:
ln -sf $SRK_TABLE SRK_1_2_3_4_table.bin
ln -sf $CSF_KEY CSF1_1_sha256_4096_65537_v3_usr_crt.pem
ln -sf $IMG_KEY IMG1_1_sha256_4096_65537_v3_usr_crt.pem
make
BINMAN .binman_stamp
Wrote map file './image.map' to show errors
binman: Error 1 running 'cst -i
./nxp.csf-config-txt.section.nxp-imx8mcst@0 -o
./nxp.csf-output-blob.section.nxp-imx8mcst@0': Error:
Cannot open key file IMG1_1_sha256_4096_65537_v3_usr_key.pem
0:error:02001002:system library:fopen:No such file or
directory:crypto/bio/bss_file.c:288:fopen('IMG1_1_sha256_4096_65537_v3_usr_key.
pem','r')
0:error:20074002:BIO routines:file_ctrl:system lib:crypto/bio/bss_file.c:290:
make: *** [Makefile:1126: .binman_stamp] Error 1
So how is it that the default for nxp,img-crt
IMG1_1_sha256_4096_65537_v3_usr_crt.pem is now looking for
IMG1_1_sha256_4096_65537_v3_usr_key? It fails also if I cp the files
vs ln them.
So what am I missing here?
Best Regards,
Tim
> @@ -131,92 +134,17 @@ build configuration:
>
> The CSF contains all the commands that the HAB executes during the secure
> boot. These commands instruct the HAB code on which memory areas of the image
> -to authenticate, which keys to install, use and etc.
> -
> -CSF examples are available under doc/imx/habv4/csf_examples/ directory.
> -
> -CSF "Blocks" line for csf_spl.txt can be generated as follows:
> -
> -```
> -spl_block_base=$(printf "0x%x" $(( $(sed -n "/CONFIG_SPL_TEXT_BASE=/
> s@.*=@@p" .config) - 0x40)) )
> -spl_block_size=$(printf "0x%x" $(stat -tc %s u-boot-spl-ddr.bin))
> -sed -i "/Blocks = / s@.*@ Blocks = $spl_block_base 0x0 $spl_block_size
> \"flash.bin\"@" csf_spl.txt
> -```
> -
> -The resul
Re: [PATCH v3] mmc: allow use of hardware partition names for mmc partconf
On Tue, May 14, 2024 at 5:05 AM Dragan Simic wrote:
>
> Hello all,
>
> On 2024-05-14 01:02, Marek Vasut wrote:
> > On 5/13/24 10:52 PM, Tim Harvey wrote:
> >> On Mon, Apr 29, 2024 at 1:51 PM Marek Vasut wrote:
> >>>
> >>> On 4/29/24 6:48 PM, Tim Harvey wrote:
> >>>> On Sat, Apr 27, 2024 at 4:20 PM Marek Vasut wrote:
> >>>>>
> >>>>> On 4/27/24 2:11 AM, Tim Harvey wrote:
> >>>>>
> >>>>> [...]
> >>>>>
> >>>>>> diff --git a/include/mmc.h b/include/mmc.h
> >>>>>> index 4b8327f1f93b..7243bd761202 100644
> >>>>>> --- a/include/mmc.h
> >>>>>> +++ b/include/mmc.h
> >>>>>> @@ -381,6 +381,21 @@ enum mmc_voltage {
> >>>>>> #define MMC_TIMING_MMC_HS2009
> >>>>>> #define MMC_TIMING_MMC_HS40010
> >>>>>>
> >>>>>> +/* emmc hardware partition values */
> >>>>>> +enum emmc_hwpart {
> >>>>>> + EMMC_HWPART_DEFAULT = 0,
> >>>>>
> >>>>> One more thing ... eMMC hardware partition 0 and 7 are both
> >>>>> referring to
> >>>>> USER HW partition. Have a look at the git log, there have been
> >>>>> patches
> >>>>> which handled this case in the MMC subsystem from about a year ago.
> >>>>
> >>>> I can't find what you are referring to. I assume you are talking
> >>>> about
> >>>> calling the first name something other than 'user' as technically
> >>>> it's
> >>>> not (but it gets treated as user).
> >>>>
> >>>> Can you find the commit or discussion you are thinking about?
> >>>
> >>> It seems this whole thing is much older:
> >>>
> >>> 7dbe63bc950b ("SPL: Add CONFIG_SUPPORT_EMMC_BOOT support to
> >>> CONFIG_SPL_FRAMEWORK")
> >>>
> >>> +* We need to check what the partition is configured
> >>> to.
> >>> +* 1 and 2 match up to boot0 / boot1 and 7 is user
> >>> data
> >>> +* which is the first physical partition (0).
> >>> +*/
> >>> + int part = (mmc->part_config >> 3) &
> >>> PART_ACCESS_MASK;
> >>> +
> >>> + if (part == 7)
> >>> + part = 0;
> >> Sorry, I haven't been able to work on U-Boot for the past week or so
> >> and am just getting back to this.
> >
> > No worries.
> >
> >> I'm glad you pointed this out as it made me aware that there is a bit
> >> of a mixing of eMMC PARTITION_CONFIG (Ext CSD 179) fields
> >> BOOT_PARTITION_ENABLE and PARTITION_ACCESS in U-Boot currently.
> >>
> >> I'm going to add an enumerated type for each and update the various
> >> places where a 'conversion' as above is done but I'm still a bit torn
> >> on naming conventions.
> >>
> >> Consider the following:
> >> - the eMMC spec refers to boot partitions and gp partitions as 1 based
> >> - the Linux kernel device names for these are 0 based
> >> - U-Boot does not currently refer to the boot devices by names but
> >> does currently refer to the gp's by names using 1-based names (the
> >> 'mmc hwpartition' command)
> >>
> >> Personally I would like to name the boot partitions 'boot0' and
> >> 'boot1' to match Linux but I think I should name the gp's
> >> 'gp1'...'gp4' to be backward compatible with the 'mmc hwpartition'
> >> command.
> >>
> >> What do you think?
> >
> > I agree.
> >
> > Maybe you could also check this with Ulf (Linux MMC maintainer) and
> > Avri (mmc-utils), both on To:, so we would be consistent and in sync ?
>
> As I promised earlier, I went through a few JEDEC standards and some
> publicly available JEDEC documents and presentations, and my conclusion
> is that no official numbering scheme for the partitions seems to be
> defined there.
>
> However, I'd propose that we keep "boot0" and "boot1", because that's
> pretty much become a de facto standard, and also switch to using "gp0"
> through "gp3" for the general-purpose partitions. That switch might
> be some kind of a backward-incompatible change, but it would follow
> the names of the
[PATCH 2/3 v4] mmc: allow use of hardware partition names for mmc partconf
eMMC v4+ devices have hardware partitions that are accessed via the
PARTITION_CONFIG (Extended CSD Register 179) PARTITION_ACCESS
and BOOT_PARTITION_ENABLE fields defined as:
bit 5:3: BOOT_PARTITION_ENABLE
0x0: Device not boot enabled (default)
0x1: Boot Area partition 1 enabled for boot
0x2: Boot Area partition 2 enabled for boot
0x3-0x6: Reserved
0x7: User area enabled for boot
bit 2:0 PARTITION_ACCESS
0x0: No access to boot partition (default)
0x1: Boot Area partition 1
0x2: Boot Area partition 2
0x3: Replay Protected Memory Block (RPMB)
0x4: Access to General Purpose partition 1
0x5: Access to General Purpose partition 2
0x6: Access to General Purpose partition 3
0x7: Access to General Purpose partition 4
Note that setting PARTITION_ACCESS to 0x0 results in selecting the User
Data Area partition.
Add char arrays to provide names for these values.
Use these names which displaying or setting the PARTITION_CONFIG
register via the 'mmc partconf' command.
Before:
u-boot=> mmc partconf 2 1 1 0 && mmc partconf 2
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x1
BOOT_PARTITION_ENABLE: 0x2
PARTITION_ACCESS: 0x0
After:
u-boot=> mmc partconf 2 1 1 0 && mmc partconf 2
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x1
BOOT_PARTITION_ENABLE: 0x1 (boot0)
PARTITION_ACCESS: 0x0 (user)
u-boot=> mmc partconf 2 1 boot1 user && mmc partconf 2
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x1
BOOT_PARTITION_ENABLE: 0x2 (boot1)
PARTITION_ACCESS: 0x0 (user)
Signed-off-by: Tim Harvey
---
v4:
- use static arrays so we can use ARRAY_SIZE when evaluating
- differentiate between PARTITION_CONFIG BOOT_PARTITION_ENABLE and
PARTITION_ACCESS field values and meanings
v3:
- define partition names and values in mmc.h/mmc.c for others to use
v2:
- fix typo in subject
- add names for gp1..gp4
Signed-off-by: Tim Harvey
---
cmd/mmc.c | 27 +++
drivers/mmc/mmc.c | 35 +++
include/mmc.h | 6 ++
3 files changed, 64 insertions(+), 4 deletions(-)
diff --git a/cmd/mmc.c b/cmd/mmc.c
index 2d5430a53079..02316796ba4e 100644
--- a/cmd/mmc.c
+++ b/cmd/mmc.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
static int curr_device = -1;
@@ -918,8 +919,9 @@ static int mmc_partconf_print(struct mmc *mmc, const char
*varname)
printf("EXT_CSD[179], PARTITION_CONFIG:\n"
"BOOT_ACK: 0x%x\n"
- "BOOT_PARTITION_ENABLE: 0x%x\n"
- "PARTITION_ACCESS: 0x%x\n", ack, part, access);
+ "BOOT_PARTITION_ENABLE: 0x%x (%s)\n"
+ "PARTITION_ACCESS: 0x%x (%s)\n", ack, part,
emmc_boot_part_names[part],
+ access, emmc_hwpart_names[access]);
return CMD_RET_SUCCESS;
}
@@ -948,9 +950,26 @@ static int do_mmc_partconf(struct cmd_tbl *cmdtp, int flag,
if (argc == 2 || argc == 3)
return mmc_partconf_print(mmc, cmd_arg2(argc, argv));
+ /* BOOT_ACK */
ack = dectoul(argv[2], NULL);
- part_num = dectoul(argv[3], NULL);
- access = dectoul(argv[4], NULL);
+ /* BOOT_PARTITION_ENABLE */
+ if (!isdigit(*argv[3])) {
+ for (part_num = ARRAY_SIZE(emmc_boot_part_names) - 1; part_num
> 0; part_num--) {
+ if (!strcmp(argv[3], emmc_boot_part_names[part_num]))
+ break;
+ }
+ } else {
+ part_num = dectoul(argv[3], NULL);
+ }
+ /* PARTITION_ACCESS */
+ if (!isdigit(*argv[4])) {
+ for (access = ARRAY_SIZE(emmc_hwpart_names) - 1; access > 0;
access--) {
+ if (!strcmp(argv[4], emmc_hwpart_names[access]))
+ break;
+ }
+ } else {
+ access = dectoul(argv[4], NULL);
+ }
/* acknowledge to be sent during boot operation */
ret = mmc_set_part_conf(mmc, ack, part_num, access);
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 7b068c71ff37..bfbf47a73009 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -29,6 +29,41 @@
#define DEFAULT_CMD6_TIMEOUT_MS 500
+/**
+ * names of emmc BOOT_PARTITION_ENABLE values
+ *
+ * Boot Area Partitions - name consistent with Linux
+ */
+const char *emmc_boot_part_names[] = {
+ "default", /* EMMC_BOOT_PART_DEFAULT */
+ "boot0",/* EMMC_BOOT_PART_BOOT1 */
+ "boot1",/* EMMC_BOOT_PART_BOOT2 */
+ "",
+ "",
+ "",
+ "",
+ "user", /* EMMC_BOOT_PART_USER */
+};
+
+/**
+ * names of emmc 'hardware partitions' consistent with:
+ * - value used in mmc_switch()
+ * - value used by PARTITION_CONFIG PARTITION_ACCESS field
+ *
+ * Boot Area Partitions - name consistent with Linux
+ * G
[PATCH 3/3 v4] venice: show emmc boot hardware partition
To aid in understanding what emmc hardware partition is being
used to boot on power-up, display the hardware partition name in the
SPL.
Signed-off-by: Tim Harvey
---
v4:
- include previous stand-alone patch in series
- use emmc hw partition enum and names
---
board/gateworks/venice/spl.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/board/gateworks/venice/spl.c b/board/gateworks/venice/spl.c
index 6f6dea84feee..ad3af93143d9 100644
--- a/board/gateworks/venice/spl.c
+++ b/board/gateworks/venice/spl.c
@@ -366,16 +366,24 @@ unsigned long board_spl_mmc_get_uboot_raw_sector(struct
mmc *mmc, unsigned long
const char *spl_board_loader_name(u32 boot_device)
{
+ static char name[16];
+ struct mmc *mmc;
+
switch (boot_device) {
/* SDHC2 */
case BOOT_DEVICE_MMC1:
- return "eMMC";
+ mmc_init_device(0);
+ mmc = find_mmc_device(0);
+ mmc_init(mmc);
+ snprintf(name, sizeof(name), "eMMC %s",
emmc_hwpart_names[EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config)]);
+ return name;
/* SDHC3 */
case BOOT_DEVICE_MMC2:
- return "SD card";
- default:
- return NULL;
+ sprintf(name, "SD card");
+ return name;
}
+
+ return NULL;
}
void spl_board_init(void)
--
2.25.1
[PATCH 0/3 v4] provide names for emmc hardware partitions
Modern eMMC v4+ devices have multiple hardware partitions per the JEDEC specification described as: Boot Area Partition 1 Boot Area Partition 2 RPMB Partition General Purpose Partition 1 General Purpose Partition 2 General Purpose Partition 3 General Purpose Partition 4 User Data Area These are referenced by fields in the PARTITION_CONFIG register (Extended CSD Register 179) which is defined as: bit 7: reserved bit 6: BOOT_ACK 0x0: No boot acknowledge sent (default 0x1: Boot acknowledge sent during boot operation Bit bit 5:3: BOOT_PARTITION_ENABLE 0x0: Device not boot enabled (default) 0x1: Boot Area partition 1 enabled for boot 0x2: Boot Area partition 2 enabled for boot 0x3-0x6: Reserved 0x7: User area enabled for boot bit 2:0 PARTITION_ACCESS 0x0: No access to boot partition (default) 0x1: Boot Area partition 1 0x2: Boot Area partition 2 0x3: Replay Protected Memory Block (RPMB) 0x4: Access to General Purpose partition 1 0x5: Access to General Purpose partition 2 0x6: Access to General Purpose partition 3 0x7: Access to General Purpose partition 4 Note that setting PARTITION_ACCESS to 0x0 results in selecting the User Data Area partition. You can see above that the two fields BOOT_PARTITION_ENABLE and PARTITION_ACCESS do not use the same enumerated values. U-Boot uses a set of macros to access fields of the PARTITION_CONFIG register: #define EXT_CSD_BOOT_ACK_ENABLE (1 << 6) #define EXT_CSD_BOOT_PARTITION_ENABLE (1 << 3) #define EXT_CSD_PARTITION_ACCESS_ENABLE (1 << 0) #define EXT_CSD_PARTITION_ACCESS_DISABLE(0 << 0) #define EXT_CSD_BOOT_ACK(x) (x << 6) #define EXT_CSD_BOOT_PART_NUM(x)(x << 3) #define EXT_CSD_PARTITION_ACCESS(x) (x << 0) #define EXT_CSD_EXTRACT_BOOT_ACK(x) (((x) >> 6) & 0x1) #define EXT_CSD_EXTRACT_BOOT_PART(x) (((x) >> 3) & 0x7) #define EXT_CSD_EXTRACT_PARTITION_ACCESS(x) ((x) & 0x7) There are various places in U-Boot where the BOOT_PARTITION_ENABLE field is accessed via EXT_CSD_EXTRACT_PARTITION_ACCESS and converted to a hardware partition consistent with the definition of the PARTITION_ACCESS field used by the various mmc_switch incarnations. To add some sanity to the distinction between BOOT_PARTITION_ENABLE (used to specify the active device on power-cycle) and PARTITION_ACCESS (used to switch between hardware partitions) create two enumerated types and use them wherever struct mmc * part_config is used or the above macros are used. Additionally provide arrays of the field names and allow those to be used in the 'mmc partconf' command and in board support files. The first patch adds enumerated types and makes use of them which represents no compiled code change. The 2nd patch adds the array of names and uses them in the 'mmc partconf' command. The 3rd patch uses the array of hardware partition names in a board support file to show what emmc hardware partition U-Boot is being loaded from. I'm sending this as a series this time around as previously it was repsented as two different patches. Tim Harvey (3): mmc: use an enumerated type to represent PARTITION_CONFIG fields mmc: allow use of hardware partition names for mmc partconf venice: show emmc boot hardware partition arch/arm/mach-imx/image-container.c | 10 - arch/arm/mach-sunxi/board.c | 2 +- board/gateworks/venice/spl.c| 20 - board/gateworks/venice/venice.c | 22 +- board/purism/librem5/librem5.c | 4 ++-- board/storopack/smegw01/smegw01.c | 4 ++-- cmd/mmc.c | 27 ++ cmd/mvebu/bubt.c| 4 ++-- common/spl/spl_mmc.c| 4 ++-- drivers/mmc/mmc.c | 35 + include/mmc.h | 26 + 11 files changed, 123 insertions(+), 35 deletions(-) -- 2.25.1
[PATCH 1/3 v4] mmc: use an enumerated type to represent PARTITION_CONFIG fields
Modern eMMC v4+ devices have multiple hardware partitions per the JEDEC
specification described as:
Boot Area Partition 1
Boot Area Partition 2
RPMB Partition
General Purpose Partition 1
General Purpose Partition 2
General Purpose Partition 3
General Purpose Partition 4
User Data Area
These are referenced by fields in the PARTITION_CONFIG register
(Extended CSD Register 179) which is defined as:
bit 7: reserved
bit 6: BOOT_ACK
0x0: No boot acknowledge sent (default
0x1: Boot acknowledge sent during boot operation Bit
bit 5:3: BOOT_PARTITION_ENABLE
0x0: Device not boot enabled (default)
0x1: Boot Area partition 1 enabled for boot
0x2: Boot Area partition 2 enabled for boot
0x3-0x6: Reserved
0x7: User area enabled for boot
bit 2:0 PARTITION_ACCESS
0x0: No access to boot partition (default)
0x1: Boot Area partition 1
0x2: Boot Area partition 2
0x3: Replay Protected Memory Block (RPMB)
0x4: Access to General Purpose partition 1
0x5: Access to General Purpose partition 2
0x6: Access to General Purpose partition 3
0x7: Access to General Purpose partition 4
Note that setting PARTITION_ACCESS to 0x0 results in selecting the User
Data Area partition.
You can see above that the two fields BOOT_PARTITION_ENABLE and
PARTITION_ACCESS do not use the same enumerated values.
U-Boot uses a set of macros to access fields of the PARTITION_CONFIG
register:
There are various places in U-Boot where the BOOT_PARTITION_ENABLE field
is accessed via EXT_CSD_EXTRACT_PARTITION_ACCESS and converted to a
hardware partition consistent with the definition of the
PARTITION_ACCESS field which is also the value used to specify the
hardware partition of the various mmc_switch incarnations.
To add some sanity to the distinction between BOOT_PARTITION_ENABLE
(used to specify the active device on power-cycle) and PARTITION_ACCESS
(used to switch between hardware partitions) create two enumerated types
and use them wherever struct mmc * part_config is used or the above
macros are used.
This represents no code changes.
Signed-off-by: Tim Harvey
---
v4: new patch in this series
---
arch/arm/mach-imx/image-container.c | 10 +-
arch/arm/mach-sunxi/board.c | 2 +-
board/gateworks/venice/spl.c| 4 ++--
board/gateworks/venice/venice.c | 22 +++---
board/purism/librem5/librem5.c | 4 ++--
board/storopack/smegw01/smegw01.c | 4 ++--
cmd/mvebu/bubt.c| 4 ++--
common/spl/spl_mmc.c| 4 ++--
include/mmc.h | 20
9 files changed, 47 insertions(+), 27 deletions(-)
diff --git a/arch/arm/mach-imx/image-container.c
b/arch/arm/mach-imx/image-container.c
index 35da0ae04258..bcd40889f0fa 100644
--- a/arch/arm/mach-imx/image-container.c
+++ b/arch/arm/mach-imx/image-container.c
@@ -205,7 +205,7 @@ static unsigned long get_boot_device_offset(void *dev, int
dev_type)
} else {
u8 part = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
- if (part == 1 || part == 2) {
+ if (part == EMMC_BOOT_PART_BOOT1 || part ==
EMMC_BOOT_PART_BOOT2) {
if (is_imx8qxp() && is_soc_rev(CHIP_REV_B))
offset = CONTAINER_HDR_MMCSD_OFFSET;
else
@@ -294,15 +294,15 @@ int spl_mmc_emmc_boot_partition(struct mmc *mmc)
int part;
part = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
- if (part == 1 || part == 2) {
+ if (part == EMMC_BOOT_PART_BOOT1 || part == EMMC_BOOT_PART_BOOT2) {
unsigned long sec_set_off = 0;
bool sec_boot = false;
sec_boot = check_secondary_cnt_set(_set_off);
if (sec_boot)
- part = (part == 1) ? 2 : 1;
- } else if (part == 7) {
- part = 0;
+ part = (part == EMMC_BOOT_PART_BOOT1) ?
EMMC_HWPART_BOOT2 : EMMC_HWPART_BOOT1;
+ } else if (part == EMMC_BOOT_PART_USER) {
+ part = EMMC_HWPART_DEFAULT;
}
return part;
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index 0140b07d32a6..860e7058b69c 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -396,7 +396,7 @@ static bool sunxi_valid_emmc_boot(struct mmc *mmc)
return false;
/* Partition 0 is the user data partition, bootpart must be 1 or 2. */
- if (bootpart != 1 && bootpart != 2)
+ if (bootpart != EMMC_BOOT_PART_BOOT1 && bootpart !=
EMMC_BOOT_PART_BOOT2)
return false;
/* Failure to switch to the boot partition is fatal. */
diff --git a/board/gateworks/venice/spl.c b/board/gateworks/venice/spl.c
index 3b0f11f2fd0f..6f6dea84feee 100644
--- a/board/gateworks/venice/spl.c
+++ b/board/gateworks/venice/spl.c
@@
Re: [PATCH v3] mmc: allow use of hardware partition names for mmc partconf
On Mon, Apr 29, 2024 at 1:51 PM Marek Vasut wrote:
>
> On 4/29/24 6:48 PM, Tim Harvey wrote:
> > On Sat, Apr 27, 2024 at 4:20 PM Marek Vasut wrote:
> >>
> >> On 4/27/24 2:11 AM, Tim Harvey wrote:
> >>
> >> [...]
> >>
> >>> diff --git a/include/mmc.h b/include/mmc.h
> >>> index 4b8327f1f93b..7243bd761202 100644
> >>> --- a/include/mmc.h
> >>> +++ b/include/mmc.h
> >>> @@ -381,6 +381,21 @@ enum mmc_voltage {
> >>>#define MMC_TIMING_MMC_HS2009
> >>>#define MMC_TIMING_MMC_HS40010
> >>>
> >>> +/* emmc hardware partition values */
> >>> +enum emmc_hwpart {
> >>> + EMMC_HWPART_DEFAULT = 0,
> >>
> >> One more thing ... eMMC hardware partition 0 and 7 are both referring to
> >> USER HW partition. Have a look at the git log, there have been patches
> >> which handled this case in the MMC subsystem from about a year ago.
> >
> > Hi Marek,
> >
> > I can't find what you are referring to. I assume you are talking about
> > calling the first name something other than 'user' as technically it's
> > not (but it gets treated as user).
> >
> > Can you find the commit or discussion you are thinking about?
>
> It seems this whole thing is much older:
>
> 7dbe63bc950b ("SPL: Add CONFIG_SUPPORT_EMMC_BOOT support to
> CONFIG_SPL_FRAMEWORK")
>
> +* We need to check what the partition is configured to.
> +* 1 and 2 match up to boot0 / boot1 and 7 is user data
> +* which is the first physical partition (0).
> +*/
> + int part = (mmc->part_config >> 3) & PART_ACCESS_MASK;
> +
> + if (part == 7)
> + part = 0;
Hi Marek,
Sorry, I haven't been able to work on U-Boot for the past week or so
and am just getting back to this.
I'm glad you pointed this out as it made me aware that there is a bit
of a mixing of eMMC PARTITION_CONFIG (Ext CSD 179) fields
BOOT_PARTITION_ENABLE and PARTITION_ACCESS in U-Boot currently.
I'm going to add an enumerated type for each and update the various
places where a 'conversion' as above is done but I'm still a bit torn
on naming conventions.
Consider the following:
- the eMMC spec refers to boot partitions and gp partitions as 1 based
- the Linux kernel device names for these are 0 based
- U-Boot does not currently refer to the boot devices by names but
does currently refer to the gp's by names using 1-based names (the
'mmc hwpartition' command)
Personally I would like to name the boot partitions 'boot0' and
'boot1' to match Linux but I think I should name the gp's
'gp1'...'gp4' to be backward compatible with the 'mmc hwpartition'
command.
What do you think?
Best Regards,
Tim
Re: [PATCH 064/149] board: gateworks: Remove and add needed includes
On Tue, Apr 30, 2024 at 7:44 PM Tom Rini wrote: > > Remove from this board vendor directory and when needed > add missing include files directly. > > Signed-off-by: Tom Rini > --- > Cc: Tim Harvey > --- > board/gateworks/gw_ventana/common.c | 1 - > board/gateworks/gw_ventana/eeprom.c | 1 - > board/gateworks/gw_ventana/gw_ventana.c | 1 - > board/gateworks/gw_ventana/gw_ventana_spl.c | 2 +- > board/gateworks/venice/eeprom.c | 1 - > board/gateworks/venice/lpddr4_timing_imx8mm.c | 1 - > board/gateworks/venice/spl.c | 1 - > 7 files changed, 1 insertion(+), 7 deletions(-) > > diff --git a/board/gateworks/gw_ventana/common.c > b/board/gateworks/gw_ventana/common.c > index 74328b2e1b31..891d1b5ddcaa 100644 > --- a/board/gateworks/gw_ventana/common.c > +++ b/board/gateworks/gw_ventana/common.c > @@ -5,7 +5,6 @@ > * Author: Tim Harvey > */ > > -#include > #include > #include > #include > diff --git a/board/gateworks/gw_ventana/eeprom.c > b/board/gateworks/gw_ventana/eeprom.c > index e622a9ba9e4d..b37f19722491 100644 > --- a/board/gateworks/gw_ventana/eeprom.c > +++ b/board/gateworks/gw_ventana/eeprom.c > @@ -5,7 +5,6 @@ > */ > > #include > -#include > #include > #include > #include > diff --git a/board/gateworks/gw_ventana/gw_ventana.c > b/board/gateworks/gw_ventana/gw_ventana.c > index 683def7e9f71..21a908c20dd5 100644 > --- a/board/gateworks/gw_ventana/gw_ventana.c > +++ b/board/gateworks/gw_ventana/gw_ventana.c > @@ -6,7 +6,6 @@ > */ > > #include > -#include > #include > #include > #include > diff --git a/board/gateworks/gw_ventana/gw_ventana_spl.c > b/board/gateworks/gw_ventana/gw_ventana_spl.c > index 2f046c9c0b3e..3de4727b2edf 100644 > --- a/board/gateworks/gw_ventana/gw_ventana_spl.c > +++ b/board/gateworks/gw_ventana/gw_ventana_spl.c > @@ -4,7 +4,7 @@ > * Author: Tim Harvey > */ > > -#include > +#include > #include > #include > #include > diff --git a/board/gateworks/venice/eeprom.c b/board/gateworks/venice/eeprom.c > index 241be4ee630b..afaabf348793 100644 > --- a/board/gateworks/venice/eeprom.c > +++ b/board/gateworks/venice/eeprom.c > @@ -3,7 +3,6 @@ > * Copyright 2021 Gateworks Corporation > */ > > -#include > #include > #include > #include > diff --git a/board/gateworks/venice/lpddr4_timing_imx8mm.c > b/board/gateworks/venice/lpddr4_timing_imx8mm.c > index 78b431dc2844..3f2c090a94fc 100644 > --- a/board/gateworks/venice/lpddr4_timing_imx8mm.c > +++ b/board/gateworks/venice/lpddr4_timing_imx8mm.c > @@ -6,7 +6,6 @@ > */ > > #include > -#include > #include > #include > > diff --git a/board/gateworks/venice/spl.c b/board/gateworks/venice/spl.c > index b0a315ba9531..f10d310a46d4 100644 > --- a/board/gateworks/venice/spl.c > +++ b/board/gateworks/venice/spl.c > @@ -3,7 +3,6 @@ > * Copyright 2021 Gateworks Corporation > */ > > -#include > #include > #include > #include > -- > 2.34.1 > Acked-By: Tim Harvey Tim
Re: [PATCH] ARM: imx: Enable kaslrseed command on DH i.MX8M Plus DHCOM
On Mon, Apr 29, 2024 at 1:51 PM Marek Vasut wrote:
>
> On 4/29/24 9:10 PM, Tim Harvey wrote:
> > On Tue, Apr 23, 2024 at 4:18 PM Marek Vasut wrote:
> >>
> >> On 4/19/24 5:24 PM, Tim Harvey wrote:
> >>> On Thu, Apr 18, 2024 at 11:42 AM Marek Vasut wrote:
> >>>>
> >>>> On 4/18/24 8:02 PM, Fabio Estevam wrote:
> >>>>> Hi Tim,
> >>>>>
> >>>>> On Thu, Apr 18, 2024 at 2:54 PM Tim Harvey
> >>>>> wrote:
> >>>>>
> >>>>>> Fabio, if you enable CONFIG_DM_RNG on an imx8m{m,p}_evk do you get the
> >>>>>> following in the SPL?
> >>>>>> Couldn't bind rng driver (-96)
> >>>>>> SEC0: RNG instantiated
> >>>>>>
> >>>>>> sec_init failed!
> >>>>>
> >>>>> Yes, if I add CONFIG_DM_RNG=y to imx8mm_evk_defconfig I get:
> >>>>>
> >>>>> U-Boot SPL 2024.04-00793-g3434b88d2c2f-dirty (Apr 18 2024 - 14:58:57
> >>>>> -0300)
> >>>>> No pmic
> >>>>> Couldn't bind rng driver (-96)
> >>>>> SEC0: RNG instantiated
> >>>>>
> >>>>> sec_init failed!
> >>>>
> >>>> Interesting. Which TFA blob version do you use ? I used the mainline
> >>>> 2.10 for my tests.
> >>>
> >>> Marek,
> >>>
> >>> Were you able to reproduce this as well with the board you enabled
> >>> DM_RNG for? If it does work fine what dtb were you using... perhaps
> >>> there is something in its u-boot.dtsi that we need?
> >>
> >> This one arch/arm/dts/imx8mp-dhcom-pdk3.dts , see log below. The build
> >> has a few extra patches in it, but nothing which affects the KASLR:
> >>
> >> $ export SOURCE_DATE_EPOCH=1672531200 ; echo tst > .scmversion
> >> $ make imx8mp_dhcom_pdk3_defconfig ; make
> >>
> >> U-Boot SPL 2024.07-rc1tst (Jan 01 2023 - 00:00:00 +)
> >> DDR: 4096 MiB [0x5]
> >> DDR: Inline ECC enabled
> >> WDT: Started watchdog@3028 with servicing every 1000ms (60s timeout)
> >> Trying to boot from BOOTROM
> >> Boot Stage: Primary boot
> >> image offset 0x1000, pagesize 0x1, ivt offset 0x0
> >> NOTICE: Do not release JR0 to NS as it can be used by HAB
> >> NOTICE: BL31: v2.10.0 (release):v2.10.0-5-gfb51ca229
> >> NOTICE: BL31: Built : 20:30:36, Apr 23 2024
> >>
> >>
> >> U-Boot 2024.07-rc1tst (Jan 01 2023 - 00:00:00 +)
> >>
> >> CPU: Freescale i.MX8MP[8] rev1.1 1600 MHz (running at 1200 MHz)
> >> CPU: Industrial temperature grade (-40C to 105C) at 70C
> >> Reset cause: POR
> >> Model: DH electronics i.MX8M Plus DHCOM Premium Developer Kit (3)
> >> DRAM: 3.5 GiB
> >> Core: 183 devices, 34 uclasses, devicetree: separate
> >> WDT: Started watchdog@3028 with servicing every 1000ms (60s timeout)
> >> MMC: FSL_SDHC: 0, FSL_SDHC: 1
> >> Loading Environment from SPIFlash... SF: Detected w25q128jw with page
> >> size 256 Bytes, erase size 4 KiB, total 16 MiB
> >> OK
> >> In:serial
> >> Out: serial
> >> Err: serial
> >> SEC0: RNG instantiated
> >> Net: eth1: ethernet@30be, eth0: ethernet@30bf
> >> ...
> >>
> >>> The error -EPFNOSUPPORT is interesting and helps point to the only
> >>> place it can be where the comment says the strange errno is to make
> >>> this easier to find:
> >>> https://elixir.bootlin.com/u-boot/latest/source/drivers/core/uclass.c#L70:
> >>> if (!uc_drv) {
> >>> debug("Cannot find uclass for id %d: please add the
> >>> UCLASS_DRIVER() declaration for this UCLASS_... id\n",
> >>> id);
> >>> /*
> >>>* Use a strange error to make this case easier to
> >>> find. When
> >>>* a uclass is not available it can prevent driver
> >>> model from
> >>>* starting up and this failure is otherwise hard to
> >>> debug.
> >>>*/
> >>> return -EPFNOSUPPORT;
> >>> }
> >>>
> >>> I'm not very familiar with the dm driver binding - does the
> >>> U-BOOT_DRIVER usage in drivers/crypto/fsl/rng.c need to be refactored
> >>> to use UCLASS_DRIVER for it to be usable in both SPL and U-Boot?
> >>
> >> I don't think you need the CAAM RNG in SPL in the first place, or do you ?
> >>
> >>> Honestly I don't know why we need DM_RNG in SPL anyway and we could
> >>> just add support for disabling it there to avoid unwanted bloat.
> >>
> >> I think you can disable it , yes.
> >
> > Marek,
> >
> > Would it be advantageous for the kaslr-seed to be added automatically
> > from image_setup_libfdt?
>
> Yes, can you prepare a patch ? (I wanted to do this, just haven't had
> the time)
>
> > I notice arch/arm/cpu/armv8/fsl-layerscape/fdt.c:ft_cpu_setup does
> > this and board/raspberrypi/rpi/rpi.c looks like it copies kaslr-seed
> > from the control fdt which I assume was added by an earlier layer for
> > that target.
>
> Right, exactly, this .
>
> > I'm not clear if there is a disadvantage to automatically adding this
> > node if DM_RNG is enabled.
>
> I would say, add it.
Yes, I'll submit something this week.
Best Regards,
Tim
Re: [PATCH] ARM: imx: Enable kaslrseed command on DH i.MX8M Plus DHCOM
On Tue, Apr 23, 2024 at 4:18 PM Marek Vasut wrote:
>
> On 4/19/24 5:24 PM, Tim Harvey wrote:
> > On Thu, Apr 18, 2024 at 11:42 AM Marek Vasut wrote:
> >>
> >> On 4/18/24 8:02 PM, Fabio Estevam wrote:
> >>> Hi Tim,
> >>>
> >>> On Thu, Apr 18, 2024 at 2:54 PM Tim Harvey wrote:
> >>>
> >>>> Fabio, if you enable CONFIG_DM_RNG on an imx8m{m,p}_evk do you get the
> >>>> following in the SPL?
> >>>> Couldn't bind rng driver (-96)
> >>>> SEC0: RNG instantiated
> >>>>
> >>>> sec_init failed!
> >>>
> >>> Yes, if I add CONFIG_DM_RNG=y to imx8mm_evk_defconfig I get:
> >>>
> >>> U-Boot SPL 2024.04-00793-g3434b88d2c2f-dirty (Apr 18 2024 - 14:58:57
> >>> -0300)
> >>> No pmic
> >>> Couldn't bind rng driver (-96)
> >>> SEC0: RNG instantiated
> >>>
> >>> sec_init failed!
> >>
> >> Interesting. Which TFA blob version do you use ? I used the mainline
> >> 2.10 for my tests.
> >
> > Marek,
> >
> > Were you able to reproduce this as well with the board you enabled
> > DM_RNG for? If it does work fine what dtb were you using... perhaps
> > there is something in its u-boot.dtsi that we need?
>
> This one arch/arm/dts/imx8mp-dhcom-pdk3.dts , see log below. The build
> has a few extra patches in it, but nothing which affects the KASLR:
>
> $ export SOURCE_DATE_EPOCH=1672531200 ; echo tst > .scmversion
> $ make imx8mp_dhcom_pdk3_defconfig ; make
>
> U-Boot SPL 2024.07-rc1tst (Jan 01 2023 - 00:00:00 +)
> DDR: 4096 MiB [0x5]
> DDR: Inline ECC enabled
> WDT: Started watchdog@3028 with servicing every 1000ms (60s timeout)
> Trying to boot from BOOTROM
> Boot Stage: Primary boot
> image offset 0x1000, pagesize 0x1, ivt offset 0x0
> NOTICE: Do not release JR0 to NS as it can be used by HAB
> NOTICE: BL31: v2.10.0 (release):v2.10.0-5-gfb51ca229
> NOTICE: BL31: Built : 20:30:36, Apr 23 2024
>
>
> U-Boot 2024.07-rc1tst (Jan 01 2023 - 00:00:00 +)
>
> CPU: Freescale i.MX8MP[8] rev1.1 1600 MHz (running at 1200 MHz)
> CPU: Industrial temperature grade (-40C to 105C) at 70C
> Reset cause: POR
> Model: DH electronics i.MX8M Plus DHCOM Premium Developer Kit (3)
> DRAM: 3.5 GiB
> Core: 183 devices, 34 uclasses, devicetree: separate
> WDT: Started watchdog@3028 with servicing every 1000ms (60s timeout)
> MMC: FSL_SDHC: 0, FSL_SDHC: 1
> Loading Environment from SPIFlash... SF: Detected w25q128jw with page
> size 256 Bytes, erase size 4 KiB, total 16 MiB
> OK
> In:serial
> Out: serial
> Err: serial
> SEC0: RNG instantiated
> Net: eth1: ethernet@30be, eth0: ethernet@30bf
> ...
>
> > The error -EPFNOSUPPORT is interesting and helps point to the only
> > place it can be where the comment says the strange errno is to make
> > this easier to find:
> > https://elixir.bootlin.com/u-boot/latest/source/drivers/core/uclass.c#L70:
> > if (!uc_drv) {
> > debug("Cannot find uclass for id %d: please add the
> > UCLASS_DRIVER() declaration for this UCLASS_... id\n",
> >id);
> > /*
> > * Use a strange error to make this case easier to find.
> > When
> > * a uclass is not available it can prevent driver model
> > from
> > * starting up and this failure is otherwise hard to debug.
> > */
> > return -EPFNOSUPPORT;
> > }
> >
> > I'm not very familiar with the dm driver binding - does the
> > U-BOOT_DRIVER usage in drivers/crypto/fsl/rng.c need to be refactored
> > to use UCLASS_DRIVER for it to be usable in both SPL and U-Boot?
>
> I don't think you need the CAAM RNG in SPL in the first place, or do you ?
>
> > Honestly I don't know why we need DM_RNG in SPL anyway and we could
> > just add support for disabling it there to avoid unwanted bloat.
>
> I think you can disable it , yes.
Marek,
Would it be advantageous for the kaslr-seed to be added automatically
from image_setup_libfdt?
I notice arch/arm/cpu/armv8/fsl-layerscape/fdt.c:ft_cpu_setup does
this and board/raspberrypi/rpi/rpi.c looks like it copies kaslr-seed
from the control fdt which I assume was added by an earlier layer for
that target.
I'm not clear if there is a disadvantage to automatically adding this
node if DM_RNG is enabled.
Best Regards,
Tim
Re: [PATCH v3] mmc: allow use of hardware partition names for mmc partconf
On Sat, Apr 27, 2024 at 4:20 PM Marek Vasut wrote:
>
> On 4/27/24 2:11 AM, Tim Harvey wrote:
>
> [...]
>
> > diff --git a/include/mmc.h b/include/mmc.h
> > index 4b8327f1f93b..7243bd761202 100644
> > --- a/include/mmc.h
> > +++ b/include/mmc.h
> > @@ -381,6 +381,21 @@ enum mmc_voltage {
> > #define MMC_TIMING_MMC_HS2009
> > #define MMC_TIMING_MMC_HS40010
> >
> > +/* emmc hardware partition values */
> > +enum emmc_hwpart {
> > + EMMC_HWPART_DEFAULT = 0,
>
> One more thing ... eMMC hardware partition 0 and 7 are both referring to
> USER HW partition. Have a look at the git log, there have been patches
> which handled this case in the MMC subsystem from about a year ago.
Hi Marek,
I can't find what you are referring to. I assume you are talking about
calling the first name something other than 'user' as technically it's
not (but it gets treated as user).
Can you find the commit or discussion you are thinking about?
Best Regards,
Tim
[PATCH v3] mmc: allow use of hardware partition names for mmc partconf
eMMC devices have hardware partitions such as user, boot0, and boot1.
Add an enumerated type defining the hardware partition values and an
array of names describing them by name that can be used throughout
U-Boot.
Allow these names to be displayed when reading and used when setting
the mmc PARTITION_CONFIG field via 'mmc partconf'.
Before:
u-boot=> mmc partconf 2 1 1 0 && mmc partconf 2
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x1
BOOT_PARTITION_ENABLE: 0x2
PARTITION_ACCESS: 0x0
After:
u-boot=> mmc partconf 2 1 1 0 && mmc partconf 2
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x1
BOOT_PARTITION_ENABLE: 0x1 (boot0)
PARTITION_ACCESS: 0x0
u-boot=> mmc partconf 2 1 boot1 0 && mmc partconf 2
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x1
BOOT_PARTITION_ENABLE: 0x2 (boot1)
PARTITION_ACCESS: 0x0
Signed-off-by: Tim Harvey
---
v3:
- define partition names and values in mmc.h/mmc.c for others to use
v2:
- fix typo in subject
- add names for gp1..gp4
---
cmd/mmc.c | 14 +++---
drivers/mmc/mmc.c | 11 +++
include/mmc.h | 15 +++
3 files changed, 37 insertions(+), 3 deletions(-)
diff --git a/cmd/mmc.c b/cmd/mmc.c
index 2d5430a53079..26ab4450816b 100644
--- a/cmd/mmc.c
+++ b/cmd/mmc.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
static int curr_device = -1;
@@ -918,8 +919,8 @@ static int mmc_partconf_print(struct mmc *mmc, const char
*varname)
printf("EXT_CSD[179], PARTITION_CONFIG:\n"
"BOOT_ACK: 0x%x\n"
- "BOOT_PARTITION_ENABLE: 0x%x\n"
- "PARTITION_ACCESS: 0x%x\n", ack, part, access);
+ "BOOT_PARTITION_ENABLE: 0x%x (%s)\n"
+ "PARTITION_ACCESS: 0x%x\n", ack, part, emmc_hwpart_names[part],
access);
return CMD_RET_SUCCESS;
}
@@ -949,7 +950,14 @@ static int do_mmc_partconf(struct cmd_tbl *cmdtp, int flag,
return mmc_partconf_print(mmc, cmd_arg2(argc, argv));
ack = dectoul(argv[2], NULL);
- part_num = dectoul(argv[3], NULL);
+ if (!isdigit(*argv[3])) {
+ for (part_num = 0; part_num <= EMMC_HWPART_USER; part_num++) {
+ if (!strcmp(argv[3], emmc_hwpart_names[part_num]))
+ break;
+ }
+ } else {
+ part_num = dectoul(argv[3], NULL);
+ }
access = dectoul(argv[4], NULL);
/* acknowledge to be sent during boot operation */
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 7b068c71ff37..132afe1b8a29 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -29,6 +29,17 @@
#define DEFAULT_CMD6_TIMEOUT_MS 500
+const char *emmc_hwpart_names[] = {
+ "user",
+ "boot0",
+ "boot1",
+ "gp1",
+ "gp2",
+ "gp3",
+ "gp4",
+ "user",
+};
+
static int mmc_set_signal_voltage(struct mmc *mmc, uint signal_voltage);
#if !CONFIG_IS_ENABLED(DM_MMC)
diff --git a/include/mmc.h b/include/mmc.h
index 4b8327f1f93b..7243bd761202 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -381,6 +381,21 @@ enum mmc_voltage {
#define MMC_TIMING_MMC_HS200 9
#define MMC_TIMING_MMC_HS400 10
+/* emmc hardware partition values */
+enum emmc_hwpart {
+ EMMC_HWPART_DEFAULT = 0,
+ EMMC_HWPART_BOOT0 = 1,
+ EMMC_HWPART_BOOT1 = 2,
+ EMMC_HWPART_GP1 = 3,
+ EMMC_HWPART_GP2 = 4,
+ EMMC_HWPART_GP3 = 5,
+ EMMC_HWPART_GP4 = 6,
+ EMMC_HWPART_USER = 7,
+};
+
+/* emmc hardware partition names */
+extern const char *emmc_hwpart_names[];
+
/* Driver model support */
/**
--
2.25.1
Re: [PATCH] venice: show emmc boot hardware partition
On Fri, Apr 26, 2024 at 12:26 PM Dragan Simic wrote:
>
> Hello Tim,
>
> Please see my comments below.
>
> On 2024-04-26 18:55, Tim Harvey wrote:
> > To aid in understanding what emmc hardware partition is being
> > used to boot on power-up, display the hardware partition name in the
> > SPL.
> >
> > Signed-off-by: Tim Harvey
> > ---
> > board/gateworks/venice/spl.c | 16
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/board/gateworks/venice/spl.c
> > b/board/gateworks/venice/spl.c
> > index 3b0f11f2fd0f..531bad260b6d 100644
> > --- a/board/gateworks/venice/spl.c
> > +++ b/board/gateworks/venice/spl.c
> > @@ -366,9 +366,25 @@ unsigned long
> > board_spl_mmc_get_uboot_raw_sector(struct mmc *mmc, unsigned long
> >
> > const char *spl_board_loader_name(u32 boot_device)
> > {
> > + struct mmc *mmc;
> > + int part;
> > +
> > switch (boot_device) {
> > /* SDHC2 */
> > case BOOT_DEVICE_MMC1:
> > + mmc_init_device(0);
> > + mmc = find_mmc_device(0);
> > + mmc_init(mmc);
> > + part = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
> > + switch (part) {
> > + case 1:
> > + return "eMMC boot0";
> > + case 2:
> > + return "eMMC boot1";
> > + case 0:
> > + case 7:
> > + return "eMMC user";
> > + }
> > return "eMMC";
> > /* SDHC3 */
> > case BOOT_DEVICE_MMC2:
>
> Your other patch on the mailing list does something similar. [1]
> Perhaps this is a good oportunity to extract and unify the logic
> that produces the names of eMMC partitions? That would also allow
> other boards to use the same logic.
>
Hi Dragan,
Fair enough - I will resubmit both patches with this in mind.
Best Regards
Tim
Re: [PATCH v2] cmd: mmc: allow use of hardware partition names for mmc partconf
On Fri, Apr 26, 2024 at 10:25 AM Marek Vasut wrote:
>
> On 4/26/24 7:12 PM, Tim Harvey wrote:
> > eMMC devices have hardware partitions such as user, boot0, and boot1.
> > Allow these names to be displayed when reading the mmc PARTITION_CONFIG
> > field via 'mmc partconf'. Additionally allow a name to be specified when
> > setting the PARTITION_CONFIG.
> >
> > Before:
> > u-boot=> mmc partconf 2 1 1 0 && mmc partconf 2
> > EXT_CSD[179], PARTITION_CONFIG:
> > BOOT_ACK: 0x1
> > BOOT_PARTITION_ENABLE: 0x2
> > PARTITION_ACCESS: 0x0
> >
> > After:
> > u-boot=> mmc partconf 2 1 1 0 && mmc partconf 2
> > EXT_CSD[179], PARTITION_CONFIG:
> > BOOT_ACK: 0x1
> > BOOT_PARTITION_ENABLE: 0x1 (boot0)
> > PARTITION_ACCESS: 0x0
> > u-boot=> mmc partconf 2 1 boot1 0 && mmc partconf 2
> > EXT_CSD[179], PARTITION_CONFIG:
> > BOOT_ACK: 0x1
> > BOOT_PARTITION_ENABLE: 0x2 (boot1)
> > PARTITION_ACCESS: 0x0
> >
> > Signed-off-by: Tim Harvey
> > ---
> > v2:
> > - fix typo in subject
> > - add names for gp1..gp4
> > ---
> > cmd/mmc.c | 25 ++---
> > 1 file changed, 22 insertions(+), 3 deletions(-)
> >
> > diff --git a/cmd/mmc.c b/cmd/mmc.c
> > index 2d5430a53079..af9a66cc6df4 100644
> > --- a/cmd/mmc.c
> > +++ b/cmd/mmc.c
> > @@ -14,6 +14,18 @@
> > #include
> > #include
> > #include
> > +#include
> > +
> > +static const char *mmc_partnames[] = {
> > + "user",
> > + "boot0",
> > + "boot1",
> > + "gp1",
> > + "gp2",
> > + "gp3",
> > + "gp4",
>
> Uh, maybe gp%d are indexed from zero too ?
>
> (sorry for the confusion)
but 'mmc hwpartition' does not list them 0 based:
u-boot=> mmc hwpartition
switch to partitions #0, OK
mmc2(part 0) is current device
Partition configuration:
No enhanced user data area
No GP1 partition
No GP2 partition
No GP3 partition
No GP4 partition
I'm ok with either, I'm just not sure what is more understandable and standard.
Tim
Re: [PATCH 2/3] crypto/fsl: Introduce SPL_FSL_CAAM_RNG
On Fri, Apr 26, 2024 at 7:45 AM Heinrich Schuchardt wrote: > > On 26.04.24 06:03, Marek Vasut wrote: > > On 4/26/24 2:16 AM, Tim Harvey wrote: > > > >>> diff --git a/drivers/crypto/fsl/Makefile b/drivers/crypto/fsl/Makefile > >>> index 7a2543e16cc..4fbce519a0b 100644 > >>> --- a/drivers/crypto/fsl/Makefile > >>> +++ b/drivers/crypto/fsl/Makefile > >>> @@ -6,6 +6,6 @@ obj-y += sec.o > >>> obj-$(CONFIG_FSL_CAAM) += jr.o fsl_hash.o jobdesc.o error.o > >>> obj-$(CONFIG_CMD_BLOB)$(CONFIG_IMX_CAAM_DEK_ENCAP) += fsl_blob.o > >>> obj-$(CONFIG_RSA_FREESCALE_EXP) += fsl_rsa.o > >>> -obj-$(CONFIG_FSL_CAAM_RNG) += rng.o > >>> +obj-$(CONFIG_$(SPL_TPL_)FSL_CAAM_RNG) += rng.o > >>> obj-$(CONFIG_FSL_DCP_RNG) += dcp_rng.o > >>> obj-$(CONFIG_FSL_MFGPROT) += fsl_mfgprot.o > >>> -- > >>> 2.43.0 > >>> > >> > >> Marek, > > > > Hi, > > > >> Thanks - this series does solve the issue I am seeing in the SPL when > >> enabling DM_RNG. Is this going to cause an issue for people who expect > >> it to be currently enabled and now have to manually enable it? > > > > That's a good question. If I do '$ git grep FSL_CAAM_RNG' , there seem > > to be no users, so I don't think we need to worry here, right ? > > > > With SPL_DM_RNG i.e. 1/3 I am a bit more concerned. But, looking at the > > users that enable DM_RNG, I am not seeing any obvious ones that would > > require SPL_DM_RNG too. What do you think ? > > Grepping for UCLASS_RNG should find usages. > > The only possible SPL usage seems to be in net/net_rand.h. Here a > fallback to the mac address as seed exists. > > Best regards > > Heinrich > Hi Heinrich, looks like its also used in lib/uuid.c by CONFIG_RANDOM_UUID and the few configs have CONFIG_RANDOM_UUID=y do not have DM_RNG=y so not an issue. srand_mac is used in: net/bootp.c which is CONFIG_CMD_BOOTP so not SPL net/dhcpv6.c which is CONIFG_CMD_DHCP6 so not in SPL net/net.c which is used by CONFIG_SPL_DM_ETH and the fallback you refer to but 'git grep DM_RNG=y configs/ | cut -d: -f1 | xargs grep SPL_DM_ETH' shows no results so I think this is ok right? but I also see lib/efi_loader/efi_rng.c where UCLASS_RNG used by efi_rng_protocol - I don't know anything about efi... is this going to be used by SPL? Best Regards, Tim
[PATCH v2] cmd: mmc: allow use of hardware partition names for mmc partconf
eMMC devices have hardware partitions such as user, boot0, and boot1.
Allow these names to be displayed when reading the mmc PARTITION_CONFIG
field via 'mmc partconf'. Additionally allow a name to be specified when
setting the PARTITION_CONFIG.
Before:
u-boot=> mmc partconf 2 1 1 0 && mmc partconf 2
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x1
BOOT_PARTITION_ENABLE: 0x2
PARTITION_ACCESS: 0x0
After:
u-boot=> mmc partconf 2 1 1 0 && mmc partconf 2
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x1
BOOT_PARTITION_ENABLE: 0x1 (boot0)
PARTITION_ACCESS: 0x0
u-boot=> mmc partconf 2 1 boot1 0 && mmc partconf 2
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x1
BOOT_PARTITION_ENABLE: 0x2 (boot1)
PARTITION_ACCESS: 0x0
Signed-off-by: Tim Harvey
---
v2:
- fix typo in subject
- add names for gp1..gp4
---
cmd/mmc.c | 25 ++---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/cmd/mmc.c b/cmd/mmc.c
index 2d5430a53079..af9a66cc6df4 100644
--- a/cmd/mmc.c
+++ b/cmd/mmc.c
@@ -14,6 +14,18 @@
#include
#include
#include
+#include
+
+static const char *mmc_partnames[] = {
+ "user",
+ "boot0",
+ "boot1",
+ "gp1",
+ "gp2",
+ "gp3",
+ "gp4",
+ "user",
+};
static int curr_device = -1;
@@ -918,8 +930,8 @@ static int mmc_partconf_print(struct mmc *mmc, const char
*varname)
printf("EXT_CSD[179], PARTITION_CONFIG:\n"
"BOOT_ACK: 0x%x\n"
- "BOOT_PARTITION_ENABLE: 0x%x\n"
- "PARTITION_ACCESS: 0x%x\n", ack, part, access);
+ "BOOT_PARTITION_ENABLE: 0x%x (%s)\n"
+ "PARTITION_ACCESS: 0x%x\n", ack, part, mmc_partnames[part],
access);
return CMD_RET_SUCCESS;
}
@@ -949,7 +961,14 @@ static int do_mmc_partconf(struct cmd_tbl *cmdtp, int flag,
return mmc_partconf_print(mmc, cmd_arg2(argc, argv));
ack = dectoul(argv[2], NULL);
- part_num = dectoul(argv[3], NULL);
+ if (!isdigit(*argv[3])) {
+ for (part_num = 0; part_num < ARRAY_SIZE(mmc_partnames);
part_num++) {
+ if (!strcmp(argv[3], mmc_partnames[part_num]))
+ break;
+ }
+ } else {
+ part_num = dectoul(argv[3], NULL);
+ }
access = dectoul(argv[4], NULL);
/* acknowledge to be sent during boot operation */
--
2.25.1
[PATCH] venice: show emmc boot hardware partition
To aid in understanding what emmc hardware partition is being
used to boot on power-up, display the hardware partition name in the
SPL.
Signed-off-by: Tim Harvey
---
board/gateworks/venice/spl.c | 16
1 file changed, 16 insertions(+)
diff --git a/board/gateworks/venice/spl.c b/board/gateworks/venice/spl.c
index 3b0f11f2fd0f..531bad260b6d 100644
--- a/board/gateworks/venice/spl.c
+++ b/board/gateworks/venice/spl.c
@@ -366,9 +366,25 @@ unsigned long board_spl_mmc_get_uboot_raw_sector(struct
mmc *mmc, unsigned long
const char *spl_board_loader_name(u32 boot_device)
{
+ struct mmc *mmc;
+ int part;
+
switch (boot_device) {
/* SDHC2 */
case BOOT_DEVICE_MMC1:
+ mmc_init_device(0);
+ mmc = find_mmc_device(0);
+ mmc_init(mmc);
+ part = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
+ switch (part) {
+ case 1:
+ return "eMMC boot0";
+ case 2:
+ return "eMMC boot1";
+ case 0:
+ case 7:
+ return "eMMC user";
+ }
return "eMMC";
/* SDHC3 */
case BOOT_DEVICE_MMC2:
--
2.25.1
Re: [PATCH 2/2] imx: hab: Use nxp_imx8mcst etype for i.MX8M flash.bin signing
On Fri, Apr 26, 2024 at 8:51 AM Tom Rini wrote: > > On Fri, Apr 26, 2024 at 08:30:23AM -0700, Tim Harvey wrote: > > On Thu, Apr 25, 2024 at 4:07 PM Marek Vasut wrote: > > > > > > Update documentation and use nxp_imx8mcst binman etype for signing > > > of flash.bin instead of previous horrible shell scripting. > > > > Hi Marek, > > > > To be completely fair we are just replacing a shell script and > > template file with a python script > > (tools/binman/etype/nxp_imx8mcst.py) which also creates the template > > file. > > > > I could care less about shell vs python but do put huge value in the > > idea of making signing easier and doing so without modification of > > U-Boot code. The current implementation requires a couple of things to > > be enabled in defconfig which can be done with a seperate > > 'out-of-tree' defconfig but this new proposed implementation requires > > changing a u-boot.dtsi which is a tracked file. > > A counter-point is that with using binman for signing we start > eliminating differences between different semiconductors on how to get > something signed. Hi Tom, I agree... I'm a huge fan of binman. I just don't want to replace current constructs that use env and/or config items on a clean code directory with replacements that require code diffs to do the same. I'm simply wanting to wrap binman sections with Kconfig items. Is there a way to use environment variables within binman sections (ie to wrap sections or override filenames)? Best Regards, Tim
Re: [PATCH 2/2] imx: hab: Use nxp_imx8mcst etype for i.MX8M flash.bin signing
On Thu, Apr 25, 2024 at 4:07 PM Marek Vasut wrote:
>
> Update documentation and use nxp_imx8mcst binman etype for signing
> of flash.bin instead of previous horrible shell scripting.
Hi Marek,
To be completely fair we are just replacing a shell script and
template file with a python script
(tools/binman/etype/nxp_imx8mcst.py) which also creates the template
file.
I could care less about shell vs python but do put huge value in the
idea of making signing easier and doing so without modification of
U-Boot code. The current implementation requires a couple of things to
be enabled in defconfig which can be done with a seperate
'out-of-tree' defconfig but this new proposed implementation requires
changing a u-boot.dtsi which is a tracked file.
>
> Signed-off-by: Marek Vasut
> ---
> Cc: "NXP i.MX U-Boot Team"
> Cc: Adam Ford
> Cc: Alper Nebi Yasak
> Cc: Andrejs Cainikovs
> Cc: Angus Ainslie
> Cc: Emanuele Ghidoli
> Cc: Fabio Estevam
> Cc: Francesco Dolcini
> Cc: Marcel Ziswiler
> Cc: Rasmus Villemoes
> Cc: Simon Glass
> Cc: Stefan Eichenberger
> Cc: Stefano Babic
> Cc: Tim Harvey
> Cc: Tom Rini
> Cc: ker...@puri.sm
> Cc: u-b...@dh-electronics.com
> Cc: u-boot@lists.denx.de
> ---
> doc/imx/habv4/csf_examples/mx8m/csf.sh| 92
> doc/imx/habv4/csf_examples/mx8m/csf_fit.txt | 30
> doc/imx/habv4/csf_examples/mx8m/csf_spl.txt | 33
> doc/imx/habv4/guides/mx8m_spl_secure_boot.txt | 141 +++---
> 4 files changed, 55 insertions(+), 241 deletions(-)
> delete mode 100644 doc/imx/habv4/csf_examples/mx8m/csf.sh
> delete mode 100644 doc/imx/habv4/csf_examples/mx8m/csf_fit.txt
> delete mode 100644 doc/imx/habv4/csf_examples/mx8m/csf_spl.txt
>
> +to authenticate, which keys to install, use and etc. The CSF is generated
> +using the CST Code Signing Tool based on input configuration file. This tool
> +input configuration file is generated using binman, and the tool is invoked
> +from binman as well.
> +
> +The SPL and fitImage sections of the generated image are signed separately.
> +The signing is activated by wrapping SPL and fitImage sections into
> nxp-imx8mcst
> +etype, by adding the following modification into the binman node:
> +
Can we avoid having to modify code to sign an image? If we add a
Kconfig then you can wrap the following changes with an ifdef.
I've run into a similar issues enabling OPTEE and was able to wrap the
entries with ifdefs with the exception of one that requires a unique
load address which I guess requires another Kconfig to solve [1]
Best Regards,
Tim
[1]
https://patchwork.ozlabs.org/project/uboot/patch/20230622173006.3921891-1-thar...@gateworks.com/
> +"
> +diff --git a/arch/arm/dts/imx8mp-u-boot.dtsi
> b/arch/arm/dts/imx8mp-u-boot.dtsi
> +index c4c1a177102..ccd44bf9d0b 100644
> +--- a/arch/arm/dts/imx8mp-u-boot.dtsi
> ++++ b/arch/arm/dts/imx8mp-u-boot.dtsi
> +@@ -86,6 +86,12 @@
> +section {
> +pad-byte = <0x00>;
> +
> ++ nxp-imx8mcst@0 {
> ++ filename = "u-boot-spl-mkimage.signed.bin";
> ++ nxp,loader-address = ;
> ++ nxp,unlock;
> ++ args; /* Needed by mkimage etype superclass */
> ++
> +nxp-imx8mimage {
> +filename = "u-boot-spl-mkimage.bin";
> +nxp,boot-from = "sd";
> +@@ -129,6 +135,14 @@
> +};
> +};
> +
> ++ };
> ++
> ++ nxp-imx8mcst@1 {
> ++ filename = "u-boot-fit.signed.bin";
> ++ nxp,loader-address =
> ;
> ++ offset = <0x58000>;
> ++ args; /* Needed by mkimage etype superclass */
> ++
> +fit {
> +description = "Configuration to load ATF before
> U-Boot";
> + #ifndef CONFIG_IMX_HAB
> +@@ -191,5 +205,6 @@
> +};
> +};
> +};
> ++ };
> +};
> + };
> +"
> +
> +Build of flash.bin target then produces a signed flash.bin automatically.
>
> 1.4 Closing the device
> ---
> --
> 2.43.0
>
Re: [PATCH] cmd: mmc: allow use of hardware parittion names for mmc partconf
On Thu, Apr 25, 2024 at 9:07 PM Marek Vasut wrote:
>
> On 4/26/24 2:14 AM, Tim Harvey wrote:
> > eMMC devices have hardware partitions such as user, boot0, and boot1.
> > Allow these names to be displayed when reading the mmc PARTITION_CONFIG
> > field via 'mmc partconf'. Additionally allow a name to be specified when
> > setting the PARTITION_CONFIG.
> >
> > Before:
> > u-boot=> mmc partconf 2 1 1 0 && mmc partconf 2
> > EXT_CSD[179], PARTITION_CONFIG:
> > BOOT_ACK: 0x1
> > BOOT_PARTITION_ENABLE: 0x2
> > PARTITION_ACCESS: 0x0
> >
> > After:
> > u-boot=> mmc partconf 2 1 1 0 && mmc partconf 2
> > EXT_CSD[179], PARTITION_CONFIG:
> > BOOT_ACK: 0x1
> > BOOT_PARTITION_ENABLE: 0x1 (boot0)
> > PARTITION_ACCESS: 0x0
> > u-boot=> mmc partconf 2 1 boot1 0 && mmc partconf 2
> > EXT_CSD[179], PARTITION_CONFIG:
> > BOOT_ACK: 0x1
> > BOOT_PARTITION_ENABLE: 0x2 (boot1)
> > PARTITION_ACCESS: 0x0
> >
> > Signed-off-by: Tim Harvey
> > ---
> > cmd/mmc.c | 25 ++---
> > 1 file changed, 22 insertions(+), 3 deletions(-)
> >
> > diff --git a/cmd/mmc.c b/cmd/mmc.c
> > index 2d5430a53079..26692a8e349b 100644
> > --- a/cmd/mmc.c
> > +++ b/cmd/mmc.c
> > @@ -14,6 +14,18 @@
> > #include
> > #include
> > #include
> > +#include
> > +
> > +static const char *mmc_partnames[] = {
> > + "user",
> > + "boot0",
> > + "boot1",
> > + "",
>
> Shouldn't these be 'gp' partitions here ?
>
He Marek,
Do you mean that 3-6 should be named 'gp1', 'gp2' etc? I couldn't find
if those values were possible or have meaning.
Best Regards,
Tim
Re: [PATCH] cmd: mmc: allow use of hardware parittion names for mmc partconf
On Thu, Apr 25, 2024 at 6:37 PM Fabio Estevam wrote: > > On Thu, Apr 25, 2024 at 10:35 PM Fabio Estevam wrote: > > > This is a nice improvement: > > > > Reviewed-by: Fabio Estevam > > There is a typo in the Subject: "partition" Hi Fabio, Thanks - I will fix this in v2. Best Regards, Tim
Re: [PATCH 2/3] crypto/fsl: Introduce SPL_FSL_CAAM_RNG
On Thu, Apr 25, 2024 at 4:03 PM Marek Vasut wrote: > > Add SPL variant of SPL_FSL_CAAM_RNG so that the SPL_FSL_CAAM_RNG can > be disabled in SPL if necessary. This may be necessary due to e.g. > size constraints of the SPL. > > Signed-off-by: Marek Vasut > --- > Cc: Angelo Dureghello > Cc: Emanuele Ghidoli > Cc: Fabio Estevam > Cc: Gaurav Jain > Cc: Heinrich Schuchardt > Cc: Marek Vasut > Cc: Michal Simek > Cc: Simon Glass > Cc: Stefan Roese > Cc: Sughosh Ganu > Cc: Svyatoslav Ryhel > Cc: Tim Harvey > Cc: Tom Rini > Cc: u-boot@lists.denx.de > --- > drivers/crypto/fsl/Kconfig | 7 +++ > drivers/crypto/fsl/Makefile | 2 +- > 2 files changed, 8 insertions(+), 1 deletion(-) > > diff --git a/drivers/crypto/fsl/Kconfig b/drivers/crypto/fsl/Kconfig > index 294e1c8a44e..9f58731bb67 100644 > --- a/drivers/crypto/fsl/Kconfig > +++ b/drivers/crypto/fsl/Kconfig > @@ -78,6 +78,13 @@ config FSL_CAAM_RNG > using the prediction resistance flag which means the DRGB is > reseeded from the TRNG every time random data is generated. > > +config SPL_FSL_CAAM_RNG > + bool "Enable CAAM Random Number Generator support in SPL" > + depends on SPL_DM_RNG > + help > + This option is an SPL-variant of the FSL_CAAM_RNG option. > + See the help of FSL_CAAM_RNG for details. > + > endif > > config FSL_DCP_RNG > diff --git a/drivers/crypto/fsl/Makefile b/drivers/crypto/fsl/Makefile > index 7a2543e16cc..4fbce519a0b 100644 > --- a/drivers/crypto/fsl/Makefile > +++ b/drivers/crypto/fsl/Makefile > @@ -6,6 +6,6 @@ obj-y += sec.o > obj-$(CONFIG_FSL_CAAM) += jr.o fsl_hash.o jobdesc.o error.o > obj-$(CONFIG_CMD_BLOB)$(CONFIG_IMX_CAAM_DEK_ENCAP) += fsl_blob.o > obj-$(CONFIG_RSA_FREESCALE_EXP) += fsl_rsa.o > -obj-$(CONFIG_FSL_CAAM_RNG) += rng.o > +obj-$(CONFIG_$(SPL_TPL_)FSL_CAAM_RNG) += rng.o > obj-$(CONFIG_FSL_DCP_RNG) += dcp_rng.o > obj-$(CONFIG_FSL_MFGPROT) += fsl_mfgprot.o > -- > 2.43.0 > Marek, Thanks - this series does solve the issue I am seeing in the SPL when enabling DM_RNG. Is this going to cause an issue for people who expect it to be currently enabled and now have to manually enable it? Best Regards, Tim
[PATCH] cmd: mmc: allow use of hardware parittion names for mmc partconf
eMMC devices have hardware partitions such as user, boot0, and boot1.
Allow these names to be displayed when reading the mmc PARTITION_CONFIG
field via 'mmc partconf'. Additionally allow a name to be specified when
setting the PARTITION_CONFIG.
Before:
u-boot=> mmc partconf 2 1 1 0 && mmc partconf 2
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x1
BOOT_PARTITION_ENABLE: 0x2
PARTITION_ACCESS: 0x0
After:
u-boot=> mmc partconf 2 1 1 0 && mmc partconf 2
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x1
BOOT_PARTITION_ENABLE: 0x1 (boot0)
PARTITION_ACCESS: 0x0
u-boot=> mmc partconf 2 1 boot1 0 && mmc partconf 2
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x1
BOOT_PARTITION_ENABLE: 0x2 (boot1)
PARTITION_ACCESS: 0x0
Signed-off-by: Tim Harvey
---
cmd/mmc.c | 25 ++---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/cmd/mmc.c b/cmd/mmc.c
index 2d5430a53079..26692a8e349b 100644
--- a/cmd/mmc.c
+++ b/cmd/mmc.c
@@ -14,6 +14,18 @@
#include
#include
#include
+#include
+
+static const char *mmc_partnames[] = {
+ "user",
+ "boot0",
+ "boot1",
+ "",
+ "",
+ "",
+ "",
+ "user",
+};
static int curr_device = -1;
@@ -918,8 +930,8 @@ static int mmc_partconf_print(struct mmc *mmc, const char
*varname)
printf("EXT_CSD[179], PARTITION_CONFIG:\n"
"BOOT_ACK: 0x%x\n"
- "BOOT_PARTITION_ENABLE: 0x%x\n"
- "PARTITION_ACCESS: 0x%x\n", ack, part, access);
+ "BOOT_PARTITION_ENABLE: 0x%x (%s)\n"
+ "PARTITION_ACCESS: 0x%x\n", ack, part, mmc_partnames[part],
access);
return CMD_RET_SUCCESS;
}
@@ -949,7 +961,14 @@ static int do_mmc_partconf(struct cmd_tbl *cmdtp, int flag,
return mmc_partconf_print(mmc, cmd_arg2(argc, argv));
ack = dectoul(argv[2], NULL);
- part_num = dectoul(argv[3], NULL);
+ if (!isdigit(*argv[3])) {
+ for (part_num = 0; part_num < ARRAY_SIZE(mmc_partnames);
part_num++) {
+ if (!strcmp(argv[3], mmc_partnames[part_num]))
+ break;
+ }
+ } else {
+ part_num = dectoul(argv[3], NULL);
+ }
access = dectoul(argv[4], NULL);
/* acknowledge to be sent during boot operation */
--
2.25.1
Re: [PATCH 3/3] ARM: dts: imx: Convert i.MX8M flash.bin image generation to binman
On Tue, Apr 23, 2024 at 11:33 AM Marek Vasut wrote:
>
> Rework the flash.bin image generation such that it uses the new binman
> nxp_imx8mimage etype. This way, the flash.bin is assembled in correct
> order using plain binman, without any workarounds or sections assembled
> in special DT node order.
>
> Signed-off-by: Marek Vasut
> ---
> WARNING: This is very likely to break corner case uses, so please do
> test this on your platform.
> NOTE: This also opens the implementation for proper CST signing etype,
> the CST signing would look similar to nxp-imx8mimage section, and
> it would likely wrap the whole topmost section {} in the binman
> node.
Marek,
Thanks - this is neat and I look forward to seeing a CST signing etype!
Reviewed-By: Tim Harvey
I did test this on imx8mm_venice_defconfig and it worked great:
Tested-By: Tim Harvey # imx8mm_venice
This likely paves the way for removing IMX_CONFIG
Best Regards,
Tim
Re: [PATCH v3] tpm-v2: allow algoirthm name to be configured for pcr_read and pcr_extend
On Fri, Apr 19, 2024 at 10:37 AM Ilias Apalodimas
wrote:
>
> Also quickly looking at this, you need a new function for
> tpm2_algorithm_to_mask() (look below)
>
> On Fri, 19 Apr 2024 at 20:20, Ilias Apalodimas
> wrote:
> >
> > Hi Tim,
> >
> > On Fri, 19 Apr 2024 at 20:13, Tim Harvey wrote:
> > >
> > > On Sat, Apr 6, 2024 at 9:33 AM Ilias Apalodimas
> > > wrote:
> > > >
> > > > Hi Tim,
> > > >
> > > > Thanks for the patch
> > > >
> > > > I'll be away next week, I'll try to find time and take a closer look.
> > > > The pipeline [0] shows some TPM related failures
> > > >
> > > > [0]
> > > > https://source.denx.de/u-boot/custodians/u-boot-tpm/-/commit/9b4be64e41454e17269a968397933eeff300c380
> > > >
> > >
> > > Hi Ilias,
> > >
> > > I changed the output of 'tpm pcr_read' so that it shows the algo and
> > > size causing the test in test/py/tests/test_tpm2.py to fail:
> > > @@ -151,11 +171,12 @@ static int do_tpm_pcr_read(struct cmd_tbl
> > > *cmdtp, int flag, int argc,
> > >
> > > data = map_sysmem(simple_strtoul(argv[2], NULL, 0), 0);
> > >
> > > - rc = tpm2_pcr_read(dev, index, priv->pcr_select_min,
> > > TPM2_ALG_SHA256,
> > > - data, TPM2_DIGEST_LEN, );
> > > + rc = tpm2_pcr_read(dev, index, priv->pcr_select_min, algo,
> > > + data, algo_len, );
> > > if (!rc) {
> > > - printf("PCR #%u content (%u known updates):\n", index,
> > > updates);
> > > - print_byte_string(data, TPM2_DIGEST_LEN);
> > > + printf("PCR #%u %s %d byte content (%u known
> > > updates):\n", index,
> > > + tpm2_algorithm_name(algo), algo_len, updates);
> > > + print_byte_string(data, algo_len);
> > > }
> > >
> > > failure:
> > > E AssertionError: assert 'PCR #10 content' in 'PCR #10 sha256 32
> > > byte content (723 known updates):\r\r\n 00 00 00 00 00 00 00 00 00 00
> > > 00 00 00 00 00 00\r\r\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > 00'
> > >
> > > So I suppose I need to update test/py/tests/test_tpm2.py as well.
> >
> > Yes
> >
> > >
> > > Would I update test/py/tests/test_tpm2.py in the same patch as the one
> > > that causes the failure?
> >
> > Yes please, I'd like patches merged that won't break the CI
> >
> > >
> > > How do I go about running the tests manually to make sure I've addressed
> > > it?
> >
> > You can send a PR against U-Boots repo (in github)
> >
> > Cheers
> > /Ilias
> > >
> > > Best Regards,
> > >
> > > Tim
> > >
> > > > Cheers
> > > > /Ilias
> > > >
> > > > On Fri, 5 Apr 2024 at 03:17, Tim Harvey wrote:
> > > > >
> > > > > For pcr_read and pcr_extend commands allow the digest algorithm to be
> > > > > specified by an additional argument. If not specified it will default
> > > > > to
> > > > > SHA256 for backwards compatibility.
> > > > >
> > > > > A follow-on to this could be to extend all PCR banks with the detected
> > > > > algo when the argument is 'auto'.
> > > > >
> > > > > Signed-off-by: Tim Harvey
> > > > > ---
> > > > > v3:
> > > > > - replace tpm2_supported_algorithms with struct and use this to
> > > > > relate hash algoirthm
> > > > >details
> > > > > v2:
> > > > > - use tpm2_algorithm_to_len
> > > > > - use enum tpm2_algorithms
> > > > > - make function names and parameter names more consistent with
> > > > > existing
> > > > >tpm-v2 functions
> > > > > - fix various spelling errors
> > > > > ---
> > > > > cmd/tpm-v2.c | 49
> > > > > include/tpm-v2.h | 67
> > > > > ++-
> > > > > lib/efi_loader/efi_tcg2.c | 4 +--
> > > > > lib/tpm-v2.c | 62 +++-
> > > > > 4 files changed, 143 insertions(+), 39 deletions(-)
> > >
Re: [PATCH v3] tpm-v2: allow algoirthm name to be configured for pcr_read and pcr_extend
On Sat, Apr 6, 2024 at 9:33 AM Ilias Apalodimas
wrote:
>
> Hi Tim,
>
> Thanks for the patch
>
> I'll be away next week, I'll try to find time and take a closer look.
> The pipeline [0] shows some TPM related failures
>
> [0]
> https://source.denx.de/u-boot/custodians/u-boot-tpm/-/commit/9b4be64e41454e17269a968397933eeff300c380
>
Hi Ilias,
I changed the output of 'tpm pcr_read' so that it shows the algo and
size causing the test in test/py/tests/test_tpm2.py to fail:
@@ -151,11 +171,12 @@ static int do_tpm_pcr_read(struct cmd_tbl
*cmdtp, int flag, int argc,
data = map_sysmem(simple_strtoul(argv[2], NULL, 0), 0);
- rc = tpm2_pcr_read(dev, index, priv->pcr_select_min, TPM2_ALG_SHA256,
- data, TPM2_DIGEST_LEN, );
+ rc = tpm2_pcr_read(dev, index, priv->pcr_select_min, algo,
+ data, algo_len, );
if (!rc) {
- printf("PCR #%u content (%u known updates):\n", index, updates);
- print_byte_string(data, TPM2_DIGEST_LEN);
+ printf("PCR #%u %s %d byte content (%u known
updates):\n", index,
+ tpm2_algorithm_name(algo), algo_len, updates);
+ print_byte_string(data, algo_len);
}
failure:
E AssertionError: assert 'PCR #10 content' in 'PCR #10 sha256 32
byte content (723 known updates):\r\r\n 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00\r\r\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00'
So I suppose I need to update test/py/tests/test_tpm2.py as well.
Would I update test/py/tests/test_tpm2.py in the same patch as the one
that causes the failure?
How do I go about running the tests manually to make sure I've addressed it?
Best Regards,
Tim
> Cheers
> /Ilias
>
> On Fri, 5 Apr 2024 at 03:17, Tim Harvey wrote:
> >
> > For pcr_read and pcr_extend commands allow the digest algorithm to be
> > specified by an additional argument. If not specified it will default to
> > SHA256 for backwards compatibility.
> >
> > A follow-on to this could be to extend all PCR banks with the detected
> > algo when the argument is 'auto'.
> >
> > Signed-off-by: Tim Harvey
> > ---
> > v3:
> > - replace tpm2_supported_algorithms with struct and use this to relate
> > hash algoirthm
> >details
> > v2:
> > - use tpm2_algorithm_to_len
> > - use enum tpm2_algorithms
> > - make function names and parameter names more consistent with existing
> >tpm-v2 functions
> > - fix various spelling errors
> > ---
> > cmd/tpm-v2.c | 49
> > include/tpm-v2.h | 67 ++-
> > lib/efi_loader/efi_tcg2.c | 4 +--
> > lib/tpm-v2.c | 62 +++-
> > 4 files changed, 143 insertions(+), 39 deletions(-)
> >
> > diff --git a/cmd/tpm-v2.c b/cmd/tpm-v2.c
> > index 7e479b9dfe36..2343b4d9cb9e 100644
> > --- a/cmd/tpm-v2.c
> > +++ b/cmd/tpm-v2.c
> > @@ -99,11 +99,19 @@ static int do_tpm2_pcr_extend(struct cmd_tbl *cmdtp,
> > int flag, int argc,
> > struct tpm_chip_priv *priv;
> > u32 index = simple_strtoul(argv[1], NULL, 0);
> > void *digest = map_sysmem(simple_strtoul(argv[2], NULL, 0), 0);
> > + int algo = TPM2_ALG_SHA256;
> > + int algo_len;
> > int ret;
> > u32 rc;
> >
> > - if (argc != 3)
> > + if (argc < 3 || argc > 4)
> > return CMD_RET_USAGE;
> > + if (argc == 4) {
> > + algo = tpm2_name_to_algorithm(argv[3]);
> > + if (algo < 0)
> > + return CMD_RET_FAILURE;
> > + }
> > + algo_len = tpm2_algorithm_to_len(algo);
> >
> > ret = get_tpm();
> > if (ret)
> > @@ -116,8 +124,12 @@ static int do_tpm2_pcr_extend(struct cmd_tbl *cmdtp,
> > int flag, int argc,
> > if (index >= priv->pcr_count)
> > return -EINVAL;
> >
> > - rc = tpm2_pcr_extend(dev, index, TPM2_ALG_SHA256, digest,
> > -TPM2_DIGEST_LEN);
> > + rc = tpm2_pcr_extend(dev, index, algo, digest, algo_len);
> > + if (!rc) {
> > + printf("PCR #%u extended with %d byte %s digest\n", index,
> > + algo_len, tpm2_algorithm_name(algo));
> > + print_byte_string(digest, algo_len);
> > + }
> >
> > unmap_sysmem(digest);
> >
> > @@ -127,15 +139,23 @@ static int do_tpm2_pcr_extend(struct cmd_tbl *cmdtp,
> > in
[PATCH v3 3/3] imx8mm_venice_defconfig: Enable PCIe/NVMe support
Enable PCIe/NVMe support. Also, enable the reset driver which is a prerequisite for PCIe support. Signed-off-by: Tim Harvey --- v3: no changes v2: no changes --- configs/imx8mm_venice_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/configs/imx8mm_venice_defconfig b/configs/imx8mm_venice_defconfig index 517b70b69477..0f97b4b84243 100644 --- a/configs/imx8mm_venice_defconfig +++ b/configs/imx8mm_venice_defconfig @@ -12,6 +12,7 @@ CONFIG_DEFAULT_DEVICE_TREE="freescale/imx8mm-venice-gw71xx-0x" CONFIG_SPL_TEXT_BASE=0x7E1000 CONFIG_TARGET_IMX8MM_VENICE=y CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_DM_RESET=y CONFIG_SYS_MONITOR_LEN=524288 CONFIG_SPL_MMC=y CONFIG_SPL_SERIAL=y @@ -20,6 +21,7 @@ CONFIG_SPL_STACK=0x92 CONFIG_SPL=y CONFIG_ENV_OFFSET_REDUND=0x3f8000 CONFIG_SYS_LOAD_ADDR=0x4820 +CONFIG_PCI=y CONFIG_SYS_MEMTEST_START=0x4000 CONFIG_SYS_MEMTEST_END=0x8000 CONFIG_FIT=y @@ -60,6 +62,7 @@ CONFIG_CMD_FUSE=y CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y +CONFIG_CMD_PCI=y CONFIG_CMD_USB=y CONFIG_CMD_USB_MASS_STORAGE=y CONFIG_CMD_DHCP6=y @@ -120,6 +123,9 @@ CONFIG_PHY_GIGE=y CONFIG_FEC_MXC=y CONFIG_KSZ9477=y CONFIG_MII=y +CONFIG_NVME_PCI=y +CONFIG_PCIE_DW_IMX=y +CONFIG_PHY_IMX8M_PCIE=y CONFIG_PINCTRL=y CONFIG_SPL_PINCTRL=y CONFIG_PINCTRL_IMX8M=y -- 2.25.1
[PATCH v3 2/3] pci: dw_imx: add support for IMX8MM
Add support for the IMX8MM SoC by adding driver data with the compatible
string of the GPR controller.
Reviewed-by: Marek Vasut
Signed-off-by: Tim Harvey
---
v3: collected tags
v2: do not cache chip info in priv per Marek's suggestion
---
drivers/pci/pcie_dw_imx.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pcie_dw_imx.c b/drivers/pci/pcie_dw_imx.c
index a2ee228224b5..fdb463710ba1 100644
--- a/drivers/pci/pcie_dw_imx.c
+++ b/drivers/pci/pcie_dw_imx.c
@@ -56,6 +56,18 @@ struct pcie_dw_imx {
struct udevice *vpcie;
};
+struct pcie_chip_info {
+ const char *gpr;
+};
+
+static const struct pcie_chip_info imx8mm_chip_info = {
+ .gpr = "fsl,imx8mm-iomuxc-gpr",
+};
+
+static const struct pcie_chip_info imx8mp_chip_info = {
+ .gpr = "fsl,imx8mp-iomuxc-gpr",
+};
+
static void pcie_dw_configure(struct pcie_dw_imx *priv, u32 cap_speed)
{
dw_pcie_dbi_write_enable(>dw, true);
@@ -242,6 +254,7 @@ static int pcie_dw_imx_remove(struct udevice *dev)
static int pcie_dw_imx_of_to_plat(struct udevice *dev)
{
+ struct pcie_chip_info *info = (void *)dev_get_driver_data(dev);
struct pcie_dw_imx *priv = dev_get_priv(dev);
ofnode gpr;
int ret;
@@ -287,7 +300,7 @@ static int pcie_dw_imx_of_to_plat(struct udevice *dev)
goto err_phy;
}
- gpr = ofnode_by_compatible(ofnode_null(), "fsl,imx8mp-iomuxc-gpr");
+ gpr = ofnode_by_compatible(ofnode_null(), info->gpr);
if (ofnode_equal(gpr, ofnode_null())) {
dev_err(dev, "unable to find GPR node\n");
ret = -ENODEV;
@@ -322,7 +335,8 @@ static const struct dm_pci_ops pcie_dw_imx_ops = {
};
static const struct udevice_id pcie_dw_imx_ids[] = {
- { .compatible = "fsl,imx8mp-pcie" },
+ { .compatible = "fsl,imx8mm-pcie", .data = (ulong)_chip_info, },
+ { .compatible = "fsl,imx8mp-pcie", .data = (ulong)_chip_info, },
{ }
};
--
2.25.1
[PATCH v3 1/3] clk: imx8mm: Add support for PCIe clocks
Add support for PCIe clocks required to enable PCIe support on
iMX8MM SoC.
Signed-off-by: Tim Harvey
---
v3: wrap pcie clk config around IS_ENABLED to avoid SPL growth as
suggested by Marek
---
drivers/clk/imx/clk-imx8mm.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
index b5c253e49663..1a00dd1d287b 100644
--- a/drivers/clk/imx/clk-imx8mm.c
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -66,6 +66,17 @@ static const char *imx8mm_i2c3_sels[] = {"clock-osc-24m",
"sys_pll1_160m", "sys_
static const char *imx8mm_i2c4_sels[] = {"clock-osc-24m", "sys_pll1_160m",
"sys_pll2_50m", "sys_pll3_out", "audio_pll1_out",
"video_pll1_out", "audio_pll2_out",
"sys_pll1_133m", };
+#if CONFIG_IS_ENABLED(PCIE_DW_IMX)
+static const char *imx8mm_pcie1_ctrl_sels[] = {"clock-osc-24m",
"sys_pll2_250m", "sys_pll2_200m", "sys_pll1_266m",
+ "sys_pll1_800m",
"sys_pll2_500m", "sys_pll2_333m", "sys_pll3_out", };
+
+static const char *imx8mm_pcie1_phy_sels[] = {"clock-osc-24m",
"sys_pll2_100m", "sys_pll2_500m", "clk_ext1", "clk_ext2",
+ "clk_ext3", "clk_ext4",
"sys_pll1_400m", };
+
+static const char *imx8mm_pcie1_aux_sels[] = {"clock-osc-24m",
"sys_pll2_200m", "sys_pll2_50m", "sys_pll3_out",
+ "sys_pll2_100m", "sys_pll1_80m",
"sys_pll1_160m", "sys_pll1_200m", };
+#endif
+
#ifndef CONFIG_SPL_BUILD
static const char *imx8mm_pwm1_sels[] = {"clock-osc-24m", "sys_pll2_100m",
"sys_pll1_160m", "sys_pll1_40m",
"sys_pll3_out", "clk_ext1",
"sys_pll1_80m", "video_pll1_out", };
@@ -256,6 +267,17 @@ static int imx8mm_clk_probe(struct udevice *dev)
imx8m_clk_composite("usb_bus", imx8mm_usb_bus_sels, base +
0x8b80));
/* IP */
+#if CONFIG_IS_ENABLED(PCIE_DW_IMX)
+ clk_dm(IMX8MM_CLK_PCIE1_CTRL,
+ imx8m_clk_composite("pcie1_ctrl", imx8mm_pcie1_ctrl_sels,
+ base + 0xa300));
+ clk_dm(IMX8MM_CLK_PCIE1_PHY,
+ imx8m_clk_composite("pcie1_phy", imx8mm_pcie1_phy_sels,
+ base + 0xa380));
+ clk_dm(IMX8MM_CLK_PCIE1_AUX,
+ imx8m_clk_composite("pcie1_aux", imx8mm_pcie1_aux_sels,
+ base + 0xa400));
+#endif
clk_dm(IMX8MM_CLK_USDHC1,
imx8m_clk_composite("usdhc1", imx8mm_usdhc1_sels,
base + 0xac00));
@@ -339,6 +361,11 @@ static int imx8mm_clk_probe(struct udevice *dev)
imx_clk_gate4("pwm4_root_clk", "pwm4", base + 0x42b0, 0));
#endif
+#if CONFIG_IS_ENABLED(PCIE_DW_IMX)
+ clk_dm(IMX8MM_CLK_PCIE1_ROOT,
+ imx_clk_gate4("pcie1_root_clk", "pcie1_ctrl", base + 0x4250, 0));
+#endif
+
#if CONFIG_IS_ENABLED(DM_SPI)
clk_dm(IMX8MM_CLK_ECSPI1,
imx8m_clk_composite("ecspi1", imx8mm_ecspi1_sels, base +
0xb280));
--
2.25.1
Re: [PATCH] ARM: imx: Enable kaslrseed command on DH i.MX8M Plus DHCOM
On Thu, Apr 18, 2024 at 11:42 AM Marek Vasut wrote:
>
> On 4/18/24 8:02 PM, Fabio Estevam wrote:
> > Hi Tim,
> >
> > On Thu, Apr 18, 2024 at 2:54 PM Tim Harvey wrote:
> >
> >> Fabio, if you enable CONFIG_DM_RNG on an imx8m{m,p}_evk do you get the
> >> following in the SPL?
> >> Couldn't bind rng driver (-96)
> >> SEC0: RNG instantiated
> >>
> >> sec_init failed!
> >
> > Yes, if I add CONFIG_DM_RNG=y to imx8mm_evk_defconfig I get:
> >
> > U-Boot SPL 2024.04-00793-g3434b88d2c2f-dirty (Apr 18 2024 - 14:58:57 -0300)
> > No pmic
> > Couldn't bind rng driver (-96)
> > SEC0: RNG instantiated
> >
> > sec_init failed!
>
> Interesting. Which TFA blob version do you use ? I used the mainline
> 2.10 for my tests.
Marek,
Were you able to reproduce this as well with the board you enabled
DM_RNG for? If it does work fine what dtb were you using... perhaps
there is something in its u-boot.dtsi that we need?
The error -EPFNOSUPPORT is interesting and helps point to the only
place it can be where the comment says the strange errno is to make
this easier to find:
https://elixir.bootlin.com/u-boot/latest/source/drivers/core/uclass.c#L70:
if (!uc_drv) {
debug("Cannot find uclass for id %d: please add the
UCLASS_DRIVER() declaration for this UCLASS_... id\n",
id);
/*
* Use a strange error to make this case easier to find. When
* a uclass is not available it can prevent driver model from
* starting up and this failure is otherwise hard to debug.
*/
return -EPFNOSUPPORT;
}
I'm not very familiar with the dm driver binding - does the
U-BOOT_DRIVER usage in drivers/crypto/fsl/rng.c need to be refactored
to use UCLASS_DRIVER for it to be usable in both SPL and U-Boot?
Honestly I don't know why we need DM_RNG in SPL anyway and we could
just add support for disabling it there to avoid unwanted bloat.
Tim
Re: [PATCH v2 1/3] clk: imx8mm: Add support for PCIe clocks
On Thu, Apr 18, 2024 at 11:14 AM Marek Vasut wrote:
>
> On 4/18/24 7:56 PM, Tim Harvey wrote:
> > Add support for PCIe clocks required to enable PCIe support on
> > iMX8MM SoC.
> >
> > Signed-off-by: Tim Harvey
> > ---
> > v2: no changes
> > ---
> > drivers/clk/imx/clk-imx8mm.c | 21 +
> > 1 file changed, 21 insertions(+)
> >
> > diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
> > index b5c253e49663..c2f01b385201 100644
> > --- a/drivers/clk/imx/clk-imx8mm.c
> > +++ b/drivers/clk/imx/clk-imx8mm.c
> > @@ -66,6 +66,15 @@ static const char *imx8mm_i2c3_sels[] =
> > {"clock-osc-24m", "sys_pll1_160m", "sys_
> > static const char *imx8mm_i2c4_sels[] = {"clock-osc-24m",
> > "sys_pll1_160m", "sys_pll2_50m", "sys_pll3_out", "audio_pll1_out",
> >"video_pll1_out", "audio_pll2_out",
> > "sys_pll1_133m", };
> >
> > +static const char *imx8mm_pcie1_ctrl_sels[] = {"clock-osc-24m",
> > "sys_pll2_250m", "sys_pll2_200m", "sys_pll1_266m",
> > +"sys_pll1_800m",
> > "sys_pll2_500m", "sys_pll2_333m", "sys_pll3_out", };
> > +
> > +static const char *imx8mm_pcie1_phy_sels[] = {"clock-osc-24m",
> > "sys_pll2_100m", "sys_pll2_500m", "clk_ext1", "clk_ext2",
> > + "clk_ext3", "clk_ext4",
> > "sys_pll1_400m", };
> > +
> > +static const char *imx8mm_pcie1_aux_sels[] = {"clock-osc-24m",
> > "sys_pll2_200m", "sys_pll2_50m", "sys_pll3_out",
> > + "sys_pll2_100m",
> > "sys_pll1_80m", "sys_pll1_160m", "sys_pll1_200m", };
> > +
> > #ifndef CONFIG_SPL_BUILD
> > static const char *imx8mm_pwm1_sels[] = {"clock-osc-24m",
> > "sys_pll2_100m", "sys_pll1_160m", "sys_pll1_40m",
> >"sys_pll3_out", "clk_ext1",
> > "sys_pll1_80m", "video_pll1_out", };
> > @@ -256,6 +265,15 @@ static int imx8mm_clk_probe(struct udevice *dev)
> > imx8m_clk_composite("usb_bus", imx8mm_usb_bus_sels, base +
> > 0x8b80));
> >
> > /* IP */
> > + clk_dm(IMX8MM_CLK_PCIE1_CTRL,
> > +imx8m_clk_composite("pcie1_ctrl", imx8mm_pcie1_ctrl_sels,
> > +base + 0xa300));
> > + clk_dm(IMX8MM_CLK_PCIE1_PHY,
> > +imx8m_clk_composite("pcie1_phy", imx8mm_pcie1_phy_sels,
> > +base + 0xa380));
> > + clk_dm(IMX8MM_CLK_PCIE1_AUX,
> > +imx8m_clk_composite("pcie1_aux", imx8mm_pcie1_aux_sels,
> > +base + 0xa400));
>
> Maybe this should be behind IS_ENABLED() like the SPI clock to avoid
> growth of SPL ?
Makes sense... I'll add that in a v3. Thanks for the review!
Best Regards,
Tim
[PATCH v2 3/3] imx8mm_venice_defconfig: Enable PCIe/NVMe support
Enable PCIe/NVMe support. Also, enable the reset driver which is a prerequisite for PCIe support. Signed-off-by: Tim Harvey --- v2: no changes --- configs/imx8mm_venice_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/configs/imx8mm_venice_defconfig b/configs/imx8mm_venice_defconfig index 517b70b69477..0f97b4b84243 100644 --- a/configs/imx8mm_venice_defconfig +++ b/configs/imx8mm_venice_defconfig @@ -12,6 +12,7 @@ CONFIG_DEFAULT_DEVICE_TREE="freescale/imx8mm-venice-gw71xx-0x" CONFIG_SPL_TEXT_BASE=0x7E1000 CONFIG_TARGET_IMX8MM_VENICE=y CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_DM_RESET=y CONFIG_SYS_MONITOR_LEN=524288 CONFIG_SPL_MMC=y CONFIG_SPL_SERIAL=y @@ -20,6 +21,7 @@ CONFIG_SPL_STACK=0x92 CONFIG_SPL=y CONFIG_ENV_OFFSET_REDUND=0x3f8000 CONFIG_SYS_LOAD_ADDR=0x4820 +CONFIG_PCI=y CONFIG_SYS_MEMTEST_START=0x4000 CONFIG_SYS_MEMTEST_END=0x8000 CONFIG_FIT=y @@ -60,6 +62,7 @@ CONFIG_CMD_FUSE=y CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y +CONFIG_CMD_PCI=y CONFIG_CMD_USB=y CONFIG_CMD_USB_MASS_STORAGE=y CONFIG_CMD_DHCP6=y @@ -120,6 +123,9 @@ CONFIG_PHY_GIGE=y CONFIG_FEC_MXC=y CONFIG_KSZ9477=y CONFIG_MII=y +CONFIG_NVME_PCI=y +CONFIG_PCIE_DW_IMX=y +CONFIG_PHY_IMX8M_PCIE=y CONFIG_PINCTRL=y CONFIG_SPL_PINCTRL=y CONFIG_PINCTRL_IMX8M=y -- 2.25.1
[PATCH v2 2/3] pci: dw_imx: add support for IMX8MM
Add support for the IMX8MM SoC by adding driver data with the compatible
string of the GPR controller.
Signed-off-by: Tim Harvey
---
v2: do not cache chip info in priv per Marek's suggestion
---
drivers/pci/pcie_dw_imx.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pcie_dw_imx.c b/drivers/pci/pcie_dw_imx.c
index a2ee228224b5..fdb463710ba1 100644
--- a/drivers/pci/pcie_dw_imx.c
+++ b/drivers/pci/pcie_dw_imx.c
@@ -56,6 +56,18 @@ struct pcie_dw_imx {
struct udevice *vpcie;
};
+struct pcie_chip_info {
+ const char *gpr;
+};
+
+static const struct pcie_chip_info imx8mm_chip_info = {
+ .gpr = "fsl,imx8mm-iomuxc-gpr",
+};
+
+static const struct pcie_chip_info imx8mp_chip_info = {
+ .gpr = "fsl,imx8mp-iomuxc-gpr",
+};
+
static void pcie_dw_configure(struct pcie_dw_imx *priv, u32 cap_speed)
{
dw_pcie_dbi_write_enable(>dw, true);
@@ -242,6 +254,7 @@ static int pcie_dw_imx_remove(struct udevice *dev)
static int pcie_dw_imx_of_to_plat(struct udevice *dev)
{
+ struct pcie_chip_info *info = (void *)dev_get_driver_data(dev);
struct pcie_dw_imx *priv = dev_get_priv(dev);
ofnode gpr;
int ret;
@@ -287,7 +300,7 @@ static int pcie_dw_imx_of_to_plat(struct udevice *dev)
goto err_phy;
}
- gpr = ofnode_by_compatible(ofnode_null(), "fsl,imx8mp-iomuxc-gpr");
+ gpr = ofnode_by_compatible(ofnode_null(), info->gpr);
if (ofnode_equal(gpr, ofnode_null())) {
dev_err(dev, "unable to find GPR node\n");
ret = -ENODEV;
@@ -322,7 +335,8 @@ static const struct dm_pci_ops pcie_dw_imx_ops = {
};
static const struct udevice_id pcie_dw_imx_ids[] = {
- { .compatible = "fsl,imx8mp-pcie" },
+ { .compatible = "fsl,imx8mm-pcie", .data = (ulong)_chip_info, },
+ { .compatible = "fsl,imx8mp-pcie", .data = (ulong)_chip_info, },
{ }
};
--
2.25.1
[PATCH v2 1/3] clk: imx8mm: Add support for PCIe clocks
Add support for PCIe clocks required to enable PCIe support on
iMX8MM SoC.
Signed-off-by: Tim Harvey
---
v2: no changes
---
drivers/clk/imx/clk-imx8mm.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
index b5c253e49663..c2f01b385201 100644
--- a/drivers/clk/imx/clk-imx8mm.c
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -66,6 +66,15 @@ static const char *imx8mm_i2c3_sels[] = {"clock-osc-24m",
"sys_pll1_160m", "sys_
static const char *imx8mm_i2c4_sels[] = {"clock-osc-24m", "sys_pll1_160m",
"sys_pll2_50m", "sys_pll3_out", "audio_pll1_out",
"video_pll1_out", "audio_pll2_out",
"sys_pll1_133m", };
+static const char *imx8mm_pcie1_ctrl_sels[] = {"clock-osc-24m",
"sys_pll2_250m", "sys_pll2_200m", "sys_pll1_266m",
+ "sys_pll1_800m",
"sys_pll2_500m", "sys_pll2_333m", "sys_pll3_out", };
+
+static const char *imx8mm_pcie1_phy_sels[] = {"clock-osc-24m",
"sys_pll2_100m", "sys_pll2_500m", "clk_ext1", "clk_ext2",
+ "clk_ext3", "clk_ext4",
"sys_pll1_400m", };
+
+static const char *imx8mm_pcie1_aux_sels[] = {"clock-osc-24m",
"sys_pll2_200m", "sys_pll2_50m", "sys_pll3_out",
+ "sys_pll2_100m", "sys_pll1_80m",
"sys_pll1_160m", "sys_pll1_200m", };
+
#ifndef CONFIG_SPL_BUILD
static const char *imx8mm_pwm1_sels[] = {"clock-osc-24m", "sys_pll2_100m",
"sys_pll1_160m", "sys_pll1_40m",
"sys_pll3_out", "clk_ext1",
"sys_pll1_80m", "video_pll1_out", };
@@ -256,6 +265,15 @@ static int imx8mm_clk_probe(struct udevice *dev)
imx8m_clk_composite("usb_bus", imx8mm_usb_bus_sels, base +
0x8b80));
/* IP */
+ clk_dm(IMX8MM_CLK_PCIE1_CTRL,
+ imx8m_clk_composite("pcie1_ctrl", imx8mm_pcie1_ctrl_sels,
+ base + 0xa300));
+ clk_dm(IMX8MM_CLK_PCIE1_PHY,
+ imx8m_clk_composite("pcie1_phy", imx8mm_pcie1_phy_sels,
+ base + 0xa380));
+ clk_dm(IMX8MM_CLK_PCIE1_AUX,
+ imx8m_clk_composite("pcie1_aux", imx8mm_pcie1_aux_sels,
+ base + 0xa400));
clk_dm(IMX8MM_CLK_USDHC1,
imx8m_clk_composite("usdhc1", imx8mm_usdhc1_sels,
base + 0xac00));
@@ -339,6 +357,9 @@ static int imx8mm_clk_probe(struct udevice *dev)
imx_clk_gate4("pwm4_root_clk", "pwm4", base + 0x42b0, 0));
#endif
+ clk_dm(IMX8MM_CLK_PCIE1_ROOT,
+ imx_clk_gate4("pcie1_root_clk", "pcie1_ctrl", base + 0x4250, 0));
+
#if CONFIG_IS_ENABLED(DM_SPI)
clk_dm(IMX8MM_CLK_ECSPI1,
imx8m_clk_composite("ecspi1", imx8mm_ecspi1_sels, base +
0xb280));
--
2.25.1
Re: [PATCH] ARM: imx: Enable kaslrseed command on DH i.MX8M Plus DHCOM
On Thu, Apr 18, 2024 at 10:33 AM Marek Vasut wrote:
>
> On 4/18/24 6:21 PM, Tim Harvey wrote:
> > On Fri, Jan 19, 2024 at 4:36 PM Marek Vasut wrote:
> >>
> >> Linux 6.6.y with KASLR enabled would print the following message on boot:
> >> "
> >> KASLR disabled due to lack of seed
> >> "
> >> Enable the 'kaslrseed' command so a random number seed can be pulled
> >> from CAAM and inserted into the /chosen node 'kaslr-seed' property of
> >> Linux kernel DT before boot, thus letting KASLR work properly.
> >>
> >> Signed-off-by: Marek Vasut
> >> ---
> >> Cc: Fabio Estevam
> >> Cc: Stefano Babic
> >> Cc: u-b...@dh-electronics.com
> >> ---
> >> configs/imx8mp_dhcom_pdk2_defconfig | 2 ++
> >> configs/imx8mp_dhcom_pdk3_defconfig | 2 ++
> >> 2 files changed, 4 insertions(+)
> >>
> >> diff --git a/configs/imx8mp_dhcom_pdk2_defconfig
> >> b/configs/imx8mp_dhcom_pdk2_defconfig
> >> index 4f907ce00d0..23fb6272ad5 100644
> >> --- a/configs/imx8mp_dhcom_pdk2_defconfig
> >> +++ b/configs/imx8mp_dhcom_pdk2_defconfig
> >> @@ -117,6 +117,7 @@ CONFIG_CMD_BOOTCOUNT=y
> >> CONFIG_CMD_CACHE=y
> >> CONFIG_CMD_TIME=y
> >> CONFIG_CMD_GETTIME=y
> >> +CONFIG_CMD_KASLRSEED=y
> >> CONFIG_CMD_SYSBOOT=y
> >> CONFIG_CMD_UUID=y
> >> CONFIG_CMD_PMIC=y
> >> @@ -223,6 +224,7 @@ CONFIG_DM_REGULATOR_PCA9450=y
> >> CONFIG_SPL_DM_REGULATOR_PCA9450=y
> >> CONFIG_DM_REGULATOR_FIXED=y
> >> CONFIG_DM_REGULATOR_GPIO=y
> >> +CONFIG_DM_RNG=y
> >> CONFIG_DM_RTC=y
> >> CONFIG_RTC_M41T62=y
> >> CONFIG_CONS_INDEX=2
> >> diff --git a/configs/imx8mp_dhcom_pdk3_defconfig
> >> b/configs/imx8mp_dhcom_pdk3_defconfig
> >> index 9972e2d96b6..0d47c12b1f9 100644
> >> --- a/configs/imx8mp_dhcom_pdk3_defconfig
> >> +++ b/configs/imx8mp_dhcom_pdk3_defconfig
> >> @@ -119,6 +119,7 @@ CONFIG_CMD_BOOTCOUNT=y
> >> CONFIG_CMD_CACHE=y
> >> CONFIG_CMD_TIME=y
> >> CONFIG_CMD_GETTIME=y
> >> +CONFIG_CMD_KASLRSEED=y
> >> CONFIG_CMD_SYSBOOT=y
> >> CONFIG_CMD_UUID=y
> >> CONFIG_CMD_PMIC=y
> >> @@ -228,6 +229,7 @@ CONFIG_DM_REGULATOR_PCA9450=y
> >> CONFIG_SPL_DM_REGULATOR_PCA9450=y
> >> CONFIG_DM_REGULATOR_FIXED=y
> >> CONFIG_DM_REGULATOR_GPIO=y
> >> +CONFIG_DM_RNG=y
> >> CONFIG_DM_RTC=y
> >> CONFIG_RTC_M41T62=y
> >> CONFIG_CONS_INDEX=2
> >> --
> >> 2.43.0
> >>
> >
> > Hi Marek,
> >
> > Sorry to respond to an old thread but I ran across this when enabling
> > KALSR on my boards.
> >
> > I have noticed when you enable DM_RNG on IMX8M that SPL fails to bind
> > the driver:
> > Couldn't bind rng driver (-96)
> > SEC0: RNG instantiated
> >
> > sec_init failed!
>
> Did you enable CAAM and ARCH_MISC_INIT on your machine, to initialize
> CAAM in SPL ?
yes
>
> > Didn't you encounter this as well? It seems to me that we may need to
> > add the ability to disable DM_RNG in the SPL unless I'm missing
> > something.
>
> No, but see above, I suspect that might be it, see also
>
> 1f908b1898bd ("ARM: imx8m: Deduplicate CAAM init with arch_misc_init()
> call")
yes, I have that same patch with
c8645e74113c6 ("configs: imx8m: Prepare imx8m-venice boards for HAB support")
Do you have an IMX8M board on hand to check against to see if you see
the same error in the SPL?
Fabio, if you enable CONFIG_DM_RNG on an imx8m{m,p}_evk do you get the
following in the SPL?
Couldn't bind rng driver (-96)
SEC0: RNG instantiated
sec_init failed!
Best Regards,
Tim
Re: [PATCH] ARM: imx: Enable kaslrseed command on DH i.MX8M Plus DHCOM
On Fri, Jan 19, 2024 at 4:36 PM Marek Vasut wrote: > > Linux 6.6.y with KASLR enabled would print the following message on boot: > " > KASLR disabled due to lack of seed > " > Enable the 'kaslrseed' command so a random number seed can be pulled > from CAAM and inserted into the /chosen node 'kaslr-seed' property of > Linux kernel DT before boot, thus letting KASLR work properly. > > Signed-off-by: Marek Vasut > --- > Cc: Fabio Estevam > Cc: Stefano Babic > Cc: u-b...@dh-electronics.com > --- > configs/imx8mp_dhcom_pdk2_defconfig | 2 ++ > configs/imx8mp_dhcom_pdk3_defconfig | 2 ++ > 2 files changed, 4 insertions(+) > > diff --git a/configs/imx8mp_dhcom_pdk2_defconfig > b/configs/imx8mp_dhcom_pdk2_defconfig > index 4f907ce00d0..23fb6272ad5 100644 > --- a/configs/imx8mp_dhcom_pdk2_defconfig > +++ b/configs/imx8mp_dhcom_pdk2_defconfig > @@ -117,6 +117,7 @@ CONFIG_CMD_BOOTCOUNT=y > CONFIG_CMD_CACHE=y > CONFIG_CMD_TIME=y > CONFIG_CMD_GETTIME=y > +CONFIG_CMD_KASLRSEED=y > CONFIG_CMD_SYSBOOT=y > CONFIG_CMD_UUID=y > CONFIG_CMD_PMIC=y > @@ -223,6 +224,7 @@ CONFIG_DM_REGULATOR_PCA9450=y > CONFIG_SPL_DM_REGULATOR_PCA9450=y > CONFIG_DM_REGULATOR_FIXED=y > CONFIG_DM_REGULATOR_GPIO=y > +CONFIG_DM_RNG=y > CONFIG_DM_RTC=y > CONFIG_RTC_M41T62=y > CONFIG_CONS_INDEX=2 > diff --git a/configs/imx8mp_dhcom_pdk3_defconfig > b/configs/imx8mp_dhcom_pdk3_defconfig > index 9972e2d96b6..0d47c12b1f9 100644 > --- a/configs/imx8mp_dhcom_pdk3_defconfig > +++ b/configs/imx8mp_dhcom_pdk3_defconfig > @@ -119,6 +119,7 @@ CONFIG_CMD_BOOTCOUNT=y > CONFIG_CMD_CACHE=y > CONFIG_CMD_TIME=y > CONFIG_CMD_GETTIME=y > +CONFIG_CMD_KASLRSEED=y > CONFIG_CMD_SYSBOOT=y > CONFIG_CMD_UUID=y > CONFIG_CMD_PMIC=y > @@ -228,6 +229,7 @@ CONFIG_DM_REGULATOR_PCA9450=y > CONFIG_SPL_DM_REGULATOR_PCA9450=y > CONFIG_DM_REGULATOR_FIXED=y > CONFIG_DM_REGULATOR_GPIO=y > +CONFIG_DM_RNG=y > CONFIG_DM_RTC=y > CONFIG_RTC_M41T62=y > CONFIG_CONS_INDEX=2 > -- > 2.43.0 > Hi Marek, Sorry to respond to an old thread but I ran across this when enabling KALSR on my boards. I have noticed when you enable DM_RNG on IMX8M that SPL fails to bind the driver: Couldn't bind rng driver (-96) SEC0: RNG instantiated sec_init failed! Didn't you encounter this as well? It seems to me that we may need to add the ability to disable DM_RNG in the SPL unless I'm missing something. Best Regards, Tim
Re: [PATCH 2/3] pci: dw_imx: add support for IMX8MM
On Wed, Apr 17, 2024 at 8:04 PM Marek Vasut wrote:
>
> On 4/17/24 10:09 PM, Tim Harvey wrote:
> > Add support for the IMX8MM SoC by adding driver data with the compatible
> > string of the GPR controller.
> >
> > Signed-off-by: Tim Harvey
> > ---
> > drivers/pci/pcie_dw_imx.c | 20 ++--
> > 1 file changed, 18 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/pcie_dw_imx.c b/drivers/pci/pcie_dw_imx.c
> > index a2ee228224b5..10d926c30645 100644
> > --- a/drivers/pci/pcie_dw_imx.c
> > +++ b/drivers/pci/pcie_dw_imx.c
> > @@ -45,6 +45,10 @@
> > #define IMX8M_GPR_PCIE_CLK_REQ_OVERRIDE_EN BIT(10)
> > #define IMX8M_GPR_PCIE_CLK_REQ_OVERRIDE BIT(11)
> >
> > +struct pcie_chip_info {
> > + const char *gpr;
> > +};
> > +
> > struct pcie_dw_imx {
> > /* Must be first member of the struct */
> > struct pcie_dw dw;
> > @@ -54,6 +58,15 @@ struct pcie_dw_imx {
> > struct reset_ctlapps_reset;
> > struct phy phy;
> > struct udevice *vpcie;
> > + struct pcie_chip_info *info;
> > +};
> > +
> > +static const struct pcie_chip_info imx8mm_chip_info = {
> > + .gpr = "fsl,imx8mm-iomuxc-gpr",
> > +};
> > +
> > +static const struct pcie_chip_info imx8mp_chip_info = {
> > + .gpr = "fsl,imx8mp-iomuxc-gpr",
> > };
> >
> > static void pcie_dw_configure(struct pcie_dw_imx *priv, u32 cap_speed)
> > @@ -246,6 +259,8 @@ static int pcie_dw_imx_of_to_plat(struct udevice *dev)
> > ofnode gpr;
> > int ret;
> >
> > + priv->info = (void *)dev_get_driver_data(dev);
> > +
>
> Does this really have to be cached in priv ?
>
> The priv->info seems used only in this function.
>
Hi Marek,
Good point. I will remove that. Thanks for the review!
Best Regards,
Tim
[PATCH 1/3] clk: imx8mm: Add support for PCIe clocks
Add support for PCIe clocks required to enable PCIe support on
iMX8MM SoC.
Signed-off-by: Tim Harvey
---
drivers/clk/imx/clk-imx8mm.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
index b5c253e49663..c2f01b385201 100644
--- a/drivers/clk/imx/clk-imx8mm.c
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -66,6 +66,15 @@ static const char *imx8mm_i2c3_sels[] = {"clock-osc-24m",
"sys_pll1_160m", "sys_
static const char *imx8mm_i2c4_sels[] = {"clock-osc-24m", "sys_pll1_160m",
"sys_pll2_50m", "sys_pll3_out", "audio_pll1_out",
"video_pll1_out", "audio_pll2_out",
"sys_pll1_133m", };
+static const char *imx8mm_pcie1_ctrl_sels[] = {"clock-osc-24m",
"sys_pll2_250m", "sys_pll2_200m", "sys_pll1_266m",
+ "sys_pll1_800m",
"sys_pll2_500m", "sys_pll2_333m", "sys_pll3_out", };
+
+static const char *imx8mm_pcie1_phy_sels[] = {"clock-osc-24m",
"sys_pll2_100m", "sys_pll2_500m", "clk_ext1", "clk_ext2",
+ "clk_ext3", "clk_ext4",
"sys_pll1_400m", };
+
+static const char *imx8mm_pcie1_aux_sels[] = {"clock-osc-24m",
"sys_pll2_200m", "sys_pll2_50m", "sys_pll3_out",
+ "sys_pll2_100m", "sys_pll1_80m",
"sys_pll1_160m", "sys_pll1_200m", };
+
#ifndef CONFIG_SPL_BUILD
static const char *imx8mm_pwm1_sels[] = {"clock-osc-24m", "sys_pll2_100m",
"sys_pll1_160m", "sys_pll1_40m",
"sys_pll3_out", "clk_ext1",
"sys_pll1_80m", "video_pll1_out", };
@@ -256,6 +265,15 @@ static int imx8mm_clk_probe(struct udevice *dev)
imx8m_clk_composite("usb_bus", imx8mm_usb_bus_sels, base +
0x8b80));
/* IP */
+ clk_dm(IMX8MM_CLK_PCIE1_CTRL,
+ imx8m_clk_composite("pcie1_ctrl", imx8mm_pcie1_ctrl_sels,
+ base + 0xa300));
+ clk_dm(IMX8MM_CLK_PCIE1_PHY,
+ imx8m_clk_composite("pcie1_phy", imx8mm_pcie1_phy_sels,
+ base + 0xa380));
+ clk_dm(IMX8MM_CLK_PCIE1_AUX,
+ imx8m_clk_composite("pcie1_aux", imx8mm_pcie1_aux_sels,
+ base + 0xa400));
clk_dm(IMX8MM_CLK_USDHC1,
imx8m_clk_composite("usdhc1", imx8mm_usdhc1_sels,
base + 0xac00));
@@ -339,6 +357,9 @@ static int imx8mm_clk_probe(struct udevice *dev)
imx_clk_gate4("pwm4_root_clk", "pwm4", base + 0x42b0, 0));
#endif
+ clk_dm(IMX8MM_CLK_PCIE1_ROOT,
+ imx_clk_gate4("pcie1_root_clk", "pcie1_ctrl", base + 0x4250, 0));
+
#if CONFIG_IS_ENABLED(DM_SPI)
clk_dm(IMX8MM_CLK_ECSPI1,
imx8m_clk_composite("ecspi1", imx8mm_ecspi1_sels, base +
0xb280));
--
2.25.1
[PATCH 3/3] imx8mm_venice_defconfig: Enable PCIe/NVMe support
Enable PCIe/NVMe support. Also, enable the reset driver which is a prerequisite for PCIe support. Signed-off-by: Tim Harvey --- configs/imx8mm_venice_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/configs/imx8mm_venice_defconfig b/configs/imx8mm_venice_defconfig index c3fd4c45ab3d..d34dd7cc2bac 100644 --- a/configs/imx8mm_venice_defconfig +++ b/configs/imx8mm_venice_defconfig @@ -12,6 +12,7 @@ CONFIG_DEFAULT_DEVICE_TREE="freescale/imx8mm-venice-gw71xx-0x" CONFIG_SPL_TEXT_BASE=0x7E1000 CONFIG_TARGET_IMX8MM_VENICE=y CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_DM_RESET=y CONFIG_SYS_MONITOR_LEN=524288 CONFIG_SPL_MMC=y CONFIG_SPL_SERIAL=y @@ -20,6 +21,7 @@ CONFIG_SPL_STACK=0x92 CONFIG_SPL=y CONFIG_ENV_OFFSET_REDUND=0x3f8000 CONFIG_SYS_LOAD_ADDR=0x4820 +CONFIG_PCI=y CONFIG_SYS_MEMTEST_START=0x4000 CONFIG_SYS_MEMTEST_END=0x8000 CONFIG_FIT=y @@ -60,6 +62,7 @@ CONFIG_CMD_FUSE=y CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y +CONFIG_CMD_PCI=y CONFIG_CMD_USB=y CONFIG_CMD_USB_MASS_STORAGE=y CONFIG_CMD_DHCP6=y @@ -119,6 +122,9 @@ CONFIG_PHY_GIGE=y CONFIG_FEC_MXC=y CONFIG_KSZ9477=y CONFIG_MII=y +CONFIG_NVME_PCI=y +CONFIG_PCIE_DW_IMX=y +CONFIG_PHY_IMX8M_PCIE=y CONFIG_PINCTRL=y CONFIG_SPL_PINCTRL=y CONFIG_PINCTRL_IMX8M=y -- 2.25.1
[PATCH 2/3] pci: dw_imx: add support for IMX8MM
Add support for the IMX8MM SoC by adding driver data with the compatible
string of the GPR controller.
Signed-off-by: Tim Harvey
---
drivers/pci/pcie_dw_imx.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pcie_dw_imx.c b/drivers/pci/pcie_dw_imx.c
index a2ee228224b5..10d926c30645 100644
--- a/drivers/pci/pcie_dw_imx.c
+++ b/drivers/pci/pcie_dw_imx.c
@@ -45,6 +45,10 @@
#define IMX8M_GPR_PCIE_CLK_REQ_OVERRIDE_EN BIT(10)
#define IMX8M_GPR_PCIE_CLK_REQ_OVERRIDEBIT(11)
+struct pcie_chip_info {
+ const char *gpr;
+};
+
struct pcie_dw_imx {
/* Must be first member of the struct */
struct pcie_dw dw;
@@ -54,6 +58,15 @@ struct pcie_dw_imx {
struct reset_ctlapps_reset;
struct phy phy;
struct udevice *vpcie;
+ struct pcie_chip_info *info;
+};
+
+static const struct pcie_chip_info imx8mm_chip_info = {
+ .gpr = "fsl,imx8mm-iomuxc-gpr",
+};
+
+static const struct pcie_chip_info imx8mp_chip_info = {
+ .gpr = "fsl,imx8mp-iomuxc-gpr",
};
static void pcie_dw_configure(struct pcie_dw_imx *priv, u32 cap_speed)
@@ -246,6 +259,8 @@ static int pcie_dw_imx_of_to_plat(struct udevice *dev)
ofnode gpr;
int ret;
+ priv->info = (void *)dev_get_driver_data(dev);
+
/* Get the controller base address */
priv->dw.dbi_base = (void *)dev_read_addr_name(dev, "dbi");
if ((fdt_addr_t)priv->dw.dbi_base == FDT_ADDR_T_NONE) {
@@ -287,7 +302,7 @@ static int pcie_dw_imx_of_to_plat(struct udevice *dev)
goto err_phy;
}
- gpr = ofnode_by_compatible(ofnode_null(), "fsl,imx8mp-iomuxc-gpr");
+ gpr = ofnode_by_compatible(ofnode_null(), priv->info->gpr);
if (ofnode_equal(gpr, ofnode_null())) {
dev_err(dev, "unable to find GPR node\n");
ret = -ENODEV;
@@ -322,7 +337,8 @@ static const struct dm_pci_ops pcie_dw_imx_ops = {
};
static const struct udevice_id pcie_dw_imx_ids[] = {
- { .compatible = "fsl,imx8mp-pcie" },
+ { .compatible = "fsl,imx8mm-pcie", .data = (ulong)_chip_info, },
+ { .compatible = "fsl,imx8mp-pcie", .data = (ulong)_chip_info, },
{ }
};
--
2.25.1
[PATCH] imx8m*_venice_defconfig: enable ipv6, wget and tftpput
Enable ipv6, wget, and tftpput support Signed-off-by: Tim Harvey --- configs/imx8mm_venice_defconfig | 5 + configs/imx8mn_venice_defconfig | 5 + configs/imx8mp_venice_defconfig | 5 + 3 files changed, 15 insertions(+) diff --git a/configs/imx8mm_venice_defconfig b/configs/imx8mm_venice_defconfig index cb6b97d097c1..c3fd4c45ab3d 100644 --- a/configs/imx8mm_venice_defconfig +++ b/configs/imx8mm_venice_defconfig @@ -62,7 +62,10 @@ CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_USB=y CONFIG_CMD_USB_MASS_STORAGE=y +CONFIG_CMD_DHCP6=y +CONFIG_CMD_TFTPPUT=y CONFIG_SYS_DISABLE_AUTOLOAD=y +CONFIG_CMD_WGET=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y CONFIG_CMD_UUID=y @@ -83,6 +86,8 @@ CONFIG_ETHPRIME="eth0" CONFIG_NET_RANDOM_ETHADDR=y CONFIG_IP_DEFRAG=y CONFIG_TFTP_BLOCKSIZE=4096 +CONFIG_PROT_TCP_SACK=y +CONFIG_IPV6=y CONFIG_SPL_DM=y CONFIG_SPL_CLK_COMPOSITE_CCF=y CONFIG_CLK_COMPOSITE_CCF=y diff --git a/configs/imx8mn_venice_defconfig b/configs/imx8mn_venice_defconfig index 0a4fba5f1ca8..21b68e3cc841 100644 --- a/configs/imx8mn_venice_defconfig +++ b/configs/imx8mn_venice_defconfig @@ -65,7 +65,10 @@ CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_USB=y CONFIG_CMD_USB_MASS_STORAGE=y +CONFIG_CMD_DHCP6=y +CONFIG_CMD_TFTPPUT=y CONFIG_SYS_DISABLE_AUTOLOAD=y +CONFIG_CMD_WGET=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y CONFIG_CMD_UUID=y @@ -86,6 +89,8 @@ CONFIG_ETHPRIME="eth0" CONFIG_NET_RANDOM_ETHADDR=y CONFIG_IP_DEFRAG=y CONFIG_TFTP_BLOCKSIZE=4096 +CONFIG_PROT_TCP_SACK=y +CONFIG_IPV6=y CONFIG_SPL_DM=y CONFIG_SPL_CLK_IMX8MN=y CONFIG_CLK_IMX8MN=y diff --git a/configs/imx8mp_venice_defconfig b/configs/imx8mp_venice_defconfig index 6e4addc7728f..187221d2ba63 100644 --- a/configs/imx8mp_venice_defconfig +++ b/configs/imx8mp_venice_defconfig @@ -67,7 +67,10 @@ CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_PCI=y CONFIG_CMD_USB=y +CONFIG_CMD_DHCP6=y +CONFIG_CMD_TFTPPUT=y CONFIG_SYS_DISABLE_AUTOLOAD=y +CONFIG_CMD_WGET=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y CONFIG_CMD_UUID=y @@ -86,6 +89,8 @@ CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_IP_DEFRAG=y CONFIG_TFTP_BLOCKSIZE=4096 +CONFIG_PROT_TCP_SACK=y +CONFIG_IPV6=y CONFIG_SPL_DM=y CONFIG_REGMAP=y CONFIG_SYSCON=y -- 2.25.1
[PATCH] board: gateworks: venice: fix dt adjustment for gw73xx baseboard for imx8mp
The GW73xx baseboard needs a PCI dt adjustment for revC/D based on a
change of the PCIe switch. Make sure we are only doing this for a pci
based ethernet to avoid causing a boot hang when the ethernet1 alias
points to eqos or fec. To know this is a pcie device ensure the alias
begins with the pcie controller.
Signed-off-by: Tim Harvey
---
board/gateworks/venice/venice.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/board/gateworks/venice/venice.c b/board/gateworks/venice/venice.c
index f54f1186b686..5b105d7659e4 100644
--- a/board/gateworks/venice/venice.c
+++ b/board/gateworks/venice/venice.c
@@ -230,6 +230,7 @@ uint mmc_get_env_part(struct mmc *mmc)
int ft_board_setup(void *fdt, struct bd_info *bd)
{
const char *base_model = eeprom_get_baseboard_model();
+ const char *path;
char pcbrev;
int off;
@@ -238,10 +239,10 @@ int ft_board_setup(void *fdt, struct bd_info *bd)
if (!strncmp(base_model, "GW73", 4)) {
pcbrev = get_pcb_rev(base_model);
+ path = fdt_get_alias(fdt, "ethernet1");
- if (pcbrev > 'B' && pcbrev < 'E') {
- printf("adjusting dt for %s\n", base_model);
-
+ if (pcbrev > 'B' && pcbrev < 'E' && path && !strncmp(path,
"/soc@0/pcie@", 12)) {
+ printf("adjusting %s pcie\n", base_model);
/*
* revC/D/E has PCIe 4-port switch which changes
* ethernet1 PCIe GbE:
--
2.25.1
Re: [PATCH] imx8m*-venice: enable TPM support
On Mon, Mar 25, 2024 at 9:27 AM Tim Harvey wrote: > > Enable support for TPM2 devices. As the ATTPM20P TPM2 used on the > Gateworks Venice boards hangs off the SPI bus we enable SPI support > as well. > > Signed-off-by: Tim Harvey > --- > configs/imx8mm_venice_defconfig | 10 ++ > configs/imx8mn_venice_defconfig | 10 ++ > configs/imx8mp_venice_defconfig | 10 ++ > 3 files changed, 30 insertions(+) > > diff --git a/configs/imx8mm_venice_defconfig b/configs/imx8mm_venice_defconfig > index cb6b97d097c1..86928687df2d 100644 > --- a/configs/imx8mm_venice_defconfig > +++ b/configs/imx8mm_venice_defconfig > @@ -68,6 +68,7 @@ CONFIG_CMD_TIME=y > CONFIG_CMD_UUID=y > CONFIG_CMD_PMIC=y > CONFIG_CMD_REGULATOR=y > +CONFIG_CMD_TPM=y > CONFIG_CMD_EXT4_WRITE=y > # CONFIG_ISO_PARTITION is not set > # CONFIG_SPL_EFI_PARTITION is not set > @@ -127,14 +128,20 @@ CONFIG_SPL_DM_PMIC_MP5416=y > CONFIG_DM_REGULATOR=y > CONFIG_DM_REGULATOR_FIXED=y > CONFIG_DM_REGULATOR_GPIO=y > +# CONFIG_DM_RNG is not set > CONFIG_DM_SERIAL=y > CONFIG_MXC_UART=y > +CONFIG_SPI=y > +CONFIG_DM_SPI=y > +CONFIG_MXC_SPI=y > CONFIG_SYSRESET=y > CONFIG_SPL_SYSRESET=y > CONFIG_SYSRESET_PSCI=y > CONFIG_SYSRESET_WATCHDOG=y > CONFIG_DM_THERMAL=y > CONFIG_IMX_TMU=y > +# CONFIG_TPM_V1 is not set > +CONFIG_TPM2_TIS_SPI=y > CONFIG_USB=y > CONFIG_USB_EHCI_HCD=y > CONFIG_USB_HOST_ETHER=y > @@ -152,4 +159,7 @@ CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 > CONFIG_CI_UDC=y > CONFIG_USB_GADGET_DOWNLOAD=y > CONFIG_IMX_WATCHDOG=y > +CONFIG_TPM=y > +# CONFIG_SPL_SHA512 is not set > +# CONFIG_SPL_SHA384 is not set > CONFIG_HEXDUMP=y > diff --git a/configs/imx8mn_venice_defconfig b/configs/imx8mn_venice_defconfig > index 0a4fba5f1ca8..6bb0f015a9bf 100644 > --- a/configs/imx8mn_venice_defconfig > +++ b/configs/imx8mn_venice_defconfig > @@ -71,6 +71,7 @@ CONFIG_CMD_TIME=y > CONFIG_CMD_UUID=y > CONFIG_CMD_PMIC=y > CONFIG_CMD_REGULATOR=y > +CONFIG_CMD_TPM=y > CONFIG_CMD_EXT4_WRITE=y > # CONFIG_ISO_PARTITION is not set > # CONFIG_SPL_EFI_PARTITION is not set > @@ -128,14 +129,20 @@ CONFIG_SPL_DM_PMIC_MP5416=y > CONFIG_DM_REGULATOR=y > CONFIG_DM_REGULATOR_FIXED=y > CONFIG_DM_REGULATOR_GPIO=y > +# CONFIG_DM_RNG is not set > CONFIG_DM_SERIAL=y > CONFIG_MXC_UART=y > +CONFIG_SPI=y > +CONFIG_DM_SPI=y > +CONFIG_MXC_SPI=y > CONFIG_SYSRESET=y > CONFIG_SPL_SYSRESET=y > CONFIG_SYSRESET_PSCI=y > CONFIG_SYSRESET_WATCHDOG=y > CONFIG_DM_THERMAL=y > CONFIG_IMX_TMU=y > +# CONFIG_TPM_V1 is not set > +CONFIG_TPM2_TIS_SPI=y > CONFIG_USB=y > CONFIG_USB_EHCI_HCD=y > CONFIG_USB_HOST_ETHER=y > @@ -153,4 +160,7 @@ CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 > CONFIG_CI_UDC=y > CONFIG_USB_GADGET_DOWNLOAD=y > CONFIG_IMX_WATCHDOG=y > +CONFIG_TPM=y > +# CONFIG_SPL_SHA512 is not set > +# CONFIG_SPL_SHA384 is not set > CONFIG_HEXDUMP=y > diff --git a/configs/imx8mp_venice_defconfig b/configs/imx8mp_venice_defconfig > index 6e4addc7728f..b1055ef2f066 100644 > --- a/configs/imx8mp_venice_defconfig > +++ b/configs/imx8mp_venice_defconfig > @@ -73,6 +73,7 @@ CONFIG_CMD_TIME=y > CONFIG_CMD_UUID=y > CONFIG_CMD_PMIC=y > CONFIG_CMD_REGULATOR=y > +CONFIG_CMD_TPM=y > CONFIG_CMD_EXT4_WRITE=y > # CONFIG_ISO_PARTITION is not set > # CONFIG_SPL_EFI_PARTITION is not set > @@ -135,14 +136,20 @@ CONFIG_SPL_DM_PMIC_MP5416=y > CONFIG_DM_REGULATOR=y > CONFIG_DM_REGULATOR_FIXED=y > CONFIG_DM_REGULATOR_GPIO=y > +# CONFIG_DM_RNG is not set > CONFIG_DM_SERIAL=y > CONFIG_MXC_UART=y > +CONFIG_SPI=y > +CONFIG_DM_SPI=y > +CONFIG_MXC_SPI=y > CONFIG_SYSRESET=y > CONFIG_SPL_SYSRESET=y > CONFIG_SYSRESET_PSCI=y > CONFIG_SYSRESET_WATCHDOG=y > CONFIG_DM_THERMAL=y > CONFIG_IMX_TMU=y > +# CONFIG_TPM_V1 is not set > +CONFIG_TPM2_TIS_SPI=y > CONFIG_USB=y > CONFIG_USB_XHCI_HCD=y > CONFIG_USB_XHCI_DWC3=y > @@ -160,4 +167,7 @@ CONFIG_USB_ETHER_MCS7830=y > CONFIG_USB_ETHER_RTL8152=y > CONFIG_USB_ETHER_SMSC95XX=y > CONFIG_IMX_WATCHDOG=y > +CONFIG_TPM=y > +# CONFIG_SPL_SHA512 is not set > +# CONFIG_SPL_SHA384 is not set > CONFIG_HEXDUMP=y > -- > 2.25.1 > Fabio, This one got tagged as 'changes requested' in patchwork but I'm not clear why. Are there any issues with this? Best Regards, Tim
Re: [PATCH v2] tpm: display warning if using gpio reset with TPM
On Wed, Apr 17, 2024 at 12:01 AM Ilias Apalodimas
wrote:
>
> On Wed, 17 Apr 2024 at 09:48, Miquel Raynal wrote:
> >
> > Hi Ilias,
> >
> > ilias.apalodi...@linaro.org wrote on Wed, 17 Apr 2024 08:40:14 +0300:
> >
> > > Hi Miquel
> > >
> > > On Mon, 8 Apr 2024 at 10:23, Miquel Raynal
> > > wrote:
> > > >
> > > > Hello,
> > > >
> > > > ilias.apalodi...@linaro.org wrote on Thu, 28 Mar 2024 09:08:37 +0200:
> > > >
> > > > > Thanks Tim
> > > > >
> > > > > On Thu, 28 Mar 2024 at 00:12, Tim Harvey
> > > > > wrote:
> > > > > >
> > > > > > Instead of displaying what looks like an error message if a
> > > > > > gpio-reset dt prop is missing for a TPM display a warning that
> > > > > > having a gpio reset on a TPM should not be used for a secure
> > > > > > production
> > > > > > device.
> > > > > >
> > > > > > TCG TIS spec [1] says:
> > > > > > "The TPM_Init (LRESET#/SPI_RST#) signal MUST be connected to the
> > > > > > platform CPU Reset signal such that it complies with the
> > > > > > requirements
> > > > > > specified in section 1.2.7 HOST Platform Reset in the PC Client
> > > > > > Implementation Specification for Conventional BIOS."
> > > > > >
> > > > > > The reasoning is that you should not be able to toggle a GPIO and
> > > > > > reset
> > > > > > the TPM without resetting the CPU as well because if an attacker can
> > > > > > break into your OS via an OS level security flaw they can then
> > > > > > reset the
> > > > > > TPM via GPIO and replay the measurements required to unseal keys
> > > > > > that you have otherwise protected.
> > > > > >
> > > > > > [1]
> > > > > > https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientTPMInterfaceSpecification_TIS__1-3_27_03212013.pdf
> > > > > >
> > > > > > Signed-off-by: Tim Harvey
> > > > > > ---
> > > > > > v2: change the message to a warning and update commit desc/log
> > > > > > ---
> > > > > > drivers/tpm/tpm2_tis_spi.c | 8
> > > > > > 1 file changed, 4 insertions(+), 4 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/tpm/tpm2_tis_spi.c b/drivers/tpm/tpm2_tis_spi.c
> > > > > > index de9cf8f21e07..c9c83f6f0fc8 100644
> > > > > > --- a/drivers/tpm/tpm2_tis_spi.c
> > > > > > +++ b/drivers/tpm/tpm2_tis_spi.c
> > > > > > @@ -237,14 +237,14 @@ static int tpm_tis_spi_probe(struct udevice
> > > > > > *dev)
> > > > > > /* legacy reset */
> > > > > > ret = gpio_request_by_name(dev,
> > > > > > "gpio-reset", 0,
> > > > > >_gpio,
> > > > > > GPIOD_IS_OUT);
> > > > > > - if (ret) {
> > > > > > - log(LOGC_NONE, LOGL_NOTICE,
> > > > > > - "%s: missing reset GPIO\n",
> > > > > > __func__);
> > > > > > + if (ret)
> > > > > > goto init;
> > > > > > - }
> > > > > > log(LOGC_NONE, LOGL_NOTICE,
> > > > > > "%s: gpio-reset is deprecated\n",
> > > > > > __func__);
> > > > > > }
> > > > > > + log(LOGC_NONE, LOGL_WARNING,
> > > > > > + "%s: TPM gpio reset should not be used on
> > > > > > secure production devices\n",
> > > > > > + dev->name);
> > > > > > dm_gpio_set_value(_gpio, 1);
> > > > > > mdelay(1);
> > > > > > dm_gpio_set_value(_gpio, 0);
> > > >
> > > > The current logic expects a reset gpio and bails out if it cannot get
> > > > it with a (questionable) goto statement.
> > > >
> > > > You want to invert that logic, and expect no gpio, but only if there is
> > > > one you want to warn.
> > > >
> > > > This is perfectly fine but the logic here must be clarified. I'd go for:
> > > >
> > > > ret = gpio_request()
> > > > if (ret) {
> > > > ret = gpio_request()
> > > > if (!ret)
> > > > warn(deprecated)
> > > > }
> > > >
> > > > if (!ret) {
> > > > warn(dangerous)
> > > > toggle_value()
> > > > }
> > > >
> > > > I would ideally replace the 'if (ret)' clauses with 'if (!reset_gpio)'
> > > > which would make the checks even clearer.
> > >
> > > Fair enough. But the code with the proposed change has no functional
> > > problems right?
> >
> > No, this is functionally right, but the code is not clear like that.
> >
> > > If so I'll send a PR to Tom as is and rework it as suggested later
> >
> > Well, that's not how contribution work usually. Is there an emergency
> > in getting this merged?
>
> Not really, it's a print message. But I don't currently have time to
> pick this up.
> Tim, would you mind reworking it as Miquel suggested?
>
I'm just catching up after being out of the office for a couple of
weeks - I'll rework it and submit another revision as soon as I have
some time.
Best Regards,
Tim
[PATCH v3] tpm-v2: allow algoirthm name to be configured for pcr_read and pcr_extend
For pcr_read and pcr_extend commands allow the digest algorithm to be
specified by an additional argument. If not specified it will default to
SHA256 for backwards compatibility.
A follow-on to this could be to extend all PCR banks with the detected
algo when the argument is 'auto'.
Signed-off-by: Tim Harvey
---
v3:
- replace tpm2_supported_algorithms with struct and use this to relate hash
algoirthm
details
v2:
- use tpm2_algorithm_to_len
- use enum tpm2_algorithms
- make function names and parameter names more consistent with existing
tpm-v2 functions
- fix various spelling errors
---
cmd/tpm-v2.c | 49
include/tpm-v2.h | 67 ++-
lib/efi_loader/efi_tcg2.c | 4 +--
lib/tpm-v2.c | 62 +++-
4 files changed, 143 insertions(+), 39 deletions(-)
diff --git a/cmd/tpm-v2.c b/cmd/tpm-v2.c
index 7e479b9dfe36..2343b4d9cb9e 100644
--- a/cmd/tpm-v2.c
+++ b/cmd/tpm-v2.c
@@ -99,11 +99,19 @@ static int do_tpm2_pcr_extend(struct cmd_tbl *cmdtp, int
flag, int argc,
struct tpm_chip_priv *priv;
u32 index = simple_strtoul(argv[1], NULL, 0);
void *digest = map_sysmem(simple_strtoul(argv[2], NULL, 0), 0);
+ int algo = TPM2_ALG_SHA256;
+ int algo_len;
int ret;
u32 rc;
- if (argc != 3)
+ if (argc < 3 || argc > 4)
return CMD_RET_USAGE;
+ if (argc == 4) {
+ algo = tpm2_name_to_algorithm(argv[3]);
+ if (algo < 0)
+ return CMD_RET_FAILURE;
+ }
+ algo_len = tpm2_algorithm_to_len(algo);
ret = get_tpm();
if (ret)
@@ -116,8 +124,12 @@ static int do_tpm2_pcr_extend(struct cmd_tbl *cmdtp, int
flag, int argc,
if (index >= priv->pcr_count)
return -EINVAL;
- rc = tpm2_pcr_extend(dev, index, TPM2_ALG_SHA256, digest,
-TPM2_DIGEST_LEN);
+ rc = tpm2_pcr_extend(dev, index, algo, digest, algo_len);
+ if (!rc) {
+ printf("PCR #%u extended with %d byte %s digest\n", index,
+ algo_len, tpm2_algorithm_name(algo));
+ print_byte_string(digest, algo_len);
+ }
unmap_sysmem(digest);
@@ -127,15 +139,23 @@ static int do_tpm2_pcr_extend(struct cmd_tbl *cmdtp, int
flag, int argc,
static int do_tpm_pcr_read(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
{
+ enum tpm2_algorithms algo = TPM2_ALG_SHA256;
struct udevice *dev;
struct tpm_chip_priv *priv;
u32 index, rc;
+ int algo_len;
unsigned int updates;
void *data;
int ret;
- if (argc != 3)
+ if (argc < 3 || argc > 4)
return CMD_RET_USAGE;
+ if (argc == 4) {
+ algo = tpm2_name_to_algorithm(argv[3]);
+ if (algo < 0)
+ return CMD_RET_FAILURE;
+ }
+ algo_len = tpm2_algorithm_to_len(algo);
ret = get_tpm();
if (ret)
@@ -151,11 +171,12 @@ static int do_tpm_pcr_read(struct cmd_tbl *cmdtp, int
flag, int argc,
data = map_sysmem(simple_strtoul(argv[2], NULL, 0), 0);
- rc = tpm2_pcr_read(dev, index, priv->pcr_select_min, TPM2_ALG_SHA256,
- data, TPM2_DIGEST_LEN, );
+ rc = tpm2_pcr_read(dev, index, priv->pcr_select_min, algo,
+ data, algo_len, );
if (!rc) {
- printf("PCR #%u content (%u known updates):\n", index, updates);
- print_byte_string(data, TPM2_DIGEST_LEN);
+ printf("PCR #%u %s %d byte content (%u known updates):\n",
index,
+ tpm2_algorithm_name(algo), algo_len, updates);
+ print_byte_string(data, algo_len);
}
unmap_sysmem(data);
@@ -415,14 +436,14 @@ U_BOOT_CMD(tpm2, CONFIG_SYS_MAXARGS, 1, do_tpm, "Issue a
TPMv2.x command",
" is one of:\n"
"* TPM2_RH_LOCKOUT\n"
"* TPM2_RH_PLATFORM\n"
-"pcr_extend \n"
-"Extend PCR # with digest at .\n"
+"pcr_extend []\n"
+"Extend PCR # with digest at with digest_algo.\n"
": index of the PCR\n"
-": address of a 32-byte SHA256 digest\n"
-"pcr_read \n"
-"Read PCR # to memory address .\n"
+": address of digest of digest_algo type (defaults to
SHA256)\n"
+"pcr_read []\n"
+"Read PCR # to memory address with .\n"
": index of the PCR\n"
-": address to store the a 32-byte SHA256 digest\n"
+": address of digest of digest_algo type (defaults to
SHA256)\n"
"get_capability\n"
"Read and display
Re: [PATCH v2] tpm-v2: allow algoirthm name to be configured for pcr_read and pcr_extend
On Thu, Mar 28, 2024 at 11:18 PM Ilias Apalodimas
wrote:
>
> Hi Tim,
>
> On Thu, 28 Mar 2024 at 19:01, Tim Harvey wrote:
> >
> > For pcr_read and pcr_extend commands allow the digest algorithm to be
> > specified by an additional argument. If not specified it will default to
> > SHA256 for backwards compatibility.
> >
> > A follow-on to this could be to extend all PCR banks with the detected
> > algo when the argument is 'auto'.
> >
> > Signed-off-by: Tim Harvey
> > ---
> > v2:
> > - use tpm2_algorithm_to_len
> > - use enum tpm2_algorithms
> > - make function names and parameter names more consistent with existing
> >tpm-v2 functions
> > - fix various spelling errors
> > ---
> > cmd/tpm-v2.c | 49 ++--
> > include/tpm-v2.h | 18 ++
> > lib/tpm-v2.c | 34 +
> > 3 files changed, 87 insertions(+), 14 deletions(-)
> >
> > diff --git a/cmd/tpm-v2.c b/cmd/tpm-v2.c
> > index 7e479b9dfe36..2343b4d9cb9e 100644
> > --- a/cmd/tpm-v2.c
> > +++ b/cmd/tpm-v2.c
> > @@ -99,11 +99,19 @@ static int do_tpm2_pcr_extend(struct cmd_tbl *cmdtp,
> > int flag, int argc,
> > struct tpm_chip_priv *priv;
> > u32 index = simple_strtoul(argv[1], NULL, 0);
> > void *digest = map_sysmem(simple_strtoul(argv[2], NULL, 0), 0);
> > + int algo = TPM2_ALG_SHA256;
> > + int algo_len;
> > int ret;
> > u32 rc;
> >
> > - if (argc != 3)
> > + if (argc < 3 || argc > 4)
> > return CMD_RET_USAGE;
> > + if (argc == 4) {
> > + algo = tpm2_name_to_algorithm(argv[3]);
> > + if (algo < 0)
> > + return CMD_RET_FAILURE;
> > + }
> > + algo_len = tpm2_algorithm_to_len(algo);
> >
> > ret = get_tpm();
> > if (ret)
> > @@ -116,8 +124,12 @@ static int do_tpm2_pcr_extend(struct cmd_tbl *cmdtp,
> > int flag, int argc,
> > if (index >= priv->pcr_count)
> > return -EINVAL;
> >
> > - rc = tpm2_pcr_extend(dev, index, TPM2_ALG_SHA256, digest,
> > -TPM2_DIGEST_LEN);
> > + rc = tpm2_pcr_extend(dev, index, algo, digest, algo_len);
> > + if (!rc) {
> > + printf("PCR #%u extended with %d byte %s digest\n", index,
> > + algo_len, tpm2_algorithm_name(algo));
> > + print_byte_string(digest, algo_len);
> > + }
> >
> > unmap_sysmem(digest);
> >
> > @@ -127,15 +139,23 @@ static int do_tpm2_pcr_extend(struct cmd_tbl *cmdtp,
> > int flag, int argc,
> > static int do_tpm_pcr_read(struct cmd_tbl *cmdtp, int flag, int argc,
> >char *const argv[])
> > {
> > + enum tpm2_algorithms algo = TPM2_ALG_SHA256;
> > struct udevice *dev;
> > struct tpm_chip_priv *priv;
> > u32 index, rc;
> > + int algo_len;
> > unsigned int updates;
> > void *data;
> > int ret;
> >
> > - if (argc != 3)
> > + if (argc < 3 || argc > 4)
> > return CMD_RET_USAGE;
> > + if (argc == 4) {
> > + algo = tpm2_name_to_algorithm(argv[3]);
> > + if (algo < 0)
> > + return CMD_RET_FAILURE;
> > + }
> > + algo_len = tpm2_algorithm_to_len(algo);
> >
> > ret = get_tpm();
> > if (ret)
> > @@ -151,11 +171,12 @@ static int do_tpm_pcr_read(struct cmd_tbl *cmdtp, int
> > flag, int argc,
> >
> > data = map_sysmem(simple_strtoul(argv[2], NULL, 0), 0);
> >
> > - rc = tpm2_pcr_read(dev, index, priv->pcr_select_min,
> > TPM2_ALG_SHA256,
> > - data, TPM2_DIGEST_LEN, );
> > + rc = tpm2_pcr_read(dev, index, priv->pcr_select_min, algo,
> > + data, algo_len, );
> > if (!rc) {
> > - printf("PCR #%u content (%u known updates):\n", index,
> > updates);
> > - print_byte_string(data, TPM2_DIGEST_LEN);
> > + printf("PCR #%u %s %d byte content (%u known updates):\n",
> > index,
> > + tpm2_algorithm_name(algo), algo_len, updates);
> > + print_byte_string(data, algo_len);
> >
[PATCH v2] tpm-v2: allow algoirthm name to be configured for pcr_read and pcr_extend
For pcr_read and pcr_extend commands allow the digest algorithm to be
specified by an additional argument. If not specified it will default to
SHA256 for backwards compatibility.
A follow-on to this could be to extend all PCR banks with the detected
algo when the argument is 'auto'.
Signed-off-by: Tim Harvey
---
v2:
- use tpm2_algorithm_to_len
- use enum tpm2_algorithms
- make function names and parameter names more consistent with existing
tpm-v2 functions
- fix various spelling errors
---
cmd/tpm-v2.c | 49 ++--
include/tpm-v2.h | 18 ++
lib/tpm-v2.c | 34 +
3 files changed, 87 insertions(+), 14 deletions(-)
diff --git a/cmd/tpm-v2.c b/cmd/tpm-v2.c
index 7e479b9dfe36..2343b4d9cb9e 100644
--- a/cmd/tpm-v2.c
+++ b/cmd/tpm-v2.c
@@ -99,11 +99,19 @@ static int do_tpm2_pcr_extend(struct cmd_tbl *cmdtp, int
flag, int argc,
struct tpm_chip_priv *priv;
u32 index = simple_strtoul(argv[1], NULL, 0);
void *digest = map_sysmem(simple_strtoul(argv[2], NULL, 0), 0);
+ int algo = TPM2_ALG_SHA256;
+ int algo_len;
int ret;
u32 rc;
- if (argc != 3)
+ if (argc < 3 || argc > 4)
return CMD_RET_USAGE;
+ if (argc == 4) {
+ algo = tpm2_name_to_algorithm(argv[3]);
+ if (algo < 0)
+ return CMD_RET_FAILURE;
+ }
+ algo_len = tpm2_algorithm_to_len(algo);
ret = get_tpm();
if (ret)
@@ -116,8 +124,12 @@ static int do_tpm2_pcr_extend(struct cmd_tbl *cmdtp, int
flag, int argc,
if (index >= priv->pcr_count)
return -EINVAL;
- rc = tpm2_pcr_extend(dev, index, TPM2_ALG_SHA256, digest,
-TPM2_DIGEST_LEN);
+ rc = tpm2_pcr_extend(dev, index, algo, digest, algo_len);
+ if (!rc) {
+ printf("PCR #%u extended with %d byte %s digest\n", index,
+ algo_len, tpm2_algorithm_name(algo));
+ print_byte_string(digest, algo_len);
+ }
unmap_sysmem(digest);
@@ -127,15 +139,23 @@ static int do_tpm2_pcr_extend(struct cmd_tbl *cmdtp, int
flag, int argc,
static int do_tpm_pcr_read(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
{
+ enum tpm2_algorithms algo = TPM2_ALG_SHA256;
struct udevice *dev;
struct tpm_chip_priv *priv;
u32 index, rc;
+ int algo_len;
unsigned int updates;
void *data;
int ret;
- if (argc != 3)
+ if (argc < 3 || argc > 4)
return CMD_RET_USAGE;
+ if (argc == 4) {
+ algo = tpm2_name_to_algorithm(argv[3]);
+ if (algo < 0)
+ return CMD_RET_FAILURE;
+ }
+ algo_len = tpm2_algorithm_to_len(algo);
ret = get_tpm();
if (ret)
@@ -151,11 +171,12 @@ static int do_tpm_pcr_read(struct cmd_tbl *cmdtp, int
flag, int argc,
data = map_sysmem(simple_strtoul(argv[2], NULL, 0), 0);
- rc = tpm2_pcr_read(dev, index, priv->pcr_select_min, TPM2_ALG_SHA256,
- data, TPM2_DIGEST_LEN, );
+ rc = tpm2_pcr_read(dev, index, priv->pcr_select_min, algo,
+ data, algo_len, );
if (!rc) {
- printf("PCR #%u content (%u known updates):\n", index, updates);
- print_byte_string(data, TPM2_DIGEST_LEN);
+ printf("PCR #%u %s %d byte content (%u known updates):\n",
index,
+ tpm2_algorithm_name(algo), algo_len, updates);
+ print_byte_string(data, algo_len);
}
unmap_sysmem(data);
@@ -415,14 +436,14 @@ U_BOOT_CMD(tpm2, CONFIG_SYS_MAXARGS, 1, do_tpm, "Issue a
TPMv2.x command",
" is one of:\n"
"* TPM2_RH_LOCKOUT\n"
"* TPM2_RH_PLATFORM\n"
-"pcr_extend \n"
-"Extend PCR # with digest at .\n"
+"pcr_extend []\n"
+"Extend PCR # with digest at with digest_algo.\n"
": index of the PCR\n"
-": address of a 32-byte SHA256 digest\n"
-"pcr_read \n"
-"Read PCR # to memory address .\n"
+": address of digest of digest_algo type (defaults to
SHA256)\n"
+"pcr_read []\n"
+"Read PCR # to memory address with .\n"
": index of the PCR\n"
-": address to store the a 32-byte SHA256 digest\n"
+": address of digest of digest_algo type (defaults to
SHA256)\n"
"get_capability\n"
"Read and display entries indexed by /.\n"
"Values are 4 bytes long and are written at .\n"
diff --git a/include/tpm-v2.h b/include/tpm-v2.h
index 33dd103767c4..933882fc
Re: [PATCH] tpm-v2: allow algo name to be conigured for pcr_read and pcr_extend
On Thu, Mar 28, 2024 at 12:37 AM Ilias Apalodimas
wrote:
>
> Hi Tim,
>
> [...]
>
> >
> > +/**
> > + * tpm2_algo_len() - Return an algo value and length given a algorithm name
> > + *
> > + * @name: algorithm name
> > + * @rwlen: pointer to integer to populate with algorithm length if non-null
> > + * Return: algorithm value
> > + */
> > +int tpm2_algo_len(const char *name, int *rwlen);
> > +
> > +/**
> > + * tpm2_algo_len() - Return an algoithm name string
> > + *
> > + * @algo: algorithm value
> > + * Return: algorithm string
> > + */
> > +const char *tpm2_algo_name(int algo);
> > +
> > #endif /* __TPM_V2_H */
> > diff --git a/lib/tpm-v2.c b/lib/tpm-v2.c
> > index 68eaaa639f89..6a090ce5810c 100644
> > --- a/lib/tpm-v2.c
> > +++ b/lib/tpm-v2.c
> > @@ -1555,3 +1555,49 @@ u32 tpm2_enable_nvcommits(struct udevice *dev, uint
> > vendor_cmd,
> >
> > return 0;
> > }
> > +
> > +int tpm2_algo_len(const char *name, int *rwlen)
> > +{
> > + int algo = -EINVAL;
> > + int len = 0;
> > +
> > + if (!strcasecmp("sha1", name)) {
> > + algo = TPM2_ALG_SHA1;
> > + len = TPM2_SHA1_DIGEST_SIZE;
> > + } else if (!strcasecmp("sha256", name)) {
> > + algo = TPM2_ALG_SHA256;
> > + len = TPM2_SHA256_DIGEST_SIZE;
> > + } else if (!strcasecmp("sha384", name)) {
> > + algo = TPM2_ALG_SHA384;
> > + len = TPM2_SHA384_DIGEST_SIZE;
> > + } else if (!strcasecmp("sha512", name)) {
> > + algo = TPM2_ALG_SHA512;
> > + len = TPM2_SHA512_DIGEST_SIZE;
> > + } else if (!strcasecmp("sm3_256", name)) {
> > + algo = TPM2_ALG_SM3_256;
> > + len = TPM2_SM3_256_DIGEST_SIZE;
> > + }
> > +
> > + if (*rwlen)
> > + *rwlen = len;
> > +
> > + return algo;
> > +}
> > +
>
> We already have tpm2_algorithm_to_len(). Instead of defining a new
> function, can we convert strings to 'enum tpm2_algorithms'? We can
> then reuse the existing function.
>
Hi Ilias,
Thanks - I didn't see tpm2_algorithm_to_len. Yes, I can use it but I
still need to add a new function to turn the name into an algo. I also
didn't see tpm2_supported_algorithms; should I only support
name-to-algorithm and algorithm-to-name for that subset?
Best Regards,
Tim
> > +const char *tpm2_algo_name(int algo)
> > +{
> > + switch (algo) {
> > + case TPM2_ALG_SHA1:
> > + return "sha1";
> > + case TPM2_ALG_SHA256:
> > + return "sha256";
> > + case TPM2_ALG_SHA384:
> > + return "sha384";
> > + case TPM2_ALG_SHA512:
> > + return "sha512";
> > + case TPM2_ALG_SM3_256:
> > + return "sm3_256";
> > + }
> > +
> > + return "";
> > +}
> > --
> > 2.25.1
> >
>
> Thanks
> /Ilias
[PATCH] tpm-v2: allow algo name to be conigured for pcr_read and pcr_extend
For pcr_read and pcr_extend commands allow the digest algo to be
specified by an additional argument. If not specified it will default to
SHA256 for backwards compatibility.
A follow-on to this could be to extend all PCR banks with the detected
algo when the argument is 'auto'.
Signed-off-by: Tim Harvey
---
cmd/tpm-v2.c | 51 +++-
include/tpm-v2.h | 17
lib/tpm-v2.c | 46 +++
3 files changed, 100 insertions(+), 14 deletions(-)
diff --git a/cmd/tpm-v2.c b/cmd/tpm-v2.c
index 7e479b9dfe36..52d232c3ea7d 100644
--- a/cmd/tpm-v2.c
+++ b/cmd/tpm-v2.c
@@ -99,11 +99,20 @@ static int do_tpm2_pcr_extend(struct cmd_tbl *cmdtp, int
flag, int argc,
struct tpm_chip_priv *priv;
u32 index = simple_strtoul(argv[1], NULL, 0);
void *digest = map_sysmem(simple_strtoul(argv[2], NULL, 0), 0);
+ int algo_len = TPM2_SHA256_DIGEST_SIZE;
+ int algo = TPM2_ALG_SHA256;
int ret;
u32 rc;
- if (argc != 3)
+ if (argc < 3 || argc > 4)
return CMD_RET_USAGE;
+ if (argc == 4) {
+ algo = tpm2_algo_len(argv[3], _len);
+ if (algo < 0) {
+ printf("Error: invalid algo\n");
+ return CMD_RET_USAGE;
+ }
+ }
ret = get_tpm();
if (ret)
@@ -116,8 +125,12 @@ static int do_tpm2_pcr_extend(struct cmd_tbl *cmdtp, int
flag, int argc,
if (index >= priv->pcr_count)
return -EINVAL;
- rc = tpm2_pcr_extend(dev, index, TPM2_ALG_SHA256, digest,
-TPM2_DIGEST_LEN);
+ rc = tpm2_pcr_extend(dev, index, algo, digest, algo_len);
+ if (!rc) {
+ printf("PCR #%u extended with %d byte %s digest\n", index,
+ algo_len, tpm2_algo_name(algo));
+ print_byte_string(digest, algo_len);
+ }
unmap_sysmem(digest);
@@ -127,6 +140,8 @@ static int do_tpm2_pcr_extend(struct cmd_tbl *cmdtp, int
flag, int argc,
static int do_tpm_pcr_read(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
{
+ int algo_len = TPM2_SHA256_DIGEST_SIZE;
+ int algo = TPM2_ALG_SHA256;
struct udevice *dev;
struct tpm_chip_priv *priv;
u32 index, rc;
@@ -134,8 +149,15 @@ static int do_tpm_pcr_read(struct cmd_tbl *cmdtp, int
flag, int argc,
void *data;
int ret;
- if (argc != 3)
+ if (argc < 3 || argc > 4)
return CMD_RET_USAGE;
+ if (argc == 4) {
+ algo = tpm2_algo_len(argv[3], _len);
+ if (algo < 0) {
+ printf("Error: invalid algo\n");
+ return CMD_RET_USAGE;
+ }
+ }
ret = get_tpm();
if (ret)
@@ -151,11 +173,12 @@ static int do_tpm_pcr_read(struct cmd_tbl *cmdtp, int
flag, int argc,
data = map_sysmem(simple_strtoul(argv[2], NULL, 0), 0);
- rc = tpm2_pcr_read(dev, index, priv->pcr_select_min, TPM2_ALG_SHA256,
- data, TPM2_DIGEST_LEN, );
+ rc = tpm2_pcr_read(dev, index, priv->pcr_select_min, algo,
+ data, algo_len, );
if (!rc) {
- printf("PCR #%u content (%u known updates):\n", index, updates);
- print_byte_string(data, TPM2_DIGEST_LEN);
+ printf("PCR #%u %s %d byte content (%u known updates):\n",
index,
+ tpm2_algo_name(algo), algo_len, updates);
+ print_byte_string(data, algo_len);
}
unmap_sysmem(data);
@@ -415,14 +438,14 @@ U_BOOT_CMD(tpm2, CONFIG_SYS_MAXARGS, 1, do_tpm, "Issue a
TPMv2.x command",
" is one of:\n"
"* TPM2_RH_LOCKOUT\n"
"* TPM2_RH_PLATFORM\n"
-"pcr_extend \n"
-"Extend PCR # with digest at .\n"
+"pcr_extend []\n"
+"Extend PCR # with digest at with digest_algo.\n"
": index of the PCR\n"
-": address of a 32-byte SHA256 digest\n"
-"pcr_read \n"
-"Read PCR # to memory address .\n"
+": address of digest of digest_algo type (defaults to
SHA256)\n"
+"pcr_read []\n"
+"Read PCR # to memory address with .\n"
": index of the PCR\n"
-": address to store the a 32-byte SHA256 digest\n"
+": address of digest of digest_algo type (defaults to
SHA256)\n"
"get_capability\n"
"Read and display entries indexed by /.\n"
"Values are 4 bytes long and are written at .\n"
diff --git a/include/tpm-v2.h b/include/tpm-v2.h
index 33dd103767c4..07d3ca5e6c83 100644
--- a/include/tpm-v2.h
+++ b/inclu
[PATCH v2] tpm: display warning if using gpio reset with TPM
Instead of displaying what looks like an error message if a
gpio-reset dt prop is missing for a TPM display a warning that
having a gpio reset on a TPM should not be used for a secure production
device.
TCG TIS spec [1] says:
"The TPM_Init (LRESET#/SPI_RST#) signal MUST be connected to the
platform CPU Reset signal such that it complies with the requirements
specified in section 1.2.7 HOST Platform Reset in the PC Client
Implementation Specification for Conventional BIOS."
The reasoning is that you should not be able to toggle a GPIO and reset
the TPM without resetting the CPU as well because if an attacker can
break into your OS via an OS level security flaw they can then reset the
TPM via GPIO and replay the measurements required to unseal keys
that you have otherwise protected.
[1]
https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientTPMInterfaceSpecification_TIS__1-3_27_03212013.pdf
Signed-off-by: Tim Harvey
---
v2: change the message to a warning and update commit desc/log
---
drivers/tpm/tpm2_tis_spi.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/tpm/tpm2_tis_spi.c b/drivers/tpm/tpm2_tis_spi.c
index de9cf8f21e07..c9c83f6f0fc8 100644
--- a/drivers/tpm/tpm2_tis_spi.c
+++ b/drivers/tpm/tpm2_tis_spi.c
@@ -237,14 +237,14 @@ static int tpm_tis_spi_probe(struct udevice *dev)
/* legacy reset */
ret = gpio_request_by_name(dev, "gpio-reset", 0,
_gpio, GPIOD_IS_OUT);
- if (ret) {
- log(LOGC_NONE, LOGL_NOTICE,
- "%s: missing reset GPIO\n", __func__);
+ if (ret)
goto init;
- }
log(LOGC_NONE, LOGL_NOTICE,
"%s: gpio-reset is deprecated\n", __func__);
}
+ log(LOGC_NONE, LOGL_WARNING,
+ "%s: TPM gpio reset should not be used on secure production
devices\n",
+ dev->name);
dm_gpio_set_value(_gpio, 1);
mdelay(1);
dm_gpio_set_value(_gpio, 0);
--
2.25.1
Re: tcg2_platform_get_log failing to read address and size of memory-region via ofnode_get_addr_size
On Wed, Mar 27, 2024 at 10:06 AM Ilias Apalodimas
wrote:
>
> On Wed, 27 Mar 2024 at 18:32, Tim Harvey wrote:
> >
> > On Wed, Mar 27, 2024 at 8:46 AM Ilias Apalodimas
> > wrote:
> > >
> > > Hi both,
> > >
> > > On Wed, 27 Mar 2024 at 17:22, Eddie James wrote:
> > > >
> > > >
> > > > On 3/26/24 11:15, Tim Harvey wrote:
> > > > > On Tue, Mar 26, 2024 at 2:24 AM Ilias Apalodimas
> > > > > wrote:
> > > > >> Hi Tim,
> > > > >>
> > > > >> On Tue, 26 Mar 2024 at 03:15, Tim Harvey
> > > > >> wrote:
> > > > >>> Greetings,
> > > > >>>
> > > > >>> I'm unable to understand why tcg2_platform_get_log is failing to
> > > > >>> read
> > > > >>> a memory region.
> > > > >>>
> > > > >>> For example the following diffs:
> > > > >> I am not really sure what those nodes are supposed to do in sandbox.
> > > > >> Pehaps Eddie remembers.
> > > > >> What exactly are you trying to achieve here? Read the eventlog from
> > > > >> TF-A?
> > > > >>
> > > > > Hi Ilias,
> > > > >
> > > > > I was trying to get measured boot (CONFIG_MEASURED_BOOT=y) working on
> > > > > a tpm on my board but ran into an issue when I couldn't get the
> > > > > memory-region I added for testing to be recognized with the current
> > > > > code in tcg2_platform_get_log().
> > > > >
> > > > > I wonder if an event log should be required for measured boot - it
> > > > > sounds like that was something required for EFI, so I was thinking of
> > > > > submitting the following:
> > > > > commit b3f336c2f863168219a93cd1c7ac922396e0fad5 (HEAD ->
> > > > > master-venice)
> > > > > Author: Tim Harvey
> > > > > Date: Tue Mar 26 08:49:07 2024 -0700
> > > > >
> > > > > tpm: allow measured boot without an event log
> > > > >
> > > > > Currently an event log is required for measured boot. Remove this
> > > > > requirement.
> > > > >
> > > > > Signed-off-by: Tim Harvey
> > > > >
> > > > > diff --git a/lib/tpm-v2.c b/lib/tpm-v2.c
> > > > > index 68eaaa639f89..994f8089ba34 100644
> > > > > --- a/lib/tpm-v2.c
> > > > > +++ b/lib/tpm-v2.c
> > > > > @@ -175,17 +175,19 @@ static int tcg2_log_append_check(struct
> > > > > tcg2_event_log *elog, u32 pcr_index,
> > > > > u32 event_size;
> > > > > u8 *log;
> > > > >
> > > > > - event_size = size + tcg2_event_get_size(digest_list);
> > > > > - if (elog->log_position + event_size > elog->log_size) {
> > > > > - printf("%s: log too large: %u + %u > %u\n", __func__,
> > > > > - elog->log_position, event_size,
> > > > > elog->log_size);
> > > > > - return -ENOBUFS;
> > > > > - }
> > > > > + if (elog->log_size) {
> > > > > + event_size = size + tcg2_event_get_size(digest_list);
> > > > > + if (elog->log_position + event_size > elog->log_size)
> > > > > {
> > > > > + printf("%s: log too large: %u + %u > %u\n",
> > > > > __func__,
> > > > > + elog->log_position, event_size,
> > > > > elog->log_size);
> > > > > + return -ENOBUFS;
> > > > > + }
> > > > >
> > > > > - log = elog->log + elog->log_position;
> > > > > - elog->log_position += event_size;
> > > > > + log = elog->log + elog->log_position;
> > > > > + elog->log_position += event_size;
> > > > >
> > > > > - tcg2_log_append(pcr_index, event_type, digest_list, size,
> > > > > event, log);
> > > > > + tcg2_log_append(pcr_index, event_type, digest_list,
> > > > > size, event, log);
> > > > > + }
> > > >
Re: [PATCH] tpm: display message when using gpio-reset instead of when missing it
On Wed, Mar 27, 2024 at 10:26 AM Ilias Apalodimas
wrote:
>
> [...]
>
> > >
> > > missing an invalid property?
> > >
> > > I deal with users all the time that think things like that are
> > > 'errors' and contact tech support. In this case its not an error
> > > because there is no gpio reset in the official dt-bindings for the tpm
> > > and its generally considered bad form to add non official properties.
> > >
> > > And from what your explaining we shouldn't have a GPIO connected to
> > > the TPM so perhaps we should remove the reset completely and perhaps
> > > even spit out a warning if present:
> > > ignore Invalid DT property gpio reset to conform with the TCG
> > > specification
> >
> > We should, but those changes predate me being appointed as a TPM
> > maintainer. If I had to guess, I would say that was added for TPM that
> > are connected on an external SPI bus (e.g the RPI).
> > So what about not printing the error message, keeping the code so we
> > won't break 'test' devices, and print a warning message like "This
> > shouldn't be used on secure production devices"?
>
> Unless we can get a list of the devices that *currently* use it. If
> they aren't that many I am fine getting rid of the reset overall (and
> I can test it on the RPI4)
>
Adding Miquel who authored commit a174f0001f592 ("tpm2: tis_spi: add
the possibility to reset the chip with a gpio"):
On some designs, the reset line could not be connected to the SoC reset
line, in this case, request the GPIO and ensure the chip gets reset.
Adding Jorge who athoried commit cc5afabc9d329 ("drivers: tpm2: update
reset gpio semantics"):
Use the more generic reset-gpios property name.
I looked through all dts in U-Boot matching 'tpm' as well as Linux to
see who's using it:
Adding Adam who has a 'reset-gpios' in
arch/arm/dts/imx8mp-beacon-kit.dts (and somehow snuck it in upstream
as well)
Adding Rasmus who has a suspicious 'regulatot-tpm0-rst' (but no gpio
reset in tpm) in arch/arm/dts/imx8mm-cl-iot-gate-ied-tpm0.dtso
As there is at least one board that clearly uses a gpio reset for the
TPM in the tpm node I think we leave the tpm reset support, eliminate
the warning if its missing and print a message like "Warning: TPM gpio
reset should not be used on secure production device"
I'll send a v2 of my patch for review
Best Regards,
Tim
[1]
https://patchwork.ozlabs.org/project/uboot/patch/20240321180219.1039622-1-thar...@gateworks.com/
> Cheers
> /Ilias
> >
> > Regards
> > /Ilias
> > >
> > > Best regards,
> > >
> > > Tim
> > >
> > > >
> > > > Thanks
> > > > /Ilias
> > > > >
> > > > > Best Regards,
> > > > >
> > > > > Tim
> > > > > [1]
> > > > > https://ww1.microchip.com/downloads/en/DeviceDoc/ATTPM20P-Trusted-Platform-Module-TPM-2.0-SPI-Interface-Summary-Data-Sheet-DS40002082A.pdf
> > > > >
> > > > >
> > > > > > Thanks
> > > > > > /Ilias
> > > > > > >
> > > > > > > Signed-off-by: Tim Harvey
> > > > > > > ---
> > > > > > > drivers/tpm/tpm2_tis_spi.c | 8
> > > > > > > 1 file changed, 4 insertions(+), 4 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/tpm/tpm2_tis_spi.c
> > > > > > > b/drivers/tpm/tpm2_tis_spi.c
> > > > > > > index de9cf8f21e07..944540f7a711 100644
> > > > > > > --- a/drivers/tpm/tpm2_tis_spi.c
> > > > > > > +++ b/drivers/tpm/tpm2_tis_spi.c
> > > > > > > @@ -237,14 +237,14 @@ static int tpm_tis_spi_probe(struct udevice
> > > > > > > *dev)
> > > > > > > /* legacy reset */
> > > > > > > ret = gpio_request_by_name(dev,
> > > > > > > "gpio-reset", 0,
> > > > > > >_gpio,
> > > > > > > GPIOD_IS_OUT);
> > > > > > > - if (ret) {
> > > > > > > - log(LOGC_NONE, LOGL_NOTICE,
> > > > > > > - "%s: missing reset GPIO\n",
> > > > > > > __func__);
> > > > > > > + if (ret)
> > > > > > > goto init;
> > > > > > > - }
> > > > > > > log(LOGC_NONE, LOGL_NOTICE,
> > > > > > > "%s: gpio-reset is deprecated\n",
> > > > > > > __func__);
> > > > > > > }
> > > > > > > + log(LOGC_NONE, LOGL_NOTICE,
> > > > > > > + "%s: performing 1ms reset on %s:%d\n",
> > > > > > > dev->name,
> > > > > > > + reset_gpio.dev->name, reset_gpio.offset);
> > > > > > > dm_gpio_set_value(_gpio, 1);
> > > > > > > mdelay(1);
> > > > > > > dm_gpio_set_value(_gpio, 0);
> > > > > > > --
> > > > > > > 2.25.1
> > > > > > >
Re: [PATCH] tpm: display message when using gpio-reset instead of when missing it
On Wed, Mar 27, 2024 at 9:16 AM Ilias Apalodimas wrote: > > Hi Tim, > > On Wed, 27 Mar 2024 at 17:29, Tim Harvey wrote: > > > > On Wed, Mar 27, 2024 at 7:44 AM Ilias Apalodimas > > wrote: > > > > > > Hi Tim, > > > > > > On Thu, 21 Mar 2024 at 20:02, Tim Harvey wrote: > > > > > > > > Instead of displaying what looks like an error message if a > > > > gpio-reset dt prop is missing for a TPM dipslay a more > > > > informative message about resetting the TPM if the gpio is found: > > > > > > > > before: > > > > tpm_tis_spi_probe: missing reset GPIO > > > > > > > > after: > > > > tpm@0: performing 1ms reset on gpio@3021:12 > > > > > > > > Note that the reset dt binding prop used in this driver is not > > > > dt-compliant; it does not exist in the Linux dt-bindings documentation > > > > and the reset is not done by the Linux driver. > > > > > > Probably for a good reason. You aren't supposed to be able to reset a > > > TPM without resetting the CPUI as well no? > > > > Hi Ilias, > > > > Could you clarify what you know about TPM reset? We use the ATTPM20P > > [1] which states in the datasheet under the reset pin: "To be > > compliant with TCG requirements, this pin needs to be tied to system > > reset. TPM_Init is indicated by asserting this pin." > > In short, you shouldn't be able to toggle a GPIO and reset the TPM > without resetting the CPU as well. > An attacker could boot -> log into the OS -> reset the TPM -> replay > measurements and unseal keys that he shouldn't. I suppose that makes sense. So consider someone gets into your OS and also has access to your board and electrically isolates the TPM reset from POR# (cut the trace) then with a probe resets the TPM? At least in that case they have to have physical presence as well so we should connect TPM RST# to POR# to not make it easier on them. I'm always wanting to allow GPIO access to various chip resets to deal with issues discovered down the line that require a full chip level reset - probably not the right thing to do in the case of a security device! Thanks for explaining. I'm still learning about the TPM capabilities. If using the TPM to store a key that is used for FDE you can use 'tpm2_unseal -c $OBJECT -p pcr:sha1:0,1 -o fs.key' to get your key. There must be a concept of re-sealing this object so that it can only be unsealed again with a power cycle or something? > > > > > Our boards have a resistor loading option which routes the TPM RST# to > > an SoC GPIO or alternately to a POR# (hardware power on reset provided > > by power supply and/or PMIC). Could you point me to where in the spec > > it explains what the TPM reset should be connected to? > > I am aware of the the TCG TIS spec [0] which says > "The TPM_Init (LRESET#/SPI_RST#) signal MUST be connected to the platform CPU > Reset signal such that it complies with the requirements specified in > section 1.2.7 HOST > Platform Reset in the PC Client Implementation Specification for > Conventional BIOS." > There might be other TCG specs defining this as well. > > [0] > https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientTPMInterfaceSpecification_TIS__1-3_27_03212013.pdf > Thanks! > > > > > That being said, printing that the TPM was reset is pointless imho. > > > OTOH the existing error message at least points out a potential > > > problem in the DT. > > > > > > > I'm not sure if you are NAK'ing this patch or asking me to change it. > > > > Displaying a 'missing GPIO' message is not helpful when there is no > > GPIO in the dt bindings to begin with. > > I am not NAKing it. But isn't that message more useful than printing > the TPM did a reset? At least you get a hint of something that's > missing from your DT missing an invalid property? I deal with users all the time that think things like that are 'errors' and contact tech support. In this case its not an error because there is no gpio reset in the official dt-bindings for the tpm and its generally considered bad form to add non official properties. And from what your explaining we shouldn't have a GPIO connected to the TPM so perhaps we should remove the reset completely and perhaps even spit out a warning if present: ignore Invalid DT property gpio reset to conform with the TCG specificaiton Best regards, Tim > > Thanks > /Ilias > > > > Best Regards, > > > > Tim > > [1] > > https://ww1.microchip.com/downloads/en/DeviceDoc/ATTPM20P-Trusted-Platform-Module-
Re: tcg2_platform_get_log failing to read address and size of memory-region via ofnode_get_addr_size
On Wed, Mar 27, 2024 at 8:46 AM Ilias Apalodimas
wrote:
>
> Hi both,
>
> On Wed, 27 Mar 2024 at 17:22, Eddie James wrote:
> >
> >
> > On 3/26/24 11:15, Tim Harvey wrote:
> > > On Tue, Mar 26, 2024 at 2:24 AM Ilias Apalodimas
> > > wrote:
> > >> Hi Tim,
> > >>
> > >> On Tue, 26 Mar 2024 at 03:15, Tim Harvey wrote:
> > >>> Greetings,
> > >>>
> > >>> I'm unable to understand why tcg2_platform_get_log is failing to read
> > >>> a memory region.
> > >>>
> > >>> For example the following diffs:
> > >> I am not really sure what those nodes are supposed to do in sandbox.
> > >> Pehaps Eddie remembers.
> > >> What exactly are you trying to achieve here? Read the eventlog from TF-A?
> > >>
> > > Hi Ilias,
> > >
> > > I was trying to get measured boot (CONFIG_MEASURED_BOOT=y) working on
> > > a tpm on my board but ran into an issue when I couldn't get the
> > > memory-region I added for testing to be recognized with the current
> > > code in tcg2_platform_get_log().
> > >
> > > I wonder if an event log should be required for measured boot - it
> > > sounds like that was something required for EFI, so I was thinking of
> > > submitting the following:
> > > commit b3f336c2f863168219a93cd1c7ac922396e0fad5 (HEAD -> master-venice)
> > > Author: Tim Harvey
> > > Date: Tue Mar 26 08:49:07 2024 -0700
> > >
> > > tpm: allow measured boot without an event log
> > >
> > > Currently an event log is required for measured boot. Remove this
> > > requirement.
> > >
> > > Signed-off-by: Tim Harvey
> > >
> > > diff --git a/lib/tpm-v2.c b/lib/tpm-v2.c
> > > index 68eaaa639f89..994f8089ba34 100644
> > > --- a/lib/tpm-v2.c
> > > +++ b/lib/tpm-v2.c
> > > @@ -175,17 +175,19 @@ static int tcg2_log_append_check(struct
> > > tcg2_event_log *elog, u32 pcr_index,
> > > u32 event_size;
> > > u8 *log;
> > >
> > > - event_size = size + tcg2_event_get_size(digest_list);
> > > - if (elog->log_position + event_size > elog->log_size) {
> > > - printf("%s: log too large: %u + %u > %u\n", __func__,
> > > - elog->log_position, event_size, elog->log_size);
> > > - return -ENOBUFS;
> > > - }
> > > + if (elog->log_size) {
> > > + event_size = size + tcg2_event_get_size(digest_list);
> > > + if (elog->log_position + event_size > elog->log_size) {
> > > + printf("%s: log too large: %u + %u > %u\n",
> > > __func__,
> > > + elog->log_position, event_size,
> > > elog->log_size);
> > > + return -ENOBUFS;
> > > + }
> > >
> > > - log = elog->log + elog->log_position;
> > > - elog->log_position += event_size;
> > > + log = elog->log + elog->log_position;
> > > + elog->log_position += event_size;
> > >
> > > - tcg2_log_append(pcr_index, event_type, digest_list, size, event,
> > > log);
> > > + tcg2_log_append(pcr_index, event_type, digest_list,
> > > size, event, log);
> > > + }
> > >
> > > return 0;
> > > }
> > > @@ -613,10 +615,8 @@ int tcg2_measurement_init(struct udevice **dev,
> > > struct tcg2_event_log *elog,
> > > return rc;
> > >
> > > rc = tcg2_log_prepare_buffer(*dev, elog, ignore_existing_log);
> > > - if (rc) {
> > > + if (rc)
> > > tcg2_measurement_term(*dev, elog, true);
> > > - return rc;
> > > - }
> > >
> > > rc = tcg2_measure_event(*dev, elog, 0, EV_S_CRTM_VERSION,
> > > strlen(version_string) + 1,
> > >
> > > Would you agree with removing the requirement for the event log?
> >
> >
> > No, the log is required, otherwise it's fairly meaningless work. You
> > need the log in your OS to verify the contents of the TPM.
>
> It's the other way around. You trust the TPM and replay the event log
> in memory to verify it's correct.
> That bei
Re: [PATCH] tpm: display message when using gpio-reset instead of when missing it
On Wed, Mar 27, 2024 at 7:44 AM Ilias Apalodimas
wrote:
>
> Hi Tim,
>
> On Thu, 21 Mar 2024 at 20:02, Tim Harvey wrote:
> >
> > Instead of displaying what looks like an error message if a
> > gpio-reset dt prop is missing for a TPM dipslay a more
> > informative message about resetting the TPM if the gpio is found:
> >
> > before:
> > tpm_tis_spi_probe: missing reset GPIO
> >
> > after:
> > tpm@0: performing 1ms reset on gpio@3021:12
> >
> > Note that the reset dt binding prop used in this driver is not
> > dt-compliant; it does not exist in the Linux dt-bindings documentation
> > and the reset is not done by the Linux driver.
>
> Probably for a good reason. You aren't supposed to be able to reset a
> TPM without resetting the CPUI as well no?
Hi Ilias,
Could you clarify what you know about TPM reset? We use the ATTPM20P
[1] which states in the datasheet under the reset pin: "To be
compliant with TCG requirements, this pin needs to be tied to system
reset. TPM_Init is indicated by asserting this pin."
Our boards have a resistor loading option which routes the TPM RST# to
an SoC GPIO or alternately to a POR# (hardware power on reset provided
by power supply and/or PMIC). Could you point me to where in the spec
it explains what the TPM reset should be connected to?
> That being said, printing that the TPM was reset is pointless imho.
> OTOH the existing error message at least points out a potential
> problem in the DT.
>
I'm not sure if you are NAK'ing this patch or asking me to change it.
Displaying a 'missing GPIO' message is not helpful when there is no
GPIO in the dt bindings to begin with.
Best Regards,
Tim
[1]
https://ww1.microchip.com/downloads/en/DeviceDoc/ATTPM20P-Trusted-Platform-Module-TPM-2.0-SPI-Interface-Summary-Data-Sheet-DS40002082A.pdf
> Thanks
> /Ilias
> >
> > Signed-off-by: Tim Harvey
> > ---
> > drivers/tpm/tpm2_tis_spi.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/tpm/tpm2_tis_spi.c b/drivers/tpm/tpm2_tis_spi.c
> > index de9cf8f21e07..944540f7a711 100644
> > --- a/drivers/tpm/tpm2_tis_spi.c
> > +++ b/drivers/tpm/tpm2_tis_spi.c
> > @@ -237,14 +237,14 @@ static int tpm_tis_spi_probe(struct udevice *dev)
> > /* legacy reset */
> > ret = gpio_request_by_name(dev, "gpio-reset", 0,
> >_gpio,
> > GPIOD_IS_OUT);
> > - if (ret) {
> > - log(LOGC_NONE, LOGL_NOTICE,
> > - "%s: missing reset GPIO\n", __func__);
> > + if (ret)
> > goto init;
> > - }
> > log(LOGC_NONE, LOGL_NOTICE,
> > "%s: gpio-reset is deprecated\n", __func__);
> > }
> > + log(LOGC_NONE, LOGL_NOTICE,
> > + "%s: performing 1ms reset on %s:%d\n", dev->name,
> > + reset_gpio.dev->name, reset_gpio.offset);
> > dm_gpio_set_value(_gpio, 1);
> > mdelay(1);
> > dm_gpio_set_value(_gpio, 0);
> > --
> > 2.25.1
> >
Re: tcg2_platform_get_log failing to read address and size of memory-region via ofnode_get_addr_size
On Tue, Mar 26, 2024 at 2:24 AM Ilias Apalodimas
wrote:
>
> Hi Tim,
>
> On Tue, 26 Mar 2024 at 03:15, Tim Harvey wrote:
> >
> > Greetings,
> >
> > I'm unable to understand why tcg2_platform_get_log is failing to read
> > a memory region.
> >
> > For example the following diffs:
>
> I am not really sure what those nodes are supposed to do in sandbox.
> Pehaps Eddie remembers.
> What exactly are you trying to achieve here? Read the eventlog from TF-A?
>
Hi Ilias,
I was trying to get measured boot (CONFIG_MEASURED_BOOT=y) working on
a tpm on my board but ran into an issue when I couldn't get the
memory-region I added for testing to be recognized with the current
code in tcg2_platform_get_log().
I wonder if an event log should be required for measured boot - it
sounds like that was something required for EFI, so I was thinking of
submitting the following:
commit b3f336c2f863168219a93cd1c7ac922396e0fad5 (HEAD -> master-venice)
Author: Tim Harvey
Date: Tue Mar 26 08:49:07 2024 -0700
tpm: allow measured boot without an event log
Currently an event log is required for measured boot. Remove this
requirement.
Signed-off-by: Tim Harvey
diff --git a/lib/tpm-v2.c b/lib/tpm-v2.c
index 68eaaa639f89..994f8089ba34 100644
--- a/lib/tpm-v2.c
+++ b/lib/tpm-v2.c
@@ -175,17 +175,19 @@ static int tcg2_log_append_check(struct
tcg2_event_log *elog, u32 pcr_index,
u32 event_size;
u8 *log;
- event_size = size + tcg2_event_get_size(digest_list);
- if (elog->log_position + event_size > elog->log_size) {
- printf("%s: log too large: %u + %u > %u\n", __func__,
- elog->log_position, event_size, elog->log_size);
- return -ENOBUFS;
- }
+ if (elog->log_size) {
+ event_size = size + tcg2_event_get_size(digest_list);
+ if (elog->log_position + event_size > elog->log_size) {
+ printf("%s: log too large: %u + %u > %u\n", __func__,
+ elog->log_position, event_size, elog->log_size);
+ return -ENOBUFS;
+ }
- log = elog->log + elog->log_position;
- elog->log_position += event_size;
+ log = elog->log + elog->log_position;
+ elog->log_position += event_size;
- tcg2_log_append(pcr_index, event_type, digest_list, size, event, log);
+ tcg2_log_append(pcr_index, event_type, digest_list,
size, event, log);
+ }
return 0;
}
@@ -613,10 +615,8 @@ int tcg2_measurement_init(struct udevice **dev,
struct tcg2_event_log *elog,
return rc;
rc = tcg2_log_prepare_buffer(*dev, elog, ignore_existing_log);
- if (rc) {
+ if (rc)
tcg2_measurement_term(*dev, elog, true);
- return rc;
- }
rc = tcg2_measure_event(*dev, elog, 0, EV_S_CRTM_VERSION,
strlen(version_string) + 1,
Would you agree with removing the requirement for the event log?
I have another question that perhaps you may have some feedback on.
The tpm commands such as pcr_extend, pcr_read currently require a
32-byte SHA256 digest and I wish to extend that as my TPM supports
only SHA1. The tpm2_pcr_extend and tpm2_pcr_read functions were
extended to function to allow the digest type and length to be passed
in and I'm wondering what the best way to extend the tpm extend/read
commands would be to support that.
The tcg2_create_digest function creates a digest based on the
capabilities of the tpm and the tcg2_pcr_extend loops over those
calling tpm2_pcr_extend for each digtest supported (and same for
tcg2_pcr_read looping over tpm2_pcr_read) and I'm assuming TPM's can
support multiple algos so I suppose a parameter needs to be added to
the pcr_read and pcr_extend commands. Would you agree with that?
Best Regards,
Tim
> Thanks
> /Ilias
> >
> > diff --git a/arch/arm/dts/imx8mm-venice-gw73xx.dtsi
> > b/arch/arm/dts/imx8mm-venice-gw73xx.dtsi
> > index 7b2130dbdb21..57b3c227ceaf 100644
> > --- a/arch/arm/dts/imx8mm-venice-gw73xx.dtsi
> > +++ b/arch/arm/dts/imx8mm-venice-gw73xx.dtsi
> > @@ -112,6 +112,7 @@
> > compatible = "tcg,tpm_tis-spi";
> > reg = <0x1>;
> > spi-max-frequency = <3600>;
> > + memory-region = <_log>;
> > };
> > };
> > diff --git a/arch/arm/dts/imx8mm-venice-gw700x.dtsi
> > b/arch/arm/dts/imx8mm-venice-gw700x.dtsi
> > index c305e325d007..697fd1148785 100644
> > --- a/arch/arm/dts/imx8mm-venice-gw700x.dtsi
> > +++ b/arch/arm/dts/imx8mm-venice-gw700x.dtsi
> > @@ -13,6 +13,17 @@
> > reg = <0x
tcg2_platform_get_log failing to read address and size of memory-region via ofnode_get_addr_size
Greetings,
I'm unable to understand why tcg2_platform_get_log is failing to read
a memory region.
For example the following diffs:
diff --git a/arch/arm/dts/imx8mm-venice-gw73xx.dtsi
b/arch/arm/dts/imx8mm-venice-gw73xx.dtsi
index 7b2130dbdb21..57b3c227ceaf 100644
--- a/arch/arm/dts/imx8mm-venice-gw73xx.dtsi
+++ b/arch/arm/dts/imx8mm-venice-gw73xx.dtsi
@@ -112,6 +112,7 @@
compatible = "tcg,tpm_tis-spi";
reg = <0x1>;
spi-max-frequency = <3600>;
+ memory-region = <_log>;
};
};
diff --git a/arch/arm/dts/imx8mm-venice-gw700x.dtsi
b/arch/arm/dts/imx8mm-venice-gw700x.dtsi
index c305e325d007..697fd1148785 100644
--- a/arch/arm/dts/imx8mm-venice-gw700x.dtsi
+++ b/arch/arm/dts/imx8mm-venice-gw700x.dtsi
@@ -13,6 +13,17 @@
reg = <0x0 0x4000 0 0x8000>;
};
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ event_log: tcg_event_log {
+ no-map;
+ reg = <0 0x4000 0x2000>;
+ };
+ };
+
gpio-keys {
compatible = "gpio-keys";
And at runtime:
u-boot=> fdt addr $fdtcontroladdr
u-boot=> fdt list /soc@0/bus@3080/spba-bus@3080/spi@3083/tpm@1/
tpm@1 {
compatible = "tcg,tpm_tis-spi";
reg = <0x0001>;
spi-max-frequency = <0x02255100>;
memory-region = <0x0025>;
};
u-boot=> fdt list /reserved-memory/
reserved-memory {
#address-cells = <0x0002>;
#size-cells = <0x0002>;
ranges;
tcg_event_log {
};
};
u-boot=> fdt list /reserved-memory/tcg_event_log
tcg_event_log {
no-map;
reg = <0x 0x4000 0x2000>;
phandle = <0x0025>;
};
So why does the following code in tcg2_platform_get_log() return -ENOMEM?
if (dev_read_phandle_with_args(dev, "memory-region", NULL, 0,
0, ))
return -ENODEV;
a = ofnode_get_addr_size(args.node, "reg", );
if (a == FDT_ADDR_T_NONE)
return -ENOMEM;
debugging shows that dev_read_phandle_with_args returns non-zero but
args.args_count is 0.
I feel like the construct of using dev_read_phandle_with_args followed
by the ofnode_get_addr_size is just wrong but I don't understand why
nor do I understand how my dt changes differ from what is in
arch/sandbox/dts/test.dts (other than its using address-size=1 which
doesn't appear to be the issue in my testing). The abstraction of the
ofnode and fdt stuff always trip me up... very confusing.
Can anyone explain the issue here?
Best Regards,
Tim
[PATCH] imx8m*-venice: enable TPM support
Enable support for TPM2 devices. As the ATTPM20P TPM2 used on the Gateworks Venice boards hangs off the SPI bus we enable SPI support as well. Signed-off-by: Tim Harvey --- configs/imx8mm_venice_defconfig | 10 ++ configs/imx8mn_venice_defconfig | 10 ++ configs/imx8mp_venice_defconfig | 10 ++ 3 files changed, 30 insertions(+) diff --git a/configs/imx8mm_venice_defconfig b/configs/imx8mm_venice_defconfig index cb6b97d097c1..86928687df2d 100644 --- a/configs/imx8mm_venice_defconfig +++ b/configs/imx8mm_venice_defconfig @@ -68,6 +68,7 @@ CONFIG_CMD_TIME=y CONFIG_CMD_UUID=y CONFIG_CMD_PMIC=y CONFIG_CMD_REGULATOR=y +CONFIG_CMD_TPM=y CONFIG_CMD_EXT4_WRITE=y # CONFIG_ISO_PARTITION is not set # CONFIG_SPL_EFI_PARTITION is not set @@ -127,14 +128,20 @@ CONFIG_SPL_DM_PMIC_MP5416=y CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_FIXED=y CONFIG_DM_REGULATOR_GPIO=y +# CONFIG_DM_RNG is not set CONFIG_DM_SERIAL=y CONFIG_MXC_UART=y +CONFIG_SPI=y +CONFIG_DM_SPI=y +CONFIG_MXC_SPI=y CONFIG_SYSRESET=y CONFIG_SPL_SYSRESET=y CONFIG_SYSRESET_PSCI=y CONFIG_SYSRESET_WATCHDOG=y CONFIG_DM_THERMAL=y CONFIG_IMX_TMU=y +# CONFIG_TPM_V1 is not set +CONFIG_TPM2_TIS_SPI=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_HOST_ETHER=y @@ -152,4 +159,7 @@ CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 CONFIG_CI_UDC=y CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_IMX_WATCHDOG=y +CONFIG_TPM=y +# CONFIG_SPL_SHA512 is not set +# CONFIG_SPL_SHA384 is not set CONFIG_HEXDUMP=y diff --git a/configs/imx8mn_venice_defconfig b/configs/imx8mn_venice_defconfig index 0a4fba5f1ca8..6bb0f015a9bf 100644 --- a/configs/imx8mn_venice_defconfig +++ b/configs/imx8mn_venice_defconfig @@ -71,6 +71,7 @@ CONFIG_CMD_TIME=y CONFIG_CMD_UUID=y CONFIG_CMD_PMIC=y CONFIG_CMD_REGULATOR=y +CONFIG_CMD_TPM=y CONFIG_CMD_EXT4_WRITE=y # CONFIG_ISO_PARTITION is not set # CONFIG_SPL_EFI_PARTITION is not set @@ -128,14 +129,20 @@ CONFIG_SPL_DM_PMIC_MP5416=y CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_FIXED=y CONFIG_DM_REGULATOR_GPIO=y +# CONFIG_DM_RNG is not set CONFIG_DM_SERIAL=y CONFIG_MXC_UART=y +CONFIG_SPI=y +CONFIG_DM_SPI=y +CONFIG_MXC_SPI=y CONFIG_SYSRESET=y CONFIG_SPL_SYSRESET=y CONFIG_SYSRESET_PSCI=y CONFIG_SYSRESET_WATCHDOG=y CONFIG_DM_THERMAL=y CONFIG_IMX_TMU=y +# CONFIG_TPM_V1 is not set +CONFIG_TPM2_TIS_SPI=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_HOST_ETHER=y @@ -153,4 +160,7 @@ CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 CONFIG_CI_UDC=y CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_IMX_WATCHDOG=y +CONFIG_TPM=y +# CONFIG_SPL_SHA512 is not set +# CONFIG_SPL_SHA384 is not set CONFIG_HEXDUMP=y diff --git a/configs/imx8mp_venice_defconfig b/configs/imx8mp_venice_defconfig index 6e4addc7728f..b1055ef2f066 100644 --- a/configs/imx8mp_venice_defconfig +++ b/configs/imx8mp_venice_defconfig @@ -73,6 +73,7 @@ CONFIG_CMD_TIME=y CONFIG_CMD_UUID=y CONFIG_CMD_PMIC=y CONFIG_CMD_REGULATOR=y +CONFIG_CMD_TPM=y CONFIG_CMD_EXT4_WRITE=y # CONFIG_ISO_PARTITION is not set # CONFIG_SPL_EFI_PARTITION is not set @@ -135,14 +136,20 @@ CONFIG_SPL_DM_PMIC_MP5416=y CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_FIXED=y CONFIG_DM_REGULATOR_GPIO=y +# CONFIG_DM_RNG is not set CONFIG_DM_SERIAL=y CONFIG_MXC_UART=y +CONFIG_SPI=y +CONFIG_DM_SPI=y +CONFIG_MXC_SPI=y CONFIG_SYSRESET=y CONFIG_SPL_SYSRESET=y CONFIG_SYSRESET_PSCI=y CONFIG_SYSRESET_WATCHDOG=y CONFIG_DM_THERMAL=y CONFIG_IMX_TMU=y +# CONFIG_TPM_V1 is not set +CONFIG_TPM2_TIS_SPI=y CONFIG_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y @@ -160,4 +167,7 @@ CONFIG_USB_ETHER_MCS7830=y CONFIG_USB_ETHER_RTL8152=y CONFIG_USB_ETHER_SMSC95XX=y CONFIG_IMX_WATCHDOG=y +CONFIG_TPM=y +# CONFIG_SPL_SHA512 is not set +# CONFIG_SPL_SHA384 is not set CONFIG_HEXDUMP=y -- 2.25.1
[PATCH] arm: dts: imx8m*-venice-gw72xx: add TPM device
The GW71xx baseboard has a TPM that defined in the upstream dt however
we need to ensure the GPIO reset line is de-asserted which we do in boot
firmware with a gpio hog.
Signed-off-by: Tim Harvey
---
arch/arm/dts/imx8mm-venice-gw71xx-0x-u-boot.dtsi | 7 +++
arch/arm/dts/imx8mp-venice-gw71xx-2x-u-boot.dtsi | 9 +
2 files changed, 16 insertions(+)
diff --git a/arch/arm/dts/imx8mm-venice-gw71xx-0x-u-boot.dtsi
b/arch/arm/dts/imx8mm-venice-gw71xx-0x-u-boot.dtsi
index b3592331c72b..07789c8d8835 100644
--- a/arch/arm/dts/imx8mm-venice-gw71xx-0x-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-venice-gw71xx-0x-u-boot.dtsi
@@ -25,6 +25,13 @@
gpios = <9 GPIO_ACTIVE_HIGH>;
line-name = "dio1";
};
+
+ tpm_rst {
+ gpio-hog;
+ output-high;
+ gpios = <11 GPIO_ACTIVE_HIGH>;
+ line-name = "tpm_rst#";
+ };
};
{
diff --git a/arch/arm/dts/imx8mp-venice-gw71xx-2x-u-boot.dtsi
b/arch/arm/dts/imx8mp-venice-gw71xx-2x-u-boot.dtsi
index 5c33f8c9cdcf..216a7a0d8d7c 100644
--- a/arch/arm/dts/imx8mp-venice-gw71xx-2x-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-venice-gw71xx-2x-u-boot.dtsi
@@ -4,6 +4,15 @@
*/
#include "imx8mp-venice-gw702x-u-boot.dtsi"
+ {
+ tpm_rst {
+ gpio-hog;
+ output-high;
+ gpios = <11 GPIO_ACTIVE_HIGH>;
+ line-name = "tpm_rst#";
+ };
+};
+
{
dio_1 {
gpio-hog;
--
2.25.1
[PATCH] arm: dts: imx8mm-venice-gw7901: add digital I/O direction control GPIO's
The GW7901 has GPIO's to configure the direction of its isolated
digital I/O signals. Add the GPIO pinmux, line names, and hog
configuration.
Signed-off-by: Tim Harvey
---
arch/arm/dts/imx8mm-venice-gw7901-u-boot.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/dts/imx8mm-venice-gw7901-u-boot.dtsi
b/arch/arm/dts/imx8mm-venice-gw7901-u-boot.dtsi
index e68030e7b22c..9fa21942c0c6 100644
--- a/arch/arm/dts/imx8mm-venice-gw7901-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-venice-gw7901-u-boot.dtsi
@@ -43,6 +43,20 @@
};
{
+ dig1ctl {
+ gpio-hog;
+ output-low;
+ gpios = <4 GPIO_ACTIVE_HIGH>;
+ line-name = "dig1_ctl";
+ };
+
+ dig2ctl {
+ gpio-hog;
+ output-low;
+ gpios = <5 GPIO_ACTIVE_HIGH>;
+ line-name = "dig2_ctl";
+ };
+
uart3_rs232 {
gpio-hog;
output-high;
--
2.25.1
