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=-5.8 required=3.0 tests=BAYES_00,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 4E3EFC48BE5 for ; Tue, 15 Jun 2021 07:13:46 +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 23888613DB for ; Tue, 15 Jun 2021 07:13:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 23888613DB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id B166E81249; Tue, 15 Jun 2021 09:13:42 +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=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="aMDi9/4G"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 6CCD380EC6; Tue, 15 Jun 2021 09:13:41 +0200 (CEST) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 EA1C980EC6 for ; Tue, 15 Jun 2021 09:13:37 +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=takahiro.akashi@linaro.org Received: by mail-pl1-x634.google.com with SMTP id 69so7972388plc.5 for ; Tue, 15 Jun 2021 00:13:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=CYVpsdoCP1aXgEFvDVD7JdznD1tqQCvGZaxSiv/xzwQ=; b=aMDi9/4G2HZmH0w1kXeWII+p2l29XGIizfpS8mxVmWeZLlLmOwbxqeJjyMwZhqkt1C Yr1OKbZ6y1mYslpfUckvNFarxEXdRh+Bm/jCCBRQxBi91lI3/vGoXsUqTe+Ez1yfmhKE y8JLL1IF9aqXjEnc2emC3ciAL1Fcn6JyFwP8lCbVWYyEPpEWTmANufqM2StqSPZN6p8v HkhNvWmq2b6BEsZ+fkca/2MzshI6jnd6cNXDtbloTmpwnUuwgyQ7WcpsZITuPyG4n2QQ nbBK/HXGrlLvuUG/UQB3TMH1xPljOfE9DcaKn8rgeYhgQ+zrx0zVBzYa/gPNB7bY6Wlo 0hhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=CYVpsdoCP1aXgEFvDVD7JdznD1tqQCvGZaxSiv/xzwQ=; b=c453E7TyCqjt33zEZbwsPzmonuuH6Sjvg5mquz239lxISK7njN8yMonLJdJhDJKs6k boBnDaQJREC9OBFGuOKKMMipTnaic4pn6xuzLoitk9b6m5+j0B3yht8AD02kt/USSXs3 rmVlgRRRi/PUapTzIqE28e1oOhck+/nEL2IG5LU72HFTGwhDUQc2lhRsx8U2MpJXyQcj F2I36MD4F6JqkMThprSoS91xBtVZgd648VAmOHjWwGo/lAwHRx5+a9s4gB8j9Uf5oVuQ vpZCWFs/f4yeHNfPPeNbXNye7iQwHAma5h6su3JbAw25vMDrktZG/m2zh0EgJ80AjYDK 5pyQ== X-Gm-Message-State: AOAM532veX+jg0Yk6swk80pEZ3XETFqUYxOY+TDCS6Zl3I7r7RUmTo3T x2GSFvToy0Yb+toOA7rw1klYQw== X-Google-Smtp-Source: ABdhPJxndSO0trZm3eAzpKmkjfXyge9zsXI5nHe1NdVRGpcoRRwKR5E/RxOOvFBVgMRHEq1J/pxzyQ== X-Received: by 2002:a17:90b:517:: with SMTP id r23mr23226719pjz.209.1623741215954; Tue, 15 Jun 2021 00:13:35 -0700 (PDT) Received: from laputa (p3dd30534.tkyea130.ap.so-net.ne.jp. [61.211.5.52]) by smtp.gmail.com with ESMTPSA id t6sm1567246pjo.4.2021.06.15.00.13.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Jun 2021 00:13:35 -0700 (PDT) Date: Tue, 15 Jun 2021 16:13:31 +0900 From: AKASHI Takahiro To: Ilias Apalodimas Cc: xypron.glpk@gmx.de, masami.hiramatsu@linaro.org, Simon Glass , Mario Six , Michal Simek , Alexander Graf , u-boot@lists.denx.de Subject: Re: [PATCH] efi_loader: FMP cleanups Message-ID: <20210615071331.GA58885@laputa> Mail-Followup-To: AKASHI Takahiro , Ilias Apalodimas , xypron.glpk@gmx.de, masami.hiramatsu@linaro.org, Simon Glass , Mario Six , Michal Simek , Alexander Graf , u-boot@lists.denx.de References: <20210614151015.99992-1-ilias.apalodimas@linaro.org> <20210615015101.GA46087@laputa> <20210615044458.GA54329@laputa> <20210615055538.GA56793@laputa> <20210615064023.GA58428@laputa> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Tue, Jun 15, 2021 at 09:56:10AM +0300, Ilias Apalodimas wrote: > > > > > > [...] > > > > > They are fixing "different" problems relating ESRT generation. > > > > That is my point. > > > > > > > > > > Sure, but it's a minor clean up really. As I said the current code works > > > fine. So I dont really mind the fact that it breaks a sentence of the spec. > > > Hence I considered the cleanup and the mutual exclusive part to be really > > > minor. > > > > Yes, it's minor but still a different problem. > > Let me give you an example. > > If I correct a misspelling in a given code > > very close to the change, Heinrich would ask > > me to add a separate patch as it is simply not > > related. > > > > Moreover, from the viewpoint of maintenance (i.e. bisect ability), > > they should be separated from each other. > > > > > > > > > > > > > > > > > > Is there anything very specific that you can achieve with FIT capsules that > > [...] > > > > > > you can't achieve with RAW ones (or vice versa), that would justify having > > > > > them both present at the same time? > > > > > > > > Yes. > > > > We may have different *firmware* for different software components > > > > and different devices. For example, > > > > You have firmare like U-Boot binary and default variable storage > > > > in different partitions. > > > > On the other hand, you have an extra firmware for a particular > > > > peripheral, like PCI device or anything else, which comes > > > > from a 3rd party vendor of the device. > > > > The former may and can be packed into a single binary in FIT format. > > > > The latter can be used in a separate RAW format as the timing of > > > > updating those firmware is likely to be different. > > > > > > > > > > Sure that's a use case. But that's not a specific one, nor something you cant > > > do without both of them being installed. You can arguably just create a RAW > > > image for the second firmware and put the info into dfu_alt_info. > > > > Why do you stick to a single format? > > I think it's the other way around. Why wouldn't you? It's the easiest and > sanest thing to do when generating capsules. I don't know why you think it's the easiest. "mkeficapsule" can create any format of capsule file. (This is not true in the current form. but it's quite easy to enhance this command for this purpose.) > > We can reasonably assume that each FMP may > > have a different format. > > I think it's a very natural thing. > > The FMPs logic in the EFI spec is not tied to 'format', it's tied to 'device' > and currently both FMPs target the same device. the same device? What do you mean by 'same device'? I probably won't agree. > So my understanding is, that > in order to use it you need to: > 1. Create 2 capsules, 1 raw, 1 fmp. > 2. Set dfu_alt_info -> process RAW capsule. What do you mean by "process"? > 3. Set dfu_alt_info to something different -> process FIT capsule. No. What you need to do is to *add* definition for firmware in FIT. We can have a single definition of dfu_alt_info even if we use both FIT and RAW FMPs. > and by doing so the ESRTs will use one of the information found in > dfu_alt_info. So what? > > > > > > So unless we > > > have an example of a device that says "This firmware file can only be updated > > > by a FIT image, while the rest of the firmware is on a FAT filesystem", I don't > > > see any reason why we need to support that. The changes are not set in stone > > > anyway. The code was fine before the ESRT got involved. So all my patch > > > really does is make the current code useful when an ESRT is installed. We can > > > then break the spec on purpose (yes break it :>) ignore the OsIndications > > > bit and have fwupd working with U-Boot. This will have an actual impact on > > > devices and the code usability, since people will start using it. I prefer > > > this over adding a very cumbersome corner case, that's arguably no one will > > > ever need. > > > We can always go back and make them a config option in the future. But unless > > > we get a use case for it, I'd still prefer having them mutually exclusive, > > > rather than adding code for an imaginary device (which I really doubt anyone > > > will ever design). > > > > I don't think that the example I gave is a imaginary device. > > > > All of the devices I've tested and seen up to now are working fine with just > RAW capsules installed and I can't understand why a specific *format* should > play a role in the capsule creation. I don't get your point. I never said, "a specific format should play a role." > FITs are a nice way to get authentication and bundle things without having the > EFI capsule authentication code, but really apart from that those 2 are doing > the same thing. Yes, but why do we have to have the restriction? Different capsule files for different firmware/device may come from different owners of the firmware. > [...] > > > The ESRT code right now uses get_image_info from the FMP code and the FMP code > > > uses the dfu_alt_info to derive whatever information it needs. Both of these > > > concepts are trying to provide information about the running firmware. So if > > > we change that imho both of them should get that info from an abstracted > > > object (file/c struct in u-boot/whatever). But really I think using FMP to > > > fill ESRT entries is fine (at least for me). > > > > Well, dfu_alt_info can already be seen as abstracted object > > in terms of FMP. > > Yes but it can't handle the ESRT generation properly. So if you change that, > why leave the FMPs get_image_info, read the information differently? Again, I don't get your point. -Takahiro Akashi > > > > [...] > > > Yea me neither, but since the firmware runtime information are derived from > > > that, we don't have that many options. > > > > What do you mean by "options"? > > I don't see any point of trating .get_image_info and the information that get > emitted into an ERST differently. > > [...] > > Thanks > /Ilias