Hi Tom, On Thu, 1 Aug 2024 at 16:46, Tom Rini <[email protected]> wrote:
> On Wed, Jul 31, 2024 at 10:25:10AM -0700, Raymond Mao wrote: > > > > Integrate MbedTLS v3.6 LTS (currently v3.6.0) with U-Boot. > > > > Motivations: > > ------------ > > > > 1. MbedTLS is well maintained with LTS versions. > > 2. LWIP is integrated with MbedTLS and easily to enable HTTPS. > > 3. MbedTLS recently switched license back to GPLv2. > > > > Prerequisite: > > ------------- > > > > This patch series requires mbedtls git repo to be added as a > > subtree to the main U-Boot repo via: > > $ git subtree add --prefix lib/mbedtls/external/mbedtls \ > > https://github.com/Mbed-TLS/mbedtls.git \ > > v3.6.0 --squash > > Moreover, due to the Windows-style files from mbedtls git repo, > > we need to convert the CRLF endings to LF and do a commit manually: > > $ git add --renormalize . > > $ git commit > > > > New Kconfig options: > > -------------------- > > > > `MBEDTLS_LIB` is for MbedTLS general switch. > > `MBEDTLS_LIB_CRYPTO` is for replacing original digest and crypto libs > with > > MbedTLS. > > `MBEDTLS_LIB_X509` is for replacing original X509, PKCS7, MSCode, ASN1, > > and Pubkey parser with MbedTLS. > > `LEGACY_CRYPTO` is introduced as a main switch for legacy crypto library. > > `LEGACY_CRYPTO_BASIC` is for the basic crypto functionalities and > > `LEGACY_CRYPTO_CERT` is for the certificate related functionalities. > > For each of the algorithm, a pair of `<alg>_LEGACY` and `<alg>_MBEDTLS` > > Kconfig options are introduced. Meanwhile, `SPL_` Kconfig options are > > introduced. > > > > In this patch set, MBEDTLS_LIB, MBEDTLS_LIB_CRYPTO and MBEDTLS_LIB_X509 > > are by default enabled in qemu_arm64_defconfig and sandbox_defconfig > > for testing purpose. > > > > Patches for external MbedTLS project: > > ------------------------------------- > > > > Since U-Boot uses Microsoft Authentication Code to verify PE/COFFs > > executables which is not supported by MbedTLS at the moment, > > addtional patches for MbedTLS are created to adapt with the EFI loader: > > 1. Decoding of Microsoft Authentication Code. > > 2. Decoding of PKCS#9 Authenticate Attributes. > > 3. Extending MbedTLS PKCS#7 lib to support multiple signer's > certificates. > > 4. MbedTLS native test suites for PKCS#7 signer's info. > > > > All above 4 patches (tagged with `mbedtls/external`) are submitted to > > MbedTLS project and being reviewed, eventually they should be part of > > MbedTLS LTS release. > > But before that, please merge them into U-Boot, otherwise the building > > will be broken when MBEDTLS_LIB_X509 is enabled. > > > > See below PR link for the reference: > > https://github.com/Mbed-TLS/mbedtls/pull/9001 > > > > Miscellaneous: > > -------------- > > > > Optimized MbedTLS library size by tailoring the config file > > and disabling all unnecessary features for EFI loader. > > From v2, original libs (rsa, asn1_decoder, rsa_helper, md5, sha1, sha256, > > sha512) are completely replaced when MbedTLS is enabled. > > From v3, the size-growth is slightly reduced by refactoring Hash > functions. > > > > Target(QEMU arm64) size-growth when enabling MbedTLS: > > v1: 6.03% > > v2: 4.66% > > From v3: 4.55% > > > > Please see the latest output from buildman for size-growth on QEMU arm64, > > Sandbox and Nanopi A64. [1] > > Let us inline the growth on qemu_arm64 for a moment: > aarch64: (for 1/1 boards) all +6916.0 bss -32.0 data -64.0 rodata > +200.0 text +6812.0 > qemu_arm64 : all +6916 bss -32 data -64 rodata +200 text > +6812 > u-boot: add: 28/-17, grow: 12/-16 bytes: 15492/-8304 (7188) > function old new > delta > mbedtls_internal_sha1_process - 4540 > +4540 > mbedtls_internal_md5_process - 2928 > +2928 > mbedtls_internal_sha256_process - 2052 > +2052 > mbedtls_internal_sha512_process - 1056 > +1056 > K - 896 > +896 > mbedtls_sha512_finish - 556 > +556 > mbedtls_sha256_finish - 484 > +484 > mbedtls_sha1_finish - 420 > +420 > mbedtls_sha512_starts - 340 > +340 > mbedtls_md5_finish - 336 > +336 > mbedtls_sha512_update - 264 > +264 > mbedtls_sha256_update - 252 > +252 > mbedtls_sha1_update - 236 > +236 > mbedtls_md5_update - 236 > +236 > mbedtls_sha512 - 148 > +148 > mbedtls_sha256_starts - 124 > +124 > hash_init_sha512 52 128 > +76 > hash_init_sha256 52 128 > +76 > mbedtls_sha1_starts - 72 > +72 > mbedtls_md5_starts - 60 > +60 > hash_init_sha1 52 112 > +60 > mbedtls_platform_zeroize - 56 > +56 > mbedtls_sha512_free - 16 > +16 > mbedtls_sha256_free - 16 > +16 > mbedtls_sha1_free - 16 > +16 > mbedtls_md5_free - 16 > +16 > hash_finish_sha512 72 88 > +16 > hash_finish_sha256 72 88 > +16 > hash_finish_sha1 72 88 > +16 > sha512_csum_wd 68 80 > +12 > sha256_csum_wd 68 80 > +12 > sha1_csum_wd 68 80 > +12 > md5_wd 68 80 > +12 > mbedtls_sha512_init - 12 > +12 > mbedtls_sha256_init - 12 > +12 > mbedtls_sha1_init - 12 > +12 > mbedtls_md5_init - 12 > +12 > memset_func - 8 > +8 > sha512_update 4 8 > +4 > sha384_update 4 8 > +4 > sha256_update 12 8 > -4 > sha1_update 12 8 > -4 > sha256_process 16 - > -16 > sha1_process 16 - > -16 > hash_update_sha512 36 16 > -20 > hash_update_sha256 36 16 > -20 > hash_update_sha1 36 16 > -20 > MD5Init 56 36 > -20 > sha1_starts 60 36 > -24 > hash_update_sha384 36 - > -36 > hash_init_sha384 52 - > -52 > sha384_csum_wd 68 12 > -56 > sha256_starts 104 40 > -64 > sha256_padding 64 - > -64 > sha1_padding 64 - > -64 > hash_finish_sha384 72 - > -72 > sha512_finish 152 36 > -116 > sha512_starts 168 40 > -128 > sha384_starts 168 40 > -128 > sha384_finish 152 4 > -148 > MD5Final 196 44 > -152 > sha512_base_do_finalize 160 - > -160 > static.sha256_update 228 - > -228 > static.sha1_update 240 - > -240 > sha512_base_do_update 244 - > -244 > MD5Update 260 - > -260 > sha1_finish 300 36 > -264 > sha256_finish 404 36 > -368 > sha256_armv8_ce_process 428 - > -428 > sha1_armv8_ce_process 484 - > -484 > sha512_K 640 - > -640 > sha512_block_fn 1212 - > -1212 > MD5Transform 2552 - > -2552 > > And to start with, that's not bad. In fact, tossing LTO in before mbedTLS > only changes > the top-line a little: > aarch64: (for 1/1 boards) all +5120.0 bss -16.0 data -64.0 rodata > +200.0 text +5000.0 > qemu_arm64 : all +5120 bss -16 data -64 rodata +200 text > +5000 > u-boot: add: 19/-18, grow: 11/-7 bytes: 14696/-7884 (6812) > > But, is there something we can do still? mbedTLS is a more robust > solution and I'm accepting there will be growth. But still the > process/start/finish is much larger. Is there something configurable > there? > > I have investigated all those MbedTLS native functions with big-size (_process/_update/_finish). For MD5 and SHA1, we don't have turnable configs. For SHA256 and SHA512, there are a few configs: 1. Performance configs only for Armv8/a64. I didn't turn that on, which might affect the target size as well. 2. Smaller implementation with lower size (only for non-Armv8/a64) at the expense of losing performance. I didn't enable both, as #1 is more for performance and might potentially increase target size; #2 compromises the performance and only for non-Armv8/a64. Looks like that both don't help in reducing the size of qemu_arm64. But I will try #1 on qemu_arm64 and #2 on sandbox and let you know the size impact soon. Thanks. Regards, Raymond
