Hi Andre,
On 6/21/21 6:56 PM, Andre Przywara wrote: > On Mon, 21 Jun 2021 16:35:37 -0400 > Tom Rini <tr...@konsulko.com> wrote: >> On Mon, Jun 21, 2021 at 04:43:00PM +0100, Andre Przywara wrote: >>> On Sun, 20 Jun 2021 21:55:51 -0500 >>> Samuel Holland <sam...@sholland.org> wrote: >>> >>> (CC:ing Tom and Simon for the compatibility problem below) >>> >>> Hi, >>> >>>> This series adds support for the TOC0 image format used by the Allwinner >>>> secure boot ROM (SBROM). This series has been tested on the following >>>> SoCs/boards, with the eFuse burnt to enable secure mode: >>>> - A64: Pine A64 Plus >>>> - H5: Orange Pi Zero Plus >>>> - H6: Pine H64 Model B >>>> - H616: Orange Pi Zero 2 >>> >>> many thanks for sending this. In general this looks good (will do a >>> more thorough review soon), just one thing that bothered me: >>> >>> This requires OpenSLL 1.1.x. There is nothing really wrong about this, >>> but my (admittedly not the freshest) Slackware, but also long term >>> distros like RHEL/CentOS (<=7), still come with 1.0.x (headers) only. >>> >>> I was wondering how important this is? I have the impression that >>> embedded developers sometimes use old^Wstable systems, so some people >>> might be bitten by it. I think in this case it will affect all user >>> trying to build mkimage, regardless of the target platform? >>> >>> So I wanted to know what to do here? >>> - Can we provide some kind of compatibility support? OpenSSL seems >>> to provide something: >>> https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes#Compatibility_Layer >>> Haven't tested that fully yet, just downloading that tarball >>> does not seem to cut it (or is missing files?). I guess one needs to >>> copy&paste some code from the Wiki? >>> - Shall we detect missing v1.1.x support (via #if OPENSSL_VERSION_NUMBER >>> < 0x10100000L) and disable just sunxi_toc0 support in this case? >> >> There's two things. First, the series should be on top of (sorry!) >> https://patchwork.ozlabs.org/project/uboot/patch/20210524202317.1492578-1-mr.nuke...@gmail.com/ >> which adds a similar Kconfig option to make building tools easier. > > So this is on top of Simon's large series? Poor Samuel! Is there a > branch somewhere? Now that all of these have landed, I'm rebasing this series. >> Second, while I think not supporting openssl 1.0.x is fine, > > Well, this was not what I was hoping for ;-) > I followed the advice on the OpenSSL wiki and now have a rather small > compatibility header file, which lets me compile mkimage even against > OpenSSL v1.0.2u. It seems like kwbimage.c has similar provisions in > place, I guess this could be merged into the external header? > Happy to send a patch on top, if this seems useful. Considering the note from the OpenSSL website: > Note: The latest stable version is the 1.1.1 series. This is also > our Long Term Support (LTS) version, supported until 11th September > 2023. All older versions (including 1.1.0, 1.0.2, 1.0.0 and 0.9.8) > are now out of support and should not be used. Users of these older > versions are encouraged to upgrade to 1.1.1 as soon as possible. and the fact that that I don't have access a system with an old OpenSSL, I'm not too interested in spending much effort on it. I will, though, happily test a patch if you do send one. >> I would like >> to again ask for someone to spend the time looking at switching to one >> of the GPL-compatible libraries as I'm pretty sure it's been raised a >> few times that we can't link with openssl like we do. > > Why is that? Because Apache is not compatible with GPLv2? The OpenSSL > webpage says that: > "Can I use OpenSSL with GPL software? > On many systems including the major Linux and BSD distributions, yes > (the GPL does not place restrictions on using libraries that are part > of the normal operating system distribution)." > And for mkimage we just build a regular userspace tool, which is linked > against the system installed OpenSSL library. From my understanding > this is what this quote above means with being permitted? > > And what would be the alternatives? Take one of the smaller ones and > embed them into the code? > Otherwise we would probably need to pick something that is widely > available and shipped with distros, I guess? Like GnuTLS, > libgcrypt, nettle? Maybe LibreSSL? > > Samuel, do you have an insight what would be a good fit? My original code was written against nettle. I switched to OpenSSL because that was already integrated into U-Boot (oops!), and to use the ASN.1 generation library (which the code no longer uses). So nettle would work well here because all we need is SHA256 and plain RSA. I don't know about the other image types. Regards, Samuel
