- boot-architecture - lists.linaro.org

by Miklos Balint

To += op-tee(a)lists.trustedfirmware.org<mailto:op-tee@lists.trustedfirmware.org> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of François Ozog via TF-A Sent: 26 March 2021 19:08 To: Heinrich Schuchardt <xypron.glpk(a)gmx.de> Cc: tf-a(a)lists.trustedfirmware.org; Boot Architecture Mailman List <boot-architecture(a)lists.linaro.org>; Ilias Apalodimas <ilias.apalodimas(a)linaro.org> Subject: Re: [TF-A] Firmware FuSa workshop Le ven. 26 mars 2021 à 18:42, Heinrich Schuchardt <xypron.glpk(a)gmx.de<mailto:xypron.glpk@gmx.de>> a écrit : On 26.03.21 16:05, François Ozog wrote: > Hi, > > > Linaro is conducting an opportunity assessment to make OP-TEE ready for > functional safety sensitive environments. The goal is to present a plan to > Linaro members by the end of July 2021. > > The scope of the research is somewhat bigger because we can’t think of > OP-TEE without thinking of Trusted Firmware and Hafnium. The plan will > though not address those (unless we recognize we have to). We don’t think > U-Boot shall be part of the picture but we are welcoming contradictory > points of views. Hello François, Some boards boot via SPL->TF-A->U-Boot. Here U-Boot's SPL is relevant for OP-TEE's security. U-Boot can save variables via OP-TEE (implemented by Ilias). In this case OP-TEE has an implication on secure boot. I fully understand that these scenarios are not in the focus of the workshop. it may if companies have this particular flow in mind for safety certification. Our goal is not to make all boot flows safety ready but to identify which ones we need to consider. And the workshop may help in this identification. Best regards Heinrich > > We are organizing a 2 hours workshop on April 15th 9am CET to mostly hear > about use cases and ideas about Long Term Support requirements . We will > present the state of the research. > > The first use case is booting a safety certified type-1 hypervisor (open > source or commercial is irrelevant). > > But we know there are many more: please be ready to contribute. > > We think of more radical use cases: a safety payload is actually loaded as > a Secure Partition on top of Hafnium with OP-TEE or Zephyr used as a device > backends. In other words, Trust Zone hosts both safety and security worlds > , EL3 being the « software root of trust » pivot world. In those cases, > some cores never go out of secure state… > > > Agenda (to be refined) > > - > > Vision > - > > State of the research > <https://docs.google.com/presentation/u/0/d/1jWqu39gCF-5XzbFkodXsiVNJJLUN88B…> > - > > Use cases discussion > - > > What is the right scope? > - > > “Who do what” discussion (LTS, archiving...) > - > > Safety personnel (Linaro and contractors) discussion > - > > Other considerations from participants? > - > > Community organizations and funding? > - > > Closing and next steps > > > Should you want to participate and have not yet received an invite, please > contact me directly. > > Cordially, > > François-Frédéric > > PS: Please reach out should you want another date with a time compatible > with more time zones. This alternate date is not guaranteed though. > > -- [https://drive.google.com/a/linaro.org/uc?id=0BxTAygkus3RgQVhuNHMwUi1mYWc&ex…] François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group T: +33.67221.6485 francois.ozog(a)linaro.org<mailto:francois.ozog@linaro.org> | Skype: ffozog

4 years, 3 months

1
0
0 0

Firmware FuSa workshop

by François Ozog

Hi, Linaro is conducting an opportunity assessment to make OP-TEE ready for functional safety sensitive environments. The goal is to present a plan to Linaro members by the end of July 2021. The scope of the research is somewhat bigger because we can’t think of OP-TEE without thinking of Trusted Firmware and Hafnium. The plan will though not address those (unless we recognize we have to). We don’t think U-Boot shall be part of the picture but we are welcoming contradictory points of views. We are organizing a 2 hours workshop on April 15th 9am CET to mostly hear about use cases and ideas about Long Term Support requirements . We will present the state of the research. The first use case is booting a safety certified type-1 hypervisor (open source or commercial is irrelevant). But we know there are many more: please be ready to contribute. We think of more radical use cases: a safety payload is actually loaded as a Secure Partition on top of Hafnium with OP-TEE or Zephyr used as a device backends. In other words, Trust Zone hosts both safety and security worlds , EL3 being the « software root of trust » pivot world. In those cases, some cores never go out of secure state… Agenda (to be refined) - Vision - State of the research <https://docs.google.com/presentation/u/0/d/1jWqu39gCF-5XzbFkodXsiVNJJLUN88B…> - Use cases discussion - What is the right scope? - “Who do what” discussion (LTS, archiving...) - Safety personnel (Linaro and contractors) discussion - Other considerations from participants? - Community organizations and funding? - Closing and next steps Should you want to participate and have not yet received an invite, please contact me directly. Cordially, François-Frédéric PS: Please reach out should you want another date with a time compatible with more time zones. This alternate date is not guaranteed though. -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog(a)linaro.org | Skype: ffozog

4 years, 3 months

2
2
0 0

Re: [TF-A] Glitching protection

by Joanna Farley

Hi François, The TF-A team members have thought about trying to explore the use of more mitigations for Side Channel attacks along the lines of "Canary In the Coalmine" type techniques to as you say build additional resilience and as you can expect the techniques used by our peer TF-M project are one we would like to explore. I would not say this is a plan as such but definitely something already listed on our backlog. As to if the TF-M code can be reused that would need to be explored more. Cheers Joanna On 26/03/2021, 14:12, "TF-A on behalf of François Ozog via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi Trusted Firmware M recently introduced protection against glitching at key decision points: https://github.com/mcu-tools/mcuboot/pull/776 To me this is a key mitigation element for companies that target PSA level 3 compliance which means hardware attacks resilience. I believe similar techniques need to be used in different projects involved in Linux secure booting (TF-A, OP-TEE, U-Boot, Linux kernel). Are there any efforts planned around this ? Is it feasible to have a "library" that could be integrated in different projects? Cheers FF -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 3 months

1
0
0 0

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

by Julius Werner

Just want to point out that TF-A currently already supports a (very simple) mechanism like this: https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/… https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/… https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/… It's just a linked list of tagged elements. The tag space is split into TF-A-wide generic tags and SiP-specific tags (with plenty of room to spare if more areas need to be defined -- a 64-bit tag can fit a lot). This is currently being used by some platforms that run coreboot in place of BL1/BL2, to pass information from coreboot (BL2) to BL31. I would echo Simon's sentiment of keeping this as simple as possible and avoiding complicated and bloated data structures with UUIDs. You usually want to parse something like this as early as possible in the passed-to firmware stage, particularly if the structure encodes information about the debug console (like it does for the platforms I mentioned above). For example, in BL31 this basically means doing it right after moving from assembly to C in bl31_early_platform_setup2() to get the console up before running anything else. At that point in the BL31 initialization, the MMU and caches are disabled, so data accesses are pretty expensive and you don't want to spend a lot of parsing effort or calculate complicated checksums or the like. You just want something extremely simple where you ideally have to touch every data word only once. On Wed, Mar 24, 2021 at 5:06 PM Simon Glass via TF-A < tf-a(a)lists.trustedfirmware.org> wrote: > Hi Harb, > > On Wed, 24 Mar 2021 at 11:39, Harb Abdulhamid OS < > abdulhamid(a)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.ozog(a)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. >> >> >> >> @Simon Glass <sjg(a)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. >> > > The tag is intended to serve that purpose, although perhaps it should > switch from an auto-allocating enum to one with explicit values for each > entry and a range for 'local' use. > >> >> >> 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. >> > > True. I think the pain is overstated, though. In this case I think we > actually want something that can be shared between projects and orgs, so > some amount of coordination could be considered a benefit. It could just be > a github pull request. I find the UUID unfriendly and not just to code size > and eyesight! Trying to discover what GUIDs mean or are valid is quite > tricky. E.g. see this code: > > #define FSP_HOB_RESOURCE_OWNER_TSEG_GUID \ > EFI_GUID(0xd038747c, 0xd00c, 0x4980, \ > 0xb3, 0x19, 0x49, 0x01, 0x99, 0xa4, 0x7d, 0x55) > (etc.) > > static struct guid_name { > efi_guid_t guid; > const char *name; > } guid_name[] = { > { FSP_HOB_RESOURCE_OWNER_TSEG_GUID, "TSEG" }, > { FSP_HOB_RESOURCE_OWNER_FSP_GUID, "FSP" }, > { FSP_HOB_RESOURCE_OWNER_SMM_PEI_SMRAM_GUID, "SMM PEI SMRAM" }, > { FSP_NON_VOLATILE_STORAGE_HOB_GUID, "NVS" }, > { FSP_VARIABLE_NV_DATA_HOB_GUID, "Variable NVS" }, > { FSP_GRAPHICS_INFO_HOB_GUID, "Graphics info" }, > { FSP_HOB_RESOURCE_OWNER_PCD_DATABASE_GUID1, "PCD database ea" }, > { FSP_HOB_RESOURCE_OWNER_PCD_DATABASE_GUID2, "PCD database 9b" }, > (never figured out what those two are) > > { FSP_HOB_RESOURCE_OWNER_PEIM_DXE_GUID, "PEIM Init DXE" }, > { FSP_HOB_RESOURCE_OWNER_ALLOC_STACK_GUID, "Alloc stack" }, > { FSP_HOB_RESOURCE_OWNER_SMBIOS_MEMORY_GUID, "SMBIOS memory" }, > { {}, "zero-guid" }, > {} > }; > > static const char *guid_to_name(const efi_guid_t *guid) > { > struct guid_name *entry; > > for (entry = guid_name; entry->name; entry++) { > if (!guidcmp(guid, &entry->guid)) > return entry->name; > } > > return NULL; > } > > Believe it or not it took a fair bit of effort to find just that small > list, with nearly every one in a separate doc, from memory. > > >> >> 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. >> > > Indeed. There is certainly value in both approaches. > > Regards, > Simon > > >> >> >> Thanks, >> >> --Harb >> >> >> >> *From:* François Ozog <francois.ozog(a)linaro.org> >> *Sent:* Tuesday, March 23, 2021 10:00 AM >> *To:* François Ozog <francois.ozog(a)linaro.org>; Ron Minnich < >> rminnich(a)google.com>; Paul Isaac's <paul.isaacs(a)linaro.org> >> *Cc:* Simon Glass <sjg(a)chromium.org>; Harb Abdulhamid OS < >> abdulhamid(a)os.amperecomputing.com>; Boot Architecture Mailman List < >> boot-architecture(a)lists.linaro.org>; tf-a(a)lists.trustedfirmware.org >> *Subject:* Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for >> information passing between boot stages >> >> >> >> +Ron Minnich <rminnich(a)google.com> +Paul Isaac's <paul.isaacs(a)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 < >> tf-a(a)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.p…> >> , 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_zcCq44DLGmPZQFPbYHOC6nzPowaL0X…>) >> 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 <sjg(a)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.ozog(a)linaro.org> >> wrote: >> > >> > +Boot Architecture Mailman List <boot-architecture(a)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 < >> > tf-a(a)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 >> > > TF-A(a)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.ozog(a)linaro.org | Skype: ffozog >> > _______________________________________________ >> > boot-architecture mailing list >> > boot-architecture(a)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(a)linaro.org | Skype: ffozog >> >> >> >> -- >> TF-A mailing list >> TF-A(a)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.ozog(a)linaro.org | Skype: ffozog >> >> >> > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a >

