[PATCH v8 03/27] lib: Adapt digest header files to MbedTLS
Tom Rini
trini at konsulko.com
Wed Oct 9 16:38:24 CEST 2024
On Thu, Oct 03, 2024 at 02:50:16PM -0700, Raymond Mao wrote:
> Adapt digest header files to support both original libs and MbedTLS
> by switching on/off MBEDTLS_LIB_CRYPTO.
> Introduce <alg>_LEGACY kconfig for legacy hash implementations.
> sha256.o should depend on SHA256 kconfig only but not SUPPORT_EMMC_RPMB,
> SHA256 should be selected when SUPPORT_EMMC_RPMB is enabled instead.
>
> `IS_ENABLED` or `CONFIG_IS_ENABLED` is not applicable here, since
> including <linux/kconfig.h> causes undefined reference on schedule()
> with sandbox build, as <linux/kconfig.h> includes <generated/autoconf.h>
> which enables `CONFIG_HW_WATCHDOG` and `CONFIG_WATCHDOG` but no schedule()
> are defined in sandbox build,
> Thus we use `#if defined(CONFIG_MBEDTLS_LIB_CRYPTO)` instead.
>
> Signed-off-by: Raymond Mao <raymond.mao at linaro.org>
> Reviewed-by: Ilias Apalodimas <ilias.apalodimas at linaro.org>
There's three platforms where we see something like:
arm: (for 1/1 boards) all +5651.0 data +112.0 rodata +139.0 text +5400.0
o4-imx6ull-nano: all +5651 data +112 rodata +139 text +5400
u-boot: add: 23/0, grow: 1/0 bytes: 1172/0 (1172)
function old new delta
hash_command 108 296 +188
sha1_finish - 156 +156
static.sha1_update - 114 +114
hash_algo - 112 +112
sha1_padding - 64 +64
hash_lookup_algo - 60 +60
sha1_starts - 52 +52
crc16_ccitt_wd_buf - 36 +36
sha256_csum_wd - 34 +34
sha1_csum_wd - 34 +34
hash_finish_sha256 - 34 +34
hash_finish_sha1 - 34 +34
crc32_wd_buf - 34 +34
hash_finish_crc32 - 28 +28
hash_finish_crc16_ccitt - 28 +28
hash_init_sha256 - 22 +22
hash_init_sha1 - 22 +22
hash_update_crc32 - 20 +20
hash_update_crc16_ccitt - 20 +20
hash_init_crc32 - 20 +20
hash_init_crc16_ccitt - 20 +20
hash_update_sha256 - 16 +16
hash_update_sha1 - 16 +16
sha1_update - 8 +8
This is because:
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index 982e84dc3bc..5d7fd904950 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -119,6 +119,7 @@ config MMC_HW_PARTITIONING
> config SUPPORT_EMMC_RPMB
> bool "Support eMMC replay protected memory block (RPMB)"
> imply CMD_MMC_RPMB
> + select SHA256
> help
> Enable support for reading, writing and programming the
> key for the Replay Protection Memory Block partition in eMMC.
Wasn't true / required before now, no hashing algorithms were enabled.
This was fine because:
[snip]
> diff --git a/lib/Makefile b/lib/Makefile
> index c4950b78a29..33755778283 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -50,7 +50,6 @@ obj-$(CONFIG_XXHASH) += xxhash.o
> obj-y += net_utils.o
> obj-$(CONFIG_PHYSMEM) += physmem.o
> obj-y += rc4.o
> -obj-$(CONFIG_SUPPORT_EMMC_RPMB) += sha256.o
> obj-$(CONFIG_RBTREE) += rbtree.o
> obj-$(CONFIG_BITREVERSE) += bitrev.o
> obj-y += list_sort.o
Got us the library access without bringing in everything else. And since
two of the platforms that are hitting this now are "nano" this is an
important thing to figure out how to continue to support. If there's
just no way around it, we can likely live with the size increase, but
I'd like to see this looked in to specifically first, thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20241009/a4d181d1/attachment.sig>
More information about the U-Boot
mailing list