Adding Andrea On Wed, 24 Mar 2021 at 13:55, Joanna Farley via TF-A < t...@lists.trustedfirmware.org> wrote:
> Hi Harb and others, > > > > This thread is now multi-mailing list and I can see some broader needs and > opinions on aspects not directly defined by the TF-A project such as > differing information exchange formats. However, this is definitely > something the TF-A project can try and help provide enablement for to help > with the goal of supplying support for single or common TF-A binaries builds > for different images. TF-A already have some limited support in this space > and are considering how this can be extended given some of the needs > expressed here. Folks on the TF-A project are studying the below and will > propose soon some ideas on how TF-A could provide more versatile enablement > in this space shortly. > > > > Thanks > > > > Joanna > > > > *From: *TF-A <tf-a-boun...@lists.trustedfirmware.org> on behalf of > François Ozog via TF-A <t...@lists.trustedfirmware.org> > *Reply to: *François Ozog <francois.o...@linaro.org> > *Date: *Wednesday, 24 March 2021 at 08:34 > *To: *Harb Abdulhamid OS <abdulha...@os.amperecomputing.com> > *Cc: *"t...@lists.trustedfirmware.org" <t...@lists.trustedfirmware.org>, > Simon Glass <s...@chromium.org>, Boot Architecture Mailman List < > boot-architecture@lists.linaro.org>, Paul Isaac's <paul.isa...@linaro.org>, > Ron Minnich <rminn...@google.com> > *Subject: *Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for > information passing between boot stages > > > > > > > > On Tue, 23 Mar 2021 at 23:39, Harb Abdulhamid OS < > abdulha...@os.amperecomputing.com> wrote: > > Hello Folks, > > Appreciate the feedback and replies on this. Glad to see that there is > interest in this topic. 😊 > > > > I try to address the comments/feedback from Francois and Simon below…. > > > > @François Ozog <francois.o...@linaro.org> – happy to discuss this on a > zoom call. I will make that time slot work, and will be available to > attend April 8, 4pm CT. > > > > Note that I’m using the term “HOB” here more generically, as there are > typically vendor specific structures beyond the resource descriptor HOB, > which provides only a small subset of the information that needs to be > passed between the boot phases. > > > > The whole point here is to provide mechanism to develop firmware that we > can build ARM Server SoC’s that support **any** BL33 payload (e.g. EDK2, > AptioV, CoreBoot, and maybe even directly boot strapping LinuxBoot at some > point). In other-words, we are trying to come up with a TF-A that would > be completely agnostic to the implementation of BL33 (i.e. BL33 is built > completely independently by a separate entity – e.g. an ODM/OEM). > > > > Keep in mind, in the server/datacenter market segment we are not building > vertically integrated systems with a single entity compiling > firmware/software stacks like most folks in TF-A have become use to. There > are two categories of higher level firmware code blobs in the > server/datacenter model: > > 1. “SoC” or “silicon” firmware – in TF-A this may map to BL1, BL2, > BL31, and **possibly** one or more BL32 instances > 2. “Platform” or “board” firmware – in TF-A this may map to BL33 and * > *possibly** one or more BL32 instances. > > > > Even the platform firmware stack could be further fragmented by having > multiple entities involved in delivering the entire firmware stack: IBVs, > ODMs, OEMs, CSPs, and possibly even device vendor code. > > > > To support a broad range of platform designs with a broad range of memory > devices, we need a crisp and clear contract between the SoC firmware that > initializes memory (e.g. BL2) and how that platform boot firmware (e.g. > BL33) gathers information about what memory that was initialized, at what > speeds, NUMA topology, and many other relevant information that needs to be > known and comprehended by the platform firmware and eventually by the > platform software. > > > > I understand the versatility of DT, but I see two major problems with DT: > > - DT requires more complicated parsing to get properties, and even > more complex to dynamically set properties – this HOB structures may need > to be generated in boot phases where DDR is not available, and therefore we > will be extremely memory constrained. > - DT is probably overkill for this purpose – We really just want a > list of pointers to simple C structures that code cast (e.g. JEDEC SPD data > blob) > > > > I think that we should not mix the efforts around DT/ACPI specs with what > we are doing here, because those specs and concepts were developed for a > completely different purpose (i.e. abstractions needed for OS / RTOS > software, and not necessarily suitable for firmware-to-firmware hand-offs). > > > > Frankly, I would personally push back pretty hard on defining SMC’s for > something that should be one way information passing. Every SMC we add is > another attack vector to the secure world and an increased burden on the > folks that have to do security auditing and threat analysis. I see no > benefit in exposing these boot/HOB/BOB structures at run-time via SMC > calls. > > > > Please do let me know if you disagree and why. Look forward to discussing > on this thread or on the call. > > > > I am not tied to a particular data representation and using SMC to just > pass data structures is overkill as you say. The SMC model seems useful to > do complex things like device assignment to secure world. Or something else > we don't have yet an idea. > > Let's say there is one board with two eMMCs. This board is used by two > OEMs. One is fine with all eMMCs in non-secure world, the other wants to > assign the eMMC to secure world. > > That's something that is related to inter-firmware component communication > to be authoritative. > > We need to avoid "little arrangements between friends" that exist today, > where the Linux provided DT is pruned from the second eMMC to accommodate > the use case. We need to think the OS as "immutable" across platforms and > adapt to available hardware (not come with its own description of what the > board is). > > May be a hob would contain a DT overlay or ACPI equivalent that would do > the job. > > In that case we do not need SMC. > > What do you think of this use case? > > > > @Simon Glass <s...@chromium.org> - Thanks for the pointer to bloblist. > I briefly reviewed and it seems like a good baseline for what we may be > looking for. > > > > That being said, I would say that there is some benefit in having some > kind of unique identifiers (e.g. UUID or some unique signature) so that we > can tie standardized data structures (based on some future TBD specs) to a > particular ID. For example, if the TPM driver in BL33 is looking for the > TPM structure in the HOB/BOB list, and may not care about the other data > blobs. The driver needs a way to identify and locate the blob it cares > about. > > > > I guess we can achieve this with the tag, but the problem with tag when > you have eco-system with a lot of parties doing parallel development, you > can end up with tag collisions and folks fighting about who has rights to > what tag values. We would need some official process for folks to register > tags for whatever new structures we define, or maybe some tag range for > vendor specific structures. This comes with a lot of pain and > bureaucracy. On the other hand, UUID has been a proven way to make it easy > to just define your own blobs with **either** standard or vendor specific > structures without worry of ID collisions between vendors. > > > > We can probably debate whether there is any value in GUID/UUID or not > during the call… but again, boblist seems like a reasonable starting point > as an alternative to HOB. > > > > Thanks, > > --Harb > > > > *From:* François Ozog <francois.o...@linaro.org> > *Sent:* Tuesday, March 23, 2021 10:00 AM > *To:* François Ozog <francois.o...@linaro.org>; Ron Minnich < > rminn...@google.com>; Paul Isaac's <paul.isa...@linaro.org> > *Cc:* Simon Glass <s...@chromium.org>; Harb Abdulhamid OS < > abdulha...@os.amperecomputing.com>; Boot Architecture Mailman List < > boot-architecture@lists.linaro.org>; t...@lists.trustedfirmware.org > *Subject:* Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for > information passing between boot stages > > > > +Ron Minnich <rminn...@google.com> +Paul Isaac's <paul.isa...@linaro.org> > > > > Adding Ron and Paul because I think this interface should be also > benefiting LinuxBoot efforts. > > > > On Tue, 23 Mar 2021 at 11:17, François Ozog via TF-A < > t...@lists.trustedfirmware.org> wrote: > > Hi, > > > > I propose we cover the topic at the next Trusted Substrate > <https://collaborate.linaro.org/display/TS/Trusted+Substrate+Home> zoom > call <https://linaro-org.zoom.us/j/94563644892> on April 8th 4pm CET. > > > > The agenda: > > ABI between non-secure firmware and the rest of firmware (EL3, S-EL1, > S-EL2, SCP) to adapt hardware description to some runtime conditions. > > runtime conditions here relates to DRAM size and topology detection, > secure DRAM memory carvings, PSCI and SCMI interface publishing. > > > > For additional background on existing metadata: UEFI Platform > Initialization Specification Version 1.7 > <https://uefi.org/sites/default/files/resources/PI_Spec_1_7_final_Jan_2019.pdf> > , 5.5 Resource Descriptor HOB > > Out of the ResourceType we care about is EFI_RESOURCE_SYSTEM_MEMORY. > > This HOB lacks memory NUMA attachment or something that could be related > to fill SRAT table for ACPI or relevant DT proximity domains. > > HOB is not consistent accros platforms: some platforms (Arm) lists memory > from the booting NUMA node, other platforms (x86) lists all memory from all > NUMA nodes. (At least this is the case on the two platforms I tested). > > > > There are two proposals to use memory structures from SPL/BLx up to the > handover function (as defined in the Device Tree technical report > <https://docs.google.com/document/d/1CLkhLRaz_zcCq44DLGmPZQFPbYHOC6nzPowaL0XmRk0/edit?usp=sharing>) > which can be U-boot (BL33 or just U-Boot in case of SPL/U-Boot scheme) or > EDK2. > > I would propose we also discuss possibility of FF-A interface to actually > query information or request actions to be done (this is a model actually > used in some SoCs with proprietary SMC calls). > > > > Requirements (to be validated): > > - ACPI and DT hardware descriptions. > > - agnostic to boot framework (SPL/U-Boot, TF-A/U-Boot, TF-A/EDK2) > > - agnostic to boot framework (SPL/U-Boot, TF-A/U-Boot, TF-A/EDK2, > TF-A/LinuxBoot) > > - at least allows complete DRAM description and "persistent" usage > (reserved areas for secure world or other usages) > > - support secure world device assignment > > > > Cheers > > > > FF > > > > > > On Mon, 22 Mar 2021 at 19:56, Simon Glass <s...@chromium.org> wrote: > > Hi, > > Can I suggest using bloblist for this instead? It is lightweight, > easier to parse, doesn't have GUIDs and is already used within U-Boot > for passing info between SPL/U-Boot, etc. > > Docs here: > https://github.com/u-boot/u-boot/blob/master/doc/README.bloblist > Header file describes the format: > https://github.com/u-boot/u-boot/blob/master/include/bloblist.h > > Full set of unit tests: > https://github.com/u-boot/u-boot/blob/master/test/bloblist.c > > Regards, > Simon > > On Mon, 22 Mar 2021 at 23:58, François Ozog <francois.o...@linaro.org> > wrote: > > > > +Boot Architecture Mailman List <boot-architecture@lists.linaro.org> > > > > standardization is very much welcomed here and need to accommodate a very > > diverse set of situations. > > For example, TEE OS may need to pass memory reservations to BL33 or > > "capture" a device for the secure world. > > > > I have observed a number of architectures: > > 1) pass information from BLx to BLy in the form of a specific object > > 2) BLx called by BLy by a platform specific SMC to get information > > 3) BLx called by BLy by a platform specific SMC to perform Device Tree > > fixups > > > > I also imagined a standardized "broadcast" FF-A call so that any firmware > > element can either provide information or "do something". > > > > My understanding of your proposal is about standardizing on architecture > 1) > > with the HOB format. > > > > The advantage of the HOB is simplicity but it may be difficult to > implement > > schemes such as pruning a DT because device assignment in the secure > world. > > > > In any case, it looks feasible to have TF-A and OP-TEE complement the > list > > of HOBs to pass information downstream (the bootflow). > > > > It would be good to start with building the comprehensive list of > > information that need to be conveyed between firmware elements: > > > > information. | authoritative entity | reporting entity | information > > exchanged: > > dram | TFA | TFA | > > <format to be detailed, NUMA topology to build the SRAT table or DT > > equivalent?> > > PSCI | SCP | TFA? | > > SCMI | SCP or TEE-OS | TFA? TEE-OS?| > > secure SRAM | TFA. | TFA. | > > secure DRAM | TFA? TEE-OS? | TFA? TEE-OS? | > > other? | | > > | > > > > Cheers > > > > FF > > > > > > On Mon, 22 Mar 2021 at 09:34, Harb Abdulhamid OS via TF-A < > > t...@lists.trustedfirmware.org> wrote: > > > > > Hello Folks, > > > > > > > > > > > > I'm emailing to start an open discussion about the adoption of a > concept > > > known as "hand-off blocks" or HOB to become a part of the TF-A Firmware > > > Framework Architecture (FFA). This is something that is a pretty major > > > pain point when it comes to the adoption of TF-A in ARM Server SoC’s > > > designed to enable a broad range of highly configurable datacenter > > > platforms. > > > > > > > > > > > > > > > > > > What is a HOB (Background)? > > > > > > --------------------------- > > > > > > UEFI PI spec describes a particular definition for how HOB may be used > for > > > transitioning between the PEI and DXE boot phases, which is a good > > > reference point for this discussion, but not necessarily the exact > solution > > > appropriate for TF-A. > > > > > > > > > > > > A HOB is simply a dynamically generated data structure passed in > between > > > two boot phases. This is information that was obtained through > discovery > > > and needs to be passed forward to the next boot phase *once*, with no > API > > > needed to call back (e.g. no call back into previous firmware phase is > > > needed to fetch this information at run-time - it is simply passed one > time > > > during boot). > > > > > > > > > > > > There may be one or more HOBs passed in between boot phases. If there > are > > > more than one HOB that needs to be passed, this can be in a form of a > "HOB > > > table", which (for example) could be a UUID indexed array of pointers > to > > > HOB structures, used to locate a HOB of interest (based on UUID). In > such > > > cases, instead of passing a single HOB, the boot phases may rely on > passing > > > the pointer to the HOB table. > > > > > > > > > > > > This has been extremely useful concept to employ on highly configurable > > > systems that must rely on flexible discovery mechanisms to initialize > and > > > boot the system. This is especially helpful when you have multiple > > > > > > > > > > > > > > > > > > Why do we need HOBs in TF-A?: > > > > > > ----------------------------- > > > > > > It is desirable that EL3 firmware (e.g. TF-A) built for ARM Server SoC > in > > > a way that is SoC specific *but* platform agnostic. This means that a > > > single ARM SoC that a SiP may deliver to customers may provide a single > > > TF-A binary (e.g. BL1, BL2, BL31) that could be used to support a broad > > > range of platform designs and configurations in order to boot a > platform > > > specific firmware (e.g. BL33 and possibly even BL32 code). In order to > > > achieve this, the platform configuration must be *discovered* instead > of > > > statically compiled as it is today in TF-A via device tree based > > > enumeration. The mechanisms of discovery may differ broadly depending > on > > > the relevant industry standard, or in some cases may have rely on SiP > > > specific discovery flows. > > > > > > > > > > > > For example: On server systems that support a broad range DIMM memory > > > population/topologies, all the necessary information required to boot > is > > > fully discovered via standard JEDEC Serial Presence Detect (SPD) over > an > > > I2C bus. Leveraging the SPD bus, may platform variants could be > supported > > > with a single TF-A binary. Not only is this information required to > > > initialize memory in early boot phases (e.g. BL2), the subsequent boot > > > phases will also need this SPD info to construct a system physical > address > > > map and properly initialize the MMU based on the memory present, and > where > > > the memory may be present. Subsequent boot phases (e.g. BL33 / UEFI) > may > > > need to generate standard firmware tables to the operating systems, > such as > > > SMBIOS tables describing DIMM topology and various ACPI tables (e.g. > SLIT, > > > SRAT, even NFIT if NVDIMM's are present). > > > > > > > > > > > > In short, it all starts with a standardized or vendor specific > discovery > > > flow in an early boot stage (e.g. BL1/BL2), followed by the passing of > > > information to the next boot stages (e.g. BL31/BL32/BL33). > > > > > > > > > > > > Today, every HOB may be a vendor specific structure, but in the future > > > there may be benefit of defining standard HOBs. This may be useful for > > > memory discovery, passing the system physical address map, enabling TPM > > > measured boot, and potentially many other common HOB use-cases. > > > > > > > > > > > > It would be extremely beneficial to the datacenter market segment if > the > > > TF-A community would adopt this concept of information passing between > all > > > boot phases as opposed to rely solely on device tree enumeration. > This is > > > not intended to replace device tree, rather intended as an alternative > way > > > to describe the info that must be discovered and dynamically generated. > > > > > > > > > > > > > > > > > > Conclusion: > > > > > > ----------- > > > > > > We are proposing that the TF-A community begin pursuing the adoption of > > > HOBs as a mechanism used for information exchange between each boot > stage > > > (e.g. BL1->BL2, BL2->BL31, BL31->BL32, and BL31->BL33)? Longer term we > > > want to explore standardizing some HOB structures for the BL33 phase > (e.g. > > > UEFI HOB structures), but initially would like to agree on this being a > > > useful mechanism used to pass information between each boot stage. > > > > > > > > > > > > Thanks, > > > > > > --Harb > > > > > > > > > > > > > > > > > > > > > -- > > > TF-A mailing list > > > t...@lists.trustedfirmware.org > > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > > > > > > > > -- > > François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* > > T: +33.67221.6485 > > francois.o...@linaro.org | Skype: ffozog > > _______________________________________________ > > boot-architecture mailing list > > boot-architecture@lists.linaro.org > > https://lists.linaro.org/mailman/listinfo/boot-architecture > > > > > -- > > [image: Image removed by sender.] > > *François-Frédéric Ozog* | *Director Linaro Edge & Fog Computing Group* > > T: +33.67221.6485 > francois.o...@linaro.org | Skype: ffozog > > > > -- > TF-A mailing list > t...@lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > > > > -- > > [image: Image removed by sender.] > > *François-Frédéric Ozog* | *Director Linaro Edge & Fog Computing Group* > > T: +33.67221.6485 > francois.o...@linaro.org | Skype: ffozog > > > > > > > -- > > [image: Image removed by sender.] > > *François-Frédéric Ozog* | *Director Linaro Edge & Fog Computing Group* > > T: +33.67221.6485 > francois.o...@linaro.org | Skype: ffozog > > > -- > TF-A mailing list > t...@lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletc...@linaro.org | Skype: billfletcher2020 _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