4 years, 3 months

1
0
0 0

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

by François Ozog

+Ron Minnich <rminnich(a)google.com> +Paul Isaac's <paul.isaacs(a)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 < tf-a(a)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.p…> > , 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_zcCq44DLGmPZQFPbYHOC6nzPowaL0X…>) > 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 <sjg(a)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.ozog(a)linaro.org> >> wrote: >> > >> > +Boot Architecture Mailman List <boot-architecture(a)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 < >> > tf-a(a)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 >> > > TF-A(a)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.ozog(a)linaro.org | Skype: ffozog >> > _______________________________________________ >> > boot-architecture mailing list >> > boot-architecture(a)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(a)linaro.org | Skype: ffozog > > -- > TF-A mailing list > TF-A(a)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.ozog(a)linaro.org | Skype: ffozog

4 years, 3 months

3
3
0 0

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

by Bill Fletcher

Adding Andrea On Wed, 24 Mar 2021 at 13:55, Joanna Farley via TF-A < tf-a(a)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-bounces(a)lists.trustedfirmware.org> on behalf of > François Ozog via TF-A <tf-a(a)lists.trustedfirmware.org> > *Reply to: *François Ozog <francois.ozog(a)linaro.org> > *Date: *Wednesday, 24 March 2021 at 08:34 > *To: *Harb Abdulhamid OS <abdulhamid(a)os.amperecomputing.com> > *Cc: *"tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org>, > Simon Glass <sjg(a)chromium.org>, Boot Architecture Mailman List < > boot-architecture(a)lists.linaro.org>, Paul Isaac's <paul.isaacs(a)linaro.org>, > Ron Minnich <rminnich(a)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 < > abdulhamid(a)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.ozog(a)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 <sjg(a)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.ozog(a)linaro.org> > *Sent:* Tuesday, March 23, 2021 10:00 AM > *To:* François Ozog <francois.ozog(a)linaro.org>; Ron Minnich < > rminnich(a)google.com>; Paul Isaac's <paul.isaacs(a)linaro.org> > *Cc:* Simon Glass <sjg(a)chromium.org>; Harb Abdulhamid OS < > abdulhamid(a)os.amperecomputing.com>; Boot Architecture Mailman List < > boot-architecture(a)lists.linaro.org>; tf-a(a)lists.trustedfirmware.org > *Subject:* Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for > information passing between boot stages > > > > +Ron Minnich <rminnich(a)google.com> +Paul Isaac's <paul.isaacs(a)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 < > tf-a(a)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.p…> > , 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_zcCq44DLGmPZQFPbYHOC6nzPowaL0X…>) > 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 <sjg(a)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.ozog(a)linaro.org> > wrote: > > > > +Boot Architecture Mailman List <boot-architecture(a)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 < > > tf-a(a)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 > > > TF-A(a)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.ozog(a)linaro.org | Skype: ffozog > > _______________________________________________ > > boot-architecture mailing list > > boot-architecture(a)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.ozog(a)linaro.org | Skype: ffozog > > > > -- > TF-A mailing list > TF-A(a)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.ozog(a)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.ozog(a)linaro.org | Skype: ffozog > > > -- > TF-A mailing list > TF-A(a)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.fletcher(a)linaro.org | Skype: billfletcher2020

4 years, 3 months

1
0
0 0

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

by Joanna Farley

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-bounces(a)lists.trustedfirmware.org> on behalf of François Ozog via TF-A <tf-a(a)lists.trustedfirmware.org> Reply to: François Ozog <francois.ozog(a)linaro.org> Date: Wednesday, 24 March 2021 at 08:34 To: Harb Abdulhamid OS <abdulhamid(a)os.amperecomputing.com> Cc: "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org>, Simon Glass <sjg(a)chromium.org>, Boot Architecture Mailman List <boot-architecture(a)lists.linaro.org>, Paul Isaac's <paul.isaacs(a)linaro.org>, Ron Minnich <rminnich(a)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 <abdulhamid(a)os.amperecomputing.com<mailto:abdulhamid@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<mailto:francois.ozog@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<mailto:sjg@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.ozog(a)linaro.org<mailto:francois.ozog@linaro.org>> Sent: Tuesday, March 23, 2021 10:00 AM To: François Ozog <francois.ozog(a)linaro.org<mailto:francois.ozog@linaro.org>>; Ron Minnich <rminnich(a)google.com<mailto:rminnich@google.com>>; Paul Isaac's <paul.isaacs(a)linaro.org<mailto:paul.isaacs@linaro.org>> Cc: Simon Glass <sjg(a)chromium.org<mailto:sjg@chromium.org>>; Harb Abdulhamid OS <abdulhamid(a)os.amperecomputing.com<mailto:abdulhamid@os.amperecomputing.com>>; Boot Architecture Mailman List <boot-architecture(a)lists.linaro.org<mailto:boot-architecture@lists.linaro.org>>; tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages +Ron Minnich<mailto:rminnich@google.com> +Paul Isaac's<mailto:paul.isaacs@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 <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@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.p…>, 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_zcCq44DLGmPZQFPbYHOC6nzPowaL0X…>) 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 <sjg(a)chromium.org<mailto:sjg@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.ozog(a)linaro.org<mailto:francois.ozog@linaro.org>> wrote: > > +Boot Architecture Mailman List <boot-architecture(a)lists.linaro.org<mailto: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 < > tf-a(a)lists.trustedfirmware.org<mailto:tf-a@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 > > TF-A(a)lists.trustedfirmware.org<mailto:TF-A@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.ozog(a)linaro.org<mailto:francois.ozog@linaro.org> | Skype: ffozog > _______________________________________________ > boot-architecture mailing list > boot-architecture(a)lists.linaro.org<mailto:boot-architecture@lists.linaro.org> > https://lists.linaro.org/mailman/listinfo/boot-architecture -- [Image removed by sender.] François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group T: +33.67221.6485 francois.ozog(a)linaro.org<mailto:francois.ozog@linaro.org> | Skype: ffozog -- TF-A mailing list TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- [Image removed by sender.] François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group T: +33.67221.6485 francois.ozog(a)linaro.org<mailto:francois.ozog@linaro.org> | Skype: ffozog -- [Image removed by sender.] François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group T: +33.67221.6485 francois.ozog(a)linaro.org<mailto:francois.ozog@linaro.org> | Skype: ffozog

4 years, 3 months

1
0
0 0

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

by François Ozog

+Boot Architecture Mailman List <boot-architecture(a)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 < tf-a(a)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 > TF-A(a)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.ozog(a)linaro.org | Skype: ffozog

4 years, 3 months

2
2
0 0

DTE call today 4pm UK, noon US eastern

by Bill Mills

All, We have our normal DTE call today. Due to different day light saving time dates in US vs UK the meeting will be one hour later than usual for most US people. When I checked yesterday Frank was not yet ready to talk about the DTB format changes so I have no ready made agenda today. We have a DT & SysDT talk and BOF tomorrow at Linaro Connect. Hope to see you all there. Attendance is free: https://connect.linaro.org/ Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

4 years, 3 months

1
0
0 0

Change review for EBBR v2.0-pre1

by Grant Likely

Hi all, I'm about ready to tag the first pre-release of EBBR v2.0. Here is the full changelog as compared to v1.0.1. Once I tag this release I'll be casting the net wider for comments before the document gets released. There are lots of little changes to the document, and a few notable big ones. Big things to look for are: - Reduced required elements in UEFI requirements - Firmware shared storage refinements - Capsule Update is now required Please let me know if you have any comments. Better yet, open an issue in github so that it doesn't get forgotten. We'll also be discussing the release at the EBBR biweekly on Monday 15th March. https://github.com/ARM-software/ebbr/issues Here's the full list of changes: 96dbb03 Reference BBR instead of SBBR (not yet merged) 2a6ca89 Fedora needs two more packages 2e3e873 CONTRIBUTING: let wording follow branching cf29c4c README.rst: Python 2 is long time gone 396abac Fix build warnings: e5d32ca trivial: remove duplicate SCSI pass through support 98e24fe Merge pull request #73 from glikely/for-next eb34dbf Require EFI_UPDATE_CAPSULE 139e6c2 Refine RTC requirements 48e1e56 UEFI section 2.6 exceptions for boot services 72f3e2d Override UEFI section 2.6 requirements 58a2a27 Change required services table titles to be more accurate d4ff44e Minor suggestions to hopefully improve the text 0555e38 Reformat revision history table to render better 5d836bc Refine firmware shared storage requirements. a89cf43 Add reference to RFC 2119 in conventions 8db9eed Fix ResetSystem() text to describe failure condition eda36e4 Merge pull request #48 from jbech-linaro/optee-url c4ef5c7 Update link to OP-TEE secure storage And here is the full diff: CONTRIBUTING.rst | 2 +- README.rst | 15 ++-- source/chapter1-about.rst | 30 ++++--- source/chapter2-uefi.rst | 292 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++------- source/chapter4-firmware-media.rst | 72 ++++++++++++---- source/conf.py | 2 +- source/index.rst | 57 ++++++------- source/references.rst | 12 ++- 8 files changed, 378 insertions(+), 104 deletions(-) diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst index 7021f0f..be979e0 100644 --- a/CONTRIBUTING.rst +++ b/CONTRIBUTING.rst @@ -1,7 +1,7 @@ Contributing ============ -Master copy of this project is hosted on GitHub: +Main copy of this project is hosted on GitHub: https://github.com/ARM-software/ebbr Anyone may contribute to the EBBR project. diff --git a/README.rst b/README.rst index 7480dcb..acf6742 100644 --- a/README.rst +++ b/README.rst @@ -41,31 +41,28 @@ On Debian and Ubuntu ^^^^^^^^^^^^^^^^^^^^ :: - # apt-get install python-sphinx texlive texlive-latex-extra libalgorithm-diff-perl \ + # apt-get install python3-sphinx texlive texlive-latex-extra libalgorithm-diff-perl \ texlive-humanities texlive-generic-recommended texlive-generic-extra \ latexmk If the version of python-sphinx installed is too old, then an additional new version can be installed with the Python package installer:: - $ apt-get install python-pip - $ pip install --user --upgrade Sphinx + $ apt-get install python3-pip + $ pip3 install --user --upgrade Sphinx $ export SPHINXBUILD=~/.local/bin/sphinx-build -Export SPHINXBUILD (see above) if Sphinx was installed with pip --user, then follow Make commands below +Export SPHINXBUILD (see above) if Sphinx was installed with pip3 --user, then follow Make commands below. On Fedora ^^^^^^^^^ :: - # dnf install python2-sphinx texlive texlive-capt-of texlive-draftwatermark \ + # dnf install python3-sphinx texlive texlive-capt-of texlive-draftwatermark \ texlive-fncychap texlive-framed texlive-needspace \ texlive-tabulary texlive-titlesec texlive-upquote \ - texlive-wrapfig - -It is also possible to use python3-sphinx; this requires -SPHINXBUILD=sphinx-build-3 to be passed on the Make command line. + texlive-wrapfig texinfo latexmk On Mac OS X ^^^^^^^^^^^ diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst index 3744d8a..6f69f53 100644 --- a/source/chapter1-about.rst +++ b/source/chapter1-about.rst @@ -50,8 +50,8 @@ Vendors have heavy investments in both projects and are not interested in large scale changes to their firmware architecture. The challenge for EBBR is to define a set of boot standards that reduce the amount of custom engineering required, make it possible for OS distributions to -support embedded platforms, while still preserving the firmware stack product -vendors are comfortable with. +support embedded platforms, while still preserving the firmware stack that +product vendors are comfortable with. Or in simpler terms, EBBR is designed to solve the embedded boot mess by adding a defined standard (UEFI) to the existing firmware projects (U-Boot). @@ -146,19 +146,23 @@ including services that are required for virtualization. It does not define a standardized abstract virtual machine view for a Guest Operating System. -This specification is similar to the Arm Server Base Boot Requirements -specification [SBBR]_ in that it defines the firmware interface presented to an -operating system. -SBBR is targeted at the server ecosystem and places strict requirements on the -platform to ensure cross vendor interoperability. -EBBR on the other hand allows more flexibility to support embedded designs -which do not fit within the SBBR model. -For example, a platform that isn't SBBR compliant because the SoC is only -supported using Devicetree could be EBBR compliant, but not SBBR compliant. - -By definition, all SBBR compliant systems are also EBBR compliant, but the +This specification is referenced by the Arm Base Boot Requirements +Specification [ArmBBR]_ § 4.3. +The UEFI requirements found in this document are similar but not identical to +the requirements found in BBR. +EBBR provides greater flexibility for support embedded designs which cannot +easily meet the stricter BBR requirements. + +By definition, all BBR compliant systems are also EBBR compliant, but the converse is not true. +Conventions Used in this Document +================================= + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", +"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be +interpreted as described in :rfc:`2119`. + Cross References ================ This document cross-references sources that are listed in the References diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 066fefb..a0b3e8d 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -14,8 +14,179 @@ This document uses version 2.8 Errata A of the UEFI specification [UEFI]_. UEFI Compliance =============== -EBBR compliant platforms shall conform to the requirements in [UEFI]_ § 2.6, -except where explicit exemptions are provided by this document. +EBBR compliant platform shall conform to a subset of the [UEFI]_ spec as listed +in this section. +Normally, UEFI compliance would require full compliance with all items listed +in UEFI § 2.6. +However, the EBBR target market has a reduced set of requirements, +and so some UEFI features are omitted as unnecessary. + +Required Elements +----------------- + +This section replaces the list of required elements in [UEFI]_ § 2.6.1. +All of the following UEFI elements are required for EBBR compliance. + +.. list-table:: UEFI Required Elements + :widths: 50 50 + :header-rows: 1 + + * - Element + - Requirement + * - `EFI_SYSTEM_TABLE` + - The system table is required to provide required to access UEFI Boot Services, + UEFI Runtime Services, consoles, and other firmware, vendor and platform + information. + * - `EFI_BOOT_SERVICES` + - All functions defined as boot services must exist. + Methods for unsupported or unimplemented behaviour must return + an appropriate error code. + * - `EFI_RUNTIME_SERVICES` + - All functions defined as runtime services must exist. + Methods for unsupported or unimplemented behaviour must return + an appropriate error code. + If any runtime service is unimplemented, it must be indicated + via the EFI_RT_PROPERTIES_TABLE. + * - `EFI_LOADED_IMAGE_PROTOCOL` + - Must be installed for each loaded image + * - `EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL` + - Must be installed for each loaded image + * - `EFI_DEVICE_PATH_PROTOCOL` + - An `EFI_DEVICE_PATH_PROTOCOL` must be installed onto all device + handles provided by the firmware. + * - `EFI_DEVICE_PATH_UTILITIES_PROTOCOL` + - Interface for creating and manipulating UEFI device paths + +.. list-table:: Notable omissions from UEFI § 2.6.1 + :header-rows: 1 + + * - Element + - Note + * - `EFI_DECOMPRESS_PROTOCOL` + - Native EFI decompression is rarely used and therefore not required. + +Required Platform Specific Elements +----------------------------------- + +This section replaces the list of required elements in [UEFI]_ § 2.6.2. +All of the following UEFI elements are required for EBBR compliance. + +.. list-table:: UEFI Platform-Specific Required Elements + :widths: 50 50 + :header-rows: 1 + + * - Element + - Description + * - Console devices + - The platform must have at least one console device + * - `EFI_SIMPLE_TEXT_INPUT_PROTOCOL` + - Needed for console input + * - `EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL` + - Needed for console input + * - `EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL` + - Needed for console output + * - `EFI_DEVICE_PATH_TO_TEXT_PROTOCOL` + - Needed for console output + * - `EFI_HII_STRING_PROTOCOL` + - Required by EFI shell and for compliance testing + * - `EFI_HII_DATABASE_PROTOCOL` + - Required by EFI shell and for compliance testing + * - `EFI_UNICODE_COLLATION2_PROTOCOL` + - Required by EFI shell and for compliance testing + * - `EFI_BLOCK_IO_PROTOCOL` + - Required for block device access + * - `EFI_SIMPLE_FILE_SYSTEM_PROTOCOL` + - Required if booting from block device is supported + * - `EFI_RNG_PROTOCOL` + - Required if the platform has a hardware entropy source + * - `EFI_SIMPLE_NETWORK_PROTOCOL` + - Required if the platform has a network device. + * - HTTP Boot (UEFI § 24.7) + - Required if the platform supports network booting + +The following table is a list of notable deviations from UEFI § 2.6.2. +Many of these deviations are because the EBBR use cases do not require +interface specific UEFI protocols, and so they have been made optional. + +.. list-table:: Notable Deviations from UEFI § 2.6.2 + :widths: 50 50 + :header-rows: 1 + + * - Element + - Description of deviation + * - `LoadImage()` + - The LoadImage() boot service is not required to install an + EFI_HII_PACKAGE_LIST_PROTOCOL for an image containing a custom PE/COFF + resource with the type 'HII'. - HII resource images are not needed to run + the UEFI shell or the SCT. + * - `ConnectController()` + - The ConnectController()` boot service is not required to support the + EFI_PLATFORM_DRIVER_OVERRIDE_PROTOCOL, + EFI_DRIVER_FAMILY_OVERRIDE_PROTOCOL, and + EFI_BUS_SPECIFIC_DRIVER_OVERRIDE_PROTOCOL. - These override protocols are + only useful if drivers are loaded as EFI binaries by the firmware. + * - `EFI_HII_CONFIG_ACCESS_PROTOCOL` + - UEFI requires this for console devices, but it is rarely necessary in practice. + Therefore this protocol is not required. + * - `EFI_HII_CONFIG_ROUTING_PROTOCOL` + - UEFI requires this for console devices, but it is rarely necessary in practice. + Therefore this protocol is not required. + * - Graphical console + - Platforms with a graphical device are not required to expose it as a graphical console. + * - `EFI_DISK_IO_PROTOCOL` + - Rarely used interface that isn't required for EBBR use cases + * - `EFI_PXE_BASE_CODE_PROTOCOL` + - Booting via the Preboot Execution Environment (PXE) is insecure. + Loading via PXE is typically executed before launching the first UEFI application. + * - Network protocols + - A full implementation of the UEFI general purpose networking ABIs is not required, + including `EFI_NETWORK_INTERFACE_IDENTIFIER_PROTOCOL`, `EFI_MANAGED_NETWORK_PROTOCOL`, + `EFI_*_SERVICE_BINDING_PROTOCOL`, or any of the IPv4 or IPv6 protocols. + * - Byte stream device support (UART) + - UEFI protocols not required + * - PCI bus support + - UEFI protocols not required + * - USB bus support + - UEFI protocols not required + * - NVMe pass through support + - UEFI protocols not required + * - SCSI pass through support + - UEFI protocols not required + * - `EFI_DRIVER_FAMILY_OVERRIDE_PROTOCOL` + - Not required + * - Option ROM support + - In many EBBR use cases there is no requirement to generically support + any PCIe add in card at the firmware level. + When PCIe devices are used, drivers for the device are often built into + the firmware itself rather than loaded as option ROMs. + For this reason EBBR implementations are not required to support option + ROM loading. + +Required Global Variables +------------------------- + +EBBR compliant platforms are required to support the following Global +Variables as found in [UEFI]_ § 3.3. + +.. list-table:: Required UEFI Variables + :widths: 25 75 + :header-rows: 1 + + * - Variable Name + - Description + * - `Boot####` + - A boot load option. #### is a numerical hex value + * - `BootCurrent` + - The boot option that was selected for the current boot + * - `BootNext` + - The boot option that will be used for the next boot only + * - `BootOrder` + - An ordered list of boot options. + Firmware will attempt each Boot#### entry in this order + * - `OsIndications` + - Method for OS to request features from firmware + * - `OsIndicationsSupported` + - Variable for firmware to indicate which features can be enabled Block device partitioning ------------------------- @@ -53,7 +224,7 @@ a hypervisor or a virtualization aware Operating System. UEFI Boot at EL1 ^^^^^^^^^^^^^^^^ -Booting of UEFI at EL1 is most likely within a hypervisor hosted Guest +Booting of UEFI at EL1 is most likely employed within a hypervisor hosted Guest Operating System environment, to allow the subsequent booting of a UEFI-compliant Operating System. In this instance, the UEFI boot-time environment can be provided, as a @@ -77,7 +248,7 @@ The default RAM allocated attribute must be EFI_MEMORY_WB. Configuration Tables -------------------- -A UEFI system that complies with this specification may provide the additional +A UEFI system that complies with this specification may provide additional tables via the EFI Configuration Table. Compliant systems are required to provide one, but not both, of the following @@ -151,26 +322,55 @@ EFI_UNSUPPORTED. are required to be implemented during boot services and runtime services. .. _uefi_runtime_service_requirements: -.. table:: EFI_RUNTIME_SERVICES Implementation Requirements - - ============================== ============= ================ - EFI_RUNTIME_SERVICES function Boot Services Runtime Services - ============================== ============= ================ - EFI_GET_TIME Optional Optional - EFI_SET_TIME Optional Optional - EFI_GET_WAKEUP_TIME Optional Optional - EFI_SET_WAKEUP_TIME Optional Optional - EFI_SET_VIRTUAL_ADDRESS_MAP N/A Required - EFI_CONVERT_POINTER N/A Required - EFI_GET_VARIABLE Required Optional - EFI_GET_NEXT_VARIABLE_NAME Required Optional - EFI_SET_VARIABLE Required Optional - EFI_GET_NEXT_HIGH_MONO_COUNT N/A Optional - EFI_RESET_SYSTEM Required Optional - EFI_UPDATE_CAPSULE Optional Optional - EFI_QUERY_CAPSULE_CAPABILITIES Optional Optional - EFI_QUERY_VARIABLE_INFO Optional Optional - ============================== ============= ================ +.. list-table:: `EFI_RUNTIME_SERVICES` Implementation Requirements + :widths: 40 30 30 + :header-rows: 1 + + * - `EFI_RUNTIME_SERVICES` function + - Before ExitBootServices() + - After ExitBootServices() + * - `EFI_GET_TIME` + - Required if RTC present + - Optional + * - `EFI_SET_TIME` + - Required if RTC present + - Optional + * - `EFI_GET_WAKEUP_TIME` + - Required if wakeup supported + - Optional + * - `EFI_SET_WAKEUP_TIME` + - Required if wakeup supported + - Optional + * - `EFI_SET_VIRTUAL_ADDRESS_MAP` + - N/A + - Required + * - `EFI_CONVERT_POINTER` + - N/A + - Required + * - `EFI_GET_VARIABLE` + - Required + - Optional + * - `EFI_GET_NEXT_VARIABLE_NAME` + - Required + - Optional + * - `EFI_SET_VARIABLE` + - Required + - Optional + * - `EFI_GET_NEXT_HIGH_MONO_COUNT` + - N/A + - Optional + * - `EFI_RESET_SYSTEM` + - Required + - Optional + * - `EFI_UPDATE_CAPSULE` + - Required for in-band update + - Optional + * - `EFI_QUERY_CAPSULE_CAPABILITIES` + - Optional + - Optional + * - `EFI_QUERY_VARIABLE_INFO` + - Optional + - Optional Runtime Device Mappings ----------------------- @@ -198,8 +398,11 @@ it may not be possible to access the RTC from runtime services. e.g., The RTC may be on a shared I2C bus which runtime services cannot access because it will conflict with the OS. -If firmware does not support access to the RTC, then GetTime() and -SetTime() shall return EFI_UNSUPPORTED, +If an RTC is present, then GetTime() and SetTime() must be supported +before ExitBootServices() is called. + +However, if firmware does not support access to the RTC after +ExitBootServices(), then GetTime() and SetTime() shall return EFI_UNSUPPORTED and the OS must use a device driver to control the RTC. UEFI Reset and Shutdown @@ -209,9 +412,10 @@ ResetSystem() is required to be implemented in boot services, but it is optional for runtime services. During runtime services, the operating system should first attempt to use ResetSystem() to reset the system. -If firmware doesn't support ResetSystem() during runtime services, -then the call will immediately return EFI_UNSUPPORTED, and the OS should -fall back to an architecture or platform specific reset mechanism. + +If firmware doesn't support ResetSystem() during runtime services, then the call +will immediately return, and the OS should fall back to an architecture or +platform specific reset mechanism. On AArch64 platforms implementing [PSCI]_, if ResetSystem() is not implemented then the Operating System should fall @@ -242,6 +446,26 @@ Even when SetVariable() is not supported during runtime services, firmware should cache variable names and values in EfiRuntimeServicesData memory so that GetVariable() and GetNextVeriableName() can behave as specified. +Firmware Update +--------------- + +Being able to update firmware to address security issues is a key feature of secure platforms. +EBBR platforms are required to implement either an in-band or an out-of-band firmware update mechanism. + +If firmware update is performed in-band (firmware on the application processor updates itself), +then the firmware shall implement EFI_UPDATE_CAPSULE and accept updates in the +"Firmware Management Protocol Data Capsule Structure" format as described in [UEFI]_ § 23.3, +"Delivering Capsules Containing Updates to Firmware Management Protocol. [#FMPNote]_ +Firmware is also required to provide an EFI System Resource Table (ESRT). [UEFI]_ § 23.4 +Every firmware image that is updated in-band must be described in the ESRT. + +If firmware update is performed out-of-band (e.g., by an independent Baseboard +Management Controller (BMC), or firmware is provided by a hypervisor), +then the platform is not required to implement EFI_UPDATE_CAPSULE. + +EFI_UPDATE_CAPSULE is only required before ExitBootServices() is called. + + .. [#OPTEESupplicant] It is worth noting that OP-TEE has a similar problem regarding secure storage. OP-TEE's chosen solution is to rely on an OS supplicant agent to perform @@ -251,4 +475,12 @@ that GetVariable() and GetNextVeriableName() can behave as specified. Regardless, EBBR compliance does not require SetVariable() support during runtime services. - https://github.com/OP-TEE/optee_os/blob/master/documentation/secure_storage… + https://optee.readthedocs.io/en/latest/architecture/secure_storage.html + +.. [#FMPNote] The `EFI_UPDATE_CAPSULE` implementation is expected to be suitable + for use by generic firmware update services like fwupd and Windows Update. + Both fwupd and Windows Update read the ESRT table to determine what firmware + can be updated, and use an EFI helper application to call `EFI_UPDATE_CAPSULE` + before ExitBootServices() is called. + + https://fwupd.org/ diff --git a/source/chapter4-firmware-media.rst b/source/chapter4-firmware-media.rst index fc71274..cfcc8bd 100644 --- a/source/chapter4-firmware-media.rst +++ b/source/chapter4-firmware-media.rst @@ -47,13 +47,19 @@ conflict with normal usage of the media by an OS. Partitioning of Shared Storage ============================== -A shared storage device shall use GPT partitioning unless it is incompatible -with the platform boot sequence. -In which case, MBR partitioning shall be used. [#MBRReqExample]_ - -.. [#MBRReqExample] For example, if the boot ROM doesn't understand GPT - partitioning, and will only work with an MBR, then the storage must be - partitioned using an MBR. +The shared storage device must use the GUID Partition Table (GPT) disk +layout as defined in [UEFI]_ § 5.3, unless the platform boot sequence is +fundamentally incompatible with the GPT disk layout. +In which case, a legacy Master Boot Recored (MBR) must be used. +[#MBRReqExample]_ + +.. [#MBRReqExample] For example, if the SoC boot ROM requires an MBR to + find the next stage firmware image, then it is incompatible with + the GPT boot layout. + Similarly, if the boot ROM expects the next stage firmware to be located + at LBA1 (the location of the GPT Header), then it is incompatible with + the GPT disk layout. + In both cases the shared storage device must use legacy MBR partitioning. .. warning:: @@ -62,7 +68,8 @@ In which case, MBR partitioning shall be used. [#MBRReqExample]_ GPT partitioning supports a much larger number of partitions, and has built in resiliency. - A future issue of this specification will remove the MBR allowance. + A future issue of this specification will disallow the use of MBR + partitioning. Firmware images and data in shared storage should be contained in partitions described by the GPT or MBR. @@ -71,15 +78,14 @@ the partition(s) containing firmware. However, some SoCs load firmware from a fixed offset into the storage media. In this case, to protect against partitioning tools overwriting firmware, the -firmware image shall either reside entirely within the first 1MiB of storage, -or should be covered by a protective partition entry in the partition table as +partition table must be formed in a way to protect the firmware image(s) as described in sections :ref:`section-gpt-parts` and :ref:`section-mbr-parts`. -Automatic partitioning tools (e.g. an OS installer) must not create -partitions within the first 1MiB of storage, or delete, move, or modify -protective partition entries. +Automatic partitioning tools (e.g. an OS installer) must not +delete the protective information in the partition table, or +delete, move, or modify protective partition entries. Manual partitioning tools should provide warnings when modifying -protective partitions or creating partitions within the first 1MiB. +protective partitions. .. warning:: @@ -95,19 +101,49 @@ GPT partitioning ---------------- The partition table must strictly conform to the UEFI specification and include -a protective MBR authored exactly as described in [UEFI]_ § 5 (hybrid +a protective MBR authored exactly as described in [UEFI]_ § 5.3 (hybrid partitioning schemes are not permitted). -Protective partitions must have the Platform Required Attribute Flag set. +Fixed-location firmware images must be protected by creating protective +partition entries, or by placing GPT data structures away from the LBAs +occupied by firmware, + +Protective partitions are entries in the partition table that cover the +LBA region occupied by firmware and have the 'Required Partition' attribute +set. +A protective partition must use a `PartitionTypeGUID` that identifies it +as a firmware protective partition. (e.g., don't reuse a GUID used by +non-protective partitions). +There are no requirements on the contents or layout of the firmware +protective partition. + +Placing GPT data structures away from firmware images can be accomplished by +adjusting the GUID Partition Entry array location +(adjusting the values of `PartitionEntryLBA` and `NumberOfPartitionEntries`, +and `SizeOfPartitionEntry`), +or by specifying the usable LBAs (Choosing `FirstUsableLBA`/`LastUsableLBA` +to not overlap the fixed firmware location). +See [UEFI]_ § 5.3.2. + +Given the choice, platforms should use protective partitions over +adjusting the placement of GPT data structures because protective partitions +provide explicit information about the protected region. .. _section-mbr-parts: MBR partitioning ^^^^^^^^^^^^^^^^ -Protective partitions should have a partition type of 0xF8 unless some +If firmware is at a fixed location entirely within the first 1MiB of +storage (<= LBA2047) then no protective partitions are required. +If firmware resides in a fixed location outside the first 1MiB, +then a protective partition must be used to cover the firmware LBAs. +Protective partitions should have a partition type of 0xF8 unless an immutable feature of the platform makes this impossible. +OS partitioning tools must not create partitions in the first 1MiB +of the storage device, and must not remove protective partitions. + .. _section-fw-partition-fs: Firmware Partition Filesystem @@ -202,7 +238,7 @@ and cannot be moved between systems. eMMC and Universal Flash Storage (UFS) device are often used as shared fixed storage for both firmware and the OS. -Where possible, it is prefered for the system to boot from a dedicated boot +Where possible, it is preferred for the system to boot from a dedicated boot region on media that provides one (e.g., eMMC) that is sufficiently large. Otherwise, the platform storage should be pre-formatted in the factory with a partition table, a dedicated firmware partition, and firmware binaries diff --git a/source/conf.py b/source/conf.py index 86f7b88..4a2566a 100644 --- a/source/conf.py +++ b/source/conf.py @@ -100,7 +100,7 @@ html_theme = 'alabaster' # Add any paths that contain custom static files (such as style sheets) here, # relative to this directory. They are copied after the builtin static files, # so a file named "default.css" will overwrite the builtin "default.css". -html_static_path = ['_static'] +# html_static_path = ['_static'] # -- Options for HTMLHelp output ------------------------------------------ diff --git a/source/index.rst b/source/index.rst index 8eab909..bf2dadf 100644 --- a/source/index.rst +++ b/source/index.rst @@ -21,35 +21,34 @@ Creative Commons, PO Box 1866, Mountain View, CA 94042, USA. .. tabularcolumns:: l c p{11.5cm} .. table:: Revision History - ================= ========= ============================================= - Date Issue Changes - ================= ========= ============================================= - 20 September 2017 0.51 Confidentiality Change, EBBR version 0.51 - 6 July 2018 0.6-pre1 - Relicense to CC-BY-SA 4.0 - - Added Devicetree requirements - - Added Multiprocessor boot requirements - - Transitioned to reStructuredText and GitHub - - Added firmware on shared media requirements - - RTC is optional - - Add constraints on sharing devices between - firmware and OS - 12 July 2018 0.6 - Response to comments on v0.6-pre1 - - Add large note on implementation of runtime - modification of non-volatile variables - 18 October 2018 0.7 - Add AArch32 details - - Refactor Runtime Services text after face - to fact meeting at Linaro Connect YVR18 - 12 March 2019 0.8 - Update language around SetVariable() and - what is available during runtime services - - Editorial changes preparing for v1.0 - 31 March 2019 1.0 - Remove unnecessary UEFI requirements - appendix - - Allow for ACPI vendor id in firmware path - 5 August 2020 1.0.1 - Update to UEFI 2.8 Errata A - - Specify UUID for passing DTB - - Typo and editorial fixes - - Document the release process - ================= ========= ============================================= + ============= ======= ============================================= + Date Issue Changes + ============= ======= ============================================= + 20 Sep 2017 0.51 - Confidentiality Change, EBBR version 0.51 + 12 Jul 2018 0.6 - Relicense to CC-BY-SA 4.0 + - Added Devicetree requirements + - Added Multiprocessor boot requirements + - Transitioned to reStructuredText and GitHub + - Added firmware on shared media requirements + - RTC is optional + - Add constraints on sharing devices between + firmware and OS + - Add large note on implementation of runtime + modification of non-volatile variables + 18 Oct 2018 0.7 - Add AArch32 details + - Refactor Runtime Services text after face + to fact meeting at Linaro Connect YVR18 + 12 Mar 2019 0.8 - Update language around SetVariable() and + what is available during runtime services + - Editorial changes preparing for v1.0 + 31 Mar 2019 1.0 - Remove unnecessary UEFI requirements + appendix + - Allow for ACPI vendor id in firmware path + 5 Aug 2020 1.0.1 - Update to UEFI 2.8 Errata A + - Specify UUID for passing DTB + - Typo and editorial fixes + - Document the release process + ============= ======= ============================================= .. toctree:: :numbered: diff --git a/source/references.rst b/source/references.rst index 1eb0509..fb7dc81 100644 --- a/source/references.rst +++ b/source/references.rst @@ -1,5 +1,11 @@ .. SPDX-License-Identifier: CC-BY-SA-4.0 +.. only:: html + + ************ + Bibliography + ************ + .. [ACPI] `Advanced Configuration and Power Interface specification v6.2A <http://www.uefi.org/sites/default/files/resources/ACPI%206_2_A_Sept29.pdf>`_, September 2017, `UEFI Forum <http://www.uefi.org>`_ @@ -16,9 +22,9 @@ <https://static.docs.arm.com/den0022/c/DEN0022C_Power_State_Coordination_Int…>`_ 30 January 2015, `Arm Limited <http://arm.com>`_ -.. [SBBR] `Arm Server Base Boot Requirements specification Issue B (v1.0) - <https://static.docs.arm.com/den0044/b/DEN0044B_Server_Base_Boot_Requirement…>`_ - 8 March 2016, `Arm Limited <http://arm.com>`_ +.. [ArmBBR] `Arm Base Boot Requirements specification Issue F (v1.0) + <https://developer.arm.com/documentation/den0044/f>`_ + 6 Oct 2020, `Arm Limited <http://arm.com>`_ .. [UEFI] `Unified Extensable Firmware Interface Specification v2.8 Errata A <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_A_Feb14.pdf>`_,

