[PATCH 0/4] sunxi: TOC0 image type support

[Tom Rini]

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 <trini at 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 <samuel at 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.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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210822/d0b7123f/attachment.sig>