- TF-A - lists.trustedfirmware.org

Canceled event: TF-A Tech Forum @ Thu Mar 25, 2021 9am - 10am (MST) (tf-a@lists.trustedfirmware.org)

by Don Harbin

This event has been canceled. Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu Mar 25, 2021 9am – 10am Mountain Standard Time - Phoenix Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher - creator * marek.bykowski(a)gmail.com * okash.khawaja(a)gmail.com * tf-a(a)lists.trustedfirmware.org Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

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

Re: [TF-A] EHF + OPTEE on ARM64

by Sandeep Tripathy

Hi Peng, 1-Asynchronous preemption of SP: The long route is to make changes in the dispatcher and the corresponding SPD implementation to have synchronous preemption. ie: OP-TEE dispatcher will implement a G1NS (fiq) handler and invoke an entry of OP-TEE synchronously. OP-TEE will save the thread context and return. I did some POC but the complexity and effort to generalise was not justified by our requirement at that point especially envisioning the movement to SPMD in future. 2-Synchronous preemption of SP: ref: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/6345 I used this approach instead to unblock OP-TEE work alongside EHF. This serves the purpose without changing the routing model with a limitation that non yielding/fast SMC can not be preempted. And ofcourse OP-TEE can mask G0 interrupt in anycase. But I think this is sufficient for your purpose. Please feedback if the above patch works for you. Thanks Sandeep On Mon, Mar 22, 2021 at 2:43 PM Peng Fan via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Achin, > > > > We are using SDEI for Jailhouse hypervisor to minimize interrupt latency, however we also wanna use OP-TEE when SDEI enabled. > > > > So I wanna how to make both work together. > > > > Thanks, > > Peng. > > > > From: Achin Gupta [mailto:Achin.Gupta@arm.com] > Sent: 2021年3月17日 17:59 > To: Peng Fan <peng.fan(a)nxp.com>; Jens Wiklander <jens.wiklander(a)linaro.org> > Cc: op-tee(a)lists.trustedfirmware.org; tf-a(a)lists.trustedfirmware.org > Subject: Re: EHF + OPTEE on ARM64 > > > > Hi Peng, > > > > +TF-A folk. > > > > My 0.02$. > > > > What is the problem you are trying to solve? Why do you need to run OP-TEE and EHF together? EHF was originally written to support a S-EL0 SP that is managed directly by TF-A in EL3 (TF-A folk can chime in). > > > > The SP could perform RAS error handling for which it needs the EHF. The EHF triages asynchronous exceptions and hands RAS errors to the SP for further handling. > > > > This is just one use case but there is no Trusted OS in these configurations. > > > > So, it would help to understand the requirement. > > > > cheers, > > Achin > > > > ________________________________ > > From: OP-TEE <op-tee-bounces(a)lists.trustedfirmware.org> on behalf of Jens Wiklander via OP-TEE <op-tee(a)lists.trustedfirmware.org> > Sent: 17 March 2021 09:23 > To: Peng Fan <peng.fan(a)nxp.com> > Cc: op-tee(a)lists.trustedfirmware.org <op-tee(a)lists.trustedfirmware.org> > Subject: Re: EHF + OPTEE on ARM64 > > > > On Wed, Mar 17, 2021 at 9:43 AM Peng Fan <peng.fan(a)nxp.com> wrote: > > > > > Subject: Re: EHF + OPTEE on ARM64 > > > > > > On Wed, Mar 17, 2021 at 9:02 AM Peng Fan <peng.fan(a)nxp.com> wrote: > > > > > > > > > Subject: Re: EHF + OPTEE on ARM64 > > > > > > > > > > On Wed, Mar 17, 2021 at 8:41 AM Peng Fan <peng.fan(a)nxp.com> wrote: > > > > > > > > > > > > > Subject: Re: EHF + OPTEE on ARM64 > > > > > > > > > > > > > > On Tue, Mar 16, 2021 at 11:08 AM Peng Fan <peng.fan(a)nxp.com> > > > wrote: > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > In bl31/ehf.c, there are following two lines, per my > > > > > > > > understanding, when cpu is in secure world, the non-secure > > > > > > > > interrupt as FIQ(GICv3) will be directly catched by EL3, not S-EL1 > > > > > > > > /* Route EL3 interrupts when in Secure and Non-secure. > > > */ > > > > > > > > set_interrupt_rm_flag(flags, NON_SECURE); > > > > > > > > set_interrupt_rm_flag(flags, SECURE); > > > > > > > > > > > > > > > > So this will conflict with OP-TEE, because OP-TEE needs catch > > > > > > > > NS-interrupt as FIQ in S-EL1 world. > > > > > > > > > > > > > > In the case of GICv3, OP-TEE is configured to receive the > > > > > > > non-secure interrupts as FIQ and secure interrupts as IRQ. See > > > CFG_ARM_GICV3. > > > > > > > > > > > > But EHF needs NS-interrupt FIQ be catched by EL3 if I understand > > > > > > correct, per " set_interrupt_rm_flag(flags, SECURE);" > > > > > > > > > > > > So currently EHF could not work together with OP-TEE, right? > > > > > > > > > > To be honest, I'm not completely sure what EHF does. From OP-TEE > > > > > point of view we expect to receive the non-secure interrupts as a > > > > > way of doing a controlled exit. This allows OP-TEE to resume > > > > > execution with a different core on re-entry. If EL3 takes the > > > > > non-secure interrupts directly it will have to make sure to only re-enter > > > OP-TEE on this core as a return from exception. > > > > > > > > Is this easy to be achieved? > > > > > > I don't know, it depends on what you intend to do with this non-secure > > > interrupt. If it's handled at EL3 and then there's a return from exception back > > > to S-EL1 there's likely no harm done. But if there's a world switch involved > > > there might be trouble, OP-TEE might not be in a suitable state for a world > > > switch. > > > > > > > > > > > Or by using opteed_sel1_interrupt_handler, could we have similar > > > > behavior to allow the other core resume execution? > > > > > > Only OP-TEE itself can make a controlled exit as there's an internal state to > > > maintain. Currently that's signalled with a non-secure interrupt. > > > > > > Per EHF, https://trustedfirmware-a.readthedocs.io/en/latest/components/exception-han… > > On GICv3 systems, when executing in S-EL1, pending Non-secure interrupts of > > sufficient priority are signalled as FIQs, and therefore will be routed to EL3. > > As a result, S-EL1 software cannot expect to handle Non-secure interrupts at S-EL1. > > Essentially, this deprecates the routing mode described as CSS=0, TEL3=0. > > > > In order for S-EL1 software to handle Non-secure interrupts while having EHF enabled, > > the dispatcher must adopt a model where Non-secure interrupts are received at EL3, > > but are then synchronously handled over to S-EL1. > > > > The issue to me here how to synchronously handled over to S-EL1 and not break optee. > > I understand. OP-TEE is masking interrupts in some critical sections, > while in such a state OP-TEE cannot handle any asynchronous interrupt. > Temporarily masking interrupts is normally a quick operation so we do > it in quite a few places. > So the crux of the problem is to make sure that OP-TEE is in a state > where it can make a controlled exit. I don't have any good ideas for > this right now. > > Cheers, > Jens > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 3 months

