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=-8.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PULL_REQUEST, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 DC8F7C433F5 for ; Fri, 10 Sep 2021 10:40:40 +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 0BFCE6054F for ; Fri, 10 Sep 2021 10:40:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 0BFCE6054F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.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 EAACD82DB2; Fri, 10 Sep 2021 12:40:37 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="LklFclmZ"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 6897C83265; Fri, 10 Sep 2021 12:40:36 +0200 (CEST) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 177D1822D7 for ; Fri, 10 Sep 2021 12:40:30 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=francois.ozog@linaro.org Received: by mail-ed1-x534.google.com with SMTP id r7so1825976edd.6 for ; Fri, 10 Sep 2021 03:40:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qmBgVOWHgaQwvf+y7eKECABbJ55tZ3rNStFE780xEjQ=; b=LklFclmZ+uQZFb8kMdRrbv7HzIakymXT2ZT2bBo5jCQ+YVShgGkQy8QSV320iBq7+a 8vKdGqa8vCTfge4+Fd441JGxmndNDO4gQ2pLLY3quCByj7zq3UYCGaA9OAIEydowrkGa 3l6JiBgln69rBl9hp3Y5lKorsonYLjz/NntdXUNF+unuOD/U5s5bYPRYr+hv4LV1ymcR AOfZDpm+fy5rQAa3HuZF9isxZ3j/FzU/znzPOlxG/Bx7PCIuj7oFAPxoViDA/Oj3lvGw UUyfR215KFSz0r9w2XdaQwgNnzphDDxGlJtCFoVYbzlvH1xlJ1pIiXTi0b+XmIgboXix Kixg== 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=qmBgVOWHgaQwvf+y7eKECABbJ55tZ3rNStFE780xEjQ=; b=TCbzWbDYZXq7BSTVOpvefiJaPK/zNk6s20zdok7qSPz5z4nNaugGWiMxnm6t7fI1L7 0qrnE+ppUD6mmwF7V107qcTP0f/KYM3hG36B6Ff+GkZ93UCvdO5Rx28lH7DFTc1d9NZM 6M8jWTkT0kb94ZjvOsIobAzm6padn0ViVoXQqgjx+POSB80NxSeRB1Oy70zmsDxsvrkz +qHVNM5RgM1KMYviIX/vGTy2cbfXPY+gAOBEzD9dlcVBY6eu6oR6/Hb89RRSBF9rI+Gg tq7MX3b7WziqNadO0NJBaqI62apaSgJLhubJmbz3xSr5IjQ7yGegLn8OPqFnIOIHEcEG DfhQ== X-Gm-Message-State: AOAM532wD385ipfEKKlTe/P4j1bPeVWXf96pOC7Xi3Q38FbhDwGifPUB /6RXONWe1OOBtsCZjRkjfvZS3C1C3l40ZMjnUhH/7g== X-Google-Smtp-Source: ABdhPJwg4dmPgqB1P9m4UVN0wg2x/DtUcauqC4aebBUHwymEg4O9ieCjTT5gLeFC55GJdmjFiwAbLPOUBX0bkh/1mXI= X-Received: by 2002:a50:ae21:: with SMTP id c30mr8289738edd.120.1631270429531; Fri, 10 Sep 2021 03:40:29 -0700 (PDT) MIME-Version: 1.0 References: <61e2e1cc-b474-84dd-eceb-bb86a59972be@gmx.de> <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> In-Reply-To: From: =?UTF-8?Q?Fran=C3=A7ois_Ozog?= Date: Fri, 10 Sep 2021 12:40:18 +0200 Message-ID: Subject: Re: Pull request for efi-2021-10-rc4 To: Simon Glass Cc: Heinrich Schuchardt , Tom Rini , U-Boot Mailing List , Alexander Graf , Masahisa Kojima , Ilias Apalodimas , AKASHI Takahiro Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 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 Simon, On Thu, 9 Sept 2021 at 22:08, Simon Glass wrote: > Hi Fran=C3=A7ois, > > On Thu, 9 Sept 2021 at 06:17, Fran=C3=A7ois Ozog > wrote: > > > > Hi > > > > I think it may be good to step back and talk about the why's rather the > how's. (some elements were discussed in DeviceTree Evolution technical > report) > > > > We are witnessing changes in the embedded products value chain when it > is not controlled in an integrated vertical market (such as as Android fo= r > phones or Chromebooks). End-product builders (car makers, robot makers...= ) > are willing to avoid paying over and over for the same things. One > identified solution for that is to implement clear boundaries of > responsibility between different supply chain providers. > > > > This led to the creation of Arm SystemReady: a contract between > firmware and OS. SystemReady defines UEFI *interface* (not to be confused > with EDK2) as the functional aspects and either ACPI or DT for the hardwa= re > description. At present three non-secure open source firmware projects ar= e > targeted for SysteReady implementation: EDK2, U-Boot and LinuxBoot. > SystemReady states that the hardware description is a "given" by the > platform: the OS does *not* come with the one it wants to use. I read > adoption by RISC V community of the EBBR recipe of SystemReady-IR to sign= al > we are addressing an important and concrete market need. > > > > To identify the consequences on the firmware world, let's drill down > into what it means for 4 identical boards that differ from the amount of > soldiered memory. > > > > The current practice is often to maintain TFA, OP-TEE, U-Boot and even > Linux with that information. This parallel maintenance can be as simple a= s > a single line of code (a #define in TFA a single) or a whole structure of > the memory map and assumptions crippled throughout the U-Boot code. The > good things is that it avoids need for communication between firmware > elements. But if we assume that the tier1 integrator is dealing with U-Bo= ot > and the board vendor provides TF-A and OP-TEE, it makes Tier 1 integrator > life complicated to also deal with the memory size aspect. Another exampl= e > of the problems of parallel maintenance: TrustZone is often used by the > SoC/board vendor to stick platform code. But car vendors want to stick in > DRM, digital wallets, insurance company, rental company trusted > applications. In that case, the product maker should be able to easily > control TrustZone parameters. That would be greatly facilitated by having > to change only one parameter in one project. Looking at a particular case= , > it has been awfully difficult to update just the secure memory size: sing= le > line of codes in TFA, U-Boot code and structures had to be changed to > accommodate a secure memory size change. > > > > So if you stop thinking one single entity controls all aspects of > firmware (secure, non-secure, and beyond) as well as operating systems, > there are a number of things to do. And the majority of Linaro patches ar= e > delivering on making this happen. > > > > I don't say that all projects should follow that. I say that there must > be a scheme to properly address SystemReady defined DT lifecycle because = it > is addressing a major market demand (yes not universal but major). > > > > Other considerations: > > - There may be co-existing alternate schemes such as VBE or Android > Verified Boot in U-Boot. SystemReady is not the one that has to be used a= ll > the time. It serves a big market but not all markets. > > - DeviceTree abstract language can be used anywhere as a similar > technology as protobufs: to represent complex information. For example I > see great benefits in using this in blob lists But the lifecycle and > content of the one DTB that will reach the OS must be handled as part of > the firmware to OS ABI. > > - The DTB lifecycle will be the same in U-Boot and LinuxBoot so that > ultimately product vendors may simply choose which non-secure firmware th= ey > want. It means that information passing between firmware components (call > it HOBs or blob lists) should be standardized across non-secure firmwares= . > > To this point I think I agree, so far as I understand it. > > (please don't use protobuf in firmware...it requires code generation) > > > - U-Boot private configuration have no room in such an OS DTB (the one > handover by firmware to OS). If U-Boot wants to use DTB format to store > some variables that are stored in the U-Boot environment file today: > perfect, but that's a separate object from OS DTB. Should U-Boot want to > inject some elements through fixups in the OS DTB, fine providing that > there is a standardized binding for that. - There may be questions on som= e > elements. For instance inventory information such as part numbers, board > name... Some are defined in DT, some are also defined in SMBIOS, some are > defined only in SMBIOS. Based on SystemReady compliance and distro tests > field feedback, it sounds like we will need to revisit this and be cleare= r > and more exhaustive in how we deal with those parameters. Regardless of > that, one need to think of who is providing the information (say the seri= al > number) so that signing firmware is not making the process stiff and > complicated (simple for an integrated vertical market, complex in > multiparty value chain). > > Here you are, with respect and in my opinion, going off into the weeds. > > U-Boot *absolutely requires* some properties and nodes in order to > function correctly. In some special cases, this can be avoided, but in > general, it is required. Examples are the u-boot,dm- tags and the > binman image definition, The current 'config' node is there also. > > Without them you cannot make use of the available U-Boot features. I > now see that this point is the root of much of the confusion and > misunderstanding of the past month or so. We must resolve it and put > it to bed. > I think I understand your point and still view things differently. The DT passed to the OS shall essentially be a downstream information passing construct (from TF-A to U-Boot, from U-Boot to TFA). Should U-Boot need information from Linux (what you describe above) then it is about downstream to upstream and that is configuration information. The configuration information storage is irrelevant to the OS. So I would place that in either U-Boot environment or U-Boot private DT. In EDK2 or LinuxBoot, the information you refer to is kept separate from ACPI table or DT. > (Honestly I cannot fathom why we would want to use SMBIOS in this day > and age :-) but that does not relate to the point at issue here) > (Well, I admit I am not a SMBIOS fan either....if we could forget entirely that would be great and I would prefer the OS guys to introduce proper abstraction to get the information rather than just being a passive passthrough for SMBIOS related information). > > Regards, > Simon > > > > > > > > > > On Thu, 9 Sept 2021 at 10:57, Simon Glass wrote: > >> > >> Hi Heinrich, > >> > >> On Sat, 4 Sept 2021 at 12:08, Heinrich Schuchardt > wrote: > >> > > >> > > >> > > >> > Am 4. September 2021 19:39:49 MESZ schrieb Tom Rini < > trini@konsulko.com>: > >> > >On Sat, Sep 04, 2021 at 07:03:48PM +0200, Heinrich Schuchardt wrote= : > >> > >> > >> > >> > >> > >> Am 4. September 2021 16:37:22 MESZ schrieb Tom Rini < > trini@konsulko.com>: > >> > >> >On Sat, Sep 04, 2021 at 03:08:38PM +0200, Heinrich Schuchardt > wrote: > >> > >> >> > >> > >> >> > >> > >> >> Am 4. September 2021 15:01:11 MESZ schrieb Tom Rini < > trini@konsulko.com>: > >> > >> >> >On Sat, Sep 04, 2021 at 11:56:47AM +0200, Heinrich Schuchardt > wrote: > >> > >> >> > > >> > >> >> >> Dear Tom, > >> > >> >> >> > >> > >> >> >> The following changes since commit > 94509b79b13e69c209199af0757afbde8d2ebd6d: > >> > >> >> >> > >> > >> >> >> btrfs: Use default subvolume as filesystem root > (2021-09-01 10:11:24 > >> > >> >> >> -0400) > >> > >> >> >> > >> > >> >> >> are available in the Git repository at: > >> > >> >> >> > >> > >> >> >> https://source.denx.de/u-boot/custodians/u-boot-efi.git > >> > >> >> >> tags/efi-2021-10-rc4 > >> > >> >> >> > >> > >> >> >> for you to fetch changes up to > 1dfa494610c5469cc28cf1f8538abf4be6c00324: > >> > >> >> >> > >> > >> >> >> efi_loader: fix efi_tcg2_hash_log_extend_event() paramete= r > check > >> > >> >> >> (2021-09-04 09:15:09 +0200) > >> > >> >> >> > >> > >> >> >> > ---------------------------------------------------------------- > >> > >> >> >> Pull request for efi-2021-10-rc4 > >> > >> >> >> > >> > >> >> >> Documentation: > >> > >> >> >> > >> > >> >> >> Remove invalid reference to configuration variable in > UEFI doc > >> > >> >> >> > >> > >> >> >> UEFI: > >> > >> >> >> > >> > >> >> >> Parameter checks for the EFI_TCG2_PROTOCOL > >> > >> >> >> Improve support of preseeding UEFI variables. > >> > >> >> >> Correct the calculation of the size of loaded images. > >> > >> >> >> Allow for UEFI images with zero VirtualSize > >> > >> >> >> > >> > >> >> >> > ---------------------------------------------------------------- > >> > >> >> >> 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, > DeployedMode > >> > >> >> >> efi_loader: correct determination of secure boot stat= e > >> > >> >> >> > >> > >> >> >> Masahisa Kojima (3): > >> > >> >> >> efi_loader: add missing parameter check for > EFI_TCG2_PROTOCOL api > >> > >> >> >> efi_loader: fix boot_service_capability_min calculati= on > >> > >> >> >> efi_loader: fix efi_tcg2_hash_log_extend_event() > parameter check > >> > >> >> > > >> > >> >> >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+feuyRyWf0hNkf2triB4DR4= UFBQ@mail.gmail.com/ > >> > >> >> > > >> > >> >> >So at this point, are you asserting there is nothing to rever= t? > >> > >> >> > >> > >> >> Never. Simons "revert" is breaking functionality. The concept > for suporting blobs in devicetrees supplied by a prior bootstage has not > been defined yet. > >> > >> > > >> > >> >And to be clearer, reverting something that was introduced in on= e > 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. External > projects > >> > >> >may not depend on some feature introduced at -rcN unless they're > willing > >> > >> >to accept that some changes could happen before release. > >> > >> > > >> > >> > >> > >> There is no value delivered by Simon's series. Neither does the > image get smaller nor does it fix anything. If he wants to enforce a > design, it must work for all use cases. But this requires some conceptual > work. > >> > > > >> > >Yes, and what's the rush to not do the conceptual work? If I recal= l > >> > >part of the thread correctly, yes, Simon didn't get his objections = 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 reques= t. > >> > >What he had said wouldn't have changed if he had gotten the email > out a > >> > >few days earlier. > >> > > > >> > >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 related > 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. > >> > > > >> > > >> > > >> > There is nothing wrong with the current code. > >> > >> The current code is misconceived and I did go to great effort to > >> explain that in the 'devicetree' series. > >> > >> > > >> > It is Simon's concept of blobs in devicetrees that is borked in that > it ignores QEMU and any board that gets the DT from a prior boot stage. > >> > >> That's because I was completely unaware of this strange back-door > >> approach. It would have helped a lot if someone had bothered to create > >> some documentation for the design. Then I would have seen the problem > >> immediately. > >> > >> Anyway, it is now covered by the above series. The use of devicetree > >> in U-Boot is very clear, I think. > >> > >> > > >> > Simon's patches have no functional end. So what do you mean by "same > functional end"? > >> > >> So, please, again, will someone apply the revert before the release > >> and people start relying on it. > >> > >> Regards, > >> Simon > > > > > > > > -- > > Fran=C3=A7ois-Fr=C3=A9d=C3=A9ric Ozog | Director Business Development > > T: +33.67221.6485 > > francois.ozog@linaro.org | Skype: ffozog > > > --=20 Fran=C3=A7ois-Fr=C3=A9d=C3=A9ric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog