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

[Andre Przywara <andre.przywara@arm.com>]

On Mon, 21 Jun 2021 16:35:37 -0400
Tom Rini <trini@konsulko.com> wrote:

Hi Tom,

> 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@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?

> 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.

> 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?

Tom, do you have some pointer to previous discussions about this?

Cheers,
Andre


> This isn't a
> blocker for the series, just an ask for help with a known problem.
> Thanks!
>