2
1
0 0

Linaro Virtual Connect: March 23-25, 2021

by Joanna Farley

This week a 3 day Linaro Virtual Connect event is being held. There are 60+ sessions many of which may be of interest to the project community including a number of updated TF-A sessions previously presented at the Tech-Forum. The Linaro Virtual Connect schedule is available here<https://connect.linaro.org/schedule/>. Virtual Connect notes: * Free Register here<https://connect.linaro.org/>. * The virtual sessions occur across various time-zones, but all sessions will be recorded and published shortly after the event for you to be able to watch later. Thanks Joanna

4 years, 3 months

1
0
0 0

CANCELLED: TF-A Tech Forum Agenda @ Thr 25th March 2021 16:00-1700 GMT

by Joanna Farley

I am cancelling this weeks TF-A Tech forum Although I had hoped to have a session ready for this week unfortunately that is not the case. However, this week there is a three day Linaro Virtual Connect event March 23-25 where re-runs of a number of previous TF-A Tech Forum sessions are being performed with updated information in a number of cases. Please see the following email with details of the Linaro Virtual Connect event. Joanna

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 raghu.ncstate＠icloud.com

+tf-a list. -----Original Message----- From: raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com> Sent: Monday, March 22, 2021 7:21 AM To: 'Grant Likely' <grant.likely(a)arm.com>; 'Harb Abdulhamid OS' <abdulhamid(a)os.amperecomputing.com>; 'Stuart Yoder' <stuart.yoder(a)arm.com>; 'Jose Marinho' <Jose.Marinho(a)arm.com> Subject: RE: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages I'm also in favor of the proposed method as an alternative(not replace) to the fconf/device tree based method, which works well for vertically integrated systems but not so for systems like Harb has mentioned below. Stuffing/modifying device tree on the fly is awkward even for small pieces of data and not everybody(at least me) would be happy with including something like a device tree library in early boot loader stages and firmware for various reasons(complexity, avoid parsing code for security reasons). Thanks Raghu -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Grant Likely via TF-A Sent: Monday, March 22, 2021 4:03 AM To: Harb Abdulhamid OS <abdulhamid(a)os.amperecomputing.com>; tf-a(a)lists.trustedfirmware.org; Stuart Yoder <stuart.yoder(a)arm.com>; Jose Marinho <Jose.Marinho(a)arm.com> Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages Hi Harb, This sounds like a useful abstraction to me. I can see it being useful when we need to pass TPM logs from one stage to another, or to pass on firmware update status. Things that /could/ be stuffed into a single devicetree, but it is awkward to rewrite the devicetree for every piece of dynamic data that gets generated and passed on. It would also be helpful if a common approach can be used regardless of the normal-world firmware (i.e., EDK2, U-Boot, or something else). g. On 22/03/2021 08:34, Harb Abdulhamid OS via TF-A 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

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 Grant Likely

