Re: [PATCH v3 19/19] tools: Use a single target-independent config to enable OpenSSL

From: "Alex G." <mr.nuke.me@gmail.com>
To: Heiko Thiery <heiko.thiery@gmail.com>
Cc: u-boot@lists.denx.de, trini@konsulko.com
Subject: Re: [PATCH v3 19/19] tools: Use a single target-independent config to enable OpenSSL
Date: Tue, 27 Jul 2021 09:34:55 -0500	[thread overview]
Message-ID: <ff3c685c-1d65-4ca5-e030-1ab22135082c@gmail.com> (raw)
In-Reply-To: <CAEyMn7ZpYpAj-gLrr2Z0YbkUKMLt+2GCu=k6-9=b3u+oMRGw=Q@mail.gmail.com>

On 7/27/21 4:59 AM, Heiko Thiery wrote:
> Hi all,
> 
> Am Do., 15. Juli 2021 um 00:09 Uhr schrieb Alexandru Gagniuc
> <mr.nuke.me@gmail.com>:
>>
>> Host tool features, such as mkimage's ability to sign FIT images were
>> enabled or disabled based on the target configuration. However, this
>> misses the point of a target-agnostic host tool.
>>
>> A target's ability to verify FIT signatures is independent of
>> mkimage's ability to create those signatures. In fact, u-boot's build
>> system doesn't sign images. The target code can be successfully built
>> without relying on any ability to sign such code.
>>
>> Conversely, mkimage's ability to sign images does not require that
>> those images will only work on targets which support FIT verification.
>> Linking mkimage cryptographic features to target support for FIT
>> verification is misguided.
>>
>> Without loss of generality, we can say that host features are and
>> should be independent of target features.
>>
>> While we prefer that a host tool always supports the same feature set,
>> we recognize the following
>>    - some users prefer to build u-boot without a dependency on OpenSSL.
>>    - some distros prefer to ship mkimage without linking to OpenSSL
>>
>> To allow these use cases, introduce a host-only Kconfig which is used
>> to select or deselect libcrypto support. Some mkimage features or some
>> host tools might not be available, but this shouldn't affect the
>> u-boot build.
>>
>> I also considered setting the default of this config based on
>> FIT_SIGNATURE. While it would preserve the old behaviour it's also
>> contrary to the goals of this change. I decided to enable it by
>> default, so that the default build yields the most feature-complete
>> mkimage.
>>
>> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
> 
> Since this patch was applied to master the build target "flash.bin"
> for e.g. the imx8mq_evk_defconfig fails.
> 
> --- 8< ---
> 
> MKIMAGE u-boot.itb
> u-boot.its:7.11-15.5: Warning (unit_address_vs_reg): /images/uboot@1:
> node has a unit name, but no reg property
> u-boot.its:16.9-21.5: Warning (unit_address_vs_reg): /images/fdt@1:
> node has a unit name, but no reg property
> u-boot.its:22.9-31.5: Warning (unit_address_vs_reg): /images/atf@1:
> node has a unit name, but no reg property
> u-boot.its:36.12-41.5: Warning (unit_address_vs_reg):
> /configurations/config@1: node has a unit name, but no reg property
> ./tools/mkimage: verify_header failed for FIT Image support with exit code 1
> make: *** [Makefile:1440: u-boot.itb] Error 1
> make: *** Deleting file 'u-boot.itb'
> make: *** Waiting for unfinished jobs....
> 
> --- 8< ---
> 
> Does I miss here something?

Are you sure it's this patch? I don't see how this change affects this 
issue, but I did notice invalid FIT node names [1] in your build.

Alex

[1] 
https://source.denx.de/u-boot/u-boot/-/commit/3f04db891a353f4b127ed57279279f851c6b4917