4 years, 4 months

2
4
0 0

[EBBR PATCH] Reference BBR instead of SBBR

by Grant Likely

SBBR has been superseded by Arm BBR. Update the about section to reference BBR instead. However, none of the specification language changes because EBBR has a relaxed set of UEFI requirements compared to BBR. Fixes: #62 Signed-off-by: Grant Likely <grant.likely(a)secretlab.ca> --- source/chapter1-about.rst | 19 ++++++++----------- source/references.rst | 6 +++--- 2 files changed, 11 insertions(+), 14 deletions(-) diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst index 68a1abc..6f69f53 100644 --- a/source/chapter1-about.rst +++ b/source/chapter1-about.rst @@ -146,17 +146,14 @@ including services that are required for virtualization. It does not define a standardized abstract virtual machine view for a Guest Operating System. -This specification is similar to the Arm Server Base Boot Requirements -specification [SBBR]_ in that it defines the firmware interface presented to an -operating system. -SBBR is targeted at the server ecosystem and places strict requirements on the -platform to ensure cross vendor interoperability. -EBBR on the other hand allows more flexibility to support embedded designs -which do not fit within the SBBR model. -For example, a platform that isn't SBBR compliant because the SoC is only -supported using Devicetree could be EBBR compliant, but not SBBR compliant. - -By definition, all SBBR compliant systems are also EBBR compliant, but the +This specification is referenced by the Arm Base Boot Requirements +Specification [ArmBBR]_ § 4.3. +The UEFI requirements found in this document are similar but not identical to +the requirements found in BBR. +EBBR provides greater flexibility for support embedded designs which cannot +easily meet the stricter BBR requirements. + +By definition, all BBR compliant systems are also EBBR compliant, but the converse is not true. Conventions Used in this Document diff --git a/source/references.rst b/source/references.rst index d91dc08..fb7dc81 100644 --- a/source/references.rst +++ b/source/references.rst @@ -22,9 +22,9 @@ <https://static.docs.arm.com/den0022/c/DEN0022C_Power_State_Coordination_Int…>`_ 30 January 2015, `Arm Limited <http://arm.com>`_ -.. [SBBR] `Arm Server Base Boot Requirements specification Issue B (v1.0) - <https://static.docs.arm.com/den0044/b/DEN0044B_Server_Base_Boot_Requirement…>`_ - 8 March 2016, `Arm Limited <http://arm.com>`_ +.. [ArmBBR] `Arm Base Boot Requirements specification Issue F (v1.0) + <https://developer.arm.com/documentation/den0044/f>`_ + 6 Oct 2020, `Arm Limited <http://arm.com>`_ .. [UEFI] `Unified Extensable Firmware Interface Specification v2.8 Errata A <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_A_Feb14.pdf>`_, -- 2.20.1

