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 47629C433F5 for ; Tue, 9 Nov 2021 10:07:23 +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 B7D7A600CD for ; Tue, 9 Nov 2021 10:07:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org B7D7A600CD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=siemens.com 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 D870383862; Tue, 9 Nov 2021 11:07:20 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=siemens.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 1678F83862; Tue, 9 Nov 2021 11:07:18 +0100 (CET) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 3EC63836E1 for ; Tue, 9 Nov 2021 11:07:14 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=siemens.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=jan.kiszka@siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id 1A9A75MC006229 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 9 Nov 2021 11:07:05 +0100 Received: from [139.22.44.90] ([139.22.44.90]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 1A9A75w6021390; Tue, 9 Nov 2021 11:07:05 +0100 Subject: Re: [PATCH 0/2] RFC: add fdt_add_pubkey tool To: Roman Kopytin , "u-boot@lists.denx.de" , Rasmus Villemoes References: <20211108152844.3656459-1-Roman.Kopytin@kaspersky.com> <587d4694-5539-8048-7eb0-600d629ffc61@siemens.com> <94f954682da6413d87856a732b6373be@kaspersky.com> From: Jan Kiszka Message-ID: <5d59918e-7b49-a329-945e-748cdf6b5fcb@siemens.com> Date: Tue, 9 Nov 2021 11:07:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <94f954682da6413d87856a732b6373be@kaspersky.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US 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 09.11.21 10:37, Roman Kopytin wrote: > Can we have discussion with code lines? For me it is not very clear, because it isn't my code. > Please do not top-post. > -----Original Message----- > From: Jan Kiszka > Sent: Tuesday, November 9, 2021 12:17 PM > To: Roman Kopytin ; u-boot@lists.denx.de; Rasmus Villemoes > Subject: Re: [PATCH 0/2] RFC: add fdt_add_pubkey tool > > On 08.11.21 16:28, Roman Kopytin wrote: >> In order to reduce the coupling between building the kernel and >> U-Boot, I'd like a tool that can add a public key to U-Boot's dtb >> without simultaneously signing a FIT image. That tool doesn't seem to >> exist, so I stole the necessary pieces from mkimage et al and put it >> in a single .c file. >> >> I'm still working on the details of my proposed "require just k out >> these n required keys" and how it should be implemented, but it will >> probably involve teaching this tool a bunch of new options. These >> patches are not necessarily ready for inclusion (unless someone else >> finds fdt_add_pubkey useful as is), but I thought I might as well send >> it out for early comments. > > I'd also like to see the usage of this hooked into the build process. > > And to my understanding of [1], that approach will provide a feature that permits hooking with the build but would expect the key as dtsi fragment. Can we consolidate the approaches? > > My current vision of a user interface would be a Kconfig option that takes a list of key files to be injected. Maybe make that three lists, one for "required=image", one for "required=conf", and one for optional keys (if that has a use case in practice, no idea). > > Jan > > [1] > https://lore.kernel.org/u-boot/20210928085651.619892-1-rasmus.villemoes@prevas.dk/ > > -- > Siemens AG, T RDA IOT > Corporate Competence Center Embedded Linux > For what would you like to have code? The kconfig addition? diff --git a/common/Kconfig.boot b/common/Kconfig.boot index d3a12be228..a9ed4d4ec4 100644 --- a/common/Kconfig.boot +++ b/common/Kconfig.boot @@ -279,6 +279,14 @@ config SPL_FIT_GENERATOR endif # SPL +config FIT_SIGNATURE_PUB_KEYS + string "Public keys to use for FIT image verification" + depends on FIT_SIGNATURE || SPL_FIT_SIGNATURE + help + Public keys, or certificate files to extract them from, that shall + be used to verify signed FIT images. The keys will be embedded into + the control device tree of U-Boot. + endif # FIT config LEGACY_IMAGE_FORMAT But note that we are in a design discussion here, and I'm at least reluctant to code up n-versions without having some common idea where things should move. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux