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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 58263C433EF for ; Thu, 4 Nov 2021 16:51:30 +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 6B22261216 for ; Thu, 4 Nov 2021 16:51:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 6B22261216 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=xs4all.nl Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 16C8A836AD; Thu, 4 Nov 2021 17:51:27 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=xs4all.nl 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 E3BA9836AD; Thu, 4 Nov 2021 17:51:24 +0100 (CET) Received: from sibelius.xs4all.nl (sibelius.xs4all.nl [83.163.83.176]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 9D6AB831FD for ; Thu, 4 Nov 2021 17:51:21 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=xs4all.nl Authentication-Results: phobos.denx.de; spf=fail smtp.mailfrom=mark.kettenis@xs4all.nl Received: from localhost (bloch.sibelius.xs4all.nl [local]) by bloch.sibelius.xs4all.nl (OpenSMTPD) with ESMTPA id 8fd0e138; Thu, 4 Nov 2021 17:51:20 +0100 (CET) Date: Thu, 4 Nov 2021 17:51:20 +0100 (CET) From: Mark Kettenis To: Simon Glass Cc: takahiro.akashi@linaro.org, xypron.glpk@gmx.de, agraf@csgraf.de, ilias.apalodimas@linaro.org, sughosh.ganu@linaro.org, masami.hiramatsu@linaro.org, u-boot@lists.denx.de In-Reply-To: (message from Simon Glass on Thu, 4 Nov 2021 09:11:59 -0600) Subject: Re: [PATCH v5 02/11] tools: mkeficapsule: add firmwware image signing References: <20211028062356.98224-1-takahiro.akashi@linaro.org> <20211028062356.98224-3-takahiro.akashi@linaro.org> <20211029045628.GA33977@laputa> Message-ID: 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 > From: Simon Glass > Date: Thu, 4 Nov 2021 09:11:59 -0600 > > Hi Mark, > > On Thu, 4 Nov 2021 at 08:31, Mark Kettenis wrote: > > > > > From: Simon Glass > > > Date: Wed, 3 Nov 2021 20:51:25 -0600 > > > > > > Hi Mark, > > > > > > On Tue, 2 Nov 2021 at 09:13, Mark Kettenis wrote: > > > > > > > > > From: Simon Glass > > > > > Date: Tue, 2 Nov 2021 08:56:50 -0600 > > > > > > > > > > Hi Takahiro, > > > > > > > > > > > > - can we just build the tool always? > > > > > > > > > > > > This is one of my questions. > > > > > > Why do you want to do so while there are bunch of tools that are > > > > > > not always built. > > > > > > > > > > Because I think all tools should be built always. It is fine if that > > > > > happens due to CONFIG options but we should try to avoid making it > > > > > complicated. > > > > > > > > Well, unless this patchset fixes things, we can't, because > > > > mkeficapsule doesn't build on OpenBSD. I tried looking into it, but I > > > > can't figure out how this is even supposed to compile as a host tool: > > > > > > > > > > > > In file included from tools/mkeficapsule.c:8: > > > > In file included from include/malloc.h:369: > > > > include/linux/string.h:15:24: error: conflicting types for 'strspn' > > > > extern __kernel_size_t strspn(const char *,const char *); > > > > ^ > > > > /usr/include/string.h:88:9: note: previous declaration is here > > > > size_t strspn(const char *, const char *); > > > > > > My guess is that linux/string.h should not be included, or perhaps > > > __kernel_size_t should be defined to size_t. > > > > > > I doubt it would take an age to figure out, with a bit of fiddling. > > > > Well, I think the problem is quite fundamental. Indeed I agree that > > linux/string.h shouldn't be included. It gets pulled in because the > > tools include . Modern software really shouldn't include > > that header anymore, and we removed it in OpenBSD some time ago. But > > even with that fixed, things break since the same header gets pulled > > in from . > > > > Redefining __kernel_size_t doesn't provide a way out: > > > > tools/mkeficapsule.c:23:16: error: typedef redefinition with different types ('size_t' (aka 'unsigned long') vs 'unsigned int') > > typedef size_t __kernel_size_t; > > ^ > > ./arch/arm/include/asm/posix_types.h:37:23: note: previous definition is here > > typedef unsigned int __kernel_size_t; > > ^ > > > > This is on an amd64 host, so "unsigned int" clearly is the wrong type > > for size_t. > > > > The fundamental problem seems to be that isn't safe to include > > in a "host" tool because it includes "target" headers that > > accidentally resolve to "system" headers on Linux systems. > > > > Maybe Takahiro or Heinrich have an idea how to fix that? But in the > > meantime it would be good if building this tool would remain optional. > > Yes let's ask them to fix that as I agree this sounds wrong. We have > several efi headers so perhaps just need to have the right stuff in > each. > > It is OK to have it optional with a CONFIG, but it should be enabled > by default, otherwise no one will know it is there. > > Can we get the OpenBSD environment into CI or is that just too hard? Last time that came it was pointed out that Azure pipelines only support Windows, macOS and Linux. I would expect that a macOS build would catch the issues I'm seeing on OpenBSD.