4 years, 4 months

1
0
0 0

DTE meeting notes 2021-03-08

by Bill Mills

All, Here are my notes from today. Please correct anything I got wrong. Attendees: Bruce Ashfield Frank Rowand Simon Glass Etienne Carriere Heinrich Schuchardt Ilias Apalodimas Joakim Bech Loic Pallardy Mark Brown Mathieu Poirier Rob Herring Ruchika Gupta Vincent Guittot Vincent Stehle CC: Stefano Stabellini Kumar Gala Discussion: Today we did a brainstorming session on goals/requirements for a new DTB format. Remember this is a laundry list of requirements / concerns. Not all will necessarily be included in the new format but all will be considered. It is not a discussion of the format changes to achieve these goals. Frank Rowand will be collecting past discussions related to this and expects this to be ready for the meeting on March 22. * FR: Reduce Size * FR: Overlay support in "symbol table" not looking like HW description * FR: Ability to express "delete node" and "delete property" ** many: do we really need delete node, every node should have status ** RH: not everyone today looks for status != ok ** general agreement that they should ** RH: perhaps we should make it more automatic somehow * SG: New format should be little endian ** most current active / popular CPU arch are LE these days * SG: Ability to refer to data blob by reference instead of inline ** blob would still be in DTB file/image but not inline as a property blob * RH: Include type info ** Know what is a u64 vs u32 vs phandle ** replicate what we have in schema with bit fields etc ** enums?? structs?? * SG: Provision for comments * RH: In general want more less conversion DTS -> DTB -> DTS ** WAM: Is it OK to rely on schema? ** SG: Ideally not, would prefer self describing format * HS: Want to be able to validate DTB (against schema) ** WAM: Isnt this the same as type info? ** RH: That is a lot of it but there is more * WAM: We want a new section for meta data ** WAM: signatures as discussed on this call ** FR: Source file info / version markers ** HS/WAM: taint flag if the DTC compile or validate is not clean * SG: IN yaml we can import a node, ** would be good to have this in DTS as well ** FR: It is valid to bring in DTS requirements as some of this will effect anyway * WAM: Segmeneted DTB or DTB set ** instead of applying overlays leave base and overlay intact ** deliver to OS as a set with assembly order. ** [We can call it IKEA mode :) ] ** allows signatures to reamin valid, can be passed on ** makes it clear what fixups were performed by the firmware * SG: a previous node "pointer" ** going backwards is very slow in FDT * WAM: Huawei is asking for B-Tree to speed up search in FDT ** FR/RH: probably too far but we will consider * RH: DTB format could be unflattened ** SG: could be too big ** SG: we may really need more than one format to balance speed vs size ** [WAM: learns that libfdt does not unflatten. U-boot copies Linux code for this.] ** RH: we could have a libdt that would be lib for live trees * SG: for speed it would be nice to have a directory for quick access ** WAM: improved alias? SG: Yes if they were phandles perhaps * WAM: Can we revist size, that is pretty broad ** Eliminate as many strings as possible ** FR: Compiler does "tail recursion" on strings already ** WAM: strings in properties are not in symbold table today ** SG: Yes I studied that and elimination of that did not help a lot. ** SG: Today everything is 32 bit *** I looked at reducing and could save 20% *** But it is not as regular *** WAM: is it aligned today? *** RH: Yes, 64 bit aligned but not very clear in spec ** HS: Just gzip the DTB if you just want to reduce storage size ** WAM: Published ATOM based DTB doc a few years ago. *** Try to move most strings to 32 bit ATOM constants (not offsets) *** Optionally include ATOM table to include the strings Devicetree Atom Table Format: https://docs.google.com/document/d/19XbxN-zX-GYwOXdF78lGnp0j7UNx1MT3wzyCjai… Frank reminds us that we want to collect all the stake holders: * Linux * DTC * U-Boot * BSDs ** One has its own DTC * RTOS ** Zephyr (mostly DTS) *** Have their own DTS parser, DOM lib, and code gen *** Want to make it more generic ** Vxworks (does use runtime DT of some sort) All agree: Old DTB format will need to be supported for a good while after new DTB format is defined. Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

