From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8D36AC4743C for ; Mon, 21 Jun 2021 23:56:58 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 849A06100A for ; Mon, 21 Jun 2021 23:56:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 849A06100A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 2C681829EE; Tue, 22 Jun 2021 01:56:55 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id 043CE82BC7; Tue, 22 Jun 2021 01:56:53 +0200 (CEST) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by phobos.denx.de (Postfix) with ESMTP id 2CDC0829D5 for ; Tue, 22 Jun 2021 01:56:49 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=andre.przywara@arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BB84A1042; Mon, 21 Jun 2021 16:56:47 -0700 (PDT) Received: from slackpad.fritz.box (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8B8363F694; Mon, 21 Jun 2021 16:56:46 -0700 (PDT) Date: Tue, 22 Jun 2021 00:56:26 +0100 From: Andre Przywara To: Tom Rini Cc: Samuel Holland , Jagan Teki , Hans de Goede , u-boot@lists.denx.de, Simon Glass , Jernej =?UTF-8?B?xaBrcmFiZWM=?= Subject: Re: [PATCH 0/4] sunxi: TOC0 image type support Message-ID: <20210622005626.65f27491@slackpad.fritz.box> In-Reply-To: <20210621203537.GN9516@bill-the-cat> References: <20210621025555.19390-1-samuel@sholland.org> <20210621164300.231e3a11@slackpad.fritz.box> <20210621203537.GN9516@bill-the-cat> Organization: Arm Ltd. X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.31; x86_64-slackware-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean On Mon, 21 Jun 2021 16:35:37 -0400 Tom Rini 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 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! >