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 17FCBC433EF for ; Wed, 10 Nov 2021 19:37:22 +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 7982A60F46 for ; Wed, 10 Nov 2021 19:37:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7982A60F46 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org 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 DF835839C9; Wed, 10 Nov 2021 20:37:13 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=chromium.org header.i=@chromium.org header.b="DQB7qGO7"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 3E513839EE; Wed, 10 Nov 2021 20:37:10 +0100 (CET) Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 458A8839E9 for ; Wed, 10 Nov 2021 20:37:05 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com Received: by mail-ua1-x929.google.com with SMTP id o26so7150127uab.5 for ; Wed, 10 Nov 2021 11:37:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dn4GdG2VfJsp7bibZxr/Mo5TZ8O2OVnfQ9oN+BTLjqA=; b=DQB7qGO7y57c0VfDAg6dZ4KiUHztm5qbX+WW+m73iVZ7TOU54VYVx28FiW+nG1PJgw cmp/zkQaFCsetCzJujGdmCJxIX6nxrJlZNrQqo8epuWALx1mSh1TGcieuMrsRbZ2kihz 66s0lBqg+PxyooCQGAuuPf7uTFE1JTXqnh8bI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dn4GdG2VfJsp7bibZxr/Mo5TZ8O2OVnfQ9oN+BTLjqA=; b=dLnFdrTJdtsyoC4jSJebtZ1bSpoJX+jF5LxvasID9XQHGalhlkCM3eKb1UUPgVqHoz M3/R7WB/o0Jn7QVCa3GSFdXYAUpbOrlI0zEyEdtNvQDcSDKSXUimBj1E133227CFX8Ak Jw7iyYpys/p7A0beMPDPsJk598YZyOfAbGe47yb5L6newyalwiNeyqua9/GohgVkyuNk nDRiWWhBAW8AYRD8wawS38PzkDtoJIjxhvL7yjoaGFfc0UuOuv3S6iRudVp7S9ZF/3K2 CnpteF97EOJsK+HQ5jJrV9Sqfk5F857aucNSfHQmTLhyfDJsAR2xGtesKmf2/faPuzyL 2Q9A== X-Gm-Message-State: AOAM530xX0/UMPYNxNjamVJ+ew+kG2Zrxo9xPbATy0lU1AYR/HAcYCNv b5baNQ2Zg22/SiPH4aijCPhfAgAxCUfFh0UxlGoK5g== X-Google-Smtp-Source: ABdhPJxNyQqqFNkpMgHAAOQJ333l1ya+B2WIM7Dh11+5/BArzeJCWbuX6uZ+p7+kth0yAQR8251Bey5bprPvifXMbZk= X-Received: by 2002:a67:de88:: with SMTP id r8mr1917434vsk.15.1636573023844; Wed, 10 Nov 2021 11:37:03 -0800 (PST) MIME-Version: 1.0 References: <20211108152844.3656459-1-Roman.Kopytin@kaspersky.com> <587d4694-5539-8048-7eb0-600d629ffc61@siemens.com> <070cb856-f9d1-90d4-dea5-874ffdaa051a@siemens.com> In-Reply-To: From: Simon Glass Date: Wed, 10 Nov 2021 12:36:52 -0700 Message-ID: Subject: Re: [PATCH 0/2] RFC: add fdt_add_pubkey tool To: Jan Kiszka Cc: Roman Kopytin , u-boot@lists.denx.de, Rasmus Villemoes Content-Type: text/plain; charset="UTF-8" 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 Hi Jan, On Wed, 10 Nov 2021 at 09:49, Jan Kiszka wrote: > > On 10.11.21 17:31, Simon Glass wrote: > > Hi Jan, > > > > On Wed, 10 Nov 2021 at 00:20, Jan Kiszka wrote: > >> > >> On 10.11.21 07:55, Jan Kiszka wrote: > >>> On 10.11.21 01:58, Simon Glass wrote: > >>>> Hi, > >>>> > >>>> On Tue, 9 Nov 2021 at 02:17, Jan Kiszka wrote: > >>>>> > >>>>> 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). > >>>> > >>>> Also please take a look at binman which is designed to handle create > >>>> (or later updating from Yocto) the devicetree or firmware image. > >>>> > >>> > >>> Yes, binman is another problem area, but not for the public key > >>> injection, rather for permitting to sign fit images that are described > >>> for binman (rather than for mkimage). I'm currently back to dd for > >>> signing the U-Boot container in > >>> arch/arm/dts/k3-am65-iot2050-boot-image.dtsi, or I would have to split > >>> that FIT image description from that file - both not optimal. > > > > Well I don't think binman supports that at present, or at least I'm > > not sure what it would do. We don't have a test case for it. If you > > have an idea for how it should work, please send some ideas and I can > > look at it. > > > >> > >> OK, this can already be optimized with "binman replace" - once I > >> understood where fdtmap can go and where not. Why no support for using > >> map files? > > > > The fdtmap provides enough information to extract anything from the > > image and regenerate/replace things. > > > > What is a map file? > > *.map, e.g. image.map? Also generated by many binmap -m? Using map files for what? Do you mean passing it to Binman in lieu of an in-image fdtmap? If so, they are not equivalent. The map is just a simple text output of offsets and sizes. The fdtmap contains the full image description. > > > > >> > >> Jan > >> > >>> > >>> And another area: Trust centers that perform the signing (and only that) > >>> usually do not support random formats and workflows but just few common > >>> ones, e.g. x509. It would be nice to have a way to route out the payload > >>> (hashes etc.) that mkimage would sign, ideally into a standard signing > >>> request, and permit to inject the resulting signature at the right > >>> places into the FIT image. > > > > Well that needs to be provided somewhere. It should be fairly easy to > > get Binman to do this, so long as the image description has info about > > what is being signed. > > I would assume that it has to have that information, already to use > mkimage on it or its parts. Well, at present the information is there but Binman does not fully parse the mkimage subnodes. E.g. it doesn't look to see what things are signed/hashed. It just runs mkimage. If we want to output the hash for signing, we would need to implement that somewhere. Binman could do this after the image is build, i.e. look at the various signature nodes, hash the appropriate data and write out an 'instructions' file in a suitable format. > > > > >>> > >>> But one after the other. > > > > Possibly, but sometimes it is best to design things up-front. > > > > True as well. Regards, Simon