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

[Samuel Holland]

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.

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