From: "Alex G." <mr.nuke.me@gmail.com>
To: "Pali Rohár" <pali@kernel.org>
Cc: "Jernej Škrabec" <jernej.skrabec@gmail.com>, u-boot@lists.denx.de
Subject: Re: Broken build with disabling OpenSSL crypto
Date: Mon, 18 Oct 2021 09:04:26 -0500 [thread overview]
Message-ID: <10b5a16f-9aa3-38f6-0bd7-cc9df5f38e0b@gmail.com> (raw)
In-Reply-To: <20211015203049.kaky7lbffbgh2fvx@pali>
On 10/15/21 3:30 PM, Pali Rohár wrote:
> On Friday 15 October 2021 09:35:43 Alex G. wrote:
>> On 10/15/21 6:34 AM, Pali Rohár wrote:
>>> On Wednesday 06 October 2021 17:05:24 Alex G. wrote:
>>>> Hi Jernej,
>>>>
>>>> On 10/6/21 4:27 PM, Jernej Škrabec wrote:
>>>>> Hi everyone!
>>>>>
>>>>> Commit cb9faa6f98ae ("tools: Use a single target-independent config to enable
>>>>> OpenSSL") recently introduced option to disable usage of OpenSSL via
>>>>> CONFIG_TOOLS_LIBCRYPTO. However, just a bit later, another commit b4f3cc2c42d9
>>>>> ("tools: kwbimage: Do not hide usage of secure header under
>>>>> CONFIG_ARMADA_38X") made U-Boot tools hard dependent on OpenSSL. That totally
>>>>> defeats the purpose of first commit. I suggest that it gets reverted.
>>>>>
>>>>> I would like disable OpenSSL for my usage, since it gives me troubles when
>>>>> cross-compiling U-Boot inside LibreELEC build system. It's not needed for our
>>>>> case anyway.
>>>>>
>>>>> Best regards,
>>>>>
>>>>
>>>> Can you please give the following diff a try, and if it works for you, submit as patch?
>>>
>>> This change is incorrect and will break mvebu builds. mvebu requires
>>> kwbimage for building boot images and so you cannot disable it or make
>>> it optional.
>>>
>>
>> If kwbimage is required and missing the CI builds and tests don't catch
>> that. I ran buildman with the change, and nothing broke. Sounds like that
>> needs to be addressed.
>
> It is possible that tests do not covert all scenarios.
>
>> That being said, I'm not okay with making everyone a slave to OpenSSL
>> because of any given platform.
>>
>> I propose to revert commit b4f3cc2c42d9 ("tools: kwbimage: Do not hide usage
>> of secure header under CONFIG_ARMADA_38X"), and rework it such that it
>> doesn't force libcrypto on everyone. And we very likely need a CI test
>> against libcrypto linkage when TOOLS_LIBCRYPTO is not set.
>
> Reverting that commit is not a solution as it can lead to broken
> kwbimage (when crypto stuff is not enabled). Plus there is lot of other
> changes and fixes in kwboot and kwbimage...
There are lots of CI tests that do not build usable images. I caution
against conflating testability with usability, as anyone who intends to
run images on hardware will likely have done their diligence and enabled
TOOLS_LIBCRYPTO.
Alex
> Some information with another approach how to solve build issues are in
> this email:
> https://lore.kernel.org/u-boot/20211015114735.rig3e4cuc7mn6a7e@pali/
>
>> Alex
>>
>>>>
>>>> diff --git a/tools/Makefile b/tools/Makefile
>>>> index 4a86321f64..7f72ff9645 100644
>>>> --- a/tools/Makefile
>>>> +++ b/tools/Makefile
>>>> @@ -96,7 +96,8 @@ AES_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix lib/aes/, \
>>>>
>>>> # Cryptographic helpers that depend on openssl/libcrypto
>>>> LIBCRYPTO_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix lib/, \
>>>> - fdt-libcrypto.o)
>>>> + fdt-libcrypto.o) \
>>>> + kwbimage.o
>>>>
>>>> ROCKCHIP_OBS = lib/rc4.o rkcommon.o rkimage.o rksd.o rkspi.o
>>>>
>>>> @@ -117,7 +118,6 @@ dumpimage-mkimage-objs := aisimage.o \
>>>> imximage.o \
>>>> imx8image.o \
>>>> imx8mimage.o \
>>>> - kwbimage.o \
>>>> lib/md5.o \
>>>> lpc32xximage.o \
>>>> mxsimage.o \
>>>> @@ -169,8 +169,8 @@ HOST_EXTRACFLAGS += -DCONFIG_FIT_SIGNATURE_MAX_SIZE=0xffffffff
>>>> HOST_EXTRACFLAGS += -DCONFIG_FIT_CIPHER
>>>> endif
>>>>
>>>> -# MXSImage needs LibSSL
>>>> -ifneq ($(CONFIG_MX23)$(CONFIG_MX28)$(CONFIG_ARMADA_38X)$(CONFIG_TOOLS_LIBCRYPTO),)
>>>> +# MXSImage needs LibSSL <- Nope! Read the frogging notice at the top
>>>> +ifneq ($(CONFIG_TOOLS_LIBCRYPTO),)
>>>> HOSTCFLAGS_kwbimage.o += \
>>>> $(shell pkg-config --cflags libssl libcrypto 2> /dev/null || echo "")
>>>> HOSTLDLIBS_mkimage += \
next prev parent reply other threads:[~2021-10-18 14:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-06 21:27 Broken build with disabling OpenSSL crypto Jernej Škrabec
2021-10-06 22:05 ` Alex G.
2021-10-08 9:34 ` Rudi Heitbaum
2021-10-10 11:06 ` Jernej Škrabec
2021-10-11 16:48 ` Alex G.
2021-10-13 5:26 ` Andre Heider
2021-10-15 11:34 ` Pali Rohár
2021-10-15 14:35 ` Alex G.
2021-10-15 20:30 ` Pali Rohár
2021-10-18 14:04 ` Alex G. [this message]
2021-10-07 19:41 ` Tom Rini
2021-10-10 11:04 ` Jernej Škrabec
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=10b5a16f-9aa3-38f6-0bd7-cc9df5f38e0b@gmail.com \
--to=mr.nuke.me@gmail.com \
--cc=jernej.skrabec@gmail.com \
--cc=pali@kernel.org \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).