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=-6.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 AFCBFC433EF for ; Mon, 6 Sep 2021 12:50:27 +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 7F25D6101C for ; Mon, 6 Sep 2021 12:50:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7F25D6101C 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 47C99831BF; Mon, 6 Sep 2021 14:50:24 +0200 (CEST) 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="feWjvNDO"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id CE644831C4; Mon, 6 Sep 2021 14:50:22 +0200 (CEST) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 8E0FB83189 for ; Mon, 6 Sep 2021 14:50:18 +0200 (CEST) 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-wr1-x433.google.com with SMTP id v10so9710085wrd.4 for ; Mon, 06 Sep 2021 05:50:18 -0700 (PDT) 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=dqRIxiDyIDgjzJ6jWUSD3lWmAhcqPKME0wPsTP2gOTA=; b=feWjvNDOCCKcHhdmo+RhRwWbVwCwOrJn+LwFPGsPYjLIdsk/w8TFqoiCjFHMxCClR3 XwGSJbBeytY9lDcKhiZLUai86LJqE3Gp5f6bH1i5EAMKZh5IUsNiAbRLFyfB1Wo8+lrl mDNcyceKp5xLM3p74Q//NZk3LMuP0hWAK9wkY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dqRIxiDyIDgjzJ6jWUSD3lWmAhcqPKME0wPsTP2gOTA=; b=suBbpPjayOclK/tYKcN4Ng1ue1o+qmp4PaYm4skTAWWBCt9rjUYtwAYJ5hzQfm+jxk rvNfGW9zy1MvrQP8+C8PQANkafOzrDYQMDXEVpixsVqOtTzfaYbDzsLaEvHquUMx8Swx ThKkkh5J3ruVewibOaWbKEFX3iHWnZZCHZsv1TFcIeunEyH8j9owYY4PwAkTChx8xa1x QYXTiAITaJulxZWeEwe6SBL7QuuBYHljZ0lQq8gV6QEfzW0MSgbP627RwBCaRGubAzeT VoR++fSGaDWg7mYl8cbY/gaGpKIX3x9DuoxxWLNqJGg5Mc/AsuXZgjXcfp24Ib0707zs QJ3Q== X-Gm-Message-State: AOAM530LCrZhKob4hHBLK8s4OSQrth0U3bGEoS8pDXFy1ro2VMSAOcp8 sjvSSfvvuuAVWKTYt0JUPy1XxqrpJFVvA7USBMBNUQ== X-Google-Smtp-Source: ABdhPJyQ9ihDYnAN48GCJQkg2LvPP+tYOBCtPgRAIAuCdHma2cLeaCNi0Sar7ggqtudWIx5RswGPWLb78yzCQ0eAinQ= X-Received: by 2002:a05:6000:92:: with SMTP id m18mr13144186wrx.293.1630932617512; Mon, 06 Sep 2021 05:50:17 -0700 (PDT) MIME-Version: 1.0 References: <28090b36-1af4-95a3-2d76-deaf1a2034ab@gmx.de> In-Reply-To: From: Simon Glass Date: Mon, 6 Sep 2021 06:50:05 -0600 Message-ID: Subject: Re: Pull request for efi-2021-10-rc2-2 To: Ilias Apalodimas Cc: U-Boot Mailing List 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 Ilias, On Mon, 6 Sept 2021 at 05:59, Ilias Apalodimas wrote: > > Hi Simon, > > > > > > > > > Well of course if the DT holds the key and you want to add the key > > > > after the build, you have to modify the DT. You make it sounds like a > > > > huge deal... > > > > > > Having to edit the DT and concat it is not a huge deal. Limiting the > > > ability to provide authenticated capsule updates, based on a config option > > > which defines how we supply he DTB is (at least for me). Especially since > > > the current approach doesn't have such limitations. > > > > Heinrich asked the same question. I went as far as sending a patch > > with docs on how it should work. > > > > I've commented on that patch as well wrt DTB origin. Yes I'll take that up there. I'm on holiday for two more weeks so things are a bit quiet. > > > > > > > > > > > > OF_SEPARATE is required, actually. We try to use OF_EMBED just for > > > > testing and development. > > > > > > And that's what I've been trying to get an answer on a few mails. > > > It's now quite clear, any board that's not compiled with OF_SEPARATE won't > > > support authenticated capsule updates (e.g rpi4 on the defconfig). > > > > I don't see why...where does the DT come from on that board? > > From a previous bootloader. It's address is usually is one of the cpu > registers. The most cases I've seen in u-boot is boards using their > version of board_fdt_blob_setup(). > > > > > > > > > > > > > > If mkeficapsule is how you want to write to the DT, that is fine. You > > > > could also add support for this to binman, which might be easier to > > > > maintain. > > > > > > > > Concatenating is handled by binman. > > > > > > That's what Akashi patches were fixing. IT doesn't make too much sesne to > > > have it in mkeficapsule, so I'll leave it up to him. > > > > I am not sure about mkeficapsule, but we already have the tool and the > > approach you have sent does not fit without how U-Boot should work. > > > > > > > > > > > > > > > > > > > > That is easy to do > > > > > > with a DTB but of course a real pain to do with an executable binary. > > > > > > > > > > > > What really complicates things is building the key into the source > > > > > > code of U-Boot. Whose key is it? > > > > > > > > > > The public portion of the organization that creates the capsule. > > > > > > > > > > > What if someone wants their own key? > > > > > > > > > > I am not sure I am following > > > > > > > > They have to add the key into an environment variable and rebuild > > > > U-Boot from source. That's my point. You should not have to rebuild > > > > something from source to add the public key. > > > > > > > > > > "They" have to compile uboot anyway since they are offering the firmware to > > > begin with. I get that's t has some limitations, but it doesn't sound that > > > bad to me. > > > > Let's just agree to disagree on that. > > > > > > > > > > > > > > > > Will people really accept that another project has to sign their > > > > > > U-Boot? Or does everyone have to fiddle with the build system to make > > > > > > it produce suitable output. It's just not a good idea. > > > > > > > > > > No one *signs* U-Boot. The capsule is signed not u-boot (but contains > > > > > u-boot). This key is a placeholder to authenticate the incoming capsule > > > > > update (which might update more than u-boot). But since > > > > > U-Boot *is* the EFI payload, it's responsible for having the key somewhere. > > > > > > > > I just mean that U-Boot has the public key. I call it signing because > > > > signing produces two things: > > > > > > > > - certificate or public key wrapper for checking signature (in U-Boot) > > > > - signature (in the thing you sign) > > > > > > > > I think it is easier to think of signing as a single operation > > > > although of course you may split it in some build systems. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Someone has to hold the line on important design decisions and I am > > > > > > > > frustrated that there has been so much push-back on something that > > > > > > > > should have been a simple 'oh sorry, didn't know'. I wrote this patch > > > > > > > > somewhat in response: > > > > > > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210725164400.468319-3-sjg@chromium.org/ > > > > > > > > > > > > > > > > > > > > > > > > > > Furthermore, on the entire thread, the responses I keep getting is "we just > > > > > > > > > need to move it on the dtb", although as I repeated a bunch of times up to > > > > > > > > > now, it's creating problems we don't have to deal with in the first place > > > > > > > > > and no one cares to argue about them. But I'll agree it's taking way more > > > > > > > > > time that it has to. For the record I am fine with whatever Heinrich > > > > > > > > > decides and I'll pick it up from there. > > > > > > > > > > > > > > > > It was already in DT, as I understand it. There was no good reason to > > > > > > > > change it, just some things that looked attractive on the surface. > > > > > > > > > > > > > > I won't go back explaining the entire thing again. It's not attractive "on > > > > > > > the surface", the only thing missing is u-boot doing a proper mapping of > > > > > > > sections during relocation. > > > > > > > > > > > > Which you can easily do with DT as well. Just copy the key somewhere > > > > > > and protect it...turn off CONFIG_CMLINE so commands cannot be used > > > > > > (call the overlay code directly!), this is just rehashing the same > > > > > > arguments. We have been using the current approach for years and it > > > > > > works well. This was all covered in: > > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210717142648.26588-1-ilias.apalodimas@linaro.org/ > > > > > > > > > > > > I think perhaps the core of the confusion is that qemu passes the DT > > > > > > to U-Boot which passes it to linux and there is not a separate DT for > > > > > > U-Boot. But that is just a detail to figure out, not a reason to throw > > > > > > everything away. > > > > > > > > > > And this might be a reality for other boards as well (e.g RISC-V). > > > > > > > > As I say, that is just a detail. > > > > > > I don't know much about RISC-V and how the DTB is handled. But if it > > > relies on CONFIG_OF_PRIOR_STAGE (which effectively means the feature won't > > > be supported), that's far away from a detail . > > > > See my docs patch on how that should be handled. However I am not sure > > what the prior stage is, in the RISC-V case. Are you just referring to > > QEMU? If so, I addressed that in my patch. > > If I don't read U-Boot wrong, there's more boards than QEMU (an even more > to come). What about boards using board_fdt_blob_setup() I've just mentioned? I'm going to suggest that we pass a bloblist to U-Boot in this case, with the DT being in there somewhere. I think that makes sense as a standard approach, since it is extensible for the future. [..] Regards, Simon