4 years, 4 months

1
0
0 0

DT Evo call today March 8 at 4pm UK/UTC 11AM US East

by Bill Mills

Hello, We have our DTE call today. I don't have anything on the agenda unless we want to brainstorm on the DTB format changes. I know Frank is trying to collect/organize past work on this. Is it worth while talking today or should we wait for Frank? Open to any other agenda items. Join Zoom Meeting https://linaro-org.zoom.us/j/96170428801?pwd=elBJNFdVMFJub0UzanFUcVQxTHBqdz… Meeting ID: 961 7042 8801 Passcode: 8250 ------ A note on timezones. This meeting is now anchored to the UK timezone to match the EBBR call. UK goes to Daylight savings on March 28 Most of the USA goes to Daylight savings on March 14. This means: UK: no visible change in time slot. USA (most): Meeting on 22nd will be one hour later. (and EBBR meeting on 15th) Non-daylight savings time zones: DTE and EBBR meetings are 1 hour earlier from March 28 to Oct 31. Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

4 years, 4 months

1
0
0 0

EFI_LOAD_FILE2 for initrd standardization

by Ilias Apalodimas

Hi, An arch agnostic way was recently added on the kernel, as an alternative method to load an initrd [1]. The kernel call to the firmware ends up calling the protocol with a Device Path End Structure, so the firmware must know which initrd to load on the buffer the kernel provides. The protocol is currently implemented by U-boot and EDK2, which both define a way of specifying the initrd to load. We could use this protocol, in order to provide vertical distros a way of loading (kernel, initrd) pairs without GRUB. In that case we need a common way for firmware implementations to define and manage the initrd. User space applications that control the boot flow (e.g efibootmgr), should also be able to change the variable accordingly. Looking at the EFI spec and specifically § 3.1.3 Load Options, we can use the FilePathList[] of the EFI_LOAD_OPTION, which is described as: "A packed array of UEFI device paths. The first element of the array is a device path that describes the device and location of the Image for this load option. The FilePathList[0] is specific to the device type. Other device paths may optionally exist in the FilePathList, but their usage is OSV specific. Each element in the array is variable length, and ends at the device path end structure. Because the size of Description is arbitrary, this data structure is not guaranteed to be aligned on a natural boundary. This data structure may have to be copied to an aligned natural boundary before it is used." So FilePatrhList[1-n] are available for OS usage. There are 3 ways we could implement that. All 3 ways would allow us to specify multiple initrds (and we could extend the same logic to DTBs, but that's a different discussion). They all re-use the same idea, prepend a VenMedia DP, which has a GUID. We can then use that GUID to identify the filetype and behavior of the device paths. 1. Prepend a VenMedia Device Path in every initrd Device Path. In that case FilePathList[] would look like this: Loaded Image device path - end node - VenMedia - Initrd DP - end node - VenMedia - Initrd DP - end node - repeat 2. Prepend a VenMedia Device Path once. In that case FilePathList[] would look like this: Loaded Image device path - end node - VenMedia - Initrd DP - end instance - (repeat) - Initrd DP - end node - other DPs In this case we could use the VenMedia Vendor Defined Data to indicate the number of device paths that follow, although it's redundant, since each instance would terminate on the Device Path End Structure. 3. Use Vendor Defined Data of the VenMedia device path and copy the initrd device path(s) in there. In that case the Vendor Defined Data will it self be in a device path format with all the initrds we want. Loaded Image device path - end node - VenMedia - end node - other DPs Any preference on these? Is one of them closer to the EFI spec, so we could go ahead and try to standardize some of the GUIDs of the VenMedia? [1] https://lkml.org/lkml/2020/2/16/105 Regards /Ilias

4 years, 4 months

7
17
0 0

*cancelled* EBBR Biweekly for 1 March 2021

by Grant Likely

Hi all, I'll be doing a presentation and round table about SystemReady IR at Embedded World on 1 March, but unfortunately it overlaps entirely our EBBR biweekly so I'm going to cancel that day. If you're interested in attending the round table, please email me privately. The session apparently limited to a small number of people (which seems odd for a virtual conference), so I'm sending out invites. The session is scheduled for 15:50-16:50 GMT on 1 March 2021. Cheers, g. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

4 years, 4 months

1
1
0 0

DTE Call today (Feb 22) at 11am US ET, 4PM UTC

by Bill Mills

All, We have the DTE call in ~ 1 hour (if my message is not delayed). Frank Rowand has agreed to talk about his TODO/backlog plans. We can probably entertain other agenda items after that. Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

4 years, 4 months

2
1
0 0

[EBBR PATCH 0/3] Updates for v2.0

by Grant Likely

Hi all, Here are the updates I've prepared for v2.0 of EBBR which I'd like to tag for review sometime in the next few weeks. Please take a look and yell if you have any concerns. g. [EBBR PATCH 1/3] Override UEFI section 2.6 requirements [EBBR PATCH 2/3] Refine RTC requirements [EBBR PATCH 3/3] Require EFI_UPDATE_CAPSULE

4 years, 5 months

5
13
0 0

[PATCH 1/1] Fix build warnings:

by Heinrich Schuchardt

Building target html results in warnings: WARNING: html_static_path entry '_static' does not exist ebbr/source/index.rst:53: WARNING: toctree contains reference to document 'references' that doesn't have a title: no link will be generated * remove reference to path _static * add title to references Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- source/conf.py | 2 +- source/references.rst | 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/source/conf.py b/source/conf.py index 86f7b88..4a2566a 100644 --- a/source/conf.py +++ b/source/conf.py @@ -100,7 +100,7 @@ html_theme = 'alabaster' # Add any paths that contain custom static files (such as style sheets) here, # relative to this directory. They are copied after the builtin static files, # so a file named "default.css" will overwrite the builtin "default.css". -html_static_path = ['_static'] +# html_static_path = ['_static'] # -- Options for HTMLHelp output ------------------------------------------ diff --git a/source/references.rst b/source/references.rst index 1eb0509..c94d1d1 100644 --- a/source/references.rst +++ b/source/references.rst @@ -1,5 +1,8 @@ .. SPDX-License-Identifier: CC-BY-SA-4.0 +References +========== + .. [ACPI] `Advanced Configuration and Power Interface specification v6.2A <http://www.uefi.org/sites/default/files/resources/ACPI%206_2_A_Sept29.pdf>`_, September 2017, `UEFI Forum <http://www.uefi.org>`_ -- 2.30.0

4 years, 5 months

1
0
0 0

[PATCH 1/1] UEFI section 2.6 exceptions for boot services

by Heinrich Schuchardt

Describes deviations for ConnectController() and LoadImage(). Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- source/chapter2-uefi.rst | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 49aec46..660eb27 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -112,6 +112,17 @@ interface specific UEFI protocols, and so they have been made optional. * - Element - Description of deviation + * - `LoadImage()` + - The LoadImage() boot service is not required to install an + EFI_HII_PACKAGE_LIST_PROTOCOL for an image containing a custom PE/COFF + resource with the type 'HII'. - HII resource images are not needed to run + the UEFI shell or the SCT. + * - `ConnectController()` + - The ConnectController()` boot service is not required to support the + EFI_PLATFORM_DRIVER_OVERRIDE_PROTOCOL, + EFI_DRIVER_FAMILY_OVERRIDE_PROTOCOL, and + EFI_BUS_SPECIFIC_DRIVER_OVERRIDE_PROTOCOL. - These override protocols are + only useful if drivers are loaded as EFI binaries by the firmware. * - `EFI_HII_CONFIG_ACCESS_PROTOCOL` - UEFI requires this for console devices, but it is rarely necessary in practice. Therefore this protocol is not required. -- 2.30.0

4 years, 5 months

2
1
0 0

[PATCH] Override UEFI section 2.6 requirements

by Grant Likely

EBBR only requires a subset of UEFI. Provide a replacement for the UEFI section that lists base requirements. Fixes: #60 Fixes: #61 Fixes: #64 --- This is my first complete draft itemizing the specific UEFI requirements for EBBR. Please review and comment. Cheers, g. source/chapter2-uefi.rst | 155 ++++++++++++++++++++++++++++++++++++++- 1 file changed, 152 insertions(+), 3 deletions(-) diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index aab1c2c..5864a17 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -14,8 +14,157 @@ This document uses version 2.8 Errata A of the UEFI specification [UEFI]_. UEFI Compliance =============== -EBBR compliant platforms shall conform to the requirements in [UEFI]_ § 2.6, -except where explicit exemptions are provided by this document. +EBBR compliant platform shall conform to a subset of the [UEFI]_ spec as listed +in this section. +Normally, UEFI compliance would require full compliance with all items listed +in section 2.6 of the UEFI spec. +However, the EBBR target market has a reduced set of requirements, +and so some UEFI features are omitted as unnecessary. + +Required Elements +----------------- + +This section replaces the list of required elements in [UEFI]_ § 2.6.1. +All of the following UEFI elements are required for EBBR compliance. + +.. list-table:: UEFI Required Elements + :widths: 50 50 + :header-rows: 1 + + * - Element + - Requirement + * - `EFI_SYSTEM_TABLE` + - The system table is required to provide required to access UEFI Boot Services, + UEFI Runtime Services, consoles, and other firmware, vendor and platform + information. + * - `EFI_BOOT_SERVICES` + - All functions defined as boot services must exist. + Methods for unsupported or unimplemented behavour must return an appropriate error code. + * - `EFI_RUNTIME_SERVICES` + - All functions defined as runtime services must exist. + Methods for unsupported or unimplemented behavour must return an appropriate error code. + * - `EFI_LOADED_IMAGE_PROTOCOL` + - Must be installed for each loaded image + * - `EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL` + - Must be installed for each loaded image + * - `EFI_DEVICE_PATH_PROTOCOL` + - Interface to provide location of a device + * - `EFI_DEVICE_PATH_UTILITIES_PROTOCOL` + - Interface for creating and manipulating UEFI device paths + +.. list-table:: Notible Omissions from UEFI section 2.6.1 + :header-rows: 1 + + * - Element + - Note + * - EFI_DECOMPRESS_PROTOCOL + - Native EFI Decompression is rarely used and therefore not required. + +Required Platform Specific Elements +----------------------------------- + +This section replaces the list of required elements in [UEFI]_ § 2.6.2. +All of the following UEFI elements are required for EBBR compliance. + +.. list-table:: UEFI Platform-Specific Required Elements + :widths: 50 50 + :header-rows: 1 + + * - Element + - Description + * - Console devices + - The platform must have at least one console device + * - `EFI_SIMPLE_TEXT_INPUT_PROTOCOL` + - Needed for console input + * - `EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL` + - Needed for console input + * - `EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL` + - Needed for console output + * - `EFI_DEVICE_PATH_TO_TEXT_PROTOCOL` + - Needed for console output + * - `EFI_HII_STRING_PROTOCOL` + - Required by EFI shell and for compliance testing + * - `EFI_HII_DATABASE_PROTOCOL` + - Required by EFI shell and for compliance testing + * - `EFI_UNICODE_COLLATION2_PROTOCOL` + - Required by EFI shell and for compliance testing + * - `EFI_BLOCK_IO_PROTOCOL` + - Required for block device access + * - `EFI_SIMPLE_FILE_SYSTEM_PROTOCOL` + - Required if booting from block device is supported + * - `EFI_RNG_PROTOCOL` + - Required if platform has a hardware entropy source + * - Network booting + - If the platform supports network booting via TFTP, + then `EFI_SIMPLE_NETWORK_PROTOCOL` and + `EFI_PXE_BASE_CODE_PROTOCOL` must be implemented. + +The following table is a list of notable deviations from UEFI section 2.6.2. +Many of these deviations are because the EBBR use cases do not require +interface specific UEFI protocols, and so they have been made optional. + +.. list-table:: Notible Deviations from UEFI section 2.6.2 + :widths: 50 50 + :header-rows: 1 + + * - Element + - Description of deviation + * - `EFI_HII_CONFIG_ACCESS_PROTOCOL` + - UEFI requires this for console devices, but it is rarely necessary in practice. + Therefore this protocol is not requried. + * - `EFI_HII_CONFIG_ROUTING_PROTOCOL` + - UEFI requires this for console devices, but it is rarely necessary in practice. + Therefore this protocol is not requried. + * - Graphical console + - Platforms with a graphical device are not required to expose it as a graphical console. + * - EFI_DISK_IO_PROTOCOL + - Rarely used interface that isn't requried for EBBR use cases + * - Network protocols + - A full implementation of the UEFI general purpose networking ABIs is not required, + including `EFI_NETWORK_INTERFACE_IDENTIFIER_PROTOCOL`, `EFI_MANAGED_NETWORK_PROTOCOL`, + `EFI_*_SERVICE_BINDING_PROTOCOL`, or any of the IPv4 or IPv6 protocols. + * - Byte stream device support (UART) + - UEFI protocols not required + * - PCI bus support + - UEFI protocols not required + * - USB bus support + - UEFI protocols not required + * - NVMe pass through support + - UEFI protocols not required + * - SCSI pass through support + - UEFI protocols not required + * - SCSI pass through support + - UEFI protocols not required + * - `EFI_DRIVER_FAMILY_OVERRIDE_PROTOCOL` + - Not required + * - Option ROM support + - EBBR implementations are not required to support option ROM loading + +Required Global Variables +------------------------- + +EBBR compliant platforms are required to implement the following Global +Variables as found in [UEFI]_ § 3.3. + +.. list-table:: Required UEFI Variables + :widths: 25 75 + :header-rows: 1 + + * - Variable Name + - Description + * - `Boot####` + - A boot load option. #### is a numerical hex value + * - `BootCurrent` + - The boot option that was selected for the current boot + * - `BootNext` + - The boot option that will be used for the next boot only + * - `BootOrder` + - An ordered list of boot options. + Firmware will attempt each Boot#### entry in this order + * - `OsIndications` + - Method for OS to request features from firmware + * - `OsIndicationsSupported` + - Variable for firmware to indicate which features can be enabled Block device partitioning ------------------------- @@ -148,7 +297,7 @@ are required to be implemented during boot services and runtime services. .. table:: EFI_RUNTIME_SERVICES Implementation Requirements ============================== ============= ================ - EFI_RUNTIME_SERVICES function Boot Services Runtime Services + EFI_RUNTIME_SERVICES function Before EBS() After EBS() ============================== ============= ================ EFI_GET_TIME Optional Optional EFI_SET_TIME Optional Optional -- 2.20.1

4 years, 5 months

7
17
0 0

EBBR Biweekly for Monday 01 Feb 2021

by Grant Likely

Hi all, Next EBBR biweekly is on Monday at 16:00 GMT. Dial-in details are below. Below is the agenda I have so far. I've carried over the items that we did not have time to discuss last week. Agenda: - Initrd passing - Revised UEFI requirements (patch on mailing list) - UpdateCapsule() - other business Please email if you want to add anything to the agenda Cheers, g. ---- Topic: EBBR Biweekly Time: 1 Feb 2021, 16:00-17:00 GMT Join Zoom Meeting https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09 Meeting ID: 920 8136 5511 Passcode: 490324 One tap mobile +14086380968,,92081365511#,,,,*490324# US (San Jose) +16465189805,,92081365511#,,,,*490324# US (New York) Dial by your location +1 408 638 0968 US (San Jose) +1 646 518 9805 US (New York) +1 346 248 7799 US (Houston) Meeting ID: 920 8136 5511 Passcode: 490324 Find your local number: https://armltd.zoom.us/u/aelJgr9ZAW IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

4 years, 5 months

1
2
0 0

Re: Ideas for DT improvements

by Zhangpeng (Parker, Kirin)

Hi Bill, Improve search algorithm performance: We will need data to show the problem. I suppose this would best be done when unflatening the data at runtime? What is the expected gain in boot time? Are there any measurements of how much time is spent in the search routines today? Actually, It is nessary to search and modify device tree in boot loader, and the device tree has not be unflatened. We need to search device tree node int dtb by libfdt, however libfdt algorithm is pretty horrible, eg:fdt_node_offset_by_compatible. It takes about 10ms on average to search for a node. I suppose the dtb structure and libfdt algorithm can be optimized to reduce boot time? The time for searching for a node should be less than 1 ms. Reduce DTB space: What is the goal of the use case? 1) Fit in limited storage ( ex: 256MB ) 2) Conserve more space of modest storage for container data ( 1GB eMMC) 3) Improve boot time For 3, the load time will be reduced but the decompression time will be added. These need to be balanced based on the CPU. One pet peeve I have in most of our boot loaders today is that they do loading and decompression serially. During loading the IO is 100% loaded and the CPU is very lightly loaded. During decomoression the CPU is 100% loaded and the IO is 0%. It makes sense to pipleline / overlap these things which means that it needs to go into the loader. To optimize boot time the decompression algorithm needs to be chosen correctly. On smaller CPUs the time taken to decompress newer algorithms can greatly outweigh the time taken to load the decompressed data. Ideally the time to decompress 1 block == time to load one block. The dynamics shift with CPU and IO performance. Today, a lot of people focused on boot speed just use decompressed data but I think we could do better if we pipeline Since one dtbo image contains of hundreds of dtbs, the iamge is too large. The goal of reducing dtb space is to fit in limited storage without increasing boot time. Pipleline / overlap loading and decompression is a good idea. We can try to overlap them in boot loader, and discuss it further if there's a problem. Define specific rule for properties: This is harder.In 2019 I had proposed an ATOM based DTB enhancement [2]. I was told Frank Rowand had other proposals for format changes. OK.I am very interested in the ATOM based DTB enhancement. I will learn about it and other format changes, then make some detailed discussions with you. Thanks very much, Bill. Happy Chinese New Year Regards, Zhangpeng 发件人: Jammy Zhou [mailto:jammy.zhou@linaro.org] 发送时间: 2021年2月9日 16:45 收件人: Xiamingliang (XML, Hisilicon) <xiamingliang(a)huawei.com> 抄送: Bill Mills <bill.mills(a)linaro.org>; boot-architecture(a)lists.linaro.org; Frank Rowand <frowand.list(a)gmail.com>; Zhangpeng (Parker, Kirin) <zhangpeng55(a)huawei.com>; Wangjun (U) <wangjundrv.wang(a)huawei.com> 主题: Re: Ideas for DT improvements Hi Bill, Thanks very much for your comments. Since we're close to the Chinese New Year holiday, I would assume there will be some delay for the response by Zhangpeng. Regards, Jammy On Sun, 7 Feb 2021 at 09:35, Xiamingliang (XML, Hisilicon) <xiamingliang(a)huawei.com<mailto:xiamingliang@huawei.com>> wrote: + zhangpeng, owner of DT in Hisilicon -----Original Message----- From: Bill Mills [mailto:bill.mills@linaro.org<mailto:bill.mills@linaro.org>] Sent: 2021年2月7日 1:39 To: Jammy Zhou <jammy.zhou(a)linaro.org<mailto:jammy.zhou@linaro.org>>; boot-architecture(a)lists.linaro.org<mailto:boot-architecture@lists.linaro.org>; Frank Rowand <frowand.list(a)gmail.com<mailto:frowand.list@gmail.com>> Cc: Xiamingliang (XML, Hisilicon) <xiamingliang(a)huawei.com<mailto:xiamingliang@huawei.com>> Subject: Re: Ideas for DT improvements Hi Jammy & Mingliang, On 2/5/21 2:59 AM, Jammy Zhou wrote: > Hi, > > There are several ideas for DT improvements. Please check if they are > reasonable, and any comments are welcome. I would let Mingliang (CCed) > share more details if needed. > > 1) Improve search algorithm performance: Is the binary search tree or > other algorithm better than current algorithm? > We will need data to show the problem. I suppose this would best be done when unflatening the data at runtime? What is the expected gain in boot time? Are there any measurements of how much time is spent in the search routines today? > 2) Reduce DTB space: when use one DTB to support multiple boards, the > image is quite big (e.g, ~39MB space for 100 configurations), and some > compression algorithm can reduce the space a lot (e.g, from 39MB to 7MB). > Shall we have such compression support for DTB? And it can be helpful > if we can have more efficient compression algorithm. > This could be done as an enhancement to the DTB loader instead of the DTB format itself. Compressing each DTB (boardx.dtb.xz) will get you gains but compressing a set of boards (vmlinux-5.4.0-65-generic-dbt-set-20.tar.xz) might give you more. To be significant, the number of boards would need to be large and the size of the rootfs would need to be modest. A 200 to 300 MB minimal image would make an interesting comparison point. (A rootfs of 10s of MB would probably only target a few boards.) What is the goal of the use case? 1) Fit in limited storage ( ex: 256MB ) 2) Conserve more space of modest storage for container data ( 1GB eMMC) 3) Improve boot time For 3, the load time will be reduced but the decompression time will be added. These need to be balanced based on the CPU. One pet peeve I have in most of our boot loaders today is that they do loading and decompression serially. During loading the IO is 100% loaded and the CPU is very lightly loaded. During decomoression the CPU is 100% loaded and the IO is 0%. It makes sense to pipleline / overlap these things which means that it needs to go into the loader. To optimize boot time the decompression algorithm needs to be chosen correctly. On smaller CPUs the time taken to decompress newer algorithms can greatly outweigh the time taken to load the decompressed data. Ideally the time to decompress 1 block == time to load one block. The dynamics shift with CPU and IO performance. Today, a lot of people focused on boot speed just use decompressed data but I think we could do better if we pipeline > 3) Define specific rule for properties: The property value > (FDT_PROP_DATA) itself occupies only ~50% of the total DTB space. And > the property of each node is different and the private property name > length is too long, for > example: “freq-autodown-baseaddress-num” in dt_strings. It seems more > reasonable that the property value should occupies more than 70% of > the total DTB space. It can probably be achieved to define some rules > to restrict the length of property name, etc. > This is harder. In 2019 I had proposed an ATOM based DTB enhancement [2]. I was told Frank Rowand had other proposals for format changes. Thanks, Bill [2] https://docs.google.com/document/d/19XbxN-zX-GYwOXdF78lGnp0j7UNx1MT3wzyCjai… > Thanks, > Jammy > _______________________________________________ > boot-architecture mailing list > boot-architecture(a)lists.linaro.org<mailto:boot-architecture@lists.linaro.org> > https://lists.linaro.org/mailman/listinfo/boot-architecture > -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