Hi Harb, This sounds like a useful abstraction to me. I can see it being useful when we need to pass TPM logs from one stage to another, or to pass on firmware update status. Things that /could/ be stuffed into a single devicetree, but it is awkward to rewrite the devicetree for every piece of dynamic data that gets generated and passed on. It would also be helpful if a common approach can be used regardless of the normal-world firmware (i.e., EDK2, U-Boot, or something else). g. On 22/03/2021 08:34, Harb Abdulhamid OS via TF-A 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 > >

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 Grant Likely

Hi Harb, This sounds like a useful abstraction to me. I can see it being useful when we need to pass TPM logs from one stage to another, or to pass on firmware update status. Things that /could/ be stuffed into a single devicetree, but it is awkward to rewrite the devicetree for every piece of dynamic data that gets generated and passed on. It would also be helpful if a common approach can be used regardless of the normal-world firmware (i.e., EDK2, U-Boot, or something else). g. On 22/03/2021 08:34, Harb Abdulhamid OS via TF-A 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 > >

4 years, 3 months

1
0
0 0

Re: [TF-A] EHF + OPTEE on ARM64

by Achin Gupta

Hi Peng, +TF-A folk. My 0.02$. What is the problem you are trying to solve? Why do you need to run OP-TEE and EHF together? EHF was originally written to support a S-EL0 SP that is managed directly by TF-A in EL3 (TF-A folk can chime in). The SP could perform RAS error handling for which it needs the EHF. The EHF triages asynchronous exceptions and hands RAS errors to the SP for further handling. This is just one use case but there is no Trusted OS in these configurations. So, it would help to understand the requirement. cheers, Achin ________________________________ From: OP-TEE <op-tee-bounces(a)lists.trustedfirmware.org> on behalf of Jens Wiklander via OP-TEE <op-tee(a)lists.trustedfirmware.org> Sent: 17 March 2021 09:23 To: Peng Fan <peng.fan(a)nxp.com> Cc: op-tee(a)lists.trustedfirmware.org <op-tee(a)lists.trustedfirmware.org> Subject: Re: EHF + OPTEE on ARM64 On Wed, Mar 17, 2021 at 9:43 AM Peng Fan <peng.fan(a)nxp.com> wrote: > > > Subject: Re: EHF + OPTEE on ARM64 > > > > On Wed, Mar 17, 2021 at 9:02 AM Peng Fan <peng.fan(a)nxp.com> wrote: > > > > > > > Subject: Re: EHF + OPTEE on ARM64 > > > > > > > > On Wed, Mar 17, 2021 at 8:41 AM Peng Fan <peng.fan(a)nxp.com> wrote: > > > > > > > > > > > Subject: Re: EHF + OPTEE on ARM64 > > > > > > > > > > > > On Tue, Mar 16, 2021 at 11:08 AM Peng Fan <peng.fan(a)nxp.com> > > wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > In bl31/ehf.c, there are following two lines, per my > > > > > > > understanding, when cpu is in secure world, the non-secure > > > > > > > interrupt as FIQ(GICv3) will be directly catched by EL3, not S-EL1 > > > > > > > /* Route EL3 interrupts when in Secure and Non-secure. > > */ > > > > > > > set_interrupt_rm_flag(flags, NON_SECURE); > > > > > > > set_interrupt_rm_flag(flags, SECURE); > > > > > > > > > > > > > > So this will conflict with OP-TEE, because OP-TEE needs catch > > > > > > > NS-interrupt as FIQ in S-EL1 world. > > > > > > > > > > > > In the case of GICv3, OP-TEE is configured to receive the > > > > > > non-secure interrupts as FIQ and secure interrupts as IRQ. See > > CFG_ARM_GICV3. > > > > > > > > > > But EHF needs NS-interrupt FIQ be catched by EL3 if I understand > > > > > correct, per " set_interrupt_rm_flag(flags, SECURE);" > > > > > > > > > > So currently EHF could not work together with OP-TEE, right? > > > > > > > > To be honest, I'm not completely sure what EHF does. From OP-TEE > > > > point of view we expect to receive the non-secure interrupts as a > > > > way of doing a controlled exit. This allows OP-TEE to resume > > > > execution with a different core on re-entry. If EL3 takes the > > > > non-secure interrupts directly it will have to make sure to only re-enter > > OP-TEE on this core as a return from exception. > > > > > > Is this easy to be achieved? > > > > I don't know, it depends on what you intend to do with this non-secure > > interrupt. If it's handled at EL3 and then there's a return from exception back > > to S-EL1 there's likely no harm done. But if there's a world switch involved > > there might be trouble, OP-TEE might not be in a suitable state for a world > > switch. > > > > > > > > Or by using opteed_sel1_interrupt_handler, could we have similar > > > behavior to allow the other core resume execution? > > > > Only OP-TEE itself can make a controlled exit as there's an internal state to > > maintain. Currently that's signalled with a non-secure interrupt. > > > Per EHF, https://trustedfirmware-a.readthedocs.io/en/latest/components/exception-han… > On GICv3 systems, when executing in S-EL1, pending Non-secure interrupts of > sufficient priority are signalled as FIQs, and therefore will be routed to EL3. > As a result, S-EL1 software cannot expect to handle Non-secure interrupts at S-EL1. > Essentially, this deprecates the routing mode described as CSS=0, TEL3=0. > > In order for S-EL1 software to handle Non-secure interrupts while having EHF enabled, > the dispatcher must adopt a model where Non-secure interrupts are received at EL3, > but are then synchronously handled over to S-EL1. > > The issue to me here how to synchronously handled over to S-EL1 and not break optee. I understand. OP-TEE is masking interrupts in some critical sections, while in such a state OP-TEE cannot handle any asynchronous interrupt. Temporarily masking interrupts is normally a quick operation so we do it in quite a few places. So the crux of the problem is to make sure that OP-TEE is in a state where it can make a controlled exit. I don't have any good ideas for this right now. Cheers, Jens

4 years, 3 months

2
1
0 0

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

by Harb Abdulhamid OS

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

4 years, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A