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

Sun Aug 22 23:37:26 CEST 2021

On 2021-08-22, Tom Rini wrote:
> On Sat, Aug 21, 2021 at 09:19:56PM -0500, Samuel Holland wrote:
>> 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.

The short of it is the openssl license has an advertising clause, and
the GPL requires no additional terms may be added when distributing
binaries. This is *fine* when distributing source code only, but once a
project such as Debian or some commercial entitry distributes binaries
of u-boot, the license incompatibility is triggered...

A more detailed explanation of the issue:

  https://people.gnome.org/~markmc/openssl-and-the-gpl.html

That said, Debian has recently and somewhat quietly decided to declare
openssl as a "system library" which in some opinions works around the
issue. I believe Fedora has used this workaround for quite a while
too. I personally think this is a very weak workaround and have only
reluctantly added openssl support in parts of Debian's u-boot packages,
and sometimes wonder if I shouldn't revert those changes...

If someone has the ability, time, resources, etc. to (optionally?)
switch u-boot to using a library that doesn't have any potential license
compatibility issues, that would be ideal, so ideal! But of course, it
requires *someone* to do the *work*. I don't believe *I* have the
requisite skills.

Another route would be to audit all the current codepaths using openssl
and get permission from all involved copyright holders to add a license
exception expressly permitting linking against openssl. In the past,
this was seen as something between impossible or implausible, due to the
sheer number of potential copyright holders which would need to give
permission to effectively relicense their GPL contributions with this
exception. Maybe the actual affected code paths would limit the number
of people involved enough to make it worth it... maybe not. Again, a
fair amount of work that *someone* would need to do just to even audit
the feasibility of this approach.

It is somewhat interesting to explore not adding *new* code to u-boot
that uses openssl by using a different library, and then the old code
might be able to be gradually migrated over to a different library? Last
I did a cursory look, nettle, gnutls and gcrypt seemed the most
promising candidates. I believe libressl has the same licensing issues
as openssl.

live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210822/7ef338fe/attachment.sig>