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 BD3F0C48BDF for ; Tue, 15 Jun 2021 06:56:21 +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 1A6DD61417 for ; Tue, 15 Jun 2021 06:56:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1A6DD61417 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 D389C801BE; Tue, 15 Jun 2021 08:56:18 +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="M82xy0Tn"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 7212580412; Tue, 15 Jun 2021 08:56:17 +0200 (CEST) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 51CA6800AA for ; Tue, 15 Jun 2021 08:56:14 +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=ilias.apalodimas@linaro.org Received: by mail-wr1-x42f.google.com with SMTP id z8so17045998wrp.12 for ; Mon, 14 Jun 2021 23:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ibZtcFr7JoRHG9gy+XzRtBktQP6cNfiTmsS6505NqXk=; b=M82xy0TnjGVAgJ8SehKuTZZpGtY0x6AGvxZ4dFh+ufF4tVyOoA+CemlAWmsmkiO3nJ 7tzXx2B2C0jbL8WRplTURvO9k36X0r7N0UafYNpfkVCBqe27we0DFTB3uCk7PmTFzuh7 KflKQf1OyAtl1qQwD78FzAN6fYnsiWwvzZ/dOxqme6Nk4M46jtmKN524FKNbDD7XWQbp FAunRUf2vE1yMUyO/6Nl852Fa2LOYP84+NgrV5iK09FyKITBTxuhgzrfe1u4Stj1Wbg2 zXB9aLGZYsPamceW3avURXugjuc6BDOwUVGw9jtlgdLdjECGzp0OLM6oaMFxeIg3C5gd 8TXA== 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:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ibZtcFr7JoRHG9gy+XzRtBktQP6cNfiTmsS6505NqXk=; b=RjbosNUb4kB/blBT1AnBb4lDKmbuE3kAvosvjaBcaT3qWbaxNrmYqu8ZVJwSHAjb6P e2+mLUqodvMBcswr36dkujx2z8o6vLYmKJzQB7dFlKky1OJ9n6EcD2QCgsXZYq9IGRrN 40M9jLGgS7d//mRn8fPyvbuuS2APWxJM1SjEVYzwDLtWq/ilDQx+c9b65Sjbzin7mBUy HiRErIKKUbXkHXHQOgIwR+8AU1P2w4iSxwHqyh+AECtmsi0kpFogfO4lfILG6YFOtqxd KOGUtocCUBhZaDbWS3jkRgno6g/wBChXNlZsRfTSXzQiF5pCE2WkHesqGrq2MFvuyv2M cYEA== X-Gm-Message-State: AOAM533/hhS0wg+KPAXVfXrvwLIYA200o1D+j6IHiTf0Ut/2hGd00eio XYANqlcukULHhhiulWmwF9f5/g== X-Google-Smtp-Source: ABdhPJw1uXlD/IPgFOZK+19hv3z/I6//zVxeqA+cRRCKeCT9ItnZVCS5RmL3Mn4AWrrfRVQTcADYTw== X-Received: by 2002:adf:e485:: with SMTP id i5mr23050307wrm.214.1623740173839; Mon, 14 Jun 2021 23:56:13 -0700 (PDT) Received: from enceladus (ppp-94-66-220-227.home.otenet.gr. [94.66.220.227]) by smtp.gmail.com with ESMTPSA id t4sm18091558wru.53.2021.06.14.23.56.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Jun 2021 23:56:13 -0700 (PDT) Date: Tue, 15 Jun 2021 09:56:10 +0300 From: Ilias Apalodimas To: AKASHI Takahiro , 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: 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: <20210615064023.GA58428@laputa> 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 > > > [...] > > > 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. > 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. 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. 3. Set dfu_alt_info to something different -> process FIT capsule. and by doing so the ESRTs will use one of the information found in dfu_alt_info. > > > 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. 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. [...] > > 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? > > [...] > > 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