[RFC RESEND 1/2] efi: Add ESRT to the EFI system table

[AKASHI Takahiro]

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.
> >
>