From mboxrd@z Thu Jan  1 00:00:00 1970
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
Date: Mon, 15 Feb 2021 10:22:53 +0900
Subject: [RFC RESEND 1/2] efi: Add ESRT to the EFI system table
In-Reply-To: <35028b6c-fe0b-7f95-8612-e64c4a55818f@gmx.de>
References: <20210128132932.27218-1-jose.marinho@arm.com>
 <20210128132932.27218-2-jose.marinho@arm.com>
 <285257e0-eea7-e265-cfea-826117e7a56b@gmx.de>
 <20210129052649.GA27753@laputa>
 <35028b6c-fe0b-7f95-8612-e64c4a55818f@gmx.de>
Message-ID: <20210215012253.GB8853@laputa>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On Fri, Feb 12, 2021 at 03:17:30PM +0100, Heinrich Schuchardt wrote:
> On 29.01.21 06:26, AKASHI Takahiro wrote:
> > First of all, one comment:
> > It would be nice to have a list of what features are supported
> > and what are not in this patch series.
> > For example, with this patch, I suspect
> > - FwVersion in ESRT entry will never be updated at capsule update
> 
> According to the UEFI specification the ESRT should be updated
> 
> * at EFI_EVENT_GROUP_READY_TO_BOOT
> * when a device (with a Firmware Management Protocol) is added or removed
> * after Update Capsule
> * at EFI_EVENT_GROUP_EXIT_BOOT_SERVICES
> 
> At each of these events we can call the same function collection the
> information for a new ESRT by calling
> EFI_FIRMWARE_MANAGEMENT_PROTOCOL.GetImageInfo() and freeing the memory
> of the old instance.
> 
> Monitoring EFI_EVENT_GROUP_READY_TO_BOOT and
> EFI_EVENT_GROUP_EXIT_BOOT_SERVICESs seems redundant if we catch the
> other two.
> 
> > - LastAttemptVersion/LastAttemptStatus will not be sustained across reboots.
> 
> This information is provided by the Firmware Management Protocol (see
> 23.4.3 Mapping Firmware Management Protocol Descriptors to ESRT
> Entries). Jose's patches can only use the information provided by the
> code that Sughosh and you created.

Right. I have forgot that.

> If update status persistence is missing in the current implementation of
> the firmware management protocol, what are your plans for adding it?

No plan.
Since there is no notion of "versioning" in the current U-Boot firmware,
providing such information would be vendor-specific.

Sughosh may have his own idea relating to A/B update and anti-rollback
protection.

-Takahiro Akashi


> Best regards
> 
> Heinrich
> 
> >
> > So I'm not sure that the proposed implementation is useful
> > in a practical manner.
> >
>