4 years, 5 months

1
0
0 0

Ideas for DT improvements

by Jammy Zhou

Hi, There are several ideas for DT improvements. Please check if they are reasonable, and any comments are welcome. I would let Mingliang (CCed) share more details if needed. 1) Improve search algorithm performance: Is the binary search tree or other algorithm better than current algorithm? 2) Reduce DTB space: when use one DTB to support multiple boards, the image is quite big (e.g, ~39MB space for 100 configurations), and some compression algorithm can reduce the space a lot (e.g, from 39MB to 7MB). Shall we have such compression support for DTB? And it can be helpful if we can have more efficient compression algorithm. 3) Define specific rule for properties: The property value (FDT_PROP_DATA) itself occupies only ~50% of the total DTB space. And the property of each node is different and the private property name length is too long, for example: “freq-autodown-baseaddress-num” in dt_strings. It seems more reasonable that the property value should occupies more than 70% of the total DTB space. It can probably be achieved to define some rules to restrict the length of property name, etc. Thanks, Jammy

4 years, 5 months

3
3
0 0

Devicetree Evo Call Monday Jan 25 and every two weeks thereafter

by Bill Mills

All, I hope we have finally settled on a standing meeting time for the DT Evo call. We will have the call every other Monday alternating with EBBR in the same time slot. If I have done the TZ math correctly this is 16:00 UTC, and 11 AM US Eastern, 8AM US Pacific. I have sent a google calendar invite to all those listed on the previous call. If you would like to be added to that please email me directly at bill.mills(a)linaro.org Topic: Devicetree Evolution Time: Jan 25, 2021 11:00 AM Eastern Time (US and Canada) Every 2 weeks on Mon (Alternates with EBBR meeting in same time slot) Join Zoom Meeting https://linaro-org.zoom.us/j/96170428801?pwd=elBJNFdVMFJub0UzanFUcVQxTHBqdz… Meeting ID: 961 7042 8801 Passcode: 8250 One tap mobile +13017158592,,96170428801# US (Washington D.C) +16465588656,,96170428801# US (New York) Dial by your location +1 301 715 8592 US (Washington D.C) 888 788 0099 US Toll-free 877 853 5247 US Toll-free +44 203 481 5237 United Kingdom 0 800 031 5717 United Kingdom Toll-free Meeting ID: 961 7042 8801 Find your local number: https://linaro-org.zoom.us/u/acQEZ30MEP -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

