On Sat, Aug 21, 2021 at 09:19:56PM -0500, Samuel Holland wrote: > > Hi Andre, > > On 6/21/21 6:56 PM, Andre Przywara wrote: > > On Mon, 21 Jun 2021 16:35:37 -0400 > > Tom Rini 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 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.me@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. Since this series came up we now also have: https://patchwork.ozlabs.org/project/uboot/patch/20210729183121.3798261-1-mr.nuke.me@gmail.com/ So I would rather not see more old openssl compatibility code added. > >> 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. I'd like to see one of the parties that had noted the licensing problem chime in and explain it again. -- Tom