[TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages

[François Ozog]

Hi,

I promised to send my summary of Trusted Substrate architecture council
call on HOBs, here it is:

Topics where there seem to be consensus



   - Scope include diverse firmware flows (U-Boot/SPL, TFA, CoreBoot…) on
   difference architectures (Arm, RiscV)
   - Definitions: The Hand Over Function is the firmware component that
   hands off to the booted payload = {OS/Hypervisor/Grub/Shim}.
   - Hand Over Function can be EDK2, U-Boot or LinuxBoot.
   - The HOF, through ACPI or DT is responsible to describe what shall be
   controlled and partly how (some parameters)
   - *There is information that can only be discovered at runtime and needs
   to be conveyed through the HOF to the booted payload.*


   - The proposal is to convey that dynamic information in the form of
   HandOverBlocks (HOBs) whose format is yet to be defined and built as a
   linked list of objects. The other proposal to use call backs (mmc calls or
   equivalent) from HOF to firmware is rejected. In Arm architecture, that
   choice does not preclude some firmware components to use SCMI calls into
   SCP to obtain authoritative information.


   - The firmware components shall not care about what is the actual
   HOF:the format is standard regardless if HOF is EDK2, U-Boot or LinuxBoot.
   In TF-A words, the HOBs become part of the input ABI for BL33.



Characteristics to consider about HOBs:

   - HOBs can be built by very early components and must fit into highly
   constrained SRAM
   - A HOB may be passed between different firmware components, secure and
   non-secure.
   - A HOB can be built by secure and non-secure firmware components
   - An information can have a single format: no alternative representation
   is allowed. In other words if the information is passed as a data structure
   it cannot be represented by a DT fragment by another implementation and
   conversely.



Topics that need more discussion



   - HOBs need a way to be identified: UUID, ID, hybrid (like Platform
   Initialization).


*My views: the hybrid allows constraints firmware components to be using
simple IDs and richer components may want leverage UUIDs (same as Platform
Initialization).*



   - HOB format: binary information; just static structure or flatten
   device tree fragments/overlays.


*My views: again hybrid approach seem very efficient. Static structures for
memory information, DT fragment for device assignment (for non-secure
partitions or for secure world / secure partitions). Typically I would
imagine a UUID HOB with a DT fragment seems just good. This is actually
implemented like that with Platform Initialization:*

*HOBs are identified by a simple ID, out of IDs are
EFI_HOB_RESOURCE_DESCRIPTOR for DRAM description and EFI_HOB_GUID_TYPE that
contains something identified by a GUID. There is a GUID used in the
context of EDK2 to actually contain a DT fragment today.*


Cheers


FF

On Mon, 12 Apr 2021 at 16:49, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:

> > From: Simon Glass <sjg at chromium.org>
> > Date: Fri, 9 Apr 2021 06:19:08 +1200
> >
> > Here are a few thoughts on UUIDs.
> > Why a UUID/GUID is probably not the answer
> >
> > sjg, 30-Mar-21
> > Code is for humans
> >
> > Code should be readable, so far as possible.
> >
> > This is not readable:
> >
> > #define FSP_HOB_RESOURCE_OWNER_SMM_PEI_SMRAM_GUID \
> >
> > EFI_GUID(0x6dadf1d1, 0xd4cc, 0x4910, \
> >
> > 0xbb, 0x6e, 0x82, 0xb1, 0xfd, 0x80, 0xff, 0x3d)
> >
> > This is readable:
> >
> > enum {
> >
> > BLOBLISTT_SPL_HANDOFF = 123,
> >
> > };
> > UUID is more like a hash than a sequence number
>
> No kidding.  Try figuring out what an ACPI ASL methods like _DSM and
> _OSC are supposed to do when trying to figure out what the code is
> supposed to do.
>
> They're terrible to grep for in source code since there is no uniform
> way to format them in the code.
>
> And then there is the issue of byte order of course.
> _______________________________________________
> boot-architecture mailing list
> boot-architecture at lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/boot-architecture
>


-- 
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog