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=-12.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PULL_REQUEST, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham 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 2E54FC433FE for ; Thu, 9 Sep 2021 12:02:18 +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 390C461222 for ; Thu, 9 Sep 2021 12:02:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 390C461222 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=konsulko.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 DBC7483336; Thu, 9 Sep 2021 14:02:14 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com 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=konsulko.com header.i=@konsulko.com header.b="czK2CiGR"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 24FDB82952; Thu, 9 Sep 2021 14:02:13 +0200 (CEST) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (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 433478335D for ; Thu, 9 Sep 2021 14:02:03 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qv1-xf2f.google.com with SMTP id s16so922201qvt.13 for ; Thu, 09 Sep 2021 05:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=mTL0pI8mPIUoZ+IJu9gOXG6htNLhD0nPLAb1HS6H+8o=; b=czK2CiGRJDnkh/4t2XYbDAoiQqw+n9ybxzrTI2CZdk1vW5pWbx56Ttt72UuS2ZIqN7 fczesLRnK0NdGAv61U9RnUsVNofPQ6Jx27LGO851f8xpUvAjUEzP4BYoNxmlnRHLq/Yx unHsGm4S4HS+VTZL+RghEcCXuE2f/mxUn4cbM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=mTL0pI8mPIUoZ+IJu9gOXG6htNLhD0nPLAb1HS6H+8o=; b=G0luquOsrEPP7Z0bycwF97nekJbas0vz/j9cOIg3DI/LQICBB53OYH2Ka3YzimvTdN 04FdX6PTX6JjXKvX0DKpH2e4qnp2lgDbNLuMxpf2pGQ17O/QA2o4gdc3MRP34TBEnWhj K/kPJ7NPJ/r4WNdAniw62jgDRLP+ajUYxwdRkYuS77f5aSJq8wgI796gLgomA0cXleeM O4J4Hvv8c1hzR3iVXc/DoZYGuoiPZk9oiPPyGfuXNVLMu5n/I3g4VAn+tBcO4cttEEMq 2UZMW5YYkpmQKLBscWPLdG7f4hxOfNCJpL4MGhndCz7q3xEUVGOn3NZun4laZEE9u8hh xd/A== X-Gm-Message-State: AOAM5305+j0Vp62SppFHvxliqXDQdEH0SUXuHIHoxIw2OfOMdxjzCYBM S6ofn2zn0hv2H9tsy2twlKJ/wg== X-Google-Smtp-Source: ABdhPJxurDLpZ6XJkzHsbaxrMrB9vP11XzyIjLQLTzsBz8Sif5oSxhCgv+N2FwfYaYcGPcKsO7/ufA== X-Received: by 2002:ad4:5804:: with SMTP id dd4mr2254266qvb.18.1631188921962; Thu, 09 Sep 2021 05:02:01 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-f91e-f867-d1bc-397d.res6.spectrum.com. [2603:6081:7b01:cbda:f91e:f867:d1bc:397d]) by smtp.gmail.com with ESMTPSA id w6sm1117472qkw.91.2021.09.09.05.02.00 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 09 Sep 2021 05:02:01 -0700 (PDT) Date: Thu, 9 Sep 2021 08:01:59 -0400 From: Tom Rini To: Heinrich Schuchardt Cc: Simon Glass , U-Boot Mailing List , Alexander Graf , Masahisa Kojima , AKASHI Takahiro , Ilias Apalodimas Subject: Re: Pull request for efi-2021-10-rc4 Message-ID: <20210909120159.GX12964@bill-the-cat> References: <20210904130111.GA12964@bill-the-cat> <20210904143722.GD12964@bill-the-cat> <46CAD3CD-41FA-43B9-9099-225711B754E1@gmx.de> <20210904173949.GI12964@bill-the-cat> <8FD4F99B-E1A5-4842-8BB8-EA2749E4761B@gmx.de> <20210904180825.GJ12964@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="yY6OajYROBmoEVZC" Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.9.4 (2018-02-28) 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 --yY6OajYROBmoEVZC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 09, 2021 at 01:21:17PM +0200, Heinrich Schuchardt wrote: >=20 >=20 > On 9/9/21 10:56 AM, Simon Glass wrote: > > Hi Ilias, > >=20 > > On Sat, 4 Sept 2021 at 14:09, Ilias Apalodimas > > wrote: > > >=20 > > > Hi Tom, > > >=20 > > > On Sat, 4 Sept 2021 at 21:08, Tom Rini wrote: > > > >=20 > > > > On Sat, Sep 04, 2021 at 08:02:49PM +0200, Heinrich Schuchardt wrote: > > > > >=20 > > > > >=20 > > > > > Am 4. September 2021 19:39:49 MESZ schrieb Tom Rini : > > > > > > On Sat, Sep 04, 2021 at 07:03:48PM +0200, Heinrich Schuchardt w= rote: > > > > > > >=20 > > > > > > >=20 > > > > > > > Am 4. September 2021 16:37:22 MESZ schrieb Tom Rini : > > > > > > > > On Sat, Sep 04, 2021 at 03:08:38PM +0200, Heinrich Schuchar= dt wrote: > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > Am 4. September 2021 15:01:11 MESZ schrieb Tom Rini : > > > > > > > > > > On Sat, Sep 04, 2021 at 11:56:47AM +0200, Heinrich Schu= chardt wrote: > > > > > > > > > >=20 > > > > > > > > > > > Dear Tom, > > > > > > > > > > >=20 > > > > > > > > > > > The following changes since commit 94509b79b13e69c209= 199af0757afbde8d2ebd6d: > > > > > > > > > > >=20 > > > > > > > > > > > btrfs: Use default subvolume as filesystem root (2= 021-09-01 10:11:24 > > > > > > > > > > > -0400) > > > > > > > > > > >=20 > > > > > > > > > > > are available in the Git repository at: > > > > > > > > > > >=20 > > > > > > > > > > > https://source.denx.de/u-boot/custodians/u-boot-ef= i.git > > > > > > > > > > > tags/efi-2021-10-rc4 > > > > > > > > > > >=20 > > > > > > > > > > > for you to fetch changes up to 1dfa494610c5469cc28cf1= f8538abf4be6c00324: > > > > > > > > > > >=20 > > > > > > > > > > > efi_loader: fix efi_tcg2_hash_log_extend_event() p= arameter check > > > > > > > > > > > (2021-09-04 09:15:09 +0200) > > > > > > > > > > >=20 > > > > > > > > > > > -----------------------------------------------------= ----------- > > > > > > > > > > > Pull request for efi-2021-10-rc4 > > > > > > > > > > >=20 > > > > > > > > > > > Documentation: > > > > > > > > > > >=20 > > > > > > > > > > > Remove invalid reference to configuration variab= le in UEFI doc > > > > > > > > > > >=20 > > > > > > > > > > > UEFI: > > > > > > > > > > >=20 > > > > > > > > > > > Parameter checks for the EFI_TCG2_PROTOCOL > > > > > > > > > > > Improve support of preseeding UEFI variables. > > > > > > > > > > > Correct the calculation of the size of loaded im= ages. > > > > > > > > > > > Allow for UEFI images with zero VirtualSize > > > > > > > > > > >=20 > > > > > > > > > > > -----------------------------------------------------= ----------- > > > > > > > > > > > Heinrich Schuchardt (5): > > > > > > > > > > > efi_loader: sections with zero VirtualSize > > > > > > > > > > > efi_loader: rounding of image size > > > > > > > > > > > efi_loader: don't load signature database from= file > > > > > > > > > > > efi_loader: efi_auth_var_type for AuditMode, D= eployedMode > > > > > > > > > > > efi_loader: correct determination of secure bo= ot state > > > > > > > > > > >=20 > > > > > > > > > > > Masahisa Kojima (3): > > > > > > > > > > > efi_loader: add missing parameter check for EF= I_TCG2_PROTOCOL api > > > > > > > > > > > efi_loader: fix boot_service_capability_min ca= lculation > > > > > > > > > > > efi_loader: fix efi_tcg2_hash_log_extend_event= () parameter check > > > > > > > > > >=20 > > > > > > > > > > And I don't see Simon's revert in here either. And he = asked you about > > > > > > > > > > that yesterday: > > > > > > > > > > https://lore.kernel.org/r/CAPnjgZ3eRdjF0jb9S-cJK6y+feuy= RyWf0hNkf2triB4DR4UFBQ@mail.gmail.com/ > > > > > > > > > >=20 > > > > > > > > > > So at this point, are you asserting there is nothing to= revert? > > > > > > > > >=20 > > > > > > > > > Never. Simons "revert" is breaking functionality. The con= cept for suporting blobs in devicetrees supplied by a prior bootstage has n= ot been defined yet. > > > > > > > >=20 > > > > > > > > And to be clearer, reverting something that was introduced = in one rc in > > > > > > > > a later rc isn't breaking functionality. U-Boot releases (= well, the > > > > > > > > non-rc ones for sure) are on a very regular schedule. Exte= rnal projects > > > > > > > > may not depend on some feature introduced at -rcN unless th= ey're willing > > > > > > > > to accept that some changes could happen before release. > > > > > > > >=20 > > > > > > >=20 > > > > > > > There is no value delivered by Simon's series. Neither does t= he image get smaller nor does it fix anything. If he wants to enforce a des= ign, it must work for all use cases. But this requires some conceptual work. > > > > > >=20 > > > > > > Yes, and what's the rush to not do the conceptual work? If I r= ecall > > > > > > part of the thread correctly, yes, Simon didn't get his objecti= ons in > > > > > > before the patches were merged, but it was early enough in the = release > > > > > > cycle that taking a step back and reverting was a reasonable re= quest. > > > > > > What he had said wouldn't have changed if he had gotten the ema= il out a > > > > > > few days earlier. > > > > > >=20 > > > > > > So yes, please merge Simon's revert, or post and merge new more= minimal > > > > > > revert that brings things to the same functional end. There are > > > > > > objections to this implementation, and thus far Simon has been > > > > > > responding all of the requests to better clarify all of the rel= ated code > > > > > > and concepts that have been asked of him, so that in the end an > > > > > > implementation that fulfills all of the technical requirements = can be > > > > > > created, that hopefully leaves all parties satisfied. > > > > >=20 > > > > > There is nothing wrong with the current code. > > > > >=20 > > > > > It is Simon's concept of blobs in devicetrees that is borked in t= hat > > > > > it ignores QEMU and any board that gets the DT from a prior boot > > > > > stage. > > > >=20 > > > > Then it should be pretty easy to get Simon to withdraw his objectio= ns, > > > > if there's such a fundamental "this is the only possible way, no > > > > changes" path forward. > > > >=20 > > > > > Simon's patches have no functional end. So what do you mean by "s= ame functional end"? > > > >=20 > > > > I mean the state of the EFI subsystem, prior to the code in question > > > > being merged, without breaking the other assorted EFI changes that = have > > > > come in since then. > > > >=20 > > > > -- > > > > Tom > > > I'll sum this up since there's many emails on the topic. > > >=20 > > > The current changes move the public needed for capsule updates in > > > U-Boot's .rodata section. > > > When I sent this, I assumed u-boot was mapping .rodata as read only. > > > Since it doesn't the protection I was hoping for isn't there. So > > > security wise the two different proposals are on par. Arguably it's > > > easier to fix .rodata instead of copying the key from the dtb and > > > switching the pages to RO, but that's really minor. > > >=20 > > > However keeping the key on the DTB has some of limitations, with the > > > most notable being that you *must* only use CONFIG_OF_SEPARATE for > > > your DTB, while there's four different ways available in the Kconfig > > > (and 3 are usable on production). I've repeated enough times, that I > > > don't mind changing the code and keeping the key on the DTB, as long > > > as the limitations are lifted. If that means reverting the patch now > > > and fixing it in the future, I am fine with that as well. > > > To be honest I don't understand why this has to be set in stone. Even > > > if we keep the current patchset and change it to the dtb in the > > > future, that will have zero effect on the users. Once they upgrade to > > > the newer, shinier version, their key will just be read from a > > > different location, but that's all hidden from the user. The only they > > > will have to change, is how they include that key on the final binary. > >=20 > > This is a reasonable summary I think. > >=20 > > The devicetree series I sent explains how to deal with the limitations > > here. Heinrich requested that I clarify this which I did. I fully > > expected that the revert would then be applied. But instead it seems > > there is not even agreement about the status quo (of use of devicetree > > in U-Boot). > >=20 > > OF_SEPARATE is used by the vast majority of boards, including most > > qemu builds. I think the OF_BOARD thing should probably be deleted. > > The OF_EMBED thing should not be used in production. It is needed with > > the EFI app though and I recently sent a series to support updating > > the DT there. > >=20 > > For OF_PRIOR_STAGE the prior state is responsible for supplying the > > DT, and needs to do so and meet U-Boot's requirements. I have clearly > > set that out in the devicetree patch. >=20 > Yes, and this was wrong. You cannot impose U-Boot's requirements on > other projects. This is true IF AND ONLY IF the requirements are not in a documented, reviewed and submitted binding. U-Boot is no more, but also no less, special in this regard. --=20 Tom --yY6OajYROBmoEVZC Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmE597MACgkQFHw5/5Y0 tyzo5gv/UhXR3yVofVdUlJa7aGgDUPd7vTACRH+fHNYut8Zce+wSYuJWTqtG3VmK AusXZxp12vlH1MX8SxJtZ99iQTEPWfnTeibl6/fHDYAR+mph4yzaqHDC0aXgv7Ku Yd3sB9wKdDlWFqPOKCnApSCdIbVCHoNXFvSB1p5lrHTpTZwWNiXZOPWpc9poYUA/ MT2fu+aaYMWZO5qzn3b0lzde/4nEb31q5cSpyNxs/RwKRkEJdyFebn+ZlB+ItVRo uaVEyWFa6TEJd8Iz5PL7XnDZT7JvS6bk8O1bUKJRL+qszDH1HuBxi3NYoCEAHdxV fiQkM7E9dUw47i0t4tQlQme+SHc6oUObOyPuf2nN+W0tqWMnHsJq7hBNYaYnKy9J 3grghqthjJRU/ykDcBE+awReBZGknWkhVJxkoQEXSHjurAZ6SqQzgYRzu/93T3+B Y4AN5ZKRiSzk9bpQna2ELGXouwGrmyGX/j/oMVbhnv5oUGBbpuTrJRdKpz5d2FmY +9eDuPZ+ =+qxg -----END PGP SIGNATURE----- --yY6OajYROBmoEVZC--