4 years, 5 months

2
2
0 0

[EBBR RFC] Refine RTC requirements

by Grant Likely

If the platform has an RTC, then EFI_GET_TIME and EFI_SET_TIME are required before ExitBootServices(). Clarify this in the spec. Also specify that EFI_{GET,SET}_WAKEUP_TIME are required before ExitBootService() if the RTC can wakeup the platform. Signed-off-by: Grant Likely <grant.likely(a)arm.com> --- Reading through the RTC text it didn't seem clear to me. How's this for a clarification? g. source/chapter2-uefi.rst | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 9906fd9..ab22932 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -159,16 +159,16 @@ are required to be implemented during boot services and runtime services. - Before ExitBootServices() - After ExitBootServices() * - `EFI_GET_TIME` - - Optional + - Required if RTC present - Optional * - `EFI_SET_TIME` - - Optional + - Required if RTC present - Optional * - `EFI_GET_WAKEUP_TIME` - - Optional + - Required if wakeup supported - Optional * - `EFI_SET_WAKEUP_TIME` - - Optional + - Required if wakeup supported - Optional * - `EFI_SET_VIRTUAL_ADDRESS_MAP` - N/A @@ -227,8 +227,11 @@ it may not be possible to access the RTC from runtime services. e.g., The RTC may be on a shared I2C bus which runtime services cannot access because it will conflict with the OS. -If firmware does not support access to the RTC, then GetTime() and -SetTime() shall return EFI_UNSUPPORTED, +If an RTC is present, then GetTime() and SetTime() must be supported +before ExitBootServices() is called. + +However, if firmware does not support access to the RTC after +ExitBootServices(), then GetTime() and SetTime() shall return EFI_UNSUPPORTED and the OS must use a device driver to control the RTC. UEFI Reset and Shutdown -- 2.20.1

4 years, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture