- TF-A - lists.trustedfirmware.org

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

by Julius Werner

> > Thank you all for your feedback. > > It appears that in theory we are all happy with using bloblist with few > implementation details which needs to be taken care of during > implementation. > Just to clarify: are you using "bloblist" as a general term for the concept of a simple linked list of tagged data blobs, or to refer specifically to the U-Boot implementation with that name? The existing TF-A implementation (bl_aux_params) is basically identical in concept to the U-Boot bloblist, but not binary compatible. Are we talking about just keeping that, or throwing it away in order to reimplement the exact structure U-Boot is using? (I would prefer to keep the bl_aux_params as they are to avoid disrupting existing uses, of course. Making backwards-incompatible changes to an interface that passes across multiple repos and firmware components is always a big pain.)

4 years, 3 months

5
9
0 0

FIP and FCONF for STM32MP1

by Yann Gautier

Hi everyone, I've just pushed a series to support FIP and FCONF on STM32MP1 platform. I haven't put any TF-A maintainers yet, but feel free to comment. Just be aware that I'll be out of office for the 3 and a half coming weeks, so I won't be able to push new patch sets. But I'll try to connect from time to time to answer questions, if any. Best regards, Yann

4 years, 3 months

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Jul 15, 2021 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been canceled with this note: "Cancelling the TF-A Tech forum this week as the majority of attendees have clashing events and cannot join." 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 Jul 15, 2021 4pm – 5pm United Kingdom Time 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

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 2 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 371992: Control flow issues (DEADCODE) /plat/qemu/common/qemu_pm.c: 116 in qemu_validate_ns_entrypoint() ________________________________________________________________________________________________________ *** CID 371992: Control flow issues (DEADCODE) /plat/qemu/common/qemu_pm.c: 116 in qemu_validate_ns_entrypoint() 110 /* 111 * Check if the non secure entrypoint lies within the non 112 * secure DRAM. 113 */ 114 if ((entrypoint >= NS_DRAM0_BASE) && 115 (entrypoint < (NS_DRAM0_BASE + NS_DRAM0_SIZE))) >>> CID 371992: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "return 0;". 116 return PSCI_E_SUCCESS; 117 return PSCI_E_INVALID_ADDRESS; 118 } 119 120 /******************************************************************************* 121 * Platform handler called when a CPU is about to enter standby. ** CID 371991: Control flow issues (NO_EFFECT) /plat/qemu/common/qemu_pm.c: 115 in qemu_validate_ns_entrypoint() ________________________________________________________________________________________________________ *** CID 371991: Control flow issues (NO_EFFECT) /plat/qemu/common/qemu_pm.c: 115 in qemu_validate_ns_entrypoint() 109 { 110 /* 111 * Check if the non secure entrypoint lies within the non 112 * secure DRAM. 113 */ 114 if ((entrypoint >= NS_DRAM0_BASE) && >>> CID 371991: Control flow issues (NO_EFFECT) >>> This less-than-zero comparison of an unsigned value is never true. "entrypoint < 0UL". 115 (entrypoint < (NS_DRAM0_BASE + NS_DRAM0_SIZE))) 116 return PSCI_E_SUCCESS; 117 return PSCI_E_INVALID_ADDRESS; 118 } 119 120 /******************************************************************************* ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 3 months

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 364146: Control flow issues (DEADCODE) /plat/mediatek/mt8195/plat_pm.c: 298 in plat_validate_power_state() ________________________________________________________________________________________________________ *** CID 364146: Control flow issues (DEADCODE) /plat/mediatek/mt8195/plat_pm.c: 298 in plat_validate_power_state() 292 { 293 unsigned int pstate = psci_get_pstate_type(power_state); 294 unsigned int aff_lvl = psci_get_pstate_pwrlvl(power_state); 295 unsigned int cpu = plat_my_core_pos(); 296 297 if (aff_lvl > PLAT_MAX_PWR_LVL) { >>> CID 364146: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "return -2;". 298 return PSCI_E_INVALID_PARAMS; 299 } 300 301 if (pstate == PSTATE_TYPE_STANDBY) { 302 req_state->pwr_domain_state[0] = PLAT_MAX_RET_STATE; 303 } else { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

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

+ TF-A list that got dropped (again)! Joanna From: Joanna Farley <Joanna.Farley(a)arm.com> Date: Wednesday, 2 June 2021 at 15:29 To: Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com>, Okash Khawaja <okash.khawaja(a)gmail.com>, Simon Glass <sjg(a)chromium.org> Cc: Harb Abdulhamid OS <abdulhamid(a)os.amperecomputing.com>, Boot Architecture Mailman List <boot-architecture(a)lists.linaro.org>, Ed Stuber <edstuber(a)amperecomputing.com>, Arjun Khare <akhare(a)amperecomputing.com>, U-Boot Mailing List <u-boot(a)lists.denx.de>, Paul Isaac's <paul.isaacs(a)linaro.org>, Ron Minnich <rminnich(a)google.com>, Moe Ammar <moe(a)amperecomputing.com> Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages Hi Everyone, The Manish Pandy and Madhukar Pappireddy of the TF-A team are planning to host another TF-A Tech Forum this Thursday to continue the live discussion. Here is their agenda: On tech forum this week, we would like to continue discussions on HOB list design. The topics which we would like to cover is 1. Evaluate different proposals of passing information through boot phases. 2. If we don't get an agreement on one solution fit for all then we would try to get consensus for Infra segment platform(to solve original problem mentioned by Harb) 3. Try to get an agreement on size of tags and how "hybrid and tag only" HOB list can co-exist together? Details of the call are: ====================== TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org 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/ Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974 Meeting ID: 915 970 4974 One 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-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h ================ Joanna On 19/05/2021, 03:50, "Madhukar Pappireddy" <Madhukar.Pappireddy(a)arm.com> wrote: Attached slides presented by Manish in the TF-A tech forum. -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Madhukar Pappireddy via TF-A Sent: Tuesday, May 18, 2021 8:59 PM To: Joanna Farley <Joanna.Farley(a)arm.com>; Okash Khawaja <okash.khawaja(a)gmail.com>; Simon Glass <sjg(a)chromium.org> Cc: Harb Abdulhamid OS <abdulhamid(a)os.amperecomputing.com>; Boot Architecture Mailman List <boot-architecture(a)lists.linaro.org>; Ed Stuber <edstuber(a)amperecomputing.com>; Arjun Khare <akhare(a)amperecomputing.com>; U-Boot Mailing List <u-boot(a)lists.denx.de>; tf-a(a)lists.trustedfirmware.org; Paul Isaac's <paul.isaacs(a)linaro.org>; Ron Minnich <rminnich(a)google.com>; Moe Ammar <moe(a)amperecomputing.com> Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages Hi, I tried to summarize the discussions in the previous TF-A tech forum regarding the proposal to adopt Hand-off Blocks (HOBs) for passing information along the boot chain. I am certain I could not capture all suggestions/concerns brought up during the call. I apologize if I missed and/or misinterpreted any comments and would appreciate it if everyone could share their thoughts in response to this email thread. The idea is to share information to other boot phases: > Dynamic information: Created during runtime. Shared in the form of a chain of blobs(built as a linked list of C structure objects i.e., HOB list). > Static information: Known at compile time. Historically, shared through the use of Device Tree/ACPI tables Both the above requirements are common in many ecosystems and need to co-exist. There are broadly 3 problems to solve: 1. Format of HOB structures: It looks like the consensus is that we could use existing mechanisms for this (BL_AUX_PARAM in TF-A or bloblist in u-boot). 2. Identification of HOB list entries: There is a debate about whether tags would suffice or if the HOB list producer and consumer would depend on UUID/GUIDs for identifying a specific HOB structure. Another suggestion was to use a hybrid approach. Reserve a single tag ID for identifying/constructing a HOB structure that further leverages UUID based identifier. This way, the generic HOB list doesn't need to support UUIDs and can work with tags. 3. The design contract for the static interface between two boot phases: The problem at hand is whether to pass a pointer to a HOB list or a device tree blob through the general-purpose registers for configuration hand-off between two boot phases. Some proposals that came up: > Proposal 1: Always pass a pointer to the device tree blob through the GP register and capture the pointer to the HOB list as a property of a node that is uniquely identifiable by the downstream boot phase. This needs to define a device tree binding such that producer and consumer agree on the information passed. > Proposal 2: Pass a pointer to a generic container through the GP register that can be interpreted appropriately by both boot loaders(i.e., producer and consumer of the boot info). This container can either be a dtb or a HOB list which can be simply inferred by checking for a magic header that indicates if the buffer appears to be a flattened device tree. > One another concern that was brought up offline is to make sure we don't break current design contracts between various boot loader phases in TF-A. Many of the general-purpose registers have a designated purpose such as to share configurations between BL images( such as firmware config dtb, SoC config dtb, Non trusted firmware config dtb, memory layout, entry point info, etc.). If I am not mistaken, a single design may not fit the needs of every segment(client, Infra, embedded) and the forum is open to solutions tailored for individual segments. Joanna will be sending a follow up email with more information about future TF-A tech forums that serves as a platform for further discussions. Thanks, Madhukar -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Joanna Farley via TF-A Sent: Sunday, May 16, 2021 5:19 AM To: Okash Khawaja <okash.khawaja(a)gmail.com>; Simon Glass <sjg(a)chromium.org> Cc: Harb Abdulhamid OS <abdulhamid(a)os.amperecomputing.com>; Boot Architecture Mailman List <boot-architecture(a)lists.linaro.org>; tf-a(a)lists.trustedfirmware.org; Ed Stuber <edstuber(a)amperecomputing.com>; Arjun Khare <akhare(a)amperecomputing.com>; U-Boot Mailing List <u-boot(a)lists.denx.de>; Paul Isaac's <paul.isaacs(a)linaro.org>; Ron Minnich <rminnich(a)google.com>; Moe Ammar <moe(a)amperecomputing.com> Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages Apologies I failed with the recording. Manish/Madhu will reply early next week with the slides and some notes to help with a follow up session which we hope to hold this Thursday. Invite and agenda will also be sent out early next week. Thanks Joanna On 14/05/2021, 13:30, "TF-A on behalf of Okash Khawaja via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi, Do we have slides and video from last week's discussion? Thanks, Okash On Wed, May 5, 2021 at 11:52 PM Simon Glass via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Harb, > > Thanks for the idea. I am still not completely sure what benefit UUID provides to an open project. I'd like to propose something different, more in the spirit of open collaboration. I also worry that the word 'standard' seems to be a synonym for UUIDs, UEFI, etc., i.e. enabling/preferring closed-source firmware and the continued decline of open-source projects. It really should not be. > > So I suggest: Use simple integer IDs and reserve some area for 'private' use. If you want to collaborate across projects outside your company, you either need to allocate a 'public' ID or agree privately between the parties which private ID to use. > > This means that the default and easiest option is for collaboration and a public ID, with private ones (whose purpose may be secret) reserved just for private use. > > Regards, > Simon > > On Wed, 5 May 2021 at 11:42, Harb Abdulhamid OS <abdulhamid(a)os.amperecomputing.com> wrote: >> >> Hey Folks, >> >> We wanted to put out a middle-ground proposal to help guide the discussion on the call tomorrow. >> >> >> >> A proposal that we have been discussing offline involves reserving a single tag ID for the purpose of construction UEFI PI HOB List structure, and that tag would be used to identify a HOB-specific structure that does leverage UUID based identifier. This will eliminate the burden of having to support UUID as the tag, and this enables projects that require UUID based identifiers for the broad range of HOB structures that need to be produced during the booting of the platform. Once we have a tag for a HOB list, this will enable various HOB producers that can add/extend the HOB list in TF-A code (or even pre-TF-A code), with a HOB consumer for that UUID/GUID on the other side (i.e. whatever the BL33 image is booting on that platform). >> >> >> >> Essentially, the idea is if someone would like to support HOB structures in a standard way using TF-A, they would wrap it up in a BL_AUX_PARAM/BLOB structure (whatever the group decides) and the way we identify the structure as a HOB list is with this new reserved tag. >> >> >> >> Hopefully that makes sense and less contentious. Look forward to discuss this further on the call. >> >> >> >> Thanks, >> >> --Harb >> >> >> >> From: Manish Pandey2 <Manish.Pandey2(a)arm.com> >> Sent: Friday, April 30, 2021 8:14 AM >> To: François Ozog <francois.ozog(a)linaro.org> >> Cc: Simon Glass <sjg(a)chromium.org>; Julius Werner <jwerner(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; U-Boot Mailing List <u-boot(a)lists.denx.de>; 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 >> >> >> >> Hi All, >> >> >> >> Please find invite for next TF-A Tech Forum session to continue our discussions on HOB implementation, feel free to forward it to others. >> >> >> >> The next TF-A Tech Forum is scheduled for Thu 6th May 2021 16:00 – 17:00 (BST). >> >> >> >> Agenda: >> >> Discussion Session: Static and Dynamic Information Handling in TF-A >> >> Lead by Manish Pandey and Madhukar Pappireddy >> >> · There is ongoing mailing lists discussion[1] related with adopting a mechanism to pass information through boot stages. >> >> The requirement is two-fold: >> >> 1. Passing static information(config files) >> >> 2. Passing dynamic information (Hob list) >> >> In the upcoming TF-A tech forum, we can start with a discussion on dynamic information passing and if time permits, we can cover static information passing. The purpose of the call is to have an open discussion and continue the discussion from the trusted-substrate call[2] done earlier. We would like to understand the various requirements and possible ways to implement it in TF-A in a generalized way so that it can work with other Firmware projects. >> >> >> >> The two specific item which we would like to discuss are: >> >> 1. HOB format: TF-A/u-boot both has an existing bloblist implementation, which uses tag values. Question, can this be enhanced to use hybrid values(Tag and UUID) both? >> >> 2. Standardization on Physical register use to pass base of HoB data structure. >> >> References: >> >> [1] https://lists.trustedfirmware.org/pipermail/tf-a/2021-April/001069.html >> >> [2] https://linaro-org.zoom.us/rec/share/zjfHeMIumkJhirLCVQYTHR6ftaqyWvF_0klgQn… Passcode: IPn+5q% >> >> >> >> Thanks >> >> >> >> Joanna >> >> >> >> You have been invited to the following event. >> >> TF-A Tech Forum >> >> When >> >> Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time >> >> Calendar >> >> tf-a(a)lists.trustedfirmware.org >> >> Who >> >> • >> >> Bill Fletcher- creator >> >> • >> >> tf-a(a)lists.trustedfirmware.org >> >> more details » >> >> >> >> 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/ >> >> >> >> Trusted Firmware is inviting you to a scheduled Zoom meeting. >> >> >> >> Join Zoom Meeting >> >> https://zoom.us/j/9159704974 >> >> >> >> Meeting ID: 915 970 4974 >> >> >> >> One 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-free >> >> Meeting ID: 915 970 4974 >> >> Find your local number: https://zoom.us/u/ad27hc6t7h >> >> >> >> ________________________________ >> >> From: François Ozog <francois.ozog(a)linaro.org> >> Sent: 08 April 2021 16:50 >> To: Manish Pandey2 <Manish.Pandey2(a)arm.com> >> Cc: Simon Glass <sjg(a)chromium.org>; Julius Werner <jwerner(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 <tf-a(a)lists.trustedfirmware.org>; U-Boot Mailing List <u-boot(a)lists.denx.de>; 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 >> >> >> >> Hi >> >> >> >> here is the meeting recording: >> >> https://linaro-org.zoom.us/rec/share/zjfHeMIumkJhirLCVQYTHR6ftaqyWvF_0klgQn… Passcode: IPn+5q%z >> >> >> >> I am really sorry about the confusion related to the meeting time. I have now understood: the Collaborate portal uses a specific calendar which is tied to US/Chicago timezone while the actual Google Calendar is tied to Central Europe timezone. I am going to drop the Collaborate portal and use a shared Google calendar (it should be visible on the trusted-substrate.org page). >> >> >> >> I'll try to summarize what I learnt and highlight my view on what can be next steps in a future mail. >> >> >> >> Cheers >> >> >> >> FF >> >> >> >> On Thu, 8 Apr 2021 at 13:56, Manish Pandey2 via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: >> >> Hi, >> >> >> >> From TF-A project point of view, we prefer to use existing mechanism to pass parameters across boot stages using linked list of tagged elements (as suggested by Julius). It has support for both generic and SiP-specific tags. Having said that, it does not stop partners to introduce new mechanisms suitable for their usecase in platform port initially and later move to generic code if its suitable for other platforms. >> >> >> >> To start with, Ampere can introduce a platform specific implementation of memory tag(speed/NUMA topology etc) which can be evaluated and discussed for generalization in future. The tag will be populated in BL2 stage and can be forwarded to further stages(and to BL33) by passing the head of list pointer in one of the registers. Initially any register can be used but going forward a standardization will be needed. >> >> >> >> The U-boot bloblist mentioned by Simon is conceptually similar to what TF-A is using, if there is consensus of using bloblist/taglist then TF-A tag list may be enhanced to take best of both the implementations. >> >> >> >> One of the potential problems of having structure used in different projects is maintainability, this can be avoided by having a single copy of these structures in TF-A (kept inside "include/export" which intended to be used by other projects.) >> >> >> >> Regarding usage of either UUID or tag, I echo the sentiments of Simon and Julius to keep it simple and use tag values. >> >> >> >> Looking forward to having further discussions on zoom call today. >> >> >> >> Thanks >> >> Manish P >> >> >> >> ________________________________ >> >> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Julius Werner via TF-A <tf-a(a)lists.trustedfirmware.org> >> Sent: 25 March 2021 02:43 >> To: Simon Glass <sjg(a)chromium.org> >> Cc: Harb Abdulhamid OS <abdulhamid(a)os.amperecomputing.com>; Boot Architecture Mailman List <boot-architecture(a)lists.linaro.org>; tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; U-Boot Mailing List <u-boot(a)lists.denx.de>; 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 >> >> >> >> 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 – 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: >> >> “SoC” or “silicon” firmware – in TF-A this may map to BL1, BL2, BL31, and *possibly* one or more BL32 instances >> “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 - 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 +Paul Isaac's >> >> >> >> 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 zoom call 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, 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) 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 >> >> -- >> 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 -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 3 months

4
6
0 0

Re: [TF-A] Missing CPU workaround warning message

by Olivier Deprez

Hi, Is the question strictly related to this platform not implementing the mentioned errata (for which a platform change can be emitted)? Or is it more generally that those "missing errata warnings" are not printed in release mode? Assuming the latter, it looks to me it is the integrator mistake to not include the appropriate mitigations at development phase (hence while using debug mode for building TF-A). Then when the device is deployed (hence most often built for release mode), if this message is printed it is an indication for a malicious agent that such attack vector through mis-implemented errata is possible. So the consequence is possibly even worst than just "missing" to include the errata. Other TF-Aers (Bipin?) may have other opinions? Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Pali Rohár via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 28 June 2021 15:36 To: tf-a(a)lists.trustedfirmware.org Cc: Konstantin Porotchkin; Marek Behún Subject: [TF-A] Missing CPU workaround warning message Hello! If TF-A for Marvell Armada 3720 platform is compiled in debug mode then at runtime it prints following warning messages: WARNING: BL1: cortex_a53: CPU workaround for 855873 was missing! WARNING: BL1: cortex_a53: CPU workaround for 1530924 was missing! These lines are not printed in non-debug mode. It is an issue? -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 3 months

2
2
0 0

v8-R64 Support Added to TF-A

by Gary Morrison

In the last Tech-Forum, Lauren Wehrmeister and I presented our work on adding Arm v8-R64 support to the TF-A codebase. Our presentation will be added to the Tech-Forum page (TF-A open Tech Forum regular call - Trusted Firmware<https://www.trustedfirmware.org/meetings/tf-a-technical-forum/>) shortly. In the meantime, however, there are more details about the patches here: https://developer.trustedfirmware.org/w/tf_a/rclasssupportdocs/

4 years, 4 months

1
0
0 0

Re: [TF-A] PL011 clock handling between TF-A and Linux

by Mayur

Hi, I tend to agree with Soby here. If the normal world and EL3 share the console, EL3 error messages/debug prints exposed to the normal world could be another potential attack vector. From a functionality perspective, will there not be contention issues on multi-core platforms and hence garbled output? I understand that using two separate UARTS may not be possible for many platforms, in which case a single UART can be shared during cold boot between EL3 and the normal world, while EL3 runtime messages can be logged to a secure memory buffer. Once boot exists EL3, UART ownership can be transferred to the normal world. Thanks, Mayur On Wed, Jun 23, 2021 at 5:00 AM Soby Mathew via TF-A < tf-a(a)lists.trustedfirmware.org> wrote: > Hi Michal, > Sure, platform can choose to share but I was bringing up the potential > attack vector of Non Secure being able to hang up EL3 if EL3 has runtime > prints and the Non secure is able to disable or control the UART used by > EL3. Typically , runtime logs are disabled on production builds so this > might not be a problem anyway. > > Regarding crash console, the plat_crash_console_init() can initialize a > stack (either the EL3 runtime stack or a dedicated crash stack) and use C > runtime to control clocks for crash logs. So the current assembly > implementation should not be a gating factor for doing clock control if > required. > > Best Regards > Soby Mathew > > > -----Original Message----- > > From: Michal Simek <michal.simek(a)xilinx.com> > > Sent: Wednesday, June 23, 2021 9:16 AM > > To: Varun Wadekar <vwadekar(a)nvidia.com>; Soby Mathew > > <Soby.Mathew(a)arm.com>; Michal Simek <michal.simek(a)xilinx.com> > > Cc: tf-a(a)lists.trustedfirmware.org > > Subject: Re: [TF-A] PL011 clock handling between TF-A and Linux > > > > Hi, > > > > I agree with Varun. TF-A can use DCC console but it is not practical. > > Using second console is definitely an option but not all platforms and > also > > monitoring two consoles is problematic. > > > > Also OP-TEE is touching this primary console. Platform which are using > DT are > > looking for chosen node (as backup) and read information about OS console > > from it. > > > > Thanks, > > Michal > > > > On 6/22/21 8:47 PM, Varun Wadekar wrote: > > > Hi Soby, > > > > > > Even though in principle I agree with you, it is not practical to add > secure > > only UART port to a platform. It is shared for multiple reasons - e.g. > lower > > board cost. That is the case on all Tegra Jetson platforms. > > > > > > This means that the secure world never owns the console - not even > during > > cold boot. The crash console code is in assembly today. This makes > > implementing code to communicate to an external clock manager is not > > straight forward and platforms might choose to keep the code to toggle > > clock/reset out of TF-A. > > > > > > -Varun > > > > > > -----Original Message----- > > > From: Soby Mathew <Soby.Mathew(a)arm.com> > > > Sent: Tuesday, June 22, 2021 4:30 PM > > > To: Michal Simek <michal.simek(a)xilinx.com>; Varun Wadekar > > > <vwadekar(a)nvidia.com> > > > Cc: tf-a(a)lists.trustedfirmware.org > > > Subject: RE: [TF-A] PL011 clock handling between TF-A and Linux > > > > > > External email: Use caution opening links or attachments > > > > > > > > > Hi Michal, > > > The general security rule of thumb is, any UART `owned` by Secure > world ( > > including EL3) should not be accessible/or controlled by Non Secure and > this > > includes control of the clocks as well. Hence sharing of UART / > management > > of Secure world UART clocks by Linux seems problematic to me. > > > > > > There are 3 types of consoles needed in TF-A. The first one is the > cold boot > > console, the second one is runtime console and the 3rd is crash console. > The > > cold boot console is initially owned by Secure world as part boot > process and > > once execution is transferred to Non Secure, the ownership of the UART > also > > is transferred. > > > Regarding clock expectations, the runtime UART is always expected to be > > ON but then this depends on the TF-A build config as it is very rare to > have any > > runtime logs from Secure world and hence this config may be restricted to > > development builds of TF-A. For the crash console, the clocks don't need > to > > enabled all the time and any init needed can be performed as part of > > plat_crash_console_init(). > > > > > > HTH, > > > Best Regards > > > Soby Mathew > > > > > >> -----Original Message----- > > >> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of > > >> Michal Simek via TF-A > > >> Sent: Tuesday, June 22, 2021 2:03 PM > > >> To: Varun Wadekar <vwadekar(a)nvidia.com>; Michal Simek > > >> <michal.simek(a)xilinx.com> > > >> Cc: tf-a(a)lists.trustedfirmware.org > > >> Subject: Re: [TF-A] PL011 clock handling between TF-A and Linux > > >> > > >> Hi Varun, > > >> > > >> do you have any links to that calls in Linux clk API? I expect the > > >> same hooks should be added also to reset. > > >> > > >> And is TF-A informs your special firmware that for example serial > > >> driver is used by TF-A to increate refcount? > > >> > > >> Thanks, > > >> Michal > > >> > > >> On 6/22/21 2:03 PM, Varun Wadekar wrote: > > >>> Hi Michal, > > >>> > > >>> Tegra platforms manage clocks/resets by special firmware. The > > >>> firmware > > >> internally manages refcount of users as you described. > > >>> > > >>> AFAIR, we placed calls to the firmware in the linux clk APIs to > achieve this. > > >> There was an effort to leverage runtime_pm for this too. > > >>> > > >>> I think we wont be able to add guidance to TF-A for clock management > > >>> as > > >> most of it is platform dependent. We can add a generic guideline > > >> saying that a certain driver expects the platform to manage the > clock/reset > > for the IP. > > >>> > > >>> -Varun > > >>> > > >>> -----Original Message----- > > >>> From: Michal Simek <michal.simek(a)xilinx.com> > > >>> Sent: Tuesday, June 22, 2021 7:24 AM > > >>> To: Varun Wadekar <vwadekar(a)nvidia.com>; Michal Simek > > >>> <michal.simek(a)xilinx.com> > > >>> Cc: tf-a(a)lists.trustedfirmware.org > > >>> Subject: Re: [TF-A] PL011 clock handling between TF-A and Linux > > >>> > > >>> External email: Use caution opening links or attachments > > >>> > > >>> > > >>> Hi Varun, > > >>> > > >>> Xilinx is also managing it by special firmware. There is a concept > > >>> of > > >> protected-clocks documented via DT binding which is used by Qualcomm. > > >>> > > >>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/ > > >>> tr > > >>> ee/Documentation/devicetree/bindings/clock/clock-bindings.txt?h=next > > >>> -2 > > >>> 0210621#n172 > > >>> > > >>> Are you also using this feature or simply don't let Linux know about > > >>> these > > >> clocks at all or simulate it via fixed-clock or so? > > >>> Or any registration is in place that firmware keep refcount of users > > >>> and > > >> don't let it change unless there is only one user of that clock? > > >>> > > >>> Thanks, > > >>> Michal > > >>> > > >>> On 6/21/21 6:41 PM, Varun Wadekar wrote: > > >>>> Hi Michal, > > >>>> > > >>>> AFAIK, TF-A does not publish guidelines for clocks/resets for > > >>>> shared IP. It > > >> is left to the platforms. > > >>>> > > >>>> For Tegra platforms, the clocks/reset are managed by a central > > >>>> entity. TF- > > >> A is expected to co-ordinate with this entity. Unfortunately, PL011 > > >> does not fall in this category and is expected to be kept on by the > previous > > bootloader. > > >>>> > > >>>> -Varun > > >>>> > > >>>> -----Original Message----- > > >>>> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of > > >>>> Michal Simek via TF-A > > >>>> Sent: Monday, June 21, 2021 2:24 PM > > >>>> To: tf-a(a)lists.trustedfirmware.org > > >>>> Subject: [TF-A] PL011 clock handling between TF-A and Linux > > >>>> > > >>>> External email: Use caution opening links or attachments > > >>>> > > >>>> > > >>>> Hi, > > >>>> > > >>>> recently we have hit the case where Linux has pl011 driver and > > >>>> using it as > > >> a console. The same console is also used by TF-A. If you look at > > >> implementation details Linux pl011 driver has in > > >> pl011_console_write() clk_enable/clk_disable calls. > > >>>> I can't see any clock handling for PL011 in TF-A that's why I guess > > >>>> that TF-A > > >> expectation is that clocks are enabled and must be enabled all the > > >> time because pl011 is also used as crashed console. > > >>>> That's why I would like to check with you what's the clock > > >>>> expectation in > > >> these shared IP cases. > > >>>> Do you have a requirement that firmware should keep refcount of IP > > >> users and never disable clock when only one requires it? > > >>>> > > >>>> Thanks, > > >>>> Michal > > >>>> -- > > >>>> TF-A mailing list > > >>>> TF-A(a)lists.trustedfirmware.org > > >>>> > > >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis > > >>>> t > > >>>> s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf- > > >> a&data=04%7C01%7C > > >>>> > > >> > > vwadekar%40nvidia.com%7C9d5af04d3aba49b18cc808d935465267%7C4308 > > 3 > > >> d1572 > > >>>> > > >> > > 7340c1b7db39efd9ccc17a%7C0%7C0%7C637599398425726681%7CUnknow > > n% > > >> 7CTWFpb > > >>>> > > >> > > GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI > > >> 6Mn > > >>>> > > >> > > 0%3D%7C1000&sdata=%2BXFRPZTttom4rvT%2FmEcQnbgSa276PYuKbvo > > >> H4VujRk8 > > >>>> %3D&reserved=0 > > >>>> > > >> -- > > >> TF-A mailing list > > >> TF-A(a)lists.trustedfirmware.org > > >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis > > >> t > > >> s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf- > > a&data=04%7C01%7C > > >> v > > >> > > wadekar%40nvidia.com%7C957021cd030643da94bc08d935928f6b%7C4308 > > 3d15727 > > >> 3 > > >> > > 40c1b7db39efd9ccc17a%7C0%7C0%7C637599725858916982%7CUnknown% > > 7CTWFpbGZ > > >> s > > >> > > b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn > > 0%3 > > >> D > > >> > > %7C2000&sdata=S0D%2FZ5rk6Wr3xyIdCmol0eigIo%2FlGn%2B2WJODig > > %2FeDqU > > >> % > > >> 3D&reserved=0 > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a >

4 years, 4 months

4
9
0 0

FF-A watchdog service

by François Ozog

Hi Following a discussion with Civil Infrastructure Project TSC, there is a watchdog protection issue with EFI: the time between the call to ExitBootService and Linux kernel takes over watchdog service is not covered by any watchdog protection. The EFI specification for BS.SetWatchdogTimer is very flexible as it states "perform a platform specific action that must eventually cause the platform to be reset.". So we could naively implement a solution that would arm platform hardware watchdog in addition to EFI timer. Assuming watchdog period is long enough that it cover the time for Linux to take over the hardware watchdog, there is nothing to be done in EFI Stub to benefit from the new protection. But this scheme fails to handle FF-A update capsules which can take a long time. So either the period is long enough to support that or we need a FF-A watchdog service. Based on Siemens feedback, time to update can last 20 minutes. StandAloneMM may also need such a protection so FF-A watchdog service seems desired. I'd be happy to receive feedback on the problem itself (watchdog in EFI) and on the possible solution (FF-A based). Cheers FF

4 years, 4 months

4
5
0 0

Tech Forum, Thursday 2021/07/01, 16:00-17:00 GMT: New FVP_R Platform

by Gary Morrison

Hello TF-A partners! As you may know, Arm recently announced the v8-R64 Architecture (AArch64 R-class cores), notably the Cortex R-82. v8-R64 has generated a lot of interest in the R-cores community, in part because of its vastly-increased address space and performance, and also because of its ability to run rich operating systems like Linux alongside more traditional RTOSes. Of course, great hardware requires great firmware to succeed! So, we are upstreaming a new platform into TF-A to support v8-R64, called "fvp_r." It's certainly reasonable to ask, "why support v8-R64 as a platform under the A-cores' trusted firmware?" The answer is simply that v8-R64 cores are far more similar with v8-A cores than different. Therefore, most of the trusted firmware code for v8-R64 cores is in-common with v8-A cores. If a separate trusted-firmware project were created for them, we would have a huge parallel-maintenance headache! Also, SystemReady IR certification for v8-R64 cores requires compliance with EBBR, and building from a TF-A framework puts us on the path toward that goal. The immediate firmware requirement for v8-R64, however, is not the entirety of TF-A. The immediate requirement for the fvp_r platform is to let the partner/customer dictate the nature of the run-time environment, and for TF to "trusted-boot" their environment. Therefore, the patch that we're upstreaming boots up only through BL1, and BL1 is adapted to load the customer/partner custom-defined run-time system. On 1 July, the Arm team who are upstreaming the fvp_r platform, will host a Tech Forum session wherein we'll provide an overview, and medium level of detail on: * The differences between v8-A and v8-R64 (again, more similar than different!), * The impacts of these differences upon BL1, and * Changes to BL1 to boot a partner/customer run-time system. * We'll then detail the nature of the patches involved - which patches provide what functionality. * Provide some suggestions for making the review of these patches easier. ________________________________ You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Who * Bill Fletcher- creator * tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> more details ><https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> 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/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974

4 years, 4 months

1
0
0 0

Missing CPU workaround warning message

by Pali Rohár

Hello! If TF-A for Marvell Armada 3720 platform is compiled in debug mode then at runtime it prints following warning messages: WARNING: BL1: cortex_a53: CPU workaround for 855873 was missing! WARNING: BL1: cortex_a53: CPU workaround for 1530924 was missing! These lines are not printed in non-debug mode. It is an issue?

4 years, 4 months

1
0
0 0

Re: [TF-A] PL011 clock handling between TF-A and Linux

by Soby Mathew

Hi Michal, The general security rule of thumb is, any UART `owned` by Secure world ( including EL3) should not be accessible/or controlled by Non Secure and this includes control of the clocks as well. Hence sharing of UART / management of Secure world UART clocks by Linux seems problematic to me. There are 3 types of consoles needed in TF-A. The first one is the cold boot console, the second one is runtime console and the 3rd is crash console. The cold boot console is initially owned by Secure world as part boot process and once execution is transferred to Non Secure, the ownership of the UART also is transferred. Regarding clock expectations, the runtime UART is always expected to be ON but then this depends on the TF-A build config as it is very rare to have any runtime logs from Secure world and hence this config may be restricted to development builds of TF-A. For the crash console, the clocks don’t need to enabled all the time and any init needed can be performed as part of plat_crash_console_init(). HTH, Best Regards Soby Mathew > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Michal > Simek via TF-A > Sent: Tuesday, June 22, 2021 2:03 PM > To: Varun Wadekar <vwadekar(a)nvidia.com>; Michal Simek > <michal.simek(a)xilinx.com> > Cc: tf-a(a)lists.trustedfirmware.org > Subject: Re: [TF-A] PL011 clock handling between TF-A and Linux > > Hi Varun, > > do you have any links to that calls in Linux clk API? I expect the same hooks > should be added also to reset. > > And is TF-A informs your special firmware that for example serial driver is > used by TF-A to increate refcount? > > Thanks, > Michal > > On 6/22/21 2:03 PM, Varun Wadekar wrote: > > Hi Michal, > > > > Tegra platforms manage clocks/resets by special firmware. The firmware > internally manages refcount of users as you described. > > > > AFAIR, we placed calls to the firmware in the linux clk APIs to achieve this. > There was an effort to leverage runtime_pm for this too. > > > > I think we wont be able to add guidance to TF-A for clock management as > most of it is platform dependent. We can add a generic guideline saying that > a certain driver expects the platform to manage the clock/reset for the IP. > > > > -Varun > > > > -----Original Message----- > > From: Michal Simek <michal.simek(a)xilinx.com> > > Sent: Tuesday, June 22, 2021 7:24 AM > > To: Varun Wadekar <vwadekar(a)nvidia.com>; Michal Simek > > <michal.simek(a)xilinx.com> > > Cc: tf-a(a)lists.trustedfirmware.org > > Subject: Re: [TF-A] PL011 clock handling between TF-A and Linux > > > > External email: Use caution opening links or attachments > > > > > > Hi Varun, > > > > Xilinx is also managing it by special firmware. There is a concept of > protected-clocks documented via DT binding which is used by Qualcomm. > > > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tr > > ee/Documentation/devicetree/bindings/clock/clock-bindings.txt?h=next-2 > > 0210621#n172 > > > > Are you also using this feature or simply don't let Linux know about these > clocks at all or simulate it via fixed-clock or so? > > Or any registration is in place that firmware keep refcount of users and > don't let it change unless there is only one user of that clock? > > > > Thanks, > > Michal > > > > On 6/21/21 6:41 PM, Varun Wadekar wrote: > >> Hi Michal, > >> > >> AFAIK, TF-A does not publish guidelines for clocks/resets for shared IP. It > is left to the platforms. > >> > >> For Tegra platforms, the clocks/reset are managed by a central entity. TF- > A is expected to co-ordinate with this entity. Unfortunately, PL011 does not > fall in this category and is expected to be kept on by the previous bootloader. > >> > >> -Varun > >> > >> -----Original Message----- > >> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of > >> Michal Simek via TF-A > >> Sent: Monday, June 21, 2021 2:24 PM > >> To: tf-a(a)lists.trustedfirmware.org > >> Subject: [TF-A] PL011 clock handling between TF-A and Linux > >> > >> External email: Use caution opening links or attachments > >> > >> > >> Hi, > >> > >> recently we have hit the case where Linux has pl011 driver and using it as > a console. The same console is also used by TF-A. If you look at > implementation details Linux pl011 driver has in pl011_console_write() > clk_enable/clk_disable calls. > >> I can't see any clock handling for PL011 in TF-A that's why I guess that TF-A > expectation is that clocks are enabled and must be enabled all the time > because pl011 is also used as crashed console. > >> That's why I would like to check with you what's the clock expectation in > these shared IP cases. > >> Do you have a requirement that firmware should keep refcount of IP > users and never disable clock when only one requires it? > >> > >> Thanks, > >> Michal > >> -- > >> TF-A mailing list > >> TF-A(a)lists.trustedfirmware.org > >> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis > >> t > >> s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf- > a&data=04%7C01%7C > >> > vwadekar%40nvidia.com%7C9d5af04d3aba49b18cc808d935465267%7C43083 > d1572 > >> > 7340c1b7db39efd9ccc17a%7C0%7C0%7C637599398425726681%7CUnknown% > 7CTWFpb > >> > GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI > 6Mn > >> > 0%3D%7C1000&sdata=%2BXFRPZTttom4rvT%2FmEcQnbgSa276PYuKbvo > H4VujRk8 > >> %3D&reserved=0 > >> > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 4 months

3
3
0 0

Re: [TF-A] SP manifest: avoid manual updates to "entrypoint-offset"

by Olivier Deprez

Hi, See few comments inline [OD] Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 16 June 2021 11:41 To: tf-a(a)lists.trustedfirmware.org Cc: Raghupathy Krishnamurthy; Nicolas Benech Subject: [TF-A] SP manifest: avoid manual updates to "entrypoint-offset" Hello, We (Nico/Raghu) have been implementing SEL0 partitions for Tegra platforms [OD] Just to be clear, is this about SEL0 partitions using an SEL1 shim (as per https://review.trustedfirmware.org/q/topic:%22db%252Fsel0%22+(status:open%2… )? and recently hit an issue, where the “entrypoint-offset” field of the SP manifest [1] cannot cope with increasing manifest blobs. The way the SP manifest is created today, the “entrypoint-offset” field is set to a value *statically* by the implementer. Down the line if the manifest grows past the value written in the “entrypoint-offset”, we must manually update it. This needs to be fixed. We believe there is an opportunity to upgrade the sptool to handle this situation during SP package creation, where sptool calculates the manifest size and bumps the “entrypoint-offset” past the end of the manifest. There are other ways of patching the SP manifest at runtime, but they seem sub-optimal. Please let me know if there are other ideas to solve this problem. I will post a patch to update the sptool shortly but wanted to get the ball rolling. [OD] We had an attempt (https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/8536) to move the entry point farther in the image such that we can support 64KB granules in the Stage-1 translation regime. This does not relate exactly to your problem but the effect is the "same" (aka there is more room for the manifest dtb). Agree this still requires hard-coding the entry point. At this stage I had thought of pushing the entry point even farther at a reasonably large 64KB aligned offset such that it helps with both problems. Cheers. [1] 14. FF-A manifest binding to device tree — Trusted Firmware-A documentation<https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-…>

4 years, 4 months

2
8
0 0

Re: [TF-A] PL011 clock handling between TF-A and Linux

by Varun Wadekar

Hi Michal, AFAIK, TF-A does not publish guidelines for clocks/resets for shared IP. It is left to the platforms. For Tegra platforms, the clocks/reset are managed by a central entity. TF-A is expected to co-ordinate with this entity. Unfortunately, PL011 does not fall in this category and is expected to be kept on by the previous bootloader. -Varun -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Michal Simek via TF-A Sent: Monday, June 21, 2021 2:24 PM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] PL011 clock handling between TF-A and Linux External email: Use caution opening links or attachments Hi, recently we have hit the case where Linux has pl011 driver and using it as a console. The same console is also used by TF-A. If you look at implementation details Linux pl011 driver has in pl011_console_write() clk_enable/clk_disable calls. I can't see any clock handling for PL011 in TF-A that's why I guess that TF-A expectation is that clocks are enabled and must be enabled all the time because pl011 is also used as crashed console. That's why I would like to check with you what's the clock expectation in these shared IP cases. Do you have a requirement that firmware should keep refcount of IP users and never disable clock when only one requires it? Thanks, Michal -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

4 years, 4 months

2
3
0 0

PL011 clock handling between TF-A and Linux

by Michal Simek

Hi, recently we have hit the case where Linux has pl011 driver and using it as a console. The same console is also used by TF-A. If you look at implementation details Linux pl011 driver has in pl011_console_write() clk_enable/clk_disable calls. I can't see any clock handling for PL011 in TF-A that's why I guess that TF-A expectation is that clocks are enabled and must be enabled all the time because pl011 is also used as crashed console. That's why I would like to check with you what's the clock expectation in these shared IP cases. Do you have a requirement that firmware should keep refcount of IP users and never disable clock when only one requires it? Thanks, Michal

4 years, 4 months

1
0
0 0

PIE in tf-a

by virtuoho virtuoho

Hello tf experts, I've been studying the PIE support in TF-A recently, and there is one thing I'm confused about. One is GOT table entry, is there any difference between this and .rela.dyn? I have done some homework, but I didn't find the answer. If someone can tell me, thanks a lot. It looks like the current got segment is only 8 byte, so why must I need this section? Which kind of code will put into this section?

4 years, 4 months

1
0
0 0

TF-A] CANCELLED: TF-A Tech Forum Agenda @ Thr 17th June 2021 16:00-1700 BST

by Joanna Farley

Apologies we don't have any topics to present this week so I am cancelling the TF-A Tech forum for 17th June 2021. We do however we have an exciting topic coming up for Thursday 1st July 2021 which we will share more about nearer the time. In addition I’ll also like to promote this separate Linaro and Arm CCA Tech Event - Deep dive into Arm Confidential Compute Architecture the details of which can be found here https://www.linaro.org/events/linaro-and-arm-cca-tech-day-deep-dive-into-ar… Registration is free for this event which will begin at 14:00 UTC on June 23rd . Thanks all. Joanna

4 years, 4 months

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Jun 17, 2021 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been canceled with this note: "Apologies we don't have any topics to present this week so I am cancelling the Tech forum for 17th June 2021 however we have an exciting topic coming up for Thursday 1st July 2021 which we will share near the time." 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 Jun 17, 2021 4pm – 5pm United Kingdom Time 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, 4 months

1
0
0 0

SP manifest: avoid manual updates to "entrypoint-offset"

by Varun Wadekar

Hello, We (Nico/Raghu) have been implementing SEL0 partitions for Tegra platforms and recently hit an issue, where the "entrypoint-offset" field of the SP manifest [1] cannot cope with increasing manifest blobs. The way the SP manifest is created today, the "entrypoint-offset" field is set to a value *statically* by the implementer. Down the line if the manifest grows past the value written in the "entrypoint-offset", we must manually update it. This needs to be fixed. We believe there is an opportunity to upgrade the sptool to handle this situation during SP package creation, where sptool calculates the manifest size and bumps the "entrypoint-offset" past the end of the manifest. There are other ways of patching the SP manifest at runtime, but they seem sub-optimal. Please let me know if there are other ideas to solve this problem. I will post a patch to update the sptool shortly but wanted to get the ball rolling. Cheers. [1] 14. FF-A manifest binding to device tree - Trusted Firmware-A documentation<https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-…>

4 years, 4 months

1
0
0 0

Test Post

by Arjun Khare

Test (sorry for the noise)

4 years, 4 months

1
0
0 0

Re: [TF-A] Support for Kinibi in ATF/SPMD - linear ID

by Achin Gupta

Hi Francois, The blobs are passed in memory only when the primary core boots. The linear id is required when both primaries and secondaries boot. Secondly, the linear id is used to reference per-cpu structures in memory during very early initialisation. Putting the linear id in a memory structure would either require a per-cpu structure (chicken and egg) or a read-only global structure (to avoid complicated locks with the MMU turned off). It seems to me that the linear id should be passed in an unused register specified by the partition manifest. Passing it in the blob list seems a bit counter intuitive to me but happy to understand your thoughts better. cheers, Achin ________________________________ 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> Sent: 14 June 2021 16:29 To: Lukas Hanel <lukas.hanel(a)trustonic.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Support for Kinibi in ATF/SPMD - linear ID This looks like a good candidate for the bloblist discussion we have on other mail thread. Why not aggregating "topology" metadata in a block rather than passing "random" information elements in registers? On Thu, 10 Jun 2021 at 13:57, Lukas Hanel via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> wrote: Hi, in this PR, I propose a first change to the SPMD to better support Kinibi, the TEE from Trustonic. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/10235 The idea here is to pass the core linear id in the x3 register in the boot of secondary cores. In the past, the Kinibi SPD was not public and so some requirements to TF-A were not visible to the wider community. For Kinibi, one binary should run on a multitude of platforms. For that reason, many platform-specific settings are shared by TF-A with Kinibi: at boot, in registers and in a boot datastructure, and at runtime. In the line of work of making Kinibi compatible with FFA APIs, I moved some bits from the Kinibi SPD to the SPMD. Instead of sharing such patches only with our customers, we would like to upstream the patches to the generic code. For this particular patch, it is really simple and changes the interface SPMD-to-SPMC in a somewhat adhoc manner. There is some discussion within ARM to standardize such behavior and to propose configuration options, i.e. within a manifest. That way, you could change what register the linear id, if at all, should be transferred in. A first tour of the CI showed that there seem to be no consequences to hafnium and optee. I guess, question to the mailing list, is there something that this patch breaks? Greetings, Lukas Trustonic SAS - 535 route de Lucioles, Les Aqueducs Batiment 2, Sophia Antipolis 06560 Valbonne, France – SAS au capital de 3 038 000€ - RCS Grasse – SIRET 480 011 998 00055 - TVA intracommunautaire : FR02 480 011 998 -- TF-A mailing list TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- [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, 4 months

2
1
0 0

Re: [TF-A] Support for Kinibi in ATF/SPMD - linear ID

by François Ozog

This looks like a good candidate for the bloblist discussion we have on other mail thread. Why not aggregating "topology" metadata in a block rather than passing "random" information elements in registers? On Thu, 10 Jun 2021 at 13:57, Lukas Hanel via TF-A < tf-a(a)lists.trustedfirmware.org> wrote: > Hi, > > in this PR, I propose a first change to the SPMD to better support Kinibi, > the TEE from Trustonic. > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/10235 > > The idea here is to pass the core linear id in the x3 register in the boot > of secondary cores. > > In the past, the Kinibi SPD was not public and so some requirements to > TF-A were not visible to the wider community. > For Kinibi, one binary should run on a multitude of platforms. > For that reason, many platform-specific settings are shared by TF-A with > Kinibi: at boot, in registers and in a boot datastructure, and at runtime. > > In the line of work of making Kinibi compatible with FFA APIs, I moved > some bits from the Kinibi SPD to the SPMD. > Instead of sharing such patches only with our customers, we would like to > upstream the patches to the generic code. > > For this particular patch, it is really simple and changes the interface > SPMD-to-SPMC in a somewhat adhoc manner. > There is some discussion within ARM to standardize such behavior and to > propose configuration options, i.e. within a manifest. > That way, you could change what register the linear id, if at all, should > be transferred in. > > A first tour of the CI showed that there seem to be no consequences to > hafnium and optee. > I guess, question to the mailing list, is there something that this patch > breaks? > > Greetings, > Lukas > > > Trustonic SAS - 535 route de Lucioles, Les Aqueducs Batiment 2, Sophia > Antipolis 06560 Valbonne, France – SAS au capital de 3 038 000€ - RCS > Grasse – SIRET 480 011 998 00055 - TVA intracommunautaire : FR02 480 011 998 > -- > 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, 4 months

1
0
0 0

Support for Kinibi in ATF/SPMD - linear ID

by Lukas Hanel

Hi, in this PR, I propose a first change to the SPMD to better support Kinibi, the TEE from Trustonic. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/10235 The idea here is to pass the core linear id in the x3 register in the boot of secondary cores. In the past, the Kinibi SPD was not public and so some requirements to TF-A were not visible to the wider community. For Kinibi, one binary should run on a multitude of platforms. For that reason, many platform-specific settings are shared by TF-A with Kinibi: at boot, in registers and in a boot datastructure, and at runtime. In the line of work of making Kinibi compatible with FFA APIs, I moved some bits from the Kinibi SPD to the SPMD. Instead of sharing such patches only with our customers, we would like to upstream the patches to the generic code. For this particular patch, it is really simple and changes the interface SPMD-to-SPMC in a somewhat adhoc manner. There is some discussion within ARM to standardize such behavior and to propose configuration options, i.e. within a manifest. That way, you could change what register the linear id, if at all, should be transferred in. A first tour of the CI showed that there seem to be no consequences to hafnium and optee. I guess, question to the mailing list, is there something that this patch breaks? Greetings, Lukas Trustonic SAS - 535 route de Lucioles, Les Aqueducs Batiment 2, Sophia Antipolis 06560 Valbonne, France - SAS au capital de 3 038 000EUR - RCS Grasse - SIRET 480 011 998 00055 - TVA intracommunautaire : FR02 480 011 998

4 years, 4 months

1
0
0 0

Re: [TF-A] please fix incomplete distclean Makefile target

by Manish Pandey2

Hi, Can you try below steps, try with fresh pull? 1. Login with your github account on https://review.trustedfirmware.org/admin/repos/TF-A%2Ftrusted-firmware-a 2. git clone "ssh://<user>@review.trustedfirmware.org:29418/TF-A/trusted-firmware-a 3. git push <remote-name> HEAD:refs/for/integration 4. While pushing if it complains about git hooks, run scp -p -P 29418 <user>@review.trustedfirmware.org:hooks/commit-msg "trusted-firmware-a/.git/hooks/" and amend your commit (it will give you this hint) ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Nicolas Boulenguez via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 03 April 2021 13:02 To: raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; 'Benjamin Copeland' <ben.copeland(a)linaro.org> Subject: Re: [TF-A] please fix incomplete distclean Makefile target raghu.ncstate(a)icloud.com: > Are you pushing ssh://<username>@review.trustedfirmware.org:29418/TF-A/trusted-firmware-a HEAD:refs/for/integration? > Note that 29418 port. That tripped me up initially. It is not clear from your earlier emails where you cloned from(review.trustedfirmware.org or git.trustedfirmware.org). [α] links to [β] which recommends # git clone "https://review.trustedfirmware.org/TF-A/trusted-firmware-a" I had an existing repository (most contributors probably do) and used 'git add remote' and 'git fetch' instead. [α] recommends # git push <remote-name> HEAD:refs/for/integration%<topic-branch> As expected, the host requires a password. # git push ssh://<user>@review.trustedfirmware.org:29418/TF-A/trusted-firmware-a HEAD:refs/for/integration? -> fatal: invalid refspec 'HEAD:refs/for/integration?' Anyhow, the host would require an SSH key. [α] https://developer.trustedfirmware.org/w/tf_a/gerrit-getting-started/ [β] https://review.trustedfirmware.org/admin/repos/TF-A%2Ftrusted-firmware-a -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 4 months

2
1
0 0

Re: [TF-A] issue with vsnprintf() and unsigned_num_print()

by Varun Wadekar

HI Hiren, Can you please add more color to “even if I provide large enough string to hold the number, it does not print it”? Are you saying that the library prints a partial value? If the calculation is off by 1, I assume, the library should at least print a partial value. -Varun From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Hiren Mehta via TF-A Sent: Saturday, May 29, 2021 9:41 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] issue with vsnprintf() and unsigned_num_print() External email: Use caution opening links or attachments Hi All, We are using the snprintf() (which uses vsnprintf() and unsigned_num_print()) from libc of ATF version 2.4 and running into an issue for printing a number into a string where even if I provide large enough string to hold the number, it does not print it. I don't see that issue with it when I try to print a string using the same snprintf(). I understand that, as per the documentation use of snprintf is "banned or discouraged". But for the use case, that we are using for, it is safe enough to use it assuming that it does it what it is supposed to do. I am not sure if this is a known bug or what, but upon a further inspection, I found that there seems be a small bug in the unsigned_num_print() for one of the 'if' condition given below which is causing the issue in terms of calculating the available space in the string. if (*chars_printed < n) { .... do the prinring.... } I believe it is supposed to be if (*chars_printed <= n) { ----------------->> Notice '<=' instead of '<' } Any comment on whether this is on purpose or really a small bug? The calling routine (vsnprintf) is already reducing 'n' by 1 for the terminating null character. Thank you very much for your support. -hiren

4 years, 5 months

2
2
0 0

Re: [TF-A] TF-A Tech Forum Agenda @ Thr 3rd June 2021 16:00-1700 BST

by François Ozog

Hi food for thought for tomorrow's call: Passing information on what is plugged into the DIMM slots may not be as straightforward as it sounds. You can plug pure DRAM, NVDIMMs or pure flash (from Diablo technologies, acquired by RAMBus in 2019). The pure flash is a module where there is a few MB as bounce buffers to flash located on the DIMM itself. The largest element was 1TB on a single DIMM. So passing a C structure that details the size of the DIMM fails to fully describe NVDIMM and Flash on DIMM. Those two things required complex Passing a DT fragment that describes the plugged module is generic and can describe both the bounce buffers and the registers needed to access the flash on DIMM. In the future you may find associative memory or whatever AI based modules. Bottom line, using DT fragment to describe memory is flexible for the three existing cases and future proof. The document shows that for a 2 DIMM representation and associated SPDs, the additional cost is 88 bytes. 32 are fixed cost, 56 are somewhat name size dependent and some related to FDT format. There is no need for a full libfdt to actually produce that serialized data on a hob. So in my view, the benefit of having an alignment, version and evolution proof structure that comes with DT fragment by far exceeds the cost of a few bytes saved, even in the context of SRAM size. Cheers FF On Wed, 2 Jun 2021 at 17:33, Joanna Farley via TF-A < tf-a(a)lists.trustedfirmware.org> wrote: > Hi All, > > > > The next TF-A Tech Forum is scheduled for Thu 3rd June 2021 16:00 – 17:00 > (BST). > > > > Agenda: > > - Discussion Session: Static and Dynamic Information Handling in TF-A > (Session 2) > - Lead by Manish Pandy and Madhukar Pappireddy > - On tech forum this week, we would like to continue discussions on > HOB list design. > - The topics which we would like to cover is > 1. Evaluate different proposals of passing information through > boot phases. > 2. If we don't get an agreement on one solution fit for all then > we would try to get consensus for Infra segment platform(to solve original > problem mentioned by Harb) > 3. Try to get an agreement on size of tags and how "hybrid and > tag only" HOB list can co-exist together? > > > > > > Thanks > > > > Joanna > > > > > *You have been invited to the following event.* TF-A Tech Forum > > *more details » > <https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…>* > > > > 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/ > <https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> > > > > Trusted Firmware is inviting you to a scheduled Zoom meeting. > > > > Join Zoom Meeting > > https://zoom.us/j/9159704974 > <https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> > > > > Meeting ID: 915 970 4974 > > > > One tap mobile > > +16465588656,,9159704974# US (New York) > > +16699009128,,9159704974# US (San Jose) > > > > Dial by your location > > +1 646 558 8656 US (New York) > > When > > Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time > > Calendar > > tf-a(a)lists.trustedfirmware.org > > Who > > • > > Bill Fletcher- creator > > • > > tf-a(a)lists.trustedfirmware.org > > +1 669 900 9128 US (San Jose) > > 877 853 5247 US Toll-free > > 888 788 0099 US Toll-free > > Meeting ID: 915 970 4974 > > Find your local number: https://zoom.us/u/ad27hc6t7h > <https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> > > > > > Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: * > Yes > <https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…>** > - **Maybe > <https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…>** > - **No > <https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…>* > more options » > <https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> > > Invitation from Google Calendar <https://www.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://www.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 organiser and be added to the guest list, invite others regardless of > their own invitation status or to modify your RSVP. Learn more > <https://support.google.com/calendar/answer/37135#forwarding>. > > > -- > 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, 5 months

1
0
0 0

TF-A Tech Forum Agenda @ Thr 3rd June 2021 16:00-1700 BST

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 3rd June 2021 16:00 – 17:00 (BST). Agenda: * Discussion Session: Static and Dynamic Information Handling in TF-A (Session 2) * Lead by Manish Pandy and Madhukar Pappireddy * On tech forum this week, we would like to continue discussions on HOB list design. * The topics which we would like to cover is * Evaluate different proposals of passing information through boot phases. * If we don't get an agreement on one solution fit for all then we would try to get consensus for Infra segment platform(to solve original problem mentioned by Harb) * Try to get an agreement on size of tags and how "hybrid and tag only" HOB list can co-exist together? Thanks Joanna You have been invited to the following event. TF-A Tech Forum more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> 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/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.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://www.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 organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>.

4 years, 5 months

1
0
0 0

Re: [TF-A] Linux kernel set the hypervisor vector table through ATF

by Marc Zyngier

On Tue, 01 Jun 2021 14:34:05 +0100, Dongjiu Geng <gengdongjiu1(a)gmail.com> wrote: > > Marc Zyngier <maz(a)kernel.org> 于2021年6月1日周二下午6:09写道： > > > > On Tue, 01 Jun 2021 10:53:49 +0100, > > Dongjiu Geng <gengdongjiu1(a)gmail.com> wrote: > > > > > > Mark Rutland <mark.rutland(a)arm.com> 于2021年6月1日周二下午5:19写道： > > > > > > > > On Fri, May 28, 2021 at 05:26:51PM +0800, Dongjiu Geng wrote: > > > > > Hi All, > > > > > when Linux kernel boot from EL1, there is no method to let > > > > > kernel to enter EL2 to enable hypervisor. so I want to add an SMC > > > > > interface between kernel and EL3 ATF to let kernel can set the > > > > > hypervisor vector table, then can enter EL2 to enable hypervisor, as > > > > > shown in [1]. > > > > > Do you agree? Otherwise there is no method to enter EL2 hypervisor > > > > > when kernel boot from EL1, because the hypervisor vector > > > > > table(vbar_el2) is unknown. > > > > > > > > The kernel already supported being booted at EL2, where it will install > > > > itself as the hypervisor (and will drop to EL1 if required). EL2 is the > > > > preferred boot mode, as we document in: > > > > > > > > https://www.kernel.org/doc/html/latest/arm64/booting.html > > > > > > > > ... where we say: > > > > > > > > | The CPU must be in either EL2 (RECOMMENDED in order to have access to > > > > | the virtualisation extensions) or non-secure EL1. > > > > > > > > We *strongly* prefer this over adding new ABIs to transition from EL1 to > > > > EL2. Please boot the kernel at EL2 if you want to use KVM. > > > > > > Thanks for the answer. > > > If use KVM, it should boot from EL2. But if the hypervisor is not > > > KVM, such as Jailhouse hypervisor and some Chip manufacturer boot the > > > host kernel from EL1(not follow above rule), it seems there is not way > > > to enter the Jailhouse hypervisor. > > > > We only deal with two cases: > > - either the kernel uses its own, built-in hypervisor: it boots at > > EL2, and installs itself. > > > > - or there is a pre-existing hypervisor, and the kernel boots at EL1. > > > > In the past, Jailhouse used the exact same entry points as KVM. What > > has changed? > > Jailhouse use the __hyp_stub_vectors vector table[1] in linux > kernel arch/arm64/kernel/hyp-stub.S to re-set his own's hypervisor > vector table, but if linux kernel is boot from EL1，it can not use the > entry points(__hyp_stub_vectors). I agree Linux kernel is recommended > boot from EL2, but some custer's boards not follow this rule. So Jailhouse doesn't have this problem when used as intended. > > [1]: > ENTRY(__hyp_stub_vectors) > ventry el2_sync_invalid // Synchronous EL2t > ventry el2_irq_invalid // IRQ EL2t > ventry el2_fiq_invalid // FIQ EL2t > ventry el2_error_invalid // Error EL2t > > ventry el2_sync_invalid // Synchronous EL2h > ventry el2_irq_invalid // IRQ EL2h > ventry el2_fiq_invalid // FIQ EL2h > ventry el2_error_invalid // Error EL2h > > ventry el1_sync // Synchronous 64-bit EL1 > ventry el1_irq_invalid // IRQ 64-bit EL1 > ventry el1_fiq_invalid // FIQ 64-bit EL1 > ventry el1_error_invalid // Error 64-bit EL1 > > ventry el1_sync_invalid // Synchronous 32-bit EL1 > ventry el1_irq_invalid // IRQ 32-bit EL1 > ventry el1_fiq_invalid // FIQ 32-bit EL1 > ventry el1_error_invalid // Error 32-bit EL1 > ENDPROC(__hyp_stub_vectors) > > > > > Finally, if you can change the firmware to install the EL2 vectors, > > you can also change it to enter the kernel at EL2. I suggest you do > > that instead. > > I agree with you, but needs to change customer‘s board, I will try to > discuess with customer. In both cases, you'll need to change your customer's firmware. It seems to me that there is no reason for the arm64 boot protocol to change and adopt weird, wonderful and proprietary privilege escalation methods. Thanks, M. -- Without deviation from the norm, progress is not possible.

4 years, 5 months

1
0
0 0

Re: [TF-A] Linux kernel set the hypervisor vector table through ATF

by Marc Zyngier

On Tue, 01 Jun 2021 10:53:49 +0100, Dongjiu Geng <gengdongjiu1(a)gmail.com> wrote: > > Mark Rutland <mark.rutland(a)arm.com> 于2021年6月1日周二下午5:19写道： > > > > On Fri, May 28, 2021 at 05:26:51PM +0800, Dongjiu Geng wrote: > > > Hi All, > > > when Linux kernel boot from EL1, there is no method to let > > > kernel to enter EL2 to enable hypervisor. so I want to add an SMC > > > interface between kernel and EL3 ATF to let kernel can set the > > > hypervisor vector table, then can enter EL2 to enable hypervisor, as > > > shown in [1]. > > > Do you agree? Otherwise there is no method to enter EL2 hypervisor > > > when kernel boot from EL1, because the hypervisor vector > > > table(vbar_el2) is unknown. > > > > The kernel already supported being booted at EL2, where it will install > > itself as the hypervisor (and will drop to EL1 if required). EL2 is the > > preferred boot mode, as we document in: > > > > https://www.kernel.org/doc/html/latest/arm64/booting.html > > > > ... where we say: > > > > | The CPU must be in either EL2 (RECOMMENDED in order to have access to > > | the virtualisation extensions) or non-secure EL1. > > > > We *strongly* prefer this over adding new ABIs to transition from EL1 to > > EL2. Please boot the kernel at EL2 if you want to use KVM. > > Thanks for the answer. > If use KVM, it should boot from EL2. But if the hypervisor is not > KVM, such as Jailhouse hypervisor and some Chip manufacturer boot the > host kernel from EL1(not follow above rule), it seems there is not way > to enter the Jailhouse hypervisor. We only deal with two cases: - either the kernel uses its own, built-in hypervisor: it boots at EL2, and installs itself. - or there is a pre-existing hypervisor, and the kernel boots at EL1. In the past, Jailhouse used the exact same entry points as KVM. What has changed? Finally, if you can change the firmware to install the EL2 vectors, you can also change it to enter the kernel at EL2. I suggest you do that instead. Thanks, M. -- Without deviation from the norm, progress is not possible.

4 years, 5 months

1
0
0 0

Re: [TF-A] Linux kernel set the hypervisor vector table through ATF

by Mark Rutland

On Fri, May 28, 2021 at 05:26:51PM +0800, Dongjiu Geng wrote: > Hi All, > when Linux kernel boot from EL1, there is no method to let > kernel to enter EL2 to enable hypervisor. so I want to add an SMC > interface between kernel and EL3 ATF to let kernel can set the > hypervisor vector table, then can enter EL2 to enable hypervisor, as > shown in [1]. > Do you agree? Otherwise there is no method to enter EL2 hypervisor > when kernel boot from EL1, because the hypervisor vector > table(vbar_el2) is unknown. The kernel already supported being booted at EL2, where it will install itself as the hypervisor (and will drop to EL1 if required). EL2 is the preferred boot mode, as we document in: https://www.kernel.org/doc/html/latest/arm64/booting.html ... where we say: | The CPU must be in either EL2 (RECOMMENDED in order to have access to | the virtualisation extensions) or non-secure EL1. We *strongly* prefer this over adding new ABIs to transition from EL1 to EL2. Please boot the kernel at EL2 if you want to use KVM. Thanks, Mark. > > > > [1]: > el1_sync: > cmp x0, #SMC_SET_VECTORS > b.ne 2f > msr vbar_el2, x1 > b 9f > > 2: cmp x0, #SMC_SOFT_RESTART > b.ne 3f > mov x0, x2 > mov x2, x4 > mov x4, x1 > mov x1, x3 > br x4 // no return > > 3: cmp x0, #SMC_RESET_VECTORS > beq 9f // Nothing to reset! > > ldr x0, =SMC_STUB_ERR > eret > > 9: mov x0, xzr > eret > ENDPROC(el1_sync) > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel(a)lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

4 years, 5 months

1
0
0 0

issue with vsnprintf() and unsigned_num_print()

by Hiren Mehta

Hi All, We are using the snprintf() (which uses vsnprintf() and unsigned_num_print()) from libc of ATF version 2.4and running into an issue for printing a number into a string where even if I provide large enough string to hold the number, it does not print it. I don't see that issue with it when I try to print a string using the same snprintf().I understand that, as per the documentation use of snprintf is "banned or discouraged". But for the use case,that we are using for, it is safe enough to use it assuming that it does it what it is supposed to do. I am not sure if this is a known bug or what, but upon a further inspection, I found that there seems be a small bugin the unsigned_num_print() for one of the 'if' condition given below which is causing the issue in terms of calculatingthe available space in the string. if (*chars_printed < n) { .... do the prinring....} I believe it is supposed to be if (*chars_printed <= n) { ----------------->> Notice '<=' instead of '<' } Any comment on whether this is on purpose or really a small bug? The calling routine (vsnprintf) is already reducing 'n' by 1 for the terminating null character. Thank you very much for your support.-hiren

4 years, 5 months

1
0
0 0

Re: [TF-A] zynqmp: How to inform the bl33 about RAM reservation?

by Samuel Holland

On 4/19/21 11:11 AM, Jan Kiszka via TF-A wrote: > On 19.04.21 17:21, Michal Simek wrote: >> On 4/18/21 8:44 PM, Jan Kiszka wrote: >>> when SPD or DEBUG is enabled, TF-A is moved to RAM on the zynqmp (as it >>> longer fits into OCM). U-Boot happens to avoid that region, but the >>> kernel's DTB has no reservation entry, and Linux will trigger an >>> exception when accessing that region during early boot. >>> >>> Can we improve this - without requiring the user to manually add a >>> reservation to the DTB? Should we unconditionally reserve >>> 0x1000..0x7ffff in all BL33 DTBs? Or is there a chance to communicate >>> that need? Or some way to detect in BL33 whether it is needed? >> >> Normally this ddr region should be also protected by security IPs that >> NS has no access there. >> It means in Xilinx flow this can be (and should be) propagated via >> device-tree generator to final DTS file that you don't need to touch it >> by hand. >> I am not aware about any way that NS can query secure world what memory >> can be used. And not sure if there is any standard way to do so. >> > > OK, understood. But then, to be safe, shouldn't the upstream "static" > default DT contain an exclusion of that region so that it won't get > stuck if it is in use? Would block half a meg, but when you have a > custom platform that does not need that, you can and will provide your > own DT anyway. Ideally, the static DTS is a description of the hardware only, and not of runtime constraints imposed by the firmware. If BL31 needs to reserve some memory, it can add that reservation to the DTB at runtime. The fdt_add_reserved_memory() function is available for this purpose. For an example, see the code used by the rpi4[0] or sun50i_h616[1] platforms. If you later load a DTB from disk for use by Linux, you will need to copy the reserved-memory nodes from the U-Boot DTB to the loaded DTB. Regards, Samuel [0]: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/rpi/r… [1]: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/allwi…

4 years, 5 months

3
2
0 0

Re: [TF-A] MEM_PROTECT for secure world?

by Sandrine Bailleux

Hi Okash, Varun, Sorry I've not had a chance to properly read this email thread yet so apologies if my comment is irrelevant. I just wanted to point out that TF-A Tests provide some tests for MEM_PROTECT [1] and MEM_PROTECT_CHECK [2] SMC interfaces, in case that helps clarifying their intended usage. Cheers, Sandrine [1] https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/tftf/tests/runtime… [2] https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/tftf/tests/runtime…

4 years, 5 months

2
1
0 0

Re: [TF-A] Rethrow SError from EL3 to kernel on arm64

by Achin Gupta

Hi, The last time I checked injecting an SError from a higher to lower EL is a bad idea since the latter could be running with SErrors masked. EL3 could check this before injecting but then there is no consistent contract with the lower EL about reporting of these errors. SDEI does not suffer from the same problem. +James who knows more from the OS/Hypervisor perspective. cheers, Achin ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Soby Mathew via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 25 May 2021 09:59 To: Pali Rohár <pali(a)kernel.org> Cc: kabel(a)kernel.org <kabel(a)kernel.org>; tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Rethrow SError from EL3 to kernel on arm64 [+tf-a list] Hi Pali, There are 2 philosophies for handing SError in the system, kernel first and firmware first. Assuming you want to stick with firmware first handling (i.e scr_el3.ea is set to 1), then as you mentioned, there are 2 ways to notify the kernel for delegating the error handling: SDEI and SError injection back to kernel. Upstream TF-A only supports SDEI at the moment. For SError injection back to lower EL, you have to setup the hardware state via software at higher EL in such a way that it appears that the fault was taken to the exception vector at the lower exception level. The pseudocode function AArch64.TakeException() in ARM ARM shows the behavior when the PE takes an exception to an Exception level using AArch64 in Non-debug state. This behaviour has to replicated and it involves the higher EL setting up the PSTATE registers correctly and values in other registers for the lower EL (spsr, elr and fault syndrome registers) and jumping to the right offset point to by the vbar_elx of the lower EL. To the lower EL is appears as a SError has triggered at its exception vector and it can proceed with the fault handling. Best Regards Soby Mathew > -----Original Message----- > From: Pali Rohár <pali(a)kernel.org> > Sent: Monday, May 24, 2021 6:07 PM > To: Soby Mathew <Soby.Mathew(a)arm.com> > Subject: Rethrow SError from EL3 to kernel on arm64 > > Hello Soby! > > I have found following discussion in Armada 3720 PCIe SError issue: > https://review.trustedfirmware.org/c/TF-A/trusted-firmware- > a/+/1541/comment/ca882427_d142bde2/ > > TF-A on Armada 3720 redirects all SErrors to EL3 and panic in TF-A handler. > You wrote in that discussion: > > Ideally you need to signal the SError back to kernel from EL3 using > SDEI or inject the SError to the lower EL and the kernel can decide to > die or not. > > And I would like to ask you, could you help me with implementation of this > SError rethrow functionality? Because I have absolutely no idea how to do it > and catching all SErrors in EL3 is causing issues because some of them can be > handled and recovered by kernel. -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 5 months

4
4
0 0

Re: [TF-A] Rethrow SError from EL3 to kernel on arm64

by Soby Mathew

[+tf-a list] Hi Pali, There are 2 philosophies for handing SError in the system, kernel first and firmware first. Assuming you want to stick with firmware first handling (i.e scr_el3.ea is set to 1), then as you mentioned, there are 2 ways to notify the kernel for delegating the error handling: SDEI and SError injection back to kernel. Upstream TF-A only supports SDEI at the moment. For SError injection back to lower EL, you have to setup the hardware state via software at higher EL in such a way that it appears that the fault was taken to the exception vector at the lower exception level. The pseudocode function AArch64.TakeException() in ARM ARM shows the behavior when the PE takes an exception to an Exception level using AArch64 in Non-debug state. This behaviour has to replicated and it involves the higher EL setting up the PSTATE registers correctly and values in other registers for the lower EL (spsr, elr and fault syndrome registers) and jumping to the right offset point to by the vbar_elx of the lower EL. To the lower EL is appears as a SError has triggered at its exception vector and it can proceed with the fault handling. Best Regards Soby Mathew > -----Original Message----- > From: Pali Rohár <pali(a)kernel.org> > Sent: Monday, May 24, 2021 6:07 PM > To: Soby Mathew <Soby.Mathew(a)arm.com> > Subject: Rethrow SError from EL3 to kernel on arm64 > > Hello Soby! > > I have found following discussion in Armada 3720 PCIe SError issue: > https://review.trustedfirmware.org/c/TF-A/trusted-firmware- > a/+/1541/comment/ca882427_d142bde2/ > > TF-A on Armada 3720 redirects all SErrors to EL3 and panic in TF-A handler. > You wrote in that discussion: > > Ideally you need to signal the SError back to kernel from EL3 using > SDEI or inject the SError to the lower EL and the kernel can decide to > die or not. > > And I would like to ask you, could you help me with implementation of this > SError rethrow functionality? Because I have absolutely no idea how to do it > and catching all SErrors in EL3 is causing issues because some of them can be > handled and recovered by kernel.

4 years, 5 months

1
0
0 0

Re: [TF-A] Trusted Firmware version 2.5 is now available

by Chris Kay

Thanks, Gary, and to everybody who contributed to this release! I’d like to quickly remind everybody that, as part of the v2.5 release, the Trusted Firmware-A project formally adopted the Conventional Commits v1.0.0<https://www.conventionalcommits.org/en/v1.0.0/> specification to enable us to radically reduce our time-to-release in the future. Thank you to everybody who took part in the discussions that allowed us to integrate this, and to those whose concerns I hope we have by now satisfied. As part of this effort, we have introduced a commit verification check to the existing Gerrit-triggered CI job. Where before this applied only to Arm employees, this now includes everybody (even you, reader of this email). This will no doubt require some initial mental reorientation as it did for our Arm-based guinea pigs, but I hope that this it will become a non-issue in short time. To aid in the transition, we are also now packaging additional tooling, namely Commitizen<https://commitizen-tools.github.io/commitizen/> and commitlint<https://commitlint.js.org/#/>, to make writing conformant commits easier, the installation instructions for which have been integrated into the v2.5 prerequisites page<https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/prerequi…>. These tools are optional, but highly recommended if you do find your commits being rejected by the CI. Please note that patches currently awaiting review on Gerrit will need to adhere to this specification before merging (this should only take a minute). If you missed previous communications or are unfamiliar with Conventional Commits, here is a brief summary of the format that commit messages are now expected to take: <type>[optional scope]: <description> [optional body] [optional footer(s)] Where the <type> is one of: * feat: A new feature * fix: A bug fix * docs: Documentation only changes * style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) * refactor: A code change that neither fixes a bug nor adds a feature * perf: A code change that improves performance * test: Adding missing tests or correcting existing tests * build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm) * ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs) * chore: Other changes that don't modify src or test files * revert: Reverts a previous commit And the [optional scope] consists of an optional parentheses-wrapped scope of your choosing, similarly to how many contributors prefixed their commits previously. A real-world example: docs(prerequisites): add `--no-save` to `npm install` To avoid the mistake fixed by the previous commit, ensure users install the Node.js dependencies without polluting the lock file by passing `--no-save` to the `npm install` line. Change-Id: I10b5cc17b9001fc2e26deee02bf99ce033a949c1 Signed-off-by: Chris Kay <chris.kay(a)arm.com> If you have the time, please do read up on the specification for additional details – I promise it’s short. So long, and happy committing. 😊 Regards, Chris From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Gary Morrison via TF-A <tf-a(a)lists.trustedfirmware.org> Date: Thursday, 20 May 2021 at 15:59 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Trusted Firmware version 2.5 is now available Trusted Firmware version 2.5 is now available and can be found here: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.5 https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.5 https://git.trustedfirmware.org/hafnium/hafnium.git/tag/?h=v2.5 https://git.trustedfirmware.org/ci/tf-a-ci-scripts.git/tag/?h=v2.5 Please refer to the read-the-docs and change log for further information. Regards, Gary Morrison -- Arm -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 5 months

1
0
0 0

Trusted Firmware version 2.5 is now available

by Gary Morrison

Trusted Firmware version 2.5 is now available and can be found here: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.5 https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.5 https://git.trustedfirmware.org/hafnium/hafnium.git/tag/?h=v2.5 https://git.trustedfirmware.org/ci/tf-a-ci-scripts.git/tag/?h=v2.5 Please refer to the read-the-docs and change log for further information. Regards, Gary Morrison -- Arm

4 years, 5 months

1
0
0 0

Re: [TF-A] [PATCH v1] imx8mp: silent uart

by Sandrine Bailleux

Hello Heiko, Thanks for your patch! TF-A project uses Gerrit as the review system for patches, would you mind posting your patch there instead? More details about the patch submission process can be found here: https://trustedfirmware-a.readthedocs.io/en/latest/process/contributing.html Regarding the patch itself, I agree with you that this feature would be useful to other platforms as well. I wonder whether we need a new build option for this, though. We already got LOG_LEVEL, which if set to 0, will effectively silent any console output. However, it will still embed the console driver code within the firmware, if I am not mistaken. So perhaps we should change that, and make LOG_LEVEL=0 compile the console driver code out, in addition to what it already does today. How does that sound to you? Regards, Sandrine On 5/18/21 4:01 PM, Heiko Schocher via TF-A wrote: > when bootloaders and kernels console output is disabled, > (called silent boot) no output on console is recommended. > > Add commandline option IMX_BOOT_SILENT to disable > console registration at all. > > Default value is 0, so patch does not change current > functionality. > > Signed-off-by: Heiko Schocher <hs(a)denx.de> > --- > I just added this to imx8mp, but may this option is > useful on other platforms too? > > plat/imx/imx8m/imx8mp/imx8mp_bl31_setup.c | 4 ++++ > plat/imx/imx8m/imx8mp/platform.mk | 3 +++ > 2 files changed, 7 insertions(+) > > diff --git a/plat/imx/imx8m/imx8mp/imx8mp_bl31_setup.c b/plat/imx/imx8m/imx8mp/imx8mp_bl31_setup.c > index 22fbd5e4b..d75143270 100644 > --- a/plat/imx/imx8m/imx8mp/imx8mp_bl31_setup.c > +++ b/plat/imx/imx8m/imx8mp/imx8mp_bl31_setup.c > @@ -95,7 +95,9 @@ static void bl31_tzc380_setup(void) > void bl31_early_platform_setup2(u_register_t arg0, u_register_t arg1, > u_register_t arg2, u_register_t arg3) > { > +#if (IMX_BOOT_SILENT == 0) > static console_t console; > +#endif > unsigned int i; > > /* Enable CSU NS access permission */ > @@ -109,10 +111,12 @@ void bl31_early_platform_setup2(u_register_t arg0, u_register_t arg1, > > imx8m_caam_init(); > > +#if (IMX_BOOT_SILENT == 0) > console_imx_uart_register(IMX_BOOT_UART_BASE, IMX_BOOT_UART_CLK_IN_HZ, > IMX_CONSOLE_BAUDRATE, &console); > /* This console is only used for boot stage */ > console_set_scope(&console, CONSOLE_FLAG_BOOT); > +#endif > > /* > * tell BL3-1 where the non-secure software image is located > diff --git a/plat/imx/imx8m/imx8mp/platform.mk b/plat/imx/imx8m/imx8mp/platform.mk > index 1d11e3df4..471c96e70 100644 > --- a/plat/imx/imx8m/imx8mp/platform.mk > +++ b/plat/imx/imx8m/imx8mp/platform.mk > @@ -54,3 +54,6 @@ $(eval $(call add_define,BL32_SIZE)) > > IMX_BOOT_UART_BASE ?= 0x30890000 > $(eval $(call add_define,IMX_BOOT_UART_BASE)) > + > +IMX_BOOT_SILENT ?= 0 > +$(eval $(call add_define,IMX_BOOT_SILENT)) >

4 years, 5 months

2
1
0 0

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

by François Ozog

Le mer. 19 mai 2021 à 03:58, Madhukar Pappireddy via TF-A < tf-a(a)lists.trustedfirmware.org> a écrit : > Hi, > > I tried to summarize the discussions in the previous TF-A tech forum > regarding the proposal to adopt Hand-off Blocks (HOBs) for passing > information along the boot chain. I am certain I could not capture all > suggestions/concerns brought up during the call. I apologize if I missed > and/or misinterpreted any comments and would appreciate it if everyone > could share their thoughts in response to this email thread. > > The idea is to share information to other boot phases: > > Dynamic information: Created during runtime. Shared in the form of a > chain of blobs(built as a linked list of C structure objects i.e., HOB > list). > > Static information: Known at compile time. Historically, shared through > the use of Device Tree/ACPI tables > > Both the above requirements are common in many ecosystems and need to > co-exist. > > There are broadly 3 problems to solve: > 1. Format of HOB structures: It looks like the consensus is that we could > use existing mechanisms for this (BL_AUX_PARAM in TF-A or bloblist in > u-boot). > 2. Identification of HOB list entries: There is a debate about whether > tags would suffice or if the HOB list producer and consumer would depend on > UUID/GUIDs for identifying a specific HOB structure. Another suggestion was > to use a hybrid approach. Reserve a single tag ID for > identifying/constructing a HOB structure that further leverages UUID based > identifier. This way, the generic HOB list doesn't need to support UUIDs > and can work with tags. > 3. The design contract for the static interface between two boot phases: > The problem at hand is whether to pass a pointer to a HOB list or a device > tree blob through the general-purpose registers for configuration hand-off > between two boot phases. Some proposals that came up: > > Proposal 1: Always pass a pointer to the device tree blob > through the GP register and capture the pointer to the HOB list as a > property of a node that is uniquely identifiable by the downstream boot > phase. This needs to define a device tree binding such that producer and > consumer agree on the information passed. > > Proposal 2: Pass a pointer to a generic container through the GP > register that can be interpreted appropriately by both boot loaders(i.e., > producer and consumer of the boot info). This container can either be a dtb > or a HOB list which can be simply inferred by checking for a magic header > that indicates if the buffer appears to be a flattened device tree. > > One another concern that was brought up offline is to make sure > we don't break current design contracts between various boot loader phases > in TF-A. Many of the general-purpose registers have a designated purpose > such as to share configurations between BL images( such as firmware config > dtb, SoC config dtb, Non trusted firmware config dtb, memory layout, entry > point info, etc.). > there should be another paragraph: 4. Requirements for data representation. I’ll take two concrete examples related to DIMM slot population and reporting. 6 years ago (can’t be sure) only DRAM modules could be fitted into DIMM slots. And then came NVDIMM and flash as DIMM (invented by Diablo technologies: 1TB of flash on a DIMM with a few MB as IO buffers and control registers - those memory regions where the only addressable DRAM). In both cases all firmware chain had to be changed to cope with them. If we had used self descriptive information passing (CBOR, DT, AML) for DIMM slot population and not C structure the journey would have been much simpler with forward and backward compatibility as a major side effect. So for data representation , I would concur with previous Ron Minnich @googke comment that we should be using self descriptive information rather than C structures. > > If I am not mistaken, a single design may not fit the needs of every > segment(client, Infra, embedded) and the forum is open to solutions > tailored for individual segments. Joanna will be sending a follow up email > with more information about future TF-A tech forums that serves as a > platform for further discussions. > > Thanks, > Madhukar > > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Joanna > Farley via TF-A > Sent: Sunday, May 16, 2021 5:19 AM > To: Okash Khawaja <okash.khawaja(a)gmail.com>; Simon Glass <sjg(a)chromium.org > > > Cc: Harb Abdulhamid OS <abdulhamid(a)os.amperecomputing.com>; Boot > Architecture Mailman List <boot-architecture(a)lists.linaro.org>; > tf-a(a)lists.trustedfirmware.org; Ed Stuber <edstuber(a)amperecomputing.com>; > Arjun Khare <akhare(a)amperecomputing.com>; U-Boot Mailing List < > u-boot(a)lists.denx.de>; Paul Isaac's <paul.isaacs(a)linaro.org>; Ron Minnich > <rminnich(a)google.com>; Moe Ammar <moe(a)amperecomputing.com> > Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for > information passing between boot stages > > Apologies I failed with the recording. Manish/Madhu will reply early next > week with the slides and some notes to help with a follow up session which > we hope to hold this Thursday. Invite and agenda will also be sent out > early next week. > > Thanks > > Joanna > > On 14/05/2021, 13:30, "TF-A on behalf of Okash Khawaja via TF-A" < > tf-a-bounces(a)lists.trustedfirmware.org on behalf of > tf-a(a)lists.trustedfirmware.org> wrote: > > Hi, > > Do we have slides and video from last week's discussion? > > Thanks, > Okash > > > On Wed, May 5, 2021 at 11:52 PM Simon Glass via TF-A > <tf-a(a)lists.trustedfirmware.org> wrote: > > > > Hi Harb, > > > > Thanks for the idea. I am still not completely sure what benefit > UUID provides to an open project. I'd like to propose something different, > more in the spirit of open collaboration. I also worry that the word > 'standard' seems to be a synonym for UUIDs, UEFI, etc., i.e. > enabling/preferring closed-source firmware and the continued decline of > open-source projects. It really should not be. > > > > So I suggest: Use simple integer IDs and reserve some area for > 'private' use. If you want to collaborate across projects outside your > company, you either need to allocate a 'public' ID or agree privately > between the parties which private ID to use. > > > > This means that the default and easiest option is for collaboration > and a public ID, with private ones (whose purpose may be secret) reserved > just for private use. > > > > Regards, > > Simon > > > > On Wed, 5 May 2021 at 11:42, Harb Abdulhamid OS < > abdulhamid(a)os.amperecomputing.com> wrote: > >> > >> Hey Folks, > >> > >> We wanted to put out a middle-ground proposal to help guide the > discussion on the call tomorrow. > >> > >> > >> > >> A proposal that we have been discussing offline involves reserving > a single tag ID for the purpose of construction UEFI PI HOB List structure, > and that tag would be used to identify a HOB-specific structure that does > leverage UUID based identifier. This will eliminate the burden of having > to support UUID as the tag, and this enables projects that require UUID > based identifiers for the broad range of HOB structures that need to be > produced during the booting of the platform. Once we have a tag for a HOB > list, this will enable various HOB producers that can add/extend the HOB > list in TF-A code (or even pre-TF-A code), with a HOB consumer for that > UUID/GUID on the other side (i.e. whatever the BL33 image is booting on > that platform). > >> > >> > >> > >> Essentially, the idea is if someone would like to support HOB > structures in a standard way using TF-A, they would wrap it up in a > BL_AUX_PARAM/BLOB structure (whatever the group decides) and the way we > identify the structure as a HOB list is with this new reserved tag. > >> > >> > >> > >> Hopefully that makes sense and less contentious. Look forward to > discuss this further on the call. > >> > >> > >> > >> Thanks, > >> > >> --Harb > >> > >> > >> > >> From: Manish Pandey2 <Manish.Pandey2(a)arm.com> > >> Sent: Friday, April 30, 2021 8:14 AM > >> To: François Ozog <francois.ozog(a)linaro.org> > >> Cc: Simon Glass <sjg(a)chromium.org>; Julius Werner < > jwerner(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; > U-Boot Mailing List <u-boot(a)lists.denx.de>; 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 > >> > >> > >> > >> Hi All, > >> > >> > >> > >> Please find invite for next TF-A Tech Forum session to continue our > discussions on HOB implementation, feel free to forward it to others. > >> > >> > >> > >> The next TF-A Tech Forum is scheduled for Thu 6th May 2021 16:00 – > 17:00 (BST). > >> > >> > >> > >> Agenda: > >> > >> Discussion Session: Static and Dynamic Information Handling in TF-A > >> > >> Lead by Manish Pandey and Madhukar Pappireddy > >> > >> · There is ongoing mailing lists discussion[1] related with > adopting a mechanism to pass information through boot stages. > >> > >> The requirement is two-fold: > >> > >> 1. Passing static information(config files) > >> > >> 2. Passing dynamic information (Hob list) > >> > >> In the upcoming TF-A tech forum, we can start with a discussion on > dynamic information passing and if time permits, we can cover static > information passing. The purpose of the call is to have an open discussion > and continue the discussion from the trusted-substrate call[2] done > earlier. We would like to understand the various requirements and possible > ways to implement it in TF-A in a generalized way so that it can work with > other Firmware projects. > >> > >> > >> > >> The two specific item which we would like to discuss are: > >> > >> 1. HOB format: TF-A/u-boot both has an existing bloblist > implementation, which uses tag values. Question, can this be enhanced to > use hybrid values(Tag and UUID) both? > >> > >> 2. Standardization on Physical register use to pass base of > HoB data structure. > >> > >> References: > >> > >> [1] > https://lists.trustedfirmware.org/pipermail/tf-a/2021-April/001069.html > >> > >> [2] > https://linaro-org.zoom.us/rec/share/zjfHeMIumkJhirLCVQYTHR6ftaqyWvF_0klgQn… > Passcode: IPn+5q% > >> > >> > >> > >> Thanks > >> > >> > >> > >> Joanna > >> > >> > >> > >> You have been invited to the following event. > >> > >> TF-A Tech Forum > >> > >> When > >> > >> Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time > >> > >> Calendar > >> > >> tf-a(a)lists.trustedfirmware.org > >> > >> Who > >> > >> • > >> > >> Bill Fletcher- creator > >> > >> • > >> > >> tf-a(a)lists.trustedfirmware.org > >> > >> more details » > >> > >> > >> > >> 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/ > >> > >> > >> > >> Trusted Firmware is inviting you to a scheduled Zoom meeting. > >> > >> > >> > >> Join Zoom Meeting > >> > >> https://zoom.us/j/9159704974 > >> > >> > >> > >> Meeting ID: 915 970 4974 > >> > >> > >> > >> One 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-free > >> > >> Meeting ID: 915 970 4974 > >> > >> Find your local number: https://zoom.us/u/ad27hc6t7h > >> > >> > >> > >> ________________________________ > >> > >> From: François Ozog <francois.ozog(a)linaro.org> > >> Sent: 08 April 2021 16:50 > >> To: Manish Pandey2 <Manish.Pandey2(a)arm.com> > >> Cc: Simon Glass <sjg(a)chromium.org>; Julius Werner < > jwerner(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 < > tf-a(a)lists.trustedfirmware.org>; U-Boot Mailing List <u-boot(a)lists.denx.de>; > 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 > >> > >> > >> > >> Hi > >> > >> > >> > >> here is the meeting recording: > >> > >> > https://linaro-org.zoom.us/rec/share/zjfHeMIumkJhirLCVQYTHR6ftaqyWvF_0klgQn… > Passcode: IPn+5q%z > >> > >> > >> > >> I am really sorry about the confusion related to the meeting time. > I have now understood: the Collaborate portal uses a specific calendar > which is tied to US/Chicago timezone while the actual Google Calendar is > tied to Central Europe timezone. I am going to drop the Collaborate portal > and use a shared Google calendar (it should be visible on the > trusted-substrate.org page). > >> > >> > >> > >> I'll try to summarize what I learnt and highlight my view on what > can be next steps in a future mail. > >> > >> > >> > >> Cheers > >> > >> > >> > >> FF > >> > >> > >> > >> On Thu, 8 Apr 2021 at 13:56, Manish Pandey2 via TF-A < > tf-a(a)lists.trustedfirmware.org> wrote: > >> > >> Hi, > >> > >> > >> > >> From TF-A project point of view, we prefer to use existing > mechanism to pass parameters across boot stages using linked list of tagged > elements (as suggested by Julius). It has support for both generic and > SiP-specific tags. Having said that, it does not stop partners to introduce > new mechanisms suitable for their usecase in platform port initially and > later move to generic code if its suitable for other platforms. > >> > >> > >> > >> To start with, Ampere can introduce a platform specific > implementation of memory tag(speed/NUMA topology etc) which can be > evaluated and discussed for generalization in future. The tag will be > populated in BL2 stage and can be forwarded to further stages(and to BL33) > by passing the head of list pointer in one of the registers. Initially any > register can be used but going forward a standardization will be needed. > >> > >> > >> > >> The U-boot bloblist mentioned by Simon is conceptually similar to > what TF-A is using, if there is consensus of using bloblist/taglist then > TF-A tag list may be enhanced to take best of both the implementations. > >> > >> > >> > >> One of the potential problems of having structure used in different > projects is maintainability, this can be avoided by having a single copy of > these structures in TF-A (kept inside "include/export" which intended to be > used by other projects.) > >> > >> > >> > >> Regarding usage of either UUID or tag, I echo the sentiments of > Simon and Julius to keep it simple and use tag values. > >> > >> > >> > >> Looking forward to having further discussions on zoom call today. > >> > >> > >> > >> Thanks > >> > >> Manish P > >> > >> > >> > >> ________________________________ > >> > >> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of > Julius Werner via TF-A <tf-a(a)lists.trustedfirmware.org> > >> Sent: 25 March 2021 02:43 > >> To: Simon Glass <sjg(a)chromium.org> > >> Cc: Harb Abdulhamid OS <abdulhamid(a)os.amperecomputing.com>; Boot > Architecture Mailman List <boot-architecture(a)lists.linaro.org>; > tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; U-Boot > Mailing List <u-boot(a)lists.denx.de>; 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 > >> > >> > >> > >> 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 – 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: > >> > >> “SoC” or “silicon” firmware – in TF-A this may map to BL1, BL2, > BL31, and *possibly* one or more BL32 instances > >> “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 - 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 +Paul Isaac's > >> > >> > >> > >> 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 zoom > call 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, 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) > 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 > >> > >> -- > >> 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 > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > -- > 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, 5 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

Le mer. 19 mai 2021 à 23:51, Jeremy Linton via TF-A < tf-a(a)lists.trustedfirmware.org> a écrit : > On 5/18/21 8:59 PM, Madhukar Pappireddy via TF-A wrote: > > Hi, > > > > I tried to summarize the discussions in the previous TF-A tech forum > regarding the proposal to adopt Hand-off Blocks (HOBs) for passing > information along the boot chain. I am certain I could not capture all > suggestions/concerns brought up during the call. I apologize if I missed > and/or misinterpreted any comments and would appreciate it if everyone > could share their thoughts in response to this email thread. > > > > The idea is to share information to other boot phases: > >> Dynamic information: Created during runtime. Shared in the form of a > chain of blobs(built as a linked list of C structure objects i.e., HOB > list). > >> Static information: Known at compile time. Historically, shared through > the use of Device Tree/ACPI tables > > > > Both the above requirements are common in many ecosystems and need to > co-exist. > > > > There are broadly 3 problems to solve: > > 1. Format of HOB structures: It looks like the consensus is that we > could use existing mechanisms for this (BL_AUX_PARAM in TF-A or bloblist in > u-boot). > > 2. Identification of HOB list entries: There is a debate about whether > tags would suffice or if the HOB list producer and consumer would depend on > UUID/GUIDs for identifying a specific HOB structure. Another suggestion was > to use a hybrid approach. Reserve a single tag ID for > identifying/constructing a HOB structure that further leverages UUID based > identifier. This way, the generic HOB list doesn't need to support UUIDs > and can work with tags. > > 3. The design contract for the static interface between two boot phases: > The problem at hand is whether to pass a pointer to a HOB list or a device > tree blob through the general-purpose registers for configuration hand-off > between two boot phases. Some proposals that came up: > > > Proposal 1: Always pass a pointer to the device tree blob > through the GP register and capture the pointer to the HOB list as a > property of a node that is uniquely identifiable by the downstream boot > phase. This needs to define a device tree binding such that producer and > consumer agree on the information passed. > > > Using DT to pass platform info at this level is sort of crazy on an ACPI > machine which won't have native DTs. Meaning there is an additional > level of unnecessary indirection that needs to be converted back into a > format which can be utilized by AML and other parts of the ACPI stack. I would love the BL33 becomes a product maker (using a board vendor product) decision: using EDK2, U-Boot, LinuxBoot or even Xen directly as BL33. If this is a goal , then there will be a need for a translation layer between the firmware framework (tfa, core boot, uboot SPL) formats and the non secure firmware format. If this is not a goal then I agree that passing a DT in an ACPI system is suboptimal. That said there is a UEFI PI HOB that is a DT container and used in existing systems. And conversely, in systems with complex MDIO or other hardware without ACPI representation (serdes), it does not make sense to bring ACPI stuff. The easiest path is to not give a choice of BL33 and have a format for each “realm”: DT or ACPI. > > Its also helpful to look at what has become of the rpi4 uefi port, where > the DT is actually dynamic (or provided by the user, complete with HAT > overlays) and fed into the lower level firmware and propagated up > through the system. The result has frequently been subtle bugs or boot > failures because the DT provided by the rpi foundation as part of their > low level firwmare+kernel stack is modified by their low level firwmare, > and it differs from the DT in mainline linux. So more than once we have > discovered that there isn't a single DT that can be boot both the > current firmware and a current mainline linux. In the past there was > even an option to use one DT for the firmware and an entirely seperate > one for linux, but that was removed when it bacame apparent you couldn't > have the lower level firmwaer say modifying MMIO windows for the PCIe > subsystem and not propogate that into the other user supplied DT. > ACPI shows that firmware provided hardware description makes life easier. That’s why Arm SystemReady-IR states that it should be the case for DT too. RPI4 and beaglebone have had different strategies and each with good and bad things. The Linaro Device Tree Evolution open project is tackling diverse aspects of DT including proper handling hats, and other runtime adaptations. > > At this point the uefi firmware on the rpi will provide a DT if asked, > but it doesn't parse it nor does anything in the AML. Instead everything > is done directly against the hardware, even when the HW registers aren't > well documented.That is in large parts because the AML requirements are > a lot different than what is provided in the DT. > > > > > > Proposal 2: Pass a pointer to a generic container through the GP > register that can be interpreted appropriately by both boot loaders(i.e., > producer and consumer of the boot info). This container can either be a dtb > or a HOB list which can be simply inferred by checking for a magic header > that indicates if the buffer appears to be a flattened device tree. > > > One another concern that was brought up offline is to make sure > we don't break current design contracts between various boot loader phases > in TF-A. Many of the general-purpose registers have a designated purpose > such as to share configurations between BL images( such as firmware config > dtb, SoC config dtb, Non trusted firmware config dtb, memory layout, entry > point info, etc.). > > > > If I am not mistaken, a single design may not fit the needs of every > segment(client, Infra, embedded) and the forum is open to solutions > tailored for individual segments. Joanna will be sending a follow up email > with more information about future TF-A tech forums that serves as a > platform for further discussions. > > > > Thanks, > > Madhukar > > > > -----Original Message----- > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Joanna > Farley via TF-A > > Sent: Sunday, May 16, 2021 5:19 AM > > To: Okash Khawaja <okash.khawaja(a)gmail.com>; Simon Glass < > sjg(a)chromium.org> > > Cc: Harb Abdulhamid OS <abdulhamid(a)os.amperecomputing.com>; Boot > Architecture Mailman List <boot-architecture(a)lists.linaro.org>; > tf-a(a)lists.trustedfirmware.org; Ed Stuber <edstuber(a)amperecomputing.com>; > Arjun Khare <akhare(a)amperecomputing.com>; U-Boot Mailing List < > u-boot(a)lists.denx.de>; Paul Isaac's <paul.isaacs(a)linaro.org>; Ron Minnich > <rminnich(a)google.com>; Moe Ammar <moe(a)amperecomputing.com> > > Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for > information passing between boot stages > > > > Apologies I failed with the recording. Manish/Madhu will reply early > next week with the slides and some notes to help with a follow up session > which we hope to hold this Thursday. Invite and agenda will also be sent > out early next week. > > > > Thanks > > > > Joanna > > > > On 14/05/2021, 13:30, "TF-A on behalf of Okash Khawaja via TF-A" < > tf-a-bounces(a)lists.trustedfirmware.org on behalf of > tf-a(a)lists.trustedfirmware.org> wrote: > > > > Hi, > > > > Do we have slides and video from last week's discussion? > > > > Thanks, > > Okash > > > > > > On Wed, May 5, 2021 at 11:52 PM Simon Glass via TF-A > > <tf-a(a)lists.trustedfirmware.org> wrote: > > > > > > Hi Harb, > > > > > > Thanks for the idea. I am still not completely sure what benefit > UUID provides to an open project. I'd like to propose something different, > more in the spirit of open collaboration. I also worry that the word > 'standard' seems to be a synonym for UUIDs, UEFI, etc., i.e. > enabling/preferring closed-source firmware and the continued decline of > open-source projects. It really should not be. > > > > > > So I suggest: Use simple integer IDs and reserve some area for > 'private' use. If you want to collaborate across projects outside your > company, you either need to allocate a 'public' ID or agree privately > between the parties which private ID to use. > > > > > > This means that the default and easiest option is for > collaboration and a public ID, with private ones (whose purpose may be > secret) reserved just for private use. > > > > > > Regards, > > > Simon > > > > > > On Wed, 5 May 2021 at 11:42, Harb Abdulhamid OS < > abdulhamid(a)os.amperecomputing.com> wrote: > > >> > > >> Hey Folks, > > >> > > >> We wanted to put out a middle-ground proposal to help guide the > discussion on the call tomorrow. > > >> > > >> > > >> > > >> A proposal that we have been discussing offline involves > reserving a single tag ID for the purpose of construction UEFI PI HOB List > structure, and that tag would be used to identify a HOB-specific structure > that does leverage UUID based identifier. This will eliminate the burden > of having to support UUID as the tag, and this enables projects that > require UUID based identifiers for the broad range of HOB structures that > need to be produced during the booting of the platform. Once we have a tag > for a HOB list, this will enable various HOB producers that can add/extend > the HOB list in TF-A code (or even pre-TF-A code), with a HOB consumer for > that UUID/GUID on the other side (i.e. whatever the BL33 image is booting > on that platform). > > >> > > >> > > >> > > >> Essentially, the idea is if someone would like to support HOB > structures in a standard way using TF-A, they would wrap it up in a > BL_AUX_PARAM/BLOB structure (whatever the group decides) and the way we > identify the structure as a HOB list is with this new reserved tag. > > >> > > >> > > >> > > >> Hopefully that makes sense and less contentious. Look forward > to discuss this further on the call. > > >> > > >> > > >> > > >> Thanks, > > >> > > >> --Harb > > >> > > >> > > >> > > >> From: Manish Pandey2 <Manish.Pandey2(a)arm.com> > > >> Sent: Friday, April 30, 2021 8:14 AM > > >> To: François Ozog <francois.ozog(a)linaro.org> > > >> Cc: Simon Glass <sjg(a)chromium.org>; Julius Werner < > jwerner(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; > U-Boot Mailing List <u-boot(a)lists.denx.de>; 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 > > >> > > >> > > >> > > >> Hi All, > > >> > > >> > > >> > > >> Please find invite for next TF-A Tech Forum session to continue > our discussions on HOB implementation, feel free to forward it to others. > > >> > > >> > > >> > > >> The next TF-A Tech Forum is scheduled for Thu 6th May 2021 16:00 > – 17:00 (BST). > > >> > > >> > > >> > > >> Agenda: > > >> > > >> Discussion Session: Static and Dynamic Information Handling in > TF-A > > >> > > >> Lead by Manish Pandey and Madhukar Pappireddy > > >> > > >> · There is ongoing mailing lists discussion[1] related > with adopting a mechanism to pass information through boot stages. > > >> > > >> The requirement is two-fold: > > >> > > >> 1. Passing static information(config files) > > >> > > >> 2. Passing dynamic information (Hob list) > > >> > > >> In the upcoming TF-A tech forum, we can start with a discussion > on dynamic information passing and if time permits, we can cover static > information passing. The purpose of the call is to have an open discussion > and continue the discussion from the trusted-substrate call[2] done > earlier. We would like to understand the various requirements and possible > ways to implement it in TF-A in a generalized way so that it can work with > other Firmware projects. > > >> > > >> > > >> > > >> The two specific item which we would like to discuss are: > > >> > > >> 1. HOB format: TF-A/u-boot both has an existing bloblist > implementation, which uses tag values. Question, can this be enhanced to > use hybrid values(Tag and UUID) both? > > >> > > >> 2. Standardization on Physical register use to pass base of > HoB data structure. > > >> > > >> References: > > >> > > >> [1] > https://lists.trustedfirmware.org/pipermail/tf-a/2021-April/001069.html > > >> > > >> [2] > https://linaro-org.zoom.us/rec/share/zjfHeMIumkJhirLCVQYTHR6ftaqyWvF_0klgQn… > Passcode: IPn+5q% > > >> > > >> > > >> > > >> Thanks > > >> > > >> > > >> > > >> Joanna > > >> > > >> > > >> > > >> You have been invited to the following event. > > >> > > >> TF-A Tech Forum > > >> > > >> When > > >> > > >> Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time > > >> > > >> Calendar > > >> > > >> tf-a(a)lists.trustedfirmware.org > > >> > > >> Who > > >> > > >> • > > >> > > >> Bill Fletcher- creator > > >> > > >> • > > >> > > >> tf-a(a)lists.trustedfirmware.org > > >> > > >> more details » > > >> > > >> > > >> > > >> 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/ > > >> > > >> > > >> > > >> Trusted Firmware is inviting you to a scheduled Zoom meeting. > > >> > > >> > > >> > > >> Join Zoom Meeting > > >> > > >> https://zoom.us/j/9159704974 > > >> > > >> > > >> > > >> Meeting ID: 915 970 4974 > > >> > > >> > > >> > > >> One 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-free > > >> > > >> Meeting ID: 915 970 4974 > > >> > > >> Find your local number: https://zoom.us/u/ad27hc6t7h > > >> > > >> > > >> > > >> ________________________________ > > >> > > >> From: François Ozog <francois.ozog(a)linaro.org> > > >> Sent: 08 April 2021 16:50 > > >> To: Manish Pandey2 <Manish.Pandey2(a)arm.com> > > >> Cc: Simon Glass <sjg(a)chromium.org>; Julius Werner < > jwerner(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 < > tf-a(a)lists.trustedfirmware.org>; U-Boot Mailing List <u-boot(a)lists.denx.de>; > 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 > > >> > > >> > > >> > > >> Hi > > >> > > >> > > >> > > >> here is the meeting recording: > > >> > > >> > https://linaro-org.zoom.us/rec/share/zjfHeMIumkJhirLCVQYTHR6ftaqyWvF_0klgQn… > Passcode: IPn+5q%z > > >> > > >> > > >> > > >> I am really sorry about the confusion related to the meeting > time. I have now understood: the Collaborate portal uses a specific > calendar which is tied to US/Chicago timezone while the actual Google > Calendar is tied to Central Europe timezone. I am going to drop the > Collaborate portal and use a shared Google calendar (it should be visible > on the trusted-substrate.org page). > > >> > > >> > > >> > > >> I'll try to summarize what I learnt and highlight my view on > what can be next steps in a future mail. > > >> > > >> > > >> > > >> Cheers > > >> > > >> > > >> > > >> FF > > >> > > >> > > >> > > >> On Thu, 8 Apr 2021 at 13:56, Manish Pandey2 via TF-A < > tf-a(a)lists.trustedfirmware.org> wrote: > > >> > > >> Hi, > > >> > > >> > > >> > > >> From TF-A project point of view, we prefer to use existing > mechanism to pass parameters across boot stages using linked list of tagged > elements (as suggested by Julius). It has support for both generic and > SiP-specific tags. Having said that, it does not stop partners to introduce > new mechanisms suitable for their usecase in platform port initially and > later move to generic code if its suitable for other platforms. > > >> > > >> > > >> > > >> To start with, Ampere can introduce a platform specific > implementation of memory tag(speed/NUMA topology etc) which can be > evaluated and discussed for generalization in future. The tag will be > populated in BL2 stage and can be forwarded to further stages(and to BL33) > by passing the head of list pointer in one of the registers. Initially any > register can be used but going forward a standardization will be needed. > > >> > > >> > > >> > > >> The U-boot bloblist mentioned by Simon is conceptually similar > to what TF-A is using, if there is consensus of using bloblist/taglist > then TF-A tag list may be enhanced to take best of both the implementations. > > >> > > >> > > >> > > >> One of the potential problems of having structure used in > different projects is maintainability, this can be avoided by having a > single copy of these structures in TF-A (kept inside "include/export" which > intended to be used by other projects.) > > >> > > >> > > >> > > >> Regarding usage of either UUID or tag, I echo the sentiments of > Simon and Julius to keep it simple and use tag values. > > >> > > >> > > >> > > >> Looking forward to having further discussions on zoom call today. > > >> > > >> > > >> > > >> Thanks > > >> > > >> Manish P > > >> > > >> > > >> > > >> ________________________________ > > >> > > >> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf > of Julius Werner via TF-A <tf-a(a)lists.trustedfirmware.org> > > >> Sent: 25 March 2021 02:43 > > >> To: Simon Glass <sjg(a)chromium.org> > > >> Cc: Harb Abdulhamid OS <abdulhamid(a)os.amperecomputing.com>; > Boot Architecture Mailman List <boot-architecture(a)lists.linaro.org>; > tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; U-Boot > Mailing List <u-boot(a)lists.denx.de>; 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 > > >> > > >> > > >> > > >> 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 – 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: > > >> > > >> “SoC” or “silicon” firmware – in TF-A this may map to BL1, BL2, > BL31, and *possibly* one or more BL32 instances > > >> “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 - 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 +Paul Isaac's > > >> > > >> > > >> > > >> 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 > zoom call 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, 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) > 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 > > >> > > >> -- > > >> 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 > > -- > > TF-A mailing list > > TF-A(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > > > -- > 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, 5 months

1
0
0 0

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

by Jeremy Linton

On 5/18/21 8:59 PM, Madhukar Pappireddy via TF-A wrote: > Hi, > > I tried to summarize the discussions in the previous TF-A tech forum regarding the proposal to adopt Hand-off Blocks (HOBs) for passing information along the boot chain. I am certain I could not capture all suggestions/concerns brought up during the call. I apologize if I missed and/or misinterpreted any comments and would appreciate it if everyone could share their thoughts in response to this email thread. > > The idea is to share information to other boot phases: >> Dynamic information: Created during runtime. Shared in the form of a chain of blobs(built as a linked list of C structure objects i.e., HOB list). >> Static information: Known at compile time. Historically, shared through the use of Device Tree/ACPI tables > > Both the above requirements are common in many ecosystems and need to co-exist. > > There are broadly 3 problems to solve: > 1. Format of HOB structures: It looks like the consensus is that we could use existing mechanisms for this (BL_AUX_PARAM in TF-A or bloblist in u-boot). > 2. Identification of HOB list entries: There is a debate about whether tags would suffice or if the HOB list producer and consumer would depend on UUID/GUIDs for identifying a specific HOB structure. Another suggestion was to use a hybrid approach. Reserve a single tag ID for identifying/constructing a HOB structure that further leverages UUID based identifier. This way, the generic HOB list doesn't need to support UUIDs and can work with tags. > 3. The design contract for the static interface between two boot phases: The problem at hand is whether to pass a pointer to a HOB list or a device tree blob through the general-purpose registers for configuration hand-off between two boot phases. Some proposals that came up: > > Proposal 1: Always pass a pointer to the device tree blob through the GP register and capture the pointer to the HOB list as a property of a node that is uniquely identifiable by the downstream boot phase. This needs to define a device tree binding such that producer and consumer agree on the information passed. Using DT to pass platform info at this level is sort of crazy on an ACPI machine which won't have native DTs. Meaning there is an additional level of unnecessary indirection that needs to be converted back into a format which can be utilized by AML and other parts of the ACPI stack. Its also helpful to look at what has become of the rpi4 uefi port, where the DT is actually dynamic (or provided by the user, complete with HAT overlays) and fed into the lower level firmware and propagated up through the system. The result has frequently been subtle bugs or boot failures because the DT provided by the rpi foundation as part of their low level firwmare+kernel stack is modified by their low level firwmare, and it differs from the DT in mainline linux. So more than once we have discovered that there isn't a single DT that can be boot both the current firmware and a current mainline linux. In the past there was even an option to use one DT for the firmware and an entirely seperate one for linux, but that was removed when it bacame apparent you couldn't have the lower level firmwaer say modifying MMIO windows for the PCIe subsystem and not propogate that into the other user supplied DT. At this point the uefi firmware on the rpi will provide a DT if asked, but it doesn't parse it nor does anything in the AML. Instead everything is done directly against the hardware, even when the HW registers aren't well documented.That is in large parts because the AML requirements are a lot different than what is provided in the DT. > > Proposal 2: Pass a pointer to a generic container through the GP register that can be interpreted appropriately by both boot loaders(i.e., producer and consumer of the boot info). This container can either be a dtb or a HOB list which can be simply inferred by checking for a magic header that indicates if the buffer appears to be a flattened device tree. > > One another concern that was brought up offline is to make sure we don't break current design contracts between various boot loader phases in TF-A. Many of the general-purpose registers have a designated purpose such as to share configurations between BL images( such as firmware config dtb, SoC config dtb, Non trusted firmware config dtb, memory layout, entry point info, etc.). > > If I am not mistaken, a single design may not fit the needs of every segment(client, Infra, embedded) and the forum is open to solutions tailored for individual segments. Joanna will be sending a follow up email with more information about future TF-A tech forums that serves as a platform for further discussions. > > Thanks, > Madhukar > > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Joanna Farley via TF-A > Sent: Sunday, May 16, 2021 5:19 AM > To: Okash Khawaja <okash.khawaja(a)gmail.com>; Simon Glass <sjg(a)chromium.org> > Cc: Harb Abdulhamid OS <abdulhamid(a)os.amperecomputing.com>; Boot Architecture Mailman List <boot-architecture(a)lists.linaro.org>; tf-a(a)lists.trustedfirmware.org; Ed Stuber <edstuber(a)amperecomputing.com>; Arjun Khare <akhare(a)amperecomputing.com>; U-Boot Mailing List <u-boot(a)lists.denx.de>; Paul Isaac's <paul.isaacs(a)linaro.org>; Ron Minnich <rminnich(a)google.com>; Moe Ammar <moe(a)amperecomputing.com> > Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages > > Apologies I failed with the recording. Manish/Madhu will reply early next week with the slides and some notes to help with a follow up session which we hope to hold this Thursday. Invite and agenda will also be sent out early next week. > > Thanks > > Joanna > > On 14/05/2021, 13:30, "TF-A on behalf of Okash Khawaja via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: > > Hi, > > Do we have slides and video from last week's discussion? > > Thanks, > Okash > > > On Wed, May 5, 2021 at 11:52 PM Simon Glass via TF-A > <tf-a(a)lists.trustedfirmware.org> wrote: > > > > Hi Harb, > > > > Thanks for the idea. I am still not completely sure what benefit UUID provides to an open project. I'd like to propose something different, more in the spirit of open collaboration. I also worry that the word 'standard' seems to be a synonym for UUIDs, UEFI, etc., i.e. enabling/preferring closed-source firmware and the continued decline of open-source projects. It really should not be. > > > > So I suggest: Use simple integer IDs and reserve some area for 'private' use. If you want to collaborate across projects outside your company, you either need to allocate a 'public' ID or agree privately between the parties which private ID to use. > > > > This means that the default and easiest option is for collaboration and a public ID, with private ones (whose purpose may be secret) reserved just for private use. > > > > Regards, > > Simon > > > > On Wed, 5 May 2021 at 11:42, Harb Abdulhamid OS <abdulhamid(a)os.amperecomputing.com> wrote: > >> > >> Hey Folks, > >> > >> We wanted to put out a middle-ground proposal to help guide the discussion on the call tomorrow. > >> > >> > >> > >> A proposal that we have been discussing offline involves reserving a single tag ID for the purpose of construction UEFI PI HOB List structure, and that tag would be used to identify a HOB-specific structure that does leverage UUID based identifier. This will eliminate the burden of having to support UUID as the tag, and this enables projects that require UUID based identifiers for the broad range of HOB structures that need to be produced during the booting of the platform. Once we have a tag for a HOB list, this will enable various HOB producers that can add/extend the HOB list in TF-A code (or even pre-TF-A code), with a HOB consumer for that UUID/GUID on the other side (i.e. whatever the BL33 image is booting on that platform). > >> > >> > >> > >> Essentially, the idea is if someone would like to support HOB structures in a standard way using TF-A, they would wrap it up in a BL_AUX_PARAM/BLOB structure (whatever the group decides) and the way we identify the structure as a HOB list is with this new reserved tag. > >> > >> > >> > >> Hopefully that makes sense and less contentious. Look forward to discuss this further on the call. > >> > >> > >> > >> Thanks, > >> > >> --Harb > >> > >> > >> > >> From: Manish Pandey2 <Manish.Pandey2(a)arm.com> > >> Sent: Friday, April 30, 2021 8:14 AM > >> To: François Ozog <francois.ozog(a)linaro.org> > >> Cc: Simon Glass <sjg(a)chromium.org>; Julius Werner <jwerner(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; U-Boot Mailing List <u-boot(a)lists.denx.de>; 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 > >> > >> > >> > >> Hi All, > >> > >> > >> > >> Please find invite for next TF-A Tech Forum session to continue our discussions on HOB implementation, feel free to forward it to others. > >> > >> > >> > >> The next TF-A Tech Forum is scheduled for Thu 6th May 2021 16:00 – 17:00 (BST). > >> > >> > >> > >> Agenda: > >> > >> Discussion Session: Static and Dynamic Information Handling in TF-A > >> > >> Lead by Manish Pandey and Madhukar Pappireddy > >> > >> · There is ongoing mailing lists discussion[1] related with adopting a mechanism to pass information through boot stages. > >> > >> The requirement is two-fold: > >> > >> 1. Passing static information(config files) > >> > >> 2. Passing dynamic information (Hob list) > >> > >> In the upcoming TF-A tech forum, we can start with a discussion on dynamic information passing and if time permits, we can cover static information passing. The purpose of the call is to have an open discussion and continue the discussion from the trusted-substrate call[2] done earlier. We would like to understand the various requirements and possible ways to implement it in TF-A in a generalized way so that it can work with other Firmware projects. > >> > >> > >> > >> The two specific item which we would like to discuss are: > >> > >> 1. HOB format: TF-A/u-boot both has an existing bloblist implementation, which uses tag values. Question, can this be enhanced to use hybrid values(Tag and UUID) both? > >> > >> 2. Standardization on Physical register use to pass base of HoB data structure. > >> > >> References: > >> > >> [1] https://lists.trustedfirmware.org/pipermail/tf-a/2021-April/001069.html > >> > >> [2] https://linaro-org.zoom.us/rec/share/zjfHeMIumkJhirLCVQYTHR6ftaqyWvF_0klgQn… Passcode: IPn+5q% > >> > >> > >> > >> Thanks > >> > >> > >> > >> Joanna > >> > >> > >> > >> You have been invited to the following event. > >> > >> TF-A Tech Forum > >> > >> When > >> > >> Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time > >> > >> Calendar > >> > >> tf-a(a)lists.trustedfirmware.org > >> > >> Who > >> > >> • > >> > >> Bill Fletcher- creator > >> > >> • > >> > >> tf-a(a)lists.trustedfirmware.org > >> > >> more details » > >> > >> > >> > >> 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/ > >> > >> > >> > >> Trusted Firmware is inviting you to a scheduled Zoom meeting. > >> > >> > >> > >> Join Zoom Meeting > >> > >> https://zoom.us/j/9159704974 > >> > >> > >> > >> Meeting ID: 915 970 4974 > >> > >> > >> > >> One 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-free > >> > >> Meeting ID: 915 970 4974 > >> > >> Find your local number: https://zoom.us/u/ad27hc6t7h > >> > >> > >> > >> ________________________________ > >> > >> From: François Ozog <francois.ozog(a)linaro.org> > >> Sent: 08 April 2021 16:50 > >> To: Manish Pandey2 <Manish.Pandey2(a)arm.com> > >> Cc: Simon Glass <sjg(a)chromium.org>; Julius Werner <jwerner(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 <tf-a(a)lists.trustedfirmware.org>; U-Boot Mailing List <u-boot(a)lists.denx.de>; 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 > >> > >> > >> > >> Hi > >> > >> > >> > >> here is the meeting recording: > >> > >> https://linaro-org.zoom.us/rec/share/zjfHeMIumkJhirLCVQYTHR6ftaqyWvF_0klgQn… Passcode: IPn+5q%z > >> > >> > >> > >> I am really sorry about the confusion related to the meeting time. I have now understood: the Collaborate portal uses a specific calendar which is tied to US/Chicago timezone while the actual Google Calendar is tied to Central Europe timezone. I am going to drop the Collaborate portal and use a shared Google calendar (it should be visible on the trusted-substrate.org page). > >> > >> > >> > >> I'll try to summarize what I learnt and highlight my view on what can be next steps in a future mail. > >> > >> > >> > >> Cheers > >> > >> > >> > >> FF > >> > >> > >> > >> On Thu, 8 Apr 2021 at 13:56, Manish Pandey2 via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > >> > >> Hi, > >> > >> > >> > >> From TF-A project point of view, we prefer to use existing mechanism to pass parameters across boot stages using linked list of tagged elements (as suggested by Julius). It has support for both generic and SiP-specific tags. Having said that, it does not stop partners to introduce new mechanisms suitable for their usecase in platform port initially and later move to generic code if its suitable for other platforms. > >> > >> > >> > >> To start with, Ampere can introduce a platform specific implementation of memory tag(speed/NUMA topology etc) which can be evaluated and discussed for generalization in future. The tag will be populated in BL2 stage and can be forwarded to further stages(and to BL33) by passing the head of list pointer in one of the registers. Initially any register can be used but going forward a standardization will be needed. > >> > >> > >> > >> The U-boot bloblist mentioned by Simon is conceptually similar to what TF-A is using, if there is consensus of using bloblist/taglist then TF-A tag list may be enhanced to take best of both the implementations. > >> > >> > >> > >> One of the potential problems of having structure used in different projects is maintainability, this can be avoided by having a single copy of these structures in TF-A (kept inside "include/export" which intended to be used by other projects.) > >> > >> > >> > >> Regarding usage of either UUID or tag, I echo the sentiments of Simon and Julius to keep it simple and use tag values. > >> > >> > >> > >> Looking forward to having further discussions on zoom call today. > >> > >> > >> > >> Thanks > >> > >> Manish P > >> > >> > >> > >> ________________________________ > >> > >> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Julius Werner via TF-A <tf-a(a)lists.trustedfirmware.org> > >> Sent: 25 March 2021 02:43 > >> To: Simon Glass <sjg(a)chromium.org> > >> Cc: Harb Abdulhamid OS <abdulhamid(a)os.amperecomputing.com>; Boot Architecture Mailman List <boot-architecture(a)lists.linaro.org>; tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; U-Boot Mailing List <u-boot(a)lists.denx.de>; 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 > >> > >> > >> > >> 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 – 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: > >> > >> “SoC” or “silicon” firmware – in TF-A this may map to BL1, BL2, BL31, and *possibly* one or more BL32 instances > >> “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 - 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 +Paul Isaac's > >> > >> > >> > >> 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 zoom call 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, 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) 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 > >> > >> -- > >> 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 > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a >

4 years, 5 months

1
0
0 0

CANCELLED TF-A Tech Forum Agenda @ Thr 20th May 2021 16:00-1700 BST CANCELLED

by Joanna Farley

Hi Everyone, I am cancelling this week’s TF-A Tech Forum as I don’t have any areas to present/discuss. I expect the session on 3rd June to be a follow on session of that held below from 2 weeks ago. A write up was posted yesterday to the mailing list. Thanks Joanna From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Joanna Farley via TF-A <tf-a(a)lists.trustedfirmware.org> Reply to: Joanna Farley <Joanna.Farley(a)arm.com> Date: Thursday, 29 April 2021 at 17:59 To: "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] TF-A Tech Forum Agenda @ Thr 6th May 2021 16:00-1700 BST Hi All, The next TF-A Tech Forum is scheduled for Thu 6th May 2021 16:00 – 17:00 (BST). Agenda: * Discussion Session: Static and Dynamic Information Handling in TF-A * Lead by Manish Pandy and Madhukar Pappireddy · There is ongoing mailing lists discussion[1] related with adopting a mechanism to pass information through boot stages. The requirement is two-fold: 1. Passing static information(config files) 2. Passing dynamic information (Hob list) In the upcoming TF-A tech forum, we can start with a discussion on dynamic information passing and if time permits, we can cover static information passing. The purpose of the call is to have an open discussion and continue the discussion from the trusted-substrate call[2] done earlier. We would like to understand the various requirements and possible ways to implement it in TF-A in a generalized way so that it can work with other Firmware projects. The two specific item which we would like to discuss are: 1. HOB format: TF-A/u-boot both has an existing bloblist implementation, which uses tag values. Question, can this be enhanced to use hybrid values(Tag and UUID) both? 2. Standardization on Physical register use to pass base of HoB data structure. References: [1] https://lists.trustedfirmware.org/pipermail/tf-a/2021-April/001069.html [2] https://linaro-org.zoom.us/rec/share/zjfHeMIumkJhirLCVQYTHR6ftaqyWvF_0klgQn… Passcode: IPn+5q% Thanks Joanna You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> 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/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One 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-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.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://www.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 organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>.

4 years, 5 months

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu May 20, 2021 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been canceled with this note: "Cancelling the TF-A Tech Forum session this week. We expect the session on 3rd of June to be a follow up of the Discussion Session: Static and Dynamic Information Handling in TF-A held 2 weeks ago." 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 May 20, 2021 4pm – 5pm United Kingdom Time 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, 5 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

Looks tf-a(a)lists.trustedfirmware.org got dropped. Adding that back in. Joanna On 19/05/2021, 15:33, "Joanna Farley" <Joanna.Farley(a)arm.com> wrote: It’s a bit short notice to host another TF-A Tech-forum call on this tomorrow for a live debate as well as Manish who led the call last time is not available this week. So I propose our next TF-A Techforum session on Thursday 3rd June at 4pm BST and between now and then email discussions can possibly be pursued. From a TF-A perspective we want to help facilitate a number of segments/use-cases we heard about as Madhu mentions below. As such any enablement we can provide in TF-A common code would be good to identify that contributors to other segments/use-cases can build upon in shared platform code in TF-A or elsewhere outside the TF-A repository of that works better for those segments/use-cases. Thanks Joanna On 19/05/2021, 03:50, "Madhukar Pappireddy" <Madhukar.Pappireddy(a)arm.com> wrote: Attached slides presented by Manish in the TF-A tech forum. -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Madhukar Pappireddy via TF-A Sent: Tuesday, May 18, 2021 8:59 PM To: Joanna Farley <Joanna.Farley(a)arm.com>; Okash Khawaja <okash.khawaja(a)gmail.com>; Simon Glass <sjg(a)chromium.org> Cc: Harb Abdulhamid OS <abdulhamid(a)os.amperecomputing.com>; Boot Architecture Mailman List <boot-architecture(a)lists.linaro.org>; Ed Stuber <edstuber(a)amperecomputing.com>; Arjun Khare <akhare(a)amperecomputing.com>; U-Boot Mailing List <u-boot(a)lists.denx.de>; tf-a(a)lists.trustedfirmware.org; Paul Isaac's <paul.isaacs(a)linaro.org>; Ron Minnich <rminnich(a)google.com>; Moe Ammar <moe(a)amperecomputing.com> Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages Hi, I tried to summarize the discussions in the previous TF-A tech forum regarding the proposal to adopt Hand-off Blocks (HOBs) for passing information along the boot chain. I am certain I could not capture all suggestions/concerns brought up during the call. I apologize if I missed and/or misinterpreted any comments and would appreciate it if everyone could share their thoughts in response to this email thread. The idea is to share information to other boot phases: > Dynamic information: Created during runtime. Shared in the form of a chain of blobs(built as a linked list of C structure objects i.e., HOB list). > Static information: Known at compile time. Historically, shared through the use of Device Tree/ACPI tables Both the above requirements are common in many ecosystems and need to co-exist. There are broadly 3 problems to solve: 1. Format of HOB structures: It looks like the consensus is that we could use existing mechanisms for this (BL_AUX_PARAM in TF-A or bloblist in u-boot). 2. Identification of HOB list entries: There is a debate about whether tags would suffice or if the HOB list producer and consumer would depend on UUID/GUIDs for identifying a specific HOB structure. Another suggestion was to use a hybrid approach. Reserve a single tag ID for identifying/constructing a HOB structure that further leverages UUID based identifier. This way, the generic HOB list doesn't need to support UUIDs and can work with tags. 3. The design contract for the static interface between two boot phases: The problem at hand is whether to pass a pointer to a HOB list or a device tree blob through the general-purpose registers for configuration hand-off between two boot phases. Some proposals that came up: > Proposal 1: Always pass a pointer to the device tree blob through the GP register and capture the pointer to the HOB list as a property of a node that is uniquely identifiable by the downstream boot phase. This needs to define a device tree binding such that producer and consumer agree on the information passed. > Proposal 2: Pass a pointer to a generic container through the GP register that can be interpreted appropriately by both boot loaders(i.e., producer and consumer of the boot info). This container can either be a dtb or a HOB list which can be simply inferred by checking for a magic header that indicates if the buffer appears to be a flattened device tree. > One another concern that was brought up offline is to make sure we don't break current design contracts between various boot loader phases in TF-A. Many of the general-purpose registers have a designated purpose such as to share configurations between BL images( such as firmware config dtb, SoC config dtb, Non trusted firmware config dtb, memory layout, entry point info, etc.). If I am not mistaken, a single design may not fit the needs of every segment(client, Infra, embedded) and the forum is open to solutions tailored for individual segments. Joanna will be sending a follow up email with more information about future TF-A tech forums that serves as a platform for further discussions. Thanks, Madhukar -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Joanna Farley via TF-A Sent: Sunday, May 16, 2021 5:19 AM To: Okash Khawaja <okash.khawaja(a)gmail.com>; Simon Glass <sjg(a)chromium.org> Cc: Harb Abdulhamid OS <abdulhamid(a)os.amperecomputing.com>; Boot Architecture Mailman List <boot-architecture(a)lists.linaro.org>; tf-a(a)lists.trustedfirmware.org; Ed Stuber <edstuber(a)amperecomputing.com>; Arjun Khare <akhare(a)amperecomputing.com>; U-Boot Mailing List <u-boot(a)lists.denx.de>; Paul Isaac's <paul.isaacs(a)linaro.org>; Ron Minnich <rminnich(a)google.com>; Moe Ammar <moe(a)amperecomputing.com> Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages Apologies I failed with the recording. Manish/Madhu will reply early next week with the slides and some notes to help with a follow up session which we hope to hold this Thursday. Invite and agenda will also be sent out early next week. Thanks Joanna On 14/05/2021, 13:30, "TF-A on behalf of Okash Khawaja via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi, Do we have slides and video from last week's discussion? Thanks, Okash On Wed, May 5, 2021 at 11:52 PM Simon Glass via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Harb, > > Thanks for the idea. I am still not completely sure what benefit UUID provides to an open project. I'd like to propose something different, more in the spirit of open collaboration. I also worry that the word 'standard' seems to be a synonym for UUIDs, UEFI, etc., i.e. enabling/preferring closed-source firmware and the continued decline of open-source projects. It really should not be. > > So I suggest: Use simple integer IDs and reserve some area for 'private' use. If you want to collaborate across projects outside your company, you either need to allocate a 'public' ID or agree privately between the parties which private ID to use. > > This means that the default and easiest option is for collaboration and a public ID, with private ones (whose purpose may be secret) reserved just for private use. > > Regards, > Simon > > On Wed, 5 May 2021 at 11:42, Harb Abdulhamid OS <abdulhamid(a)os.amperecomputing.com> wrote: >> >> Hey Folks, >> >> We wanted to put out a middle-ground proposal to help guide the discussion on the call tomorrow. >> >> >> >> A proposal that we have been discussing offline involves reserving a single tag ID for the purpose of construction UEFI PI HOB List structure, and that tag would be used to identify a HOB-specific structure that does leverage UUID based identifier. This will eliminate the burden of having to support UUID as the tag, and this enables projects that require UUID based identifiers for the broad range of HOB structures that need to be produced during the booting of the platform. Once we have a tag for a HOB list, this will enable various HOB producers that can add/extend the HOB list in TF-A code (or even pre-TF-A code), with a HOB consumer for that UUID/GUID on the other side (i.e. whatever the BL33 image is booting on that platform). >> >> >> >> Essentially, the idea is if someone would like to support HOB structures in a standard way using TF-A, they would wrap it up in a BL_AUX_PARAM/BLOB structure (whatever the group decides) and the way we identify the structure as a HOB list is with this new reserved tag. >> >> >> >> Hopefully that makes sense and less contentious. Look forward to discuss this further on the call. >> >> >> >> Thanks, >> >> --Harb >> >> >> >> From: Manish Pandey2 <Manish.Pandey2(a)arm.com> >> Sent: Friday, April 30, 2021 8:14 AM >> To: François Ozog <francois.ozog(a)linaro.org> >> Cc: Simon Glass <sjg(a)chromium.org>; Julius Werner <jwerner(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; U-Boot Mailing List <u-boot(a)lists.denx.de>; 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 >> >> >> >> Hi All, >> >> >> >> Please find invite for next TF-A Tech Forum session to continue our discussions on HOB implementation, feel free to forward it to others. >> >> >> >> The next TF-A Tech Forum is scheduled for Thu 6th May 2021 16:00 – 17:00 (BST). >> >> >> >> Agenda: >> >> Discussion Session: Static and Dynamic Information Handling in TF-A >> >> Lead by Manish Pandey and Madhukar Pappireddy >> >> · There is ongoing mailing lists discussion[1] related with adopting a mechanism to pass information through boot stages. >> >> The requirement is two-fold: >> >> 1. Passing static information(config files) >> >> 2. Passing dynamic information (Hob list) >> >> In the upcoming TF-A tech forum, we can start with a discussion on dynamic information passing and if time permits, we can cover static information passing. The purpose of the call is to have an open discussion and continue the discussion from the trusted-substrate call[2] done earlier. We would like to understand the various requirements and possible ways to implement it in TF-A in a generalized way so that it can work with other Firmware projects. >> >> >> >> The two specific item which we would like to discuss are: >> >> 1. HOB format: TF-A/u-boot both has an existing bloblist implementation, which uses tag values. Question, can this be enhanced to use hybrid values(Tag and UUID) both? >> >> 2. Standardization on Physical register use to pass base of HoB data structure. >> >> References: >> >> [1] https://lists.trustedfirmware.org/pipermail/tf-a/2021-April/001069.html >> >> [2] https://linaro-org.zoom.us/rec/share/zjfHeMIumkJhirLCVQYTHR6ftaqyWvF_0klgQn… Passcode: IPn+5q% >> >> >> >> Thanks >> >> >> >> Joanna >> >> >> >> You have been invited to the following event. >> >> TF-A Tech Forum >> >> When >> >> Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time >> >> Calendar >> >> tf-a(a)lists.trustedfirmware.org >> >> Who >> >> • >> >> Bill Fletcher- creator >> >> • >> >> tf-a(a)lists.trustedfirmware.org >> >> more details » >> >> >> >> 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/ >> >> >> >> Trusted Firmware is inviting you to a scheduled Zoom meeting. >> >> >> >> Join Zoom Meeting >> >> https://zoom.us/j/9159704974 >> >> >> >> Meeting ID: 915 970 4974 >> >> >> >> One 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-free >> >> Meeting ID: 915 970 4974 >> >> Find your local number: https://zoom.us/u/ad27hc6t7h >> >> >> >> ________________________________ >> >> From: François Ozog <francois.ozog(a)linaro.org> >> Sent: 08 April 2021 16:50 >> To: Manish Pandey2 <Manish.Pandey2(a)arm.com> >> Cc: Simon Glass <sjg(a)chromium.org>; Julius Werner <jwerner(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 <tf-a(a)lists.trustedfirmware.org>; U-Boot Mailing List <u-boot(a)lists.denx.de>; 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 >> >> >> >> Hi >> >> >> >> here is the meeting recording: >> >> https://linaro-org.zoom.us/rec/share/zjfHeMIumkJhirLCVQYTHR6ftaqyWvF_0klgQn… Passcode: IPn+5q%z >> >> >> >> I am really sorry about the confusion related to the meeting time. I have now understood: the Collaborate portal uses a specific calendar which is tied to US/Chicago timezone while the actual Google Calendar is tied to Central Europe timezone. I am going to drop the Collaborate portal and use a shared Google calendar (it should be visible on the trusted-substrate.org page). >> >> >> >> I'll try to summarize what I learnt and highlight my view on what can be next steps in a future mail. >> >> >> >> Cheers >> >> >> >> FF >> >> >> >> On Thu, 8 Apr 2021 at 13:56, Manish Pandey2 via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: >> >> Hi, >> >> >> >> From TF-A project point of view, we prefer to use existing mechanism to pass parameters across boot stages using linked list of tagged elements (as suggested by Julius). It has support for both generic and SiP-specific tags. Having said that, it does not stop partners to introduce new mechanisms suitable for their usecase in platform port initially and later move to generic code if its suitable for other platforms. >> >> >> >> To start with, Ampere can introduce a platform specific implementation of memory tag(speed/NUMA topology etc) which can be evaluated and discussed for generalization in future. The tag will be populated in BL2 stage and can be forwarded to further stages(and to BL33) by passing the head of list pointer in one of the registers. Initially any register can be used but going forward a standardization will be needed. >> >> >> >> The U-boot bloblist mentioned by Simon is conceptually similar to what TF-A is using, if there is consensus of using bloblist/taglist then TF-A tag list may be enhanced to take best of both the implementations. >> >> >> >> One of the potential problems of having structure used in different projects is maintainability, this can be avoided by having a single copy of these structures in TF-A (kept inside "include/export" which intended to be used by other projects.) >> >> >> >> Regarding usage of either UUID or tag, I echo the sentiments of Simon and Julius to keep it simple and use tag values. >> >> >> >> Looking forward to having further discussions on zoom call today. >> >> >> >> Thanks >> >> Manish P >> >> >> >> ________________________________ >> >> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Julius Werner via TF-A <tf-a(a)lists.trustedfirmware.org> >> Sent: 25 March 2021 02:43 >> To: Simon Glass <sjg(a)chromium.org> >> Cc: Harb Abdulhamid OS <abdulhamid(a)os.amperecomputing.com>; Boot Architecture Mailman List <boot-architecture(a)lists.linaro.org>; tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; U-Boot Mailing List <u-boot(a)lists.denx.de>; 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 >> >> >> >> 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 – 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: >> >> “SoC” or “silicon” firmware – in TF-A this may map to BL1, BL2, BL31, and *possibly* one or more BL32 instances >> “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 - 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 +Paul Isaac's >> >> >> >> 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 zoom call 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, 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) 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 >> >> -- >> 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 -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 5 months

1
0
0 0

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

by Madhukar Pappireddy

Hi, I tried to summarize the discussions in the previous TF-A tech forum regarding the proposal to adopt Hand-off Blocks (HOBs) for passing information along the boot chain. I am certain I could not capture all suggestions/concerns brought up during the call. I apologize if I missed and/or misinterpreted any comments and would appreciate it if everyone could share their thoughts in response to this email thread. The idea is to share information to other boot phases: > Dynamic information: Created during runtime. Shared in the form of a chain of blobs(built as a linked list of C structure objects i.e., HOB list). > Static information: Known at compile time. Historically, shared through the use of Device Tree/ACPI tables Both the above requirements are common in many ecosystems and need to co-exist. There are broadly 3 problems to solve: 1. Format of HOB structures: It looks like the consensus is that we could use existing mechanisms for this (BL_AUX_PARAM in TF-A or bloblist in u-boot). 2. Identification of HOB list entries: There is a debate about whether tags would suffice or if the HOB list producer and consumer would depend on UUID/GUIDs for identifying a specific HOB structure. Another suggestion was to use a hybrid approach. Reserve a single tag ID for identifying/constructing a HOB structure that further leverages UUID based identifier. This way, the generic HOB list doesn't need to support UUIDs and can work with tags. 3. The design contract for the static interface between two boot phases: The problem at hand is whether to pass a pointer to a HOB list or a device tree blob through the general-purpose registers for configuration hand-off between two boot phases. Some proposals that came up: > Proposal 1: Always pass a pointer to the device tree blob through the GP register and capture the pointer to the HOB list as a property of a node that is uniquely identifiable by the downstream boot phase. This needs to define a device tree binding such that producer and consumer agree on the information passed. > Proposal 2: Pass a pointer to a generic container through the GP register that can be interpreted appropriately by both boot loaders(i.e., producer and consumer of the boot info). This container can either be a dtb or a HOB list which can be simply inferred by checking for a magic header that indicates if the buffer appears to be a flattened device tree. > One another concern that was brought up offline is to make sure we don't break current design contracts between various boot loader phases in TF-A. Many of the general-purpose registers have a designated purpose such as to share configurations between BL images( such as firmware config dtb, SoC config dtb, Non trusted firmware config dtb, memory layout, entry point info, etc.). If I am not mistaken, a single design may not fit the needs of every segment(client, Infra, embedded) and the forum is open to solutions tailored for individual segments. Joanna will be sending a follow up email with more information about future TF-A tech forums that serves as a platform for further discussions. Thanks, Madhukar -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Joanna Farley via TF-A Sent: Sunday, May 16, 2021 5:19 AM To: Okash Khawaja <okash.khawaja(a)gmail.com>; Simon Glass <sjg(a)chromium.org> Cc: Harb Abdulhamid OS <abdulhamid(a)os.amperecomputing.com>; Boot Architecture Mailman List <boot-architecture(a)lists.linaro.org>; tf-a(a)lists.trustedfirmware.org; Ed Stuber <edstuber(a)amperecomputing.com>; Arjun Khare <akhare(a)amperecomputing.com>; U-Boot Mailing List <u-boot(a)lists.denx.de>; Paul Isaac's <paul.isaacs(a)linaro.org>; Ron Minnich <rminnich(a)google.com>; Moe Ammar <moe(a)amperecomputing.com> Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages Apologies I failed with the recording. Manish/Madhu will reply early next week with the slides and some notes to help with a follow up session which we hope to hold this Thursday. Invite and agenda will also be sent out early next week. Thanks Joanna On 14/05/2021, 13:30, "TF-A on behalf of Okash Khawaja via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi, Do we have slides and video from last week's discussion? Thanks, Okash On Wed, May 5, 2021 at 11:52 PM Simon Glass via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Harb, > > Thanks for the idea. I am still not completely sure what benefit UUID provides to an open project. I'd like to propose something different, more in the spirit of open collaboration. I also worry that the word 'standard' seems to be a synonym for UUIDs, UEFI, etc., i.e. enabling/preferring closed-source firmware and the continued decline of open-source projects. It really should not be. > > So I suggest: Use simple integer IDs and reserve some area for 'private' use. If you want to collaborate across projects outside your company, you either need to allocate a 'public' ID or agree privately between the parties which private ID to use. > > This means that the default and easiest option is for collaboration and a public ID, with private ones (whose purpose may be secret) reserved just for private use. > > Regards, > Simon > > On Wed, 5 May 2021 at 11:42, Harb Abdulhamid OS <abdulhamid(a)os.amperecomputing.com> wrote: >> >> Hey Folks, >> >> We wanted to put out a middle-ground proposal to help guide the discussion on the call tomorrow. >> >> >> >> A proposal that we have been discussing offline involves reserving a single tag ID for the purpose of construction UEFI PI HOB List structure, and that tag would be used to identify a HOB-specific structure that does leverage UUID based identifier. This will eliminate the burden of having to support UUID as the tag, and this enables projects that require UUID based identifiers for the broad range of HOB structures that need to be produced during the booting of the platform. Once we have a tag for a HOB list, this will enable various HOB producers that can add/extend the HOB list in TF-A code (or even pre-TF-A code), with a HOB consumer for that UUID/GUID on the other side (i.e. whatever the BL33 image is booting on that platform). >> >> >> >> Essentially, the idea is if someone would like to support HOB structures in a standard way using TF-A, they would wrap it up in a BL_AUX_PARAM/BLOB structure (whatever the group decides) and the way we identify the structure as a HOB list is with this new reserved tag. >> >> >> >> Hopefully that makes sense and less contentious. Look forward to discuss this further on the call. >> >> >> >> Thanks, >> >> --Harb >> >> >> >> From: Manish Pandey2 <Manish.Pandey2(a)arm.com> >> Sent: Friday, April 30, 2021 8:14 AM >> To: François Ozog <francois.ozog(a)linaro.org> >> Cc: Simon Glass <sjg(a)chromium.org>; Julius Werner <jwerner(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; U-Boot Mailing List <u-boot(a)lists.denx.de>; 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 >> >> >> >> Hi All, >> >> >> >> Please find invite for next TF-A Tech Forum session to continue our discussions on HOB implementation, feel free to forward it to others. >> >> >> >> The next TF-A Tech Forum is scheduled for Thu 6th May 2021 16:00 – 17:00 (BST). >> >> >> >> Agenda: >> >> Discussion Session: Static and Dynamic Information Handling in TF-A >> >> Lead by Manish Pandey and Madhukar Pappireddy >> >> · There is ongoing mailing lists discussion[1] related with adopting a mechanism to pass information through boot stages. >> >> The requirement is two-fold: >> >> 1. Passing static information(config files) >> >> 2. Passing dynamic information (Hob list) >> >> In the upcoming TF-A tech forum, we can start with a discussion on dynamic information passing and if time permits, we can cover static information passing. The purpose of the call is to have an open discussion and continue the discussion from the trusted-substrate call[2] done earlier. We would like to understand the various requirements and possible ways to implement it in TF-A in a generalized way so that it can work with other Firmware projects. >> >> >> >> The two specific item which we would like to discuss are: >> >> 1. HOB format: TF-A/u-boot both has an existing bloblist implementation, which uses tag values. Question, can this be enhanced to use hybrid values(Tag and UUID) both? >> >> 2. Standardization on Physical register use to pass base of HoB data structure. >> >> References: >> >> [1] https://lists.trustedfirmware.org/pipermail/tf-a/2021-April/001069.html >> >> [2] https://linaro-org.zoom.us/rec/share/zjfHeMIumkJhirLCVQYTHR6ftaqyWvF_0klgQn… Passcode: IPn+5q% >> >> >> >> Thanks >> >> >> >> Joanna >> >> >> >> You have been invited to the following event. >> >> TF-A Tech Forum >> >> When >> >> Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time >> >> Calendar >> >> tf-a(a)lists.trustedfirmware.org >> >> Who >> >> • >> >> Bill Fletcher- creator >> >> • >> >> tf-a(a)lists.trustedfirmware.org >> >> more details » >> >> >> >> 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/ >> >> >> >> Trusted Firmware is inviting you to a scheduled Zoom meeting. >> >> >> >> Join Zoom Meeting >> >> https://zoom.us/j/9159704974 >> >> >> >> Meeting ID: 915 970 4974 >> >> >> >> One 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-free >> >> Meeting ID: 915 970 4974 >> >> Find your local number: https://zoom.us/u/ad27hc6t7h >> >> >> >> ________________________________ >> >> From: François Ozog <francois.ozog(a)linaro.org> >> Sent: 08 April 2021 16:50 >> To: Manish Pandey2 <Manish.Pandey2(a)arm.com> >> Cc: Simon Glass <sjg(a)chromium.org>; Julius Werner <jwerner(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 <tf-a(a)lists.trustedfirmware.org>; U-Boot Mailing List <u-boot(a)lists.denx.de>; 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 >> >> >> >> Hi >> >> >> >> here is the meeting recording: >> >> https://linaro-org.zoom.us/rec/share/zjfHeMIumkJhirLCVQYTHR6ftaqyWvF_0klgQn… Passcode: IPn+5q%z >> >> >> >> I am really sorry about the confusion related to the meeting time. I have now understood: the Collaborate portal uses a specific calendar which is tied to US/Chicago timezone while the actual Google Calendar is tied to Central Europe timezone. I am going to drop the Collaborate portal and use a shared Google calendar (it should be visible on the trusted-substrate.org page). >> >> >> >> I'll try to summarize what I learnt and highlight my view on what can be next steps in a future mail. >> >> >> >> Cheers >> >> >> >> FF >> >> >> >> On Thu, 8 Apr 2021 at 13:56, Manish Pandey2 via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: >> >> Hi, >> >> >> >> From TF-A project point of view, we prefer to use existing mechanism to pass parameters across boot stages using linked list of tagged elements (as suggested by Julius). It has support for both generic and SiP-specific tags. Having said that, it does not stop partners to introduce new mechanisms suitable for their usecase in platform port initially and later move to generic code if its suitable for other platforms. >> >> >> >> To start with, Ampere can introduce a platform specific implementation of memory tag(speed/NUMA topology etc) which can be evaluated and discussed for generalization in future. The tag will be populated in BL2 stage and can be forwarded to further stages(and to BL33) by passing the head of list pointer in one of the registers. Initially any register can be used but going forward a standardization will be needed. >> >> >> >> The U-boot bloblist mentioned by Simon is conceptually similar to what TF-A is using, if there is consensus of using bloblist/taglist then TF-A tag list may be enhanced to take best of both the implementations. >> >> >> >> One of the potential problems of having structure used in different projects is maintainability, this can be avoided by having a single copy of these structures in TF-A (kept inside "include/export" which intended to be used by other projects.) >> >> >> >> Regarding usage of either UUID or tag, I echo the sentiments of Simon and Julius to keep it simple and use tag values. >> >> >> >> Looking forward to having further discussions on zoom call today. >> >> >> >> Thanks >> >> Manish P >> >> >> >> ________________________________ >> >> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Julius Werner via TF-A <tf-a(a)lists.trustedfirmware.org> >> Sent: 25 March 2021 02:43 >> To: Simon Glass <sjg(a)chromium.org> >> Cc: Harb Abdulhamid OS <abdulhamid(a)os.amperecomputing.com>; Boot Architecture Mailman List <boot-architecture(a)lists.linaro.org>; tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; U-Boot Mailing List <u-boot(a)lists.denx.de>; 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 >> >> >> >> 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 – 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: >> >> “SoC” or “silicon” firmware – in TF-A this may map to BL1, BL2, BL31, and *possibly* one or more BL32 instances >> “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 - 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 +Paul Isaac's >> >> >> >> 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 zoom call 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, 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) 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 >> >> -- >> 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 -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 5 months

1
0
0 0

[PATCH v1] imx8mp: silent uart

by Heiko Schocher

when bootloaders and kernels console output is disabled, (called silent boot) no output on console is recommended. Add commandline option IMX_BOOT_SILENT to disable console registration at all. Default value is 0, so patch does not change current functionality. Signed-off-by: Heiko Schocher <hs(a)denx.de> --- I just added this to imx8mp, but may this option is useful on other platforms too? plat/imx/imx8m/imx8mp/imx8mp_bl31_setup.c | 4 ++++ plat/imx/imx8m/imx8mp/platform.mk | 3 +++ 2 files changed, 7 insertions(+) diff --git a/plat/imx/imx8m/imx8mp/imx8mp_bl31_setup.c b/plat/imx/imx8m/imx8mp/imx8mp_bl31_setup.c index 22fbd5e4b..d75143270 100644 --- a/plat/imx/imx8m/imx8mp/imx8mp_bl31_setup.c +++ b/plat/imx/imx8m/imx8mp/imx8mp_bl31_setup.c @@ -95,7 +95,9 @@ static void bl31_tzc380_setup(void) void bl31_early_platform_setup2(u_register_t arg0, u_register_t arg1, u_register_t arg2, u_register_t arg3) { +#if (IMX_BOOT_SILENT == 0) static console_t console; +#endif unsigned int i; /* Enable CSU NS access permission */ @@ -109,10 +111,12 @@ void bl31_early_platform_setup2(u_register_t arg0, u_register_t arg1, imx8m_caam_init(); +#if (IMX_BOOT_SILENT == 0) console_imx_uart_register(IMX_BOOT_UART_BASE, IMX_BOOT_UART_CLK_IN_HZ, IMX_CONSOLE_BAUDRATE, &console); /* This console is only used for boot stage */ console_set_scope(&console, CONSOLE_FLAG_BOOT); +#endif /* * tell BL3-1 where the non-secure software image is located diff --git a/plat/imx/imx8m/imx8mp/platform.mk b/plat/imx/imx8m/imx8mp/platform.mk index 1d11e3df4..471c96e70 100644 --- a/plat/imx/imx8m/imx8mp/platform.mk +++ b/plat/imx/imx8m/imx8mp/platform.mk @@ -54,3 +54,6 @@ $(eval $(call add_define,BL32_SIZE)) IMX_BOOT_UART_BASE ?= 0x30890000 $(eval $(call add_define,IMX_BOOT_UART_BASE)) + +IMX_BOOT_SILENT ?= 0 +$(eval $(call add_define,IMX_BOOT_SILENT)) -- 2.30.2

4 years, 5 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

Apologies I failed with the recording. Manish/Madhu will reply early next week with the slides and some notes to help with a follow up session which we hope to hold this Thursday. Invite and agenda will also be sent out early next week. Thanks Joanna On 14/05/2021, 13:30, "TF-A on behalf of Okash Khawaja via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi, Do we have slides and video from last week's discussion? Thanks, Okash On Wed, May 5, 2021 at 11:52 PM Simon Glass via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Harb, > > Thanks for the idea. I am still not completely sure what benefit UUID provides to an open project. I'd like to propose something different, more in the spirit of open collaboration. I also worry that the word 'standard' seems to be a synonym for UUIDs, UEFI, etc., i.e. enabling/preferring closed-source firmware and the continued decline of open-source projects. It really should not be. > > So I suggest: Use simple integer IDs and reserve some area for 'private' use. If you want to collaborate across projects outside your company, you either need to allocate a 'public' ID or agree privately between the parties which private ID to use. > > This means that the default and easiest option is for collaboration and a public ID, with private ones (whose purpose may be secret) reserved just for private use. > > Regards, > Simon > > On Wed, 5 May 2021 at 11:42, Harb Abdulhamid OS <abdulhamid(a)os.amperecomputing.com> wrote: >> >> Hey Folks, >> >> We wanted to put out a middle-ground proposal to help guide the discussion on the call tomorrow. >> >> >> >> A proposal that we have been discussing offline involves reserving a single tag ID for the purpose of construction UEFI PI HOB List structure, and that tag would be used to identify a HOB-specific structure that does leverage UUID based identifier. This will eliminate the burden of having to support UUID as the tag, and this enables projects that require UUID based identifiers for the broad range of HOB structures that need to be produced during the booting of the platform. Once we have a tag for a HOB list, this will enable various HOB producers that can add/extend the HOB list in TF-A code (or even pre-TF-A code), with a HOB consumer for that UUID/GUID on the other side (i.e. whatever the BL33 image is booting on that platform). >> >> >> >> Essentially, the idea is if someone would like to support HOB structures in a standard way using TF-A, they would wrap it up in a BL_AUX_PARAM/BLOB structure (whatever the group decides) and the way we identify the structure as a HOB list is with this new reserved tag. >> >> >> >> Hopefully that makes sense and less contentious. Look forward to discuss this further on the call. >> >> >> >> Thanks, >> >> --Harb >> >> >> >> From: Manish Pandey2 <Manish.Pandey2(a)arm.com> >> Sent: Friday, April 30, 2021 8:14 AM >> To: François Ozog <francois.ozog(a)linaro.org> >> Cc: Simon Glass <sjg(a)chromium.org>; Julius Werner <jwerner(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; U-Boot Mailing List <u-boot(a)lists.denx.de>; 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 >> >> >> >> Hi All, >> >> >> >> Please find invite for next TF-A Tech Forum session to continue our discussions on HOB implementation, feel free to forward it to others. >> >> >> >> The next TF-A Tech Forum is scheduled for Thu 6th May 2021 16:00 – 17:00 (BST). >> >> >> >> Agenda: >> >> Discussion Session: Static and Dynamic Information Handling in TF-A >> >> Lead by Manish Pandey and Madhukar Pappireddy >> >> · There is ongoing mailing lists discussion[1] related with adopting a mechanism to pass information through boot stages. >> >> The requirement is two-fold: >> >> 1. Passing static information(config files) >> >> 2. Passing dynamic information (Hob list) >> >> In the upcoming TF-A tech forum, we can start with a discussion on dynamic information passing and if time permits, we can cover static information passing. The purpose of the call is to have an open discussion and continue the discussion from the trusted-substrate call[2] done earlier. We would like to understand the various requirements and possible ways to implement it in TF-A in a generalized way so that it can work with other Firmware projects. >> >> >> >> The two specific item which we would like to discuss are: >> >> 1. HOB format: TF-A/u-boot both has an existing bloblist implementation, which uses tag values. Question, can this be enhanced to use hybrid values(Tag and UUID) both? >> >> 2. Standardization on Physical register use to pass base of HoB data structure. >> >> References: >> >> [1] https://lists.trustedfirmware.org/pipermail/tf-a/2021-April/001069.html >> >> [2] https://linaro-org.zoom.us/rec/share/zjfHeMIumkJhirLCVQYTHR6ftaqyWvF_0klgQn… Passcode: IPn+5q% >> >> >> >> Thanks >> >> >> >> Joanna >> >> >> >> You have been invited to the following event. >> >> TF-A Tech Forum >> >> When >> >> Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time >> >> Calendar >> >> tf-a(a)lists.trustedfirmware.org >> >> Who >> >> • >> >> Bill Fletcher- creator >> >> • >> >> tf-a(a)lists.trustedfirmware.org >> >> more details » >> >> >> >> 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/ >> >> >> >> Trusted Firmware is inviting you to a scheduled Zoom meeting. >> >> >> >> Join Zoom Meeting >> >> https://zoom.us/j/9159704974 >> >> >> >> Meeting ID: 915 970 4974 >> >> >> >> One 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-free >> >> Meeting ID: 915 970 4974 >> >> Find your local number: https://zoom.us/u/ad27hc6t7h >> >> >> >> ________________________________ >> >> From: François Ozog <francois.ozog(a)linaro.org> >> Sent: 08 April 2021 16:50 >> To: Manish Pandey2 <Manish.Pandey2(a)arm.com> >> Cc: Simon Glass <sjg(a)chromium.org>; Julius Werner <jwerner(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 <tf-a(a)lists.trustedfirmware.org>; U-Boot Mailing List <u-boot(a)lists.denx.de>; 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 >> >> >> >> Hi >> >> >> >> here is the meeting recording: >> >> https://linaro-org.zoom.us/rec/share/zjfHeMIumkJhirLCVQYTHR6ftaqyWvF_0klgQn… Passcode: IPn+5q%z >> >> >> >> I am really sorry about the confusion related to the meeting time. I have now understood: the Collaborate portal uses a specific calendar which is tied to US/Chicago timezone while the actual Google Calendar is tied to Central Europe timezone. I am going to drop the Collaborate portal and use a shared Google calendar (it should be visible on the trusted-substrate.org page). >> >> >> >> I'll try to summarize what I learnt and highlight my view on what can be next steps in a future mail. >> >> >> >> Cheers >> >> >> >> FF >> >> >> >> On Thu, 8 Apr 2021 at 13:56, Manish Pandey2 via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: >> >> Hi, >> >> >> >> From TF-A project point of view, we prefer to use existing mechanism to pass parameters across boot stages using linked list of tagged elements (as suggested by Julius). It has support for both generic and SiP-specific tags. Having said that, it does not stop partners to introduce new mechanisms suitable for their usecase in platform port initially and later move to generic code if its suitable for other platforms. >> >> >> >> To start with, Ampere can introduce a platform specific implementation of memory tag(speed/NUMA topology etc) which can be evaluated and discussed for generalization in future. The tag will be populated in BL2 stage and can be forwarded to further stages(and to BL33) by passing the head of list pointer in one of the registers. Initially any register can be used but going forward a standardization will be needed. >> >> >> >> The U-boot bloblist mentioned by Simon is conceptually similar to what TF-A is using, if there is consensus of using bloblist/taglist then TF-A tag list may be enhanced to take best of both the implementations. >> >> >> >> One of the potential problems of having structure used in different projects is maintainability, this can be avoided by having a single copy of these structures in TF-A (kept inside "include/export" which intended to be used by other projects.) >> >> >> >> Regarding usage of either UUID or tag, I echo the sentiments of Simon and Julius to keep it simple and use tag values. >> >> >> >> Looking forward to having further discussions on zoom call today. >> >> >> >> Thanks >> >> Manish P >> >> >> >> ________________________________ >> >> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Julius Werner via TF-A <tf-a(a)lists.trustedfirmware.org> >> Sent: 25 March 2021 02:43 >> To: Simon Glass <sjg(a)chromium.org> >> Cc: Harb Abdulhamid OS <abdulhamid(a)os.amperecomputing.com>; Boot Architecture Mailman List <boot-architecture(a)lists.linaro.org>; tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; U-Boot Mailing List <u-boot(a)lists.denx.de>; 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 >> >> >> >> 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 – 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: >> >> “SoC” or “silicon” firmware – in TF-A this may map to BL1, BL2, BL31, and *possibly* one or more BL32 instances >> “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 - 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 +Paul Isaac's >> >> >> >> 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 zoom call 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, 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) 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 >> >> -- >> 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 -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 5 months

1
0
0 0

Re: [TF-A] MEM_PROTECT for secure world?

by Varun Wadekar

Hi Okash, My understanding is that the NS world must call PSCI_MEM_PROTECT_CHECK_RANGE and PSCI_MEM_PROTECT before passing the buffer to the S world. So, I believe the check in the code is correct. The spec guarantees that the memory range passed with this SMC will be cleared before executing a system reset. This statement from the spec is confusing - " When MEM_PROTECT is called, the implementation must ensure that all volatile memory that is accessible by the caller is overwritten on the following boot". How can the implementation know the memory accessible by the caller in the first place? I feel this creates an unwanted dependency - EL3 needs to understand memory requirements for all NS clients. I would like to believe that the implementation is only aware of a memory range registered by a caller via the MEM_PROTECT SMC call and so clears only this range before a system reset. -Varun -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Okash Khawaja via TF-A Sent: Wednesday, May 5, 2021 5:10 PM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] MEM_PROTECT for secure world? External email: Use caution opening links or attachments Hi, As a PSCI call, MEM_PROTECT which is used to protect against cold reboot attack, can't be called from TZ-secure. In a situation where at run time, HLOS in NS-EL1 transfers some buffer that it owns, to a secure partition then secure partition can't call MEM_PROTECT because psci_smc_handler will return SMC_UNK if the caller is secure. Should MEM_PROTECT be available to TZ-secure as well? Thanks, Okash -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

4 years, 5 months

2
3
0 0

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

by Okash Khawaja

Hi, Do we have slides and video from last week's discussion? Thanks, Okash On Wed, May 5, 2021 at 11:52 PM Simon Glass via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Harb, > > Thanks for the idea. I am still not completely sure what benefit UUID provides to an open project. I'd like to propose something different, more in the spirit of open collaboration. I also worry that the word 'standard' seems to be a synonym for UUIDs, UEFI, etc., i.e. enabling/preferring closed-source firmware and the continued decline of open-source projects. It really should not be. > > So I suggest: Use simple integer IDs and reserve some area for 'private' use. If you want to collaborate across projects outside your company, you either need to allocate a 'public' ID or agree privately between the parties which private ID to use. > > This means that the default and easiest option is for collaboration and a public ID, with private ones (whose purpose may be secret) reserved just for private use. > > Regards, > Simon > > On Wed, 5 May 2021 at 11:42, Harb Abdulhamid OS <abdulhamid(a)os.amperecomputing.com> wrote: >> >> Hey Folks, >> >> We wanted to put out a middle-ground proposal to help guide the discussion on the call tomorrow. >> >> >> >> A proposal that we have been discussing offline involves reserving a single tag ID for the purpose of construction UEFI PI HOB List structure, and that tag would be used to identify a HOB-specific structure that does leverage UUID based identifier. This will eliminate the burden of having to support UUID as the tag, and this enables projects that require UUID based identifiers for the broad range of HOB structures that need to be produced during the booting of the platform. Once we have a tag for a HOB list, this will enable various HOB producers that can add/extend the HOB list in TF-A code (or even pre-TF-A code), with a HOB consumer for that UUID/GUID on the other side (i.e. whatever the BL33 image is booting on that platform). >> >> >> >> Essentially, the idea is if someone would like to support HOB structures in a standard way using TF-A, they would wrap it up in a BL_AUX_PARAM/BLOB structure (whatever the group decides) and the way we identify the structure as a HOB list is with this new reserved tag. >> >> >> >> Hopefully that makes sense and less contentious. Look forward to discuss this further on the call. >> >> >> >> Thanks, >> >> --Harb >> >> >> >> From: Manish Pandey2 <Manish.Pandey2(a)arm.com> >> Sent: Friday, April 30, 2021 8:14 AM >> To: François Ozog <francois.ozog(a)linaro.org> >> Cc: Simon Glass <sjg(a)chromium.org>; Julius Werner <jwerner(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; U-Boot Mailing List <u-boot(a)lists.denx.de>; 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 >> >> >> >> Hi All, >> >> >> >> Please find invite for next TF-A Tech Forum session to continue our discussions on HOB implementation, feel free to forward it to others. >> >> >> >> The next TF-A Tech Forum is scheduled for Thu 6th May 2021 16:00 – 17:00 (BST). >> >> >> >> Agenda: >> >> Discussion Session: Static and Dynamic Information Handling in TF-A >> >> Lead by Manish Pandey and Madhukar Pappireddy >> >> · There is ongoing mailing lists discussion[1] related with adopting a mechanism to pass information through boot stages. >> >> The requirement is two-fold: >> >> 1. Passing static information(config files) >> >> 2. Passing dynamic information (Hob list) >> >> In the upcoming TF-A tech forum, we can start with a discussion on dynamic information passing and if time permits, we can cover static information passing. The purpose of the call is to have an open discussion and continue the discussion from the trusted-substrate call[2] done earlier. We would like to understand the various requirements and possible ways to implement it in TF-A in a generalized way so that it can work with other Firmware projects. >> >> >> >> The two specific item which we would like to discuss are: >> >> 1. HOB format: TF-A/u-boot both has an existing bloblist implementation, which uses tag values. Question, can this be enhanced to use hybrid values(Tag and UUID) both? >> >> 2. Standardization on Physical register use to pass base of HoB data structure. >> >> References: >> >> [1] https://lists.trustedfirmware.org/pipermail/tf-a/2021-April/001069.html >> >> [2] https://linaro-org.zoom.us/rec/share/zjfHeMIumkJhirLCVQYTHR6ftaqyWvF_0klgQn… Passcode: IPn+5q% >> >> >> >> Thanks >> >> >> >> Joanna >> >> >> >> You have been invited to the following event. >> >> TF-A Tech Forum >> >> When >> >> Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time >> >> Calendar >> >> tf-a(a)lists.trustedfirmware.org >> >> Who >> >> • >> >> Bill Fletcher- creator >> >> • >> >> tf-a(a)lists.trustedfirmware.org >> >> more details » >> >> >> >> 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/ >> >> >> >> Trusted Firmware is inviting you to a scheduled Zoom meeting. >> >> >> >> Join Zoom Meeting >> >> https://zoom.us/j/9159704974 >> >> >> >> Meeting ID: 915 970 4974 >> >> >> >> One 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-free >> >> Meeting ID: 915 970 4974 >> >> Find your local number: https://zoom.us/u/ad27hc6t7h >> >> >> >> ________________________________ >> >> From: François Ozog <francois.ozog(a)linaro.org> >> Sent: 08 April 2021 16:50 >> To: Manish Pandey2 <Manish.Pandey2(a)arm.com> >> Cc: Simon Glass <sjg(a)chromium.org>; Julius Werner <jwerner(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 <tf-a(a)lists.trustedfirmware.org>; U-Boot Mailing List <u-boot(a)lists.denx.de>; 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 >> >> >> >> Hi >> >> >> >> here is the meeting recording: >> >> https://linaro-org.zoom.us/rec/share/zjfHeMIumkJhirLCVQYTHR6ftaqyWvF_0klgQn… Passcode: IPn+5q%z >> >> >> >> I am really sorry about the confusion related to the meeting time. I have now understood: the Collaborate portal uses a specific calendar which is tied to US/Chicago timezone while the actual Google Calendar is tied to Central Europe timezone. I am going to drop the Collaborate portal and use a shared Google calendar (it should be visible on the trusted-substrate.org page). >> >> >> >> I'll try to summarize what I learnt and highlight my view on what can be next steps in a future mail. >> >> >> >> Cheers >> >> >> >> FF >> >> >> >> On Thu, 8 Apr 2021 at 13:56, Manish Pandey2 via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: >> >> Hi, >> >> >> >> From TF-A project point of view, we prefer to use existing mechanism to pass parameters across boot stages using linked list of tagged elements (as suggested by Julius). It has support for both generic and SiP-specific tags. Having said that, it does not stop partners to introduce new mechanisms suitable for their usecase in platform port initially and later move to generic code if its suitable for other platforms. >> >> >> >> To start with, Ampere can introduce a platform specific implementation of memory tag(speed/NUMA topology etc) which can be evaluated and discussed for generalization in future. The tag will be populated in BL2 stage and can be forwarded to further stages(and to BL33) by passing the head of list pointer in one of the registers. Initially any register can be used but going forward a standardization will be needed. >> >> >> >> The U-boot bloblist mentioned by Simon is conceptually similar to what TF-A is using, if there is consensus of using bloblist/taglist then TF-A tag list may be enhanced to take best of both the implementations. >> >> >> >> One of the potential problems of having structure used in different projects is maintainability, this can be avoided by having a single copy of these structures in TF-A (kept inside "include/export" which intended to be used by other projects.) >> >> >> >> Regarding usage of either UUID or tag, I echo the sentiments of Simon and Julius to keep it simple and use tag values. >> >> >> >> Looking forward to having further discussions on zoom call today. >> >> >> >> Thanks >> >> Manish P >> >> >> >> ________________________________ >> >> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Julius Werner via TF-A <tf-a(a)lists.trustedfirmware.org> >> Sent: 25 March 2021 02:43 >> To: Simon Glass <sjg(a)chromium.org> >> Cc: Harb Abdulhamid OS <abdulhamid(a)os.amperecomputing.com>; Boot Architecture Mailman List <boot-architecture(a)lists.linaro.org>; tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; U-Boot Mailing List <u-boot(a)lists.denx.de>; 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 >> >> >> >> 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 – 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: >> >> “SoC” or “silicon” firmware – in TF-A this may map to BL1, BL2, BL31, and *possibly* one or more BL32 instances >> “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 - 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 +Paul Isaac's >> >> >> >> 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 zoom call 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, 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) 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 >> >> -- >> 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, 5 months

1
0
0 0

Re: [TF-A] MEM_PROTECT for secure world?

by raghu.ncstate＠icloud.com

If I understand the cold boot attack correctly for the normal world, it is that we boot a NWd OS once, make it decrypt all its secrets into DRAM, pull the power and quickly boot to another OS and read contents of DRAM before the data decays, to extract secrets of the old OS using the new OS. While this can apply to secure world, It might be a safe assumption that we cannot boot arbitrary, unsigned TZ code and trusted OS's on an ARM system in the last few years due to use of CoT, Rollback protection etc. As a general rule of thumb, early boot code should probably be scrubbing secure DRAM anyway, I think, to prevent this attack, in which case the way to do the cold boot attack would be through a run time attack on TZ code. Thanks Raghu -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Okash Khawaja via TF-A Sent: Wednesday, May 5, 2021 9:10 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] MEM_PROTECT for secure world? Hi, As a PSCI call, MEM_PROTECT which is used to protect against cold reboot attack, can't be called from TZ-secure. In a situation where at run time, HLOS in NS-EL1 transfers some buffer that it owns, to a secure partition then secure partition can't call MEM_PROTECT because psci_smc_handler will return SMC_UNK if the caller is secure. Should MEM_PROTECT be available to TZ-secure as well? Thanks, Okash -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 5 months

2
5
0 0

Re: [TF-A] Stack Protector for platforms not implementing plat_get_stack_protector_canary

by raghu.ncstate＠icloud.com

Adding tf-a list again. -----Original Message----- From: raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com> Sent: Thursday, May 13, 2021 9:33 AM To: 'Heiko Thiery' <heiko.thiery(a)gmail.com>; 'tf-a-bounces(a)lists.trustedfirmware.org' <tf-a-bounces(a)lists.trustedfirmware.org> Subject: RE: [TF-A] Stack Protector for platforms not implementing plat_get_stack_protector_canary Right. The point I was trying to make is the same as the comment in the C file says "this is better than nothing but not necessarily really secure". I'm just saying SSP without truly random stack canary in an open source project is as good as not having SSP 😊 >From an TF-A point of view, I think we want to encourage folks to include TRNG's on their platform and we should not provide an insecure default implementation, since people may assume security properties about it if they don’t look closely enough. Thanks Raghu -----Original Message----- From: Heiko Thiery <heiko.thiery(a)gmail.com> Sent: Thursday, May 13, 2021 8:57 AM To: raghu.ncstate(a)icloud.com; tf-a-bounces(a)lists.trustedfirmware.org Subject: Re: [TF-A] Stack Protector for platforms not implementing plat_get_stack_protector_canary Hi, Am Do., 13. Mai 2021 um 17:13 Uhr schrieb <raghu.ncstate(a)icloud.com>: > > Without a RNG, implementing a generic function as you have mentioned below would mean returning a constant value or random numbers that are not cryptographically secure for the stack canary. Neither of those options will really provide any security benefit. In absence of a TRNG or secret seed that can be used to generate secure random numbers, I think turning off SSP is not that much worse than returning bad values. But as you can read in the comments of some implementations, it is better to return a pseudo value than none at all. Or am I wrong there? And assuming that this is true, it would be good to have an implementation for all those who don't use TRNG like the ones at https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/rockc…. > > A quick google search tells me that imx8m may have a random number generator so the platform code may need to hook up tf-a platform port to the random number. > > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Heiko > Thiery via TF-A > Sent: Thursday, May 13, 2021 12:34 AM > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] Stack Protector for platforms not implementing > plat_get_stack_protector_canary > > Hi all, > > I recently encountered a build issue with the imx8m platform. > Buildroot will set the SSP (Stack Smashing Protection) option to on by > default in the next release. This option also turns on the > ENABLE_STACK_PROTECTOR in the ATF. But since the > plat_get_stack_protector_canary() function is not implemented for the > imx8m for example, the build fails for this platform. My question now > is: could you implement a generic function like it is implemented for some platforms that don't have a real RNG? Or is there a concern here? > > I must admit that I have no experience with ATF other than building and deploying it. > > Thanks > -- > Heiko > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > Thanks -- Heiko

4 years, 5 months

2
3
0 0

Re: [TF-A] Lost gerrit email notifications

by Joanna Farley

Hi Raghu, That’s should have been corrected as there was a fault on trustedfirmware.org servers which was fixed overnight as I was also missing notifications but they have started to come through now. Joanna From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Raghu Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org> Reply to: "raghu.ncstate(a)icloud.com" <raghu.ncstate(a)icloud.com> Date: Thursday, 13 May 2021 at 15:47 To: "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Lost gerrit email notifications Hi All, I seem to have lost email notification of comments on gerrit reviews. I’ve checked my gerrit settings and reset the settings to enable notifications but I cant seem to get notifications from gerrit. Is this something others are seeing as well? Thanks Raghu

4 years, 5 months

2
1
0 0

Lost gerrit email notifications

by raghu.ncstate＠icloud.com

Hi All, I seem to have lost email notification of comments on gerrit reviews. I've checked my gerrit settings and reset the settings to enable notifications but I cant seem to get notifications from gerrit. Is this something others are seeing as well? Thanks Raghu

4 years, 5 months

1
0
0 0

Stack Protector for platforms not implementing plat_get_stack_protector_canary

by Heiko Thiery

Hi all, I recently encountered a build issue with the imx8m platform. Buildroot will set the SSP (Stack Smashing Protection) option to on by default in the next release. This option also turns on the ENABLE_STACK_PROTECTOR in the ATF. But since the plat_get_stack_protector_canary() function is not implemented for the imx8m for example, the build fails for this platform. My question now is: could you implement a generic function like it is implemented for some platforms that don't have a real RNG? Or is there a concern here? I must admit that I have no experience with ATF other than building and deploying it. Thanks -- Heiko

4 years, 5 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

Hi here is the meeting recording: https://linaro-org.zoom.us/rec/share/zjfHeMIumkJhirLCVQYTHR6ftaqyWvF_0klgQn… Passcode: IPn+5q%z I am really sorry about the confusion related to the meeting time. I have now understood: the Collaborate portal uses a specific calendar which is tied to US/Chicago timezone while the actual Google Calendar is tied to Central Europe timezone. I am going to drop the Collaborate portal and use a shared Google calendar (it should be visible on the trusted-substrate.org page). I'll try to summarize what I learnt and highlight my view on what can be next steps in a future mail. Cheers FF On Thu, 8 Apr 2021 at 13:56, Manish Pandey2 via TF-A < tf-a(a)lists.trustedfirmware.org> wrote: > Hi, > > From TF-A project point of view, we prefer to use existing mechanism to > pass parameters across boot stages using linked list of tagged elements (as > suggested by Julius). It has support for both generic and SiP-specific > tags. Having said that, it does not stop partners to introduce new > mechanisms suitable for their usecase in platform port initially and later > move to generic code if its suitable for other platforms. > > To start with, Ampere can introduce a platform specific implementation of > memory tag(speed/NUMA topology etc) which can be evaluated and discussed > for generalization in future. The tag will be populated in BL2 stage and > can be forwarded to further stages(and to BL33) by passing the head of list > pointer in one of the registers. Initially any register can be used but > going forward a standardization will be needed. > > The U-boot bloblist mentioned by Simon is conceptually similar to what > TF-A is using, if there is consensus of using bloblist/taglist then TF-A > tag list may be enhanced to take best of both the implementations. > > One of the potential problems of having structure used in different > projects is maintainability, this can be avoided by having a single copy of > these structures in TF-A (kept inside "include/export" which intended to be > used by other projects.) > > Regarding usage of either UUID or tag, I echo the sentiments of Simon and > Julius to keep it simple and use tag values. > > Looking forward to having further discussions on zoom call today. > > Thanks > Manish P > > ------------------------------ > *From:* TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Julius > Werner via TF-A <tf-a(a)lists.trustedfirmware.org> > *Sent:* 25 March 2021 02:43 > *To:* Simon Glass <sjg(a)chromium.org> > *Cc:* Harb Abdulhamid OS <abdulhamid(a)os.amperecomputing.com>; Boot > Architecture Mailman List <boot-architecture(a)lists.linaro.org>; > tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; U-Boot > Mailing List <u-boot(a)lists.denx.de>; 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 > > 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 > > -- > 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, 5 months

4
3
0 0

Rockchip rk3399 build broken with gcc11

by Olivier Deprez

Hi Rockchip platform maintainers, There's a build issue spotted with GCC11 on rk3399 platform reported here using tip of master: https://developer.trustedfirmware.org/T925 The issue is not breaking the build with earlier gcc versions, but we think the error is legitimate and caused by a mistake in the platform code. Details in the ticket. Any chance for you to have a look? Thanks, Olivier.

4 years, 5 months

1
0
0 0

MEM_PROTECT for secure world?

by Okash Khawaja

Hi, As a PSCI call, MEM_PROTECT which is used to protect against cold reboot attack, can't be called from TZ-secure. In a situation where at run time, HLOS in NS-EL1 transfers some buffer that it owns, to a secure partition then secure partition can't call MEM_PROTECT because psci_smc_handler will return SMC_UNK if the caller is secure. Should MEM_PROTECT be available to TZ-secure as well? Thanks, Okash

4 years, 5 months

1
0
0 0

TF-A Tech Forum Agenda @ Thr 6th May 2021 16:00-1700 BST

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 6th May 2021 16:00 – 17:00 (BST). Agenda: * Discussion Session: Static and Dynamic Information Handling in TF-A * Lead by Manish Pandy and Madhukar Pappireddy · There is ongoing mailing lists discussion[1] related with adopting a mechanism to pass information through boot stages. The requirement is two-fold: 1. Passing static information(config files) 2. Passing dynamic information (Hob list) In the upcoming TF-A tech forum, we can start with a discussion on dynamic information passing and if time permits, we can cover static information passing. The purpose of the call is to have an open discussion and continue the discussion from the trusted-substrate call[2] done earlier. We would like to understand the various requirements and possible ways to implement it in TF-A in a generalized way so that it can work with other Firmware projects. The two specific item which we would like to discuss are: 1. HOB format: TF-A/u-boot both has an existing bloblist implementation, which uses tag values. Question, can this be enhanced to use hybrid values(Tag and UUID) both? 2. Standardization on Physical register use to pass base of HoB data structure. References: [1] https://lists.trustedfirmware.org/pipermail/tf-a/2021-April/001069.html [2] https://linaro-org.zoom.us/rec/share/zjfHeMIumkJhirLCVQYTHR6ftaqyWvF_0klgQn… Passcode: IPn+5q% Thanks Joanna You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> 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/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One 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-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.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://www.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 organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>.

4 years, 6 months

1
0
0 0

Re: [TF-A] Run BL33 (u-boot) in EL3

by François Ozog

Le mar. 27 avr. 2021 à 11:04, Loh, Tien Hock via TF-A < tf-a(a)lists.trustedfirmware.org> a écrit : > Achin, > > Yes that’s what I have suspected in the first place, but no harm asking :) > > > > Tien Fong, > > As per discussed, we could probably expose the a compile time option in > BL31 that expose a command that read/write to the secure domain. > > That case, u-boot shell will be able to access secure domain and not need > to run in EL3. > Would you allow an OS to access underlying hypervisor ? In essence this is what you are asking: there are architectural services such as kicking off a new cpu that are supposed to be routed to the right service handler (PSCI) or secure firmware updates with anti-bricking support.... Could you be more specific on what you want to do and why ? That may help us advise on achieving your goals while still being architecturally correct. > > > Thanks > > > > *From:* Chee, Tien Fong <tien.fong.chee(a)intel.com> > *Sent:* Tuesday, April 27, 2021 5:01 PM > *To:* Achin Gupta <Achin.Gupta(a)arm.com>; tf-a(a)lists.trustedfirmware.org; > Loh, Tien Hock <tien.hock.loh(a)intel.com> > *Cc:* See, Chin Liang <chin.liang.see(a)intel.com>; Hea, Kok Kiang < > kok.kiang.hea(a)intel.com> > *Subject:* RE: Run BL33 (u-boot) in EL3 > > > > Hi Achin, > > > > Thanks for the feedback. > > > > This is use case when user doing development, testing and bring up the > board, they can use this option to run their script on U-Boot shell to > access these secure region. Once they have finished the development, and > testing, then user can switch U-Boot into EL2. This flexibility would > definitely giving some degree of convenience for development and testing. > > > > Thanks. > > > > *From:* Achin Gupta <Achin.Gupta(a)arm.com> > *Sent:* Tuesday, 27 April, 2021 4:38 PM > *To:* tf-a(a)lists.trustedfirmware.org; Loh, Tien Hock < > tien.hock.loh(a)intel.com> > *Cc:* Chee, Tien Fong <tien.fong.chee(a)intel.com>; See, Chin Liang < > chin.liang.see(a)intel.com>; Hea, Kok Kiang <kok.kiang.hea(a)intel.com> > *Subject:* Re: Run BL33 (u-boot) in EL3 > > > > Hi Tien Hock, > > > > The maintainers will have more thoughts on this but my $0.02 fwiw. > > > > I cannot see why the Trusted Firmware project should carry any option that > enables use of EL3 by users who do not care about security. EL3 is not > meant to run u-boot with a shell that can be used to fiddle with secure > memory. This flies against the basic security principles that the project > is built upon. > > > > cheers, > Achin > > > ------------------------------ > > *From:* TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Loh, > Tien Hock via TF-A <tf-a(a)lists.trustedfirmware.org> > *Sent:* 27 April 2021 09:02 > *To:* tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> > *Cc:* Chee, Tien Fong <tien.fong.chee(a)intel.com>; See, Chin Liang < > chin.liang.see(a)intel.com>; Hea, Kok Kiang <kok.kiang.hea(a)intel.com> > *Subject:* [TF-A] Run BL33 (u-boot) in EL3 > > > > Hi, > > > > I’m maintaining TF-A for Intel SoCFPGA platform. > > Would it be possible if we should have the option to run BL33 (u-boot in > our case) in EL3? > > > > The Intel SoCFPGA platform u-boot used to handle all SMC calls: > > SPL u-boot (EL3) -> u-boot (EL3) > > And we have since move to use TF-A’s BL31, thus boot became > SPL u-boot (EL3) -> TF-A BL31 (EL3) -> u-boot (EL2) > > > > Main reason is that some users would like to keep u-boot at EL3 as they do > not care about security, and some users wanted to run some debugging > read/write to secure region in u-boot shell. > > > > Thanks > > Tien Hock > > > -- > 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, 6 months

2
3
0 0

Re: [TF-A] Run BL33 (u-boot) in EL3

by Manish Pandey2

Hi Tien Hock, Did you explored EL3_PAYLOAD_BASE build option. This option enables booting an EL3 payload, if it suits you then u-boot as EL3 payload. thanks Manish ________________________________ 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> Sent: 27 April 2021 20:16 To: Loh, Tien Hock <tien.hock.loh(a)intel.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; See, Chin Liang <chin.liang.see(a)intel.com>; Chee, Tien Fong <tien.fong.chee(a)intel.com>; Hea, Kok Kiang <kok.kiang.hea(a)intel.com> Subject: Re: [TF-A] Run BL33 (u-boot) in EL3 Le mar. 27 avr. 2021 à 11:04, Loh, Tien Hock via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> a écrit : Achin, Yes that’s what I have suspected in the first place, but no harm asking :) Tien Fong, As per discussed, we could probably expose the a compile time option in BL31 that expose a command that read/write to the secure domain. That case, u-boot shell will be able to access secure domain and not need to run in EL3. Would you allow an OS to access underlying hypervisor ? In essence this is what you are asking: there are architectural services such as kicking off a new cpu that are supposed to be routed to the right service handler (PSCI) or secure firmware updates with anti-bricking support.... Could you be more specific on what you want to do and why ? That may help us advise on achieving your goals while still being architecturally correct. Thanks From: Chee, Tien Fong <tien.fong.chee(a)intel.com<mailto:tien.fong.chee@intel.com>> Sent: Tuesday, April 27, 2021 5:01 PM To: Achin Gupta <Achin.Gupta(a)arm.com<mailto:Achin.Gupta@arm.com>>; tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>; Loh, Tien Hock <tien.hock.loh(a)intel.com<mailto:tien.hock.loh@intel.com>> Cc: See, Chin Liang <chin.liang.see(a)intel.com<mailto:chin.liang.see@intel.com>>; Hea, Kok Kiang <kok.kiang.hea(a)intel.com<mailto:kok.kiang.hea@intel.com>> Subject: RE: Run BL33 (u-boot) in EL3 Hi Achin, Thanks for the feedback. This is use case when user doing development, testing and bring up the board, they can use this option to run their script on U-Boot shell to access these secure region. Once they have finished the development, and testing, then user can switch U-Boot into EL2. This flexibility would definitely giving some degree of convenience for development and testing. Thanks. From: Achin Gupta <Achin.Gupta(a)arm.com<mailto:Achin.Gupta@arm.com>> Sent: Tuesday, 27 April, 2021 4:38 PM To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>; Loh, Tien Hock <tien.hock.loh(a)intel.com<mailto:tien.hock.loh@intel.com>> Cc: Chee, Tien Fong <tien.fong.chee(a)intel.com<mailto:tien.fong.chee@intel.com>>; See, Chin Liang <chin.liang.see(a)intel.com<mailto:chin.liang.see@intel.com>>; Hea, Kok Kiang <kok.kiang.hea(a)intel.com<mailto:kok.kiang.hea@intel.com>> Subject: Re: Run BL33 (u-boot) in EL3 Hi Tien Hock, The maintainers will have more thoughts on this but my $0.02 fwiw. I cannot see why the Trusted Firmware project should carry any option that enables use of EL3 by users who do not care about security. EL3 is not meant to run u-boot with a shell that can be used to fiddle with secure memory. This flies against the basic security principles that the project is built upon. cheers, Achin ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of Loh, Tien Hock via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Sent: 27 April 2021 09:02 To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Cc: Chee, Tien Fong <tien.fong.chee(a)intel.com<mailto:tien.fong.chee@intel.com>>; See, Chin Liang <chin.liang.see(a)intel.com<mailto:chin.liang.see@intel.com>>; Hea, Kok Kiang <kok.kiang.hea(a)intel.com<mailto:kok.kiang.hea@intel.com>> Subject: [TF-A] Run BL33 (u-boot) in EL3 Hi, I’m maintaining TF-A for Intel SoCFPGA platform. Would it be possible if we should have the option to run BL33 (u-boot in our case) in EL3? The Intel SoCFPGA platform u-boot used to handle all SMC calls: SPL u-boot (EL3) -> u-boot (EL3) And we have since move to use TF-A’s BL31, thus boot became SPL u-boot (EL3) -> TF-A BL31 (EL3) -> u-boot (EL2) Main reason is that some users would like to keep u-boot at EL3 as they do not care about security, and some users wanted to run some debugging read/write to secure region in u-boot shell. Thanks Tien Hock -- TF-A mailing list TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- [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, 6 months

2
1
0 0

Re: [TF-A] Run BL33 (u-boot) in EL3

by Achin Gupta

Hi Tien Hock, The maintainers will have more thoughts on this but my $0.02 fwiw. I cannot see why the Trusted Firmware project should carry any option that enables use of EL3 by users who do not care about security. EL3 is not meant to run u-boot with a shell that can be used to fiddle with secure memory. This flies against the basic security principles that the project is built upon. cheers, Achin ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Loh, Tien Hock via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 27 April 2021 09:02 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Cc: Chee, Tien Fong <tien.fong.chee(a)intel.com>; See, Chin Liang <chin.liang.see(a)intel.com>; Hea, Kok Kiang <kok.kiang.hea(a)intel.com> Subject: [TF-A] Run BL33 (u-boot) in EL3 Hi, I’m maintaining TF-A for Intel SoCFPGA platform. Would it be possible if we should have the option to run BL33 (u-boot in our case) in EL3? The Intel SoCFPGA platform u-boot used to handle all SMC calls: SPL u-boot (EL3) -> u-boot (EL3) And we have since move to use TF-A’s BL31, thus boot became SPL u-boot (EL3) -> TF-A BL31 (EL3) -> u-boot (EL2) Main reason is that some users would like to keep u-boot at EL3 as they do not care about security, and some users wanted to run some debugging read/write to secure region in u-boot shell. Thanks Tien Hock

4 years, 6 months

3
2
0 0

Question on how enable TF-A SPM on iMX8M

by Jun Nie

Hi, I am trying to enable SPM on iMX8MP platform, which is cortex-A53. The BL2 is already enabled and the dts file is needed. But I am not sure how to write below dts information when I referencing fvp_spmc_manifest.dts. Could you help to give some suggestion or where should I find the anwsers? 1. Is fvp_spmc_manifest.dts enough to enable SPM? I see there are dts files, such as fvp_fw_config.dts. What's necessary dts nodes to enable SPM? 2. Does vcpu_count means CPU number? 3. I see load_address of attribute is optee-os load address. But I do not know how should I decide the load addresses of hypervisors. Is this address decided by virtual machine, or it is decided in runtime? I cannot find the 0x7100000 in trusted-services project. 4. I am confused on "Secure Partitions are bundled as independent package files" in below link. Does this bundle package means fip image, or into another file by jason file? Could you help point to the files and image generation command? https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/compo… Regards, Jun

4 years, 6 months

5
20
0 0

Run BL33 (u-boot) in EL3

by Loh, Tien Hock

Hi, I'm maintaining TF-A for Intel SoCFPGA platform. Would it be possible if we should have the option to run BL33 (u-boot in our case) in EL3? The Intel SoCFPGA platform u-boot used to handle all SMC calls: SPL u-boot (EL3) -> u-boot (EL3) And we have since move to use TF-A's BL31, thus boot became SPL u-boot (EL3) -> TF-A BL31 (EL3) -> u-boot (EL2) Main reason is that some users would like to keep u-boot at EL3 as they do not care about security, and some users wanted to run some debugging read/write to secure region in u-boot shell. Thanks Tien Hock

4 years, 6 months

1
0
0 0

suspend to ram on rk3399 theobroma puma

by Mika Penttilä

Hi all! We are developing a product around the rk3399 Theobroma Q7 module. For power savings, we need S3 sleep (suspend-to-ram). As far as I know, the heart of this is in ATF code. We have linux kernel 5.4, which starts the process nicely, drives down all the other cores and finally calls for the psci suspend. We have wakeup on irq, and it sure wakes up, but does a reset from the very beginning. So no context saving resume. I have tried the newest on the ATF git, with a newish mainline uboot. I suppose the role of uboot is not that important here. What should I look at to find the problem? Has someone got the Q7 module done S3 ok? Finally, how do I get some debug uart output from ATF code? Thanks for any hints! Mika Penttilä

4 years, 6 months

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 370380: Code maintainability issues (UNUSED_VALUE) /plat/xilinx/versal/pm_service/pm_svc_main.c: 96 in pm_setup() ________________________________________________________________________________________________________ *** CID 370380: Code maintainability issues (UNUSED_VALUE) /plat/xilinx/versal/pm_service/pm_svc_main.c: 96 in pm_setup() 90 int status, ret = 0; 91 92 status = pm_ipi_init(primary_proc); 93 94 if (status < 0) { 95 INFO("BL31: PM Service Init Failed, Error Code %d!\n", status); >>> CID 370380: Code maintainability issues (UNUSED_VALUE) >>> Assigning value from "status" to "ret" here, but that stored value is overwritten before it can be used. 96 ret = status; 97 } else { 98 pm_up = true; 99 } 100 101 /* ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 6 months

1
0
0 0

Re: [TF-A] [Hafnium] Getting Started page: problem with the command under "Getting the source code"

by Gyorgy Szing

Hi, Just my two cents: - I suggest using $() instead of the backtick operator to enhance readability. This means f=`git rev-parse --git-dir` becomes f=$(git rev-parse --git-dir) - use {} to group commands instead of () (no sub-shell is needed) - stop processing if curl fails (hence second {} block) - if the repo path has spaces, then some quotes are missing So finally the command would become: git clone --recurse-submodules https://git.trustedfirmware.org/hafnium/hafnium.git && { cd hafnium && f="$(git rev-parse --git-dir)"; curl -Lo "$f/hooks/commit-msg" https://review.trustedfirmware.org/tools/hooks/commit-msg && { chmod +x "$f/hooks/commit-msg"; git submodule --quiet foreach "cp \"\$toplevel/$f/hooks/commit-msg\" \"\$toplevel/$f/modules/\$path/hooks/commit-msg\"" ; } ; } /George -----Original Message----- From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> On Behalf Of Olivier Deprez via Hafnium Sent: 21 April 2021 19:12 To: Rebecca Cran <rebecca(a)bsdio.com>; hafnium(a)lists.trustedfirmware.org Subject: Re: [Hafnium] Getting Started page: problem with the command under "Getting the source code" Hi, Ah sorry for that; looks like there's some variable escape problem. I tried this with success, let me know if it works for you. I will update the doc page then. git clone --recurse-submodules https://git.trustedfirmware.org/hafnium/hafnium.git && (cd hafnium && f=`git rev-parse --git-dir`; curl -Lo $f/hooks/commit-msg https://review.trustedfirmware.org/tools/hooks/commit-msg; chmod +x $f/hooks/commit-msg; git submodule --quiet foreach "cp \$toplevel/$f/hooks/commit-msg \$toplevel/$f/modules/\$path/hooks/commit-msg") If you don't require the git hooks a simpler way to clone the project can be: git clone "https://review.trustedfirmware.org/hafnium/hafnium"; cd hafnium git submodule update --init Regards, Olivier. ________________________________________ From: Rebecca Cran <rebecca(a)bsdio.com> Sent: 21 April 2021 16:33 To: Olivier Deprez; hafnium(a)lists.trustedfirmware.org Subject: Re: [Hafnium] Getting Started page: problem with the command under "Getting the source code" It now exits with the message: cp: cannot stat '/home/rebecca/src/uefi/tmp/hafnium//hooks/commit-msg': No such file or directory fatal: run_command returned non-zero status for driver/linux . -- Rebecca Cran On 4/21/21 2:23 AM, Olivier Deprez wrote: > Hi Rebecca, > > Thanks for reporting. > > Can you try with the updated command: > https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/r > efs/changes/31/9731/1/docs/GettingStarted.md > > Thanks, Olivier. > > > ________________________________________ > From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of > Rebecca Cran via Hafnium <hafnium(a)lists.trustedfirmware.org> > Sent: 21 April 2021 04:39 > To: hafnium(a)lists.trustedfirmware.org > Subject: [Hafnium] Getting Started page: problem with the command under "Getting the source code" > > On the Getting Started document > (https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/ > HEAD/docs/GettingStarted.md) there's a command listed to get the > source code: > > git clone --recurse-submodules > https://git.trustedfirmware.org/hafnium/hafnium.git && (cd hafnium && > f=`git rev-parse --git-dir`/hooks/commit-msg ; curl -Lo $f > https://review.trustedfirmware.org/tools/hooks/commit-msg ; chmod +x > $f ; for m in `git rev-parse --git-dir`/modules/*; do cp $f > $m/hooks/commit-msg; done) > > > However, on my system it's erroring out because the 'hooks' directory > it tries to write to doesn't exist: > > % Total % Received % Xferd Average Speed Time Time Time > Current > Dload Upload Total Spent Left Speed > 100 2174 100 2174 0 0 4221 0 --:--:-- --:--:-- > --:--:-- 4221 > cp: cannot create regular file '.git/modules/driver/hooks/commit-msg': > No such file or directory > cp: cannot create regular file '.git/modules/project/hooks/commit-msg': > No such file or directory > cp: cannot create regular file > '.git/modules/third_party/hooks/commit-msg': No such file or directory > > > -- > Rebecca Cran > > -- > Hafnium mailing list > Hafnium(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/hafnium > -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/hafnium

4 years, 6 months

2
1
0 0

Canceled event with note: TF-A Tech Forum @ Thu Apr 22, 2021 8am - 9am (MST) (tf-a@lists.trustedfirmware.org)

by Don Harbin

This event has been canceled with this note: "Cancelled per Joanna" 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 Apr 22, 2021 8am – 9am 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, 6 months

1
0
0 0

TF-A Tech Forum Agenda @ Thr 22nd April 2021 16:00-1700 BST CANCELLED

by Joanna Farley

Hi Everyone, I am cancelling this weeks TF-A Tech Forum as I don’t have any areas to present/discuss. I would encourage any contributors that wants to present or lead a discussion subject to please let me know as we are always looking for topics of interest to the project community to run sessions on. Cancellations of the calendar invite will come from trustedformware.org. Thanks Joanna

4 years, 6 months

1
0
0 0

Re: [TF-A] zynqmp: How to inform the bl33 about RAM reservation?

by François Ozog

Hi There is a discussion started by Harb from Ampere about standardizing information from secure firmware to BL33: look at HOB in the object. A side aspect of the HOB is: DT shall be used wisely for things that are really static. Dynamic (such as plugged DIMMs) or configurable aspects (secure memory size) should be controllable by a single authoritative entity. On a number of platforms, the definition of secure memory size is "copied" in at least for different independent projects which make it a nightmare for product makers to choose a size for the trusted application they want to onboard. Cheers FF On Tue, 20 Apr 2021 at 07:49, Jan Kiszka via TF-A < tf-a(a)lists.trustedfirmware.org> wrote: > On 20.04.21 02:51, Samuel Holland wrote: > > On 4/19/21 11:11 AM, Jan Kiszka via TF-A wrote: > >> On 19.04.21 17:21, Michal Simek wrote: > >>> On 4/18/21 8:44 PM, Jan Kiszka wrote: > >>>> when SPD or DEBUG is enabled, TF-A is moved to RAM on the zynqmp (as > it > >>>> longer fits into OCM). U-Boot happens to avoid that region, but the > >>>> kernel's DTB has no reservation entry, and Linux will trigger an > >>>> exception when accessing that region during early boot. > >>>> > >>>> Can we improve this - without requiring the user to manually add a > >>>> reservation to the DTB? Should we unconditionally reserve > >>>> 0x1000..0x7ffff in all BL33 DTBs? Or is there a chance to communicate > >>>> that need? Or some way to detect in BL33 whether it is needed? > >>> > >>> Normally this ddr region should be also protected by security IPs that > >>> NS has no access there. > >>> It means in Xilinx flow this can be (and should be) propagated via > >>> device-tree generator to final DTS file that you don't need to touch it > >>> by hand. > >>> I am not aware about any way that NS can query secure world what memory > >>> can be used. And not sure if there is any standard way to do so. > >>> > >> > >> OK, understood. But then, to be safe, shouldn't the upstream "static" > >> default DT contain an exclusion of that region so that it won't get > >> stuck if it is in use? Would block half a meg, but when you have a > >> custom platform that does not need that, you can and will provide your > >> own DT anyway. > > > > Ideally, the static DTS is a description of the hardware only, and not > > of runtime constraints imposed by the firmware. If BL31 needs to reserve > > some memory, it can add that reservation to the DTB at runtime. The > > fdt_add_reserved_memory() function is available for this purpose. For an > > example, see the code used by the rpi4[0] or sun50i_h616[1] platforms. > > > > If you later load a DTB from disk for use by Linux, you will need to > > copy the reserved-memory nodes from the U-Boot DTB to the loaded DTB. > > > > I know the RPi4 model (just had to debug it [3]). But I wonder if that > is possible on the zynqmp as well. Are we passing a DT to BL33 here > already and, thus, could inject that reservation? > > Jan > > > Regards, > > Samuel > > > > [0]: > > > https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/rpi/r… > > [1]: > > > https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/allwi… > > > > [3] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/9316 > -- > 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, 6 months

1
0
0 0

Re: [TF-A] [RFC] TF-A threat model

by Varun Wadekar

Hi, This looks promising. Can you also create a list of guidelines resulting from the analysis? We can then roll them up as coding guidelines or design guidelines or to-do for platforms. -Varun From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Zelalem Aweke via TF-A Sent: Friday, April 16, 2021 8:15 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] [RFC] TF-A threat model External email: Use caution opening links or attachments Hi All, We are releasing the first TF-A threat model document. This release provides the baseline for future updates to be applied as required by developments to the TF-A code base. Please review the document provide comments here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/9627<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>. Thanks, Zelalem

4 years, 6 months

2
2
0 0

Re: [TF-A] platform g12a: CSSERT: File lib/cpus/aarch64/cpu_helpers.S Line 00035

by Manish Pandey2

Hi, >From git log g12a platform was first introduced in 2019 and never has any further changes, also there is no documentation for this platform, so from platform perspective not sure if you are doing everything right or not ? However, i have some generic comments 1. There is no such macro DISABLE_PEDANTIC 2. Which CPU you have in Odroid-C4 boards(is it Cortext-A55?), You probably need to add cpu lib file in platform.mk file In file plat/amlogic/g12a/platform.mk BL31_SOURCES += lib/cpus/aarch64/cortex_a53.S \ lib/cpus/aarch64/cortex_a55.S thanks Manish ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Matwey V. Kornilov via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 19 April 2021 16:47 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] platform g12a: CSSERT: File lib/cpus/aarch64/cpu_helpers.S Line 00035 Hello, Sorry, if this is the wrong place to ask. I am trying to run ATF v2.4 for platform g12a on the Odroid-C4 board. I've built ATF as the following make DISABLE_PEDANTIC=1 DEBUG=1 PLAT=g12a Unfortunately, the only thing I see in the console when BL31 is supposed to run is CSSERT: File lib/cpus/aarch64/cpu_helpers.S Line 00035 Is there any chance to figure out what is wrong? -- With best regards, Matwey V. Kornilov -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 6 months

1
0
0 0

zynqmp: How to inform the bl33 about RAM reservation?

by Jan Kiszka

Hi all, when SPD or DEBUG is enabled, TF-A is moved to RAM on the zynqmp (as it longer fits into OCM). U-Boot happens to avoid that region, but the kernel's DTB has no reservation entry, and Linux will trigger an exception when accessing that region during early boot. Can we improve this - without requiring the user to manually add a reservation to the DTB? Should we unconditionally reserve 0x1000..0x7ffff in all BL33 DTBs? Or is there a chance to communicate that need? Or some way to detect in BL33 whether it is needed? Jan

4 years, 6 months

2
2
0 0

platform g12a: CSSERT: File lib/cpus/aarch64/cpu_helpers.S Line 00035

by Matwey V. Kornilov

Hello, Sorry, if this is the wrong place to ask. I am trying to run ATF v2.4 for platform g12a on the Odroid-C4 board. I've built ATF as the following make DISABLE_PEDANTIC=1 DEBUG=1 PLAT=g12a Unfortunately, the only thing I see in the console when BL31 is supposed to run is CSSERT: File lib/cpus/aarch64/cpu_helpers.S Line 00035 Is there any chance to figure out what is wrong? -- With best regards, Matwey V. Kornilov

4 years, 6 months

1
0
0 0

Re: [TF-A] Adoption of Conventional Commits

by Chris Kay

Thanks to all those who attended the Tech Forum today! It’s become apparent that the initial 2 week deadline for alternative proposals or implementations is too short, so – as agreed – we’ll push the deadline for the investigation period to the end of March. This period is dedicated to evaluating the changelog automation proposal made, or to identifying alternative solutions. If you have an alternative proposal, any proof-of-concept tooling would be highly appreciated so we can get a clear idea of what sort of work and maintenance is going to be involved. If you do find a solution you wish to propose, please give it just a short name (e.g. “Update it manually”) and make it obvious you want to propose it formally – I’ll collect up the proposals made on the mailing list thread at the end of March and set up a Wiki poll so we can get a clear picture of where the community wants to take this. Chris From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Chris Kay via TF-A <tf-a(a)lists.trustedfirmware.org> Reply to: Chris Kay <Chris.Kay(a)arm.com> Date: Thursday, 11 February 2021 at 13:59 To: "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Adoption of Conventional Commits Hi all, Recently we had an internal discussion on the merits of introducing semantics to commit messages pushed to the main TF-A repository, the conclusion being that we would look to adopting the Conventional Commits<https://www.conventionalcommits.org/en/v1.0.0/> specification in the near future. There was one major reason for this, which was to help us in automating the changelog in future releases, but it might also help us to dramatically reduce the overall amount of work needed to make a formal release in the future. This requires some buy-in (or buy-out, in this case) from maintainers because - even though it’s to only a relatively minor extent - it does involve an adjustment to everybody’s workflow. Notably, commit messages will be expected to adopt the structure defined by the specification, which will be enforced by the CI. Most commits that go upstream today adhere to “something that looks like Conventional Commits”, so the change is not exactly sweeping, but any change has the potential be an inconvenience. With that in mind, I propose the following: * We collectively adopt the specification, enforced only for @arm.com contributors until such a time that the majority of maintainers are familiar with the new demands * We suggest - in the prerequisites documentation - the installation of two helper tools: * Commitizen<https://github.com/commitizen/cz-cli> * Commitlint<https://github.com/conventional-changelog/commitlint> Installation of these tools will be optional, but I believe they can help with the transition. In the patches currently in review, they are installed as Git hooks automatically upon execution of npm install, so it requires no manual installation or configuration (other than a relatively up-to-date Node.js installation). You’ll find the patches here<https://review.trustedfirmware.org/q/topic:%22ck%252Fconventional-commits%2…>, and specifically the changes to the prerequisites documentation here<https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/8224/1/docs/…>. Feel free to review these changes if you have comments specifically on their implementation. Let me know if you have any questions or concerns. If everybody’s on board, we can look to have this upstreamed shortly. Chris

4 years, 6 months

1
2
0 0

[RFC] TF-A threat model

by Zelalem Aweke

Hi All, We are releasing the first TF-A threat model document. This release provides the baseline for future updates to be applied as required by developments to the TF-A code base. Please review the document provide comments here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/9627. Thanks, Zelalem

4 years, 6 months

1
0
0 0

Re: [TF-A] [OCP-OSF] Firmware: Sustainability vs planned obsolescence

by François Ozog

Hi Open System Firmware and Trusted Firmware communities have common interests in driving *some* firmware discussions because upstream projects like EDK2, U-Boot and Linux boot greatly benefit from common approaches regardless of processor architecture and early firmware components. The discussion on passing metadata between early firmware components and from early firmware to EDK2/U-Boot/LinuxBoot is typically such a topic. EDK2 is the only project that has defined metadata in the form of Platform Initialization HOBs (chapter 5 of PI spec). U-Boot and LinuxBoot have platform specific techniques to consume that metadata. Let's make sure that at least there is common solution for those two and hope that the result is enticing enough that EDK2 decide to leverage the result one way or the other. Here is a patched repost of the state of discussion after last Trusted Substrate call: Topics where there seem to be consensus - Scope include diverse firmware flows (U-Boot/SPL, TFA, CoreBoot…) on different architectures (Arm, RiscV) - Definitions: The Hand Over Function is the firmware component that hands off to the booted payload = {OS/Hypervisor/Grub/Shim}. - Hand Over Function can be EDK2, U-Boot or LinuxBoot. - The HOF, through ACPI or DT is responsible to describe what shall be controlled and partly how (some parameters) - *There is information that can only be discovered at runtime by diverse early firmware components and needs to be conveyed through the HOF to the booted payload.* - The proposal is to convey that dynamic information in the form of HandOverBlocks (HOBs - generic idea, not the EDK2 construct) whose format is yet to be defined and built as a linked list of objects. The other proposal to use call backs (mmc calls or equivalent) from HOF to firmware is rejected. In Arm architecture, that choice does not preclude some firmware components to use SCMI calls into SCP to obtain authoritative information. - The firmware components shall not care about what is the actual HOF: the format is standard regardless if HOF is EDK2, U-Boot or LinuxBoot. In TF-A words, the HOBs become part of the input ABI for BL33. In the best world, it should be possible for the platform "buyer" to choose the HOF. Characteristics to consider about HOBs: - HOBs can be built by very early components and must fit into highly constrained SRAM - A HOB may be passed between different firmware components, secure and non-secure. - A HOB can be built by secure and non-secure firmware components - An information can have a single format: no alternative representation is allowed. In other words if the information is passed as a data structure it cannot be represented by a DT fragment by another implementation and conversely. Topics that need more discussion - HOBs need a way to be identified: UUID, ID, hybrid (like Platform Initialization). *My views: the hybrid allows constraints firmware components to be using simple IDs and richer components may want leverage UUIDs (same as Platform Initialization).* - HOB format: binary information; just static structure, flatten device tree fragments/overlays or even CBOR. *My views: again hybrid approach seem very efficient. Static structures for memory information, DT fragment for device assignment (for non-secure partitions or for secure world / secure partitions). Typically I would imagine a UUID HOB with a DT fragment seems just good. This is actually implemented like that with Platform Initialization:* *HOBs are identified by a simple ID, out of IDs are EFI_HOB_RESOURCE_DESCRIPTOR for DRAM description and EFI_HOB_GUID_TYPE that contains something identified by a GUID. There is a GUID used in the context of EDK2 to actually contain a DT fragment today.* *As an open specification that allows extension, there shall be a mandate to publish an open specification of any extension.* On Fri, 16 Apr 2021 at 07:51, François Ozog via TF-A < tf-a(a)lists.trustedfirmware.org> wrote: > +tf.org as the discussion evolved to a topic discussed there. > > Le ven. 16 avr. 2021 à 01:25, Zimmer, Vincent <vincent.zimmer(a)intel.com> > a écrit : > >> >> >> For the wayback machine, the design of HOB’s dates back to early 2000’s. >> >> >> >> >> >> The HOB defin was part of the Intel Framework specs & it was made public >> in 2003 through a click-through, as folks noted. HOBs became part of the >> UEFI Forum Platform Initialization (PI) spec in 2006. Essentially PI 1.0 >> absorbed most of the Framework 0.9x specs (sans datahub, CSM). >> >> from https://link.springer.com/book/10.1007/978-1-4842-0070-4 >> >> >> >> IMHO the biggest bug on the present Type Length Value (TLV)-based HOB >> design entails the “L” of the TLV, namely the 16-bit length limitation on >> the size of a specific HOB. Servers often bump into this limitation today >> given the amount of state discovered in these early initialization flows. >> The use of GUID’s w/o strings is also a usability challenge, I’d agree, >> that any new design can address. >> >> >> >> Going forward >> >> The more recent proposed use of HOB's for the generic payload interface >> https://github.com/universalpayload/documentation launching was more for >> convenience since it's a simple TLV encoded mechanism and there are parsing >> libraries already in the wild. But the use of HOB’s versus DT versus …. >> for the inargs of the payload is definitely open for discussion/change in >> the design. The earlier thread suggestions of CBOR/8949 >> https://www.rfc-editor.org/rfc/rfc8949.html from Francois/Nate is >> interesting. We can update the already open issue on this topic >> https://github.com/universalpayload/documentation/issues/9 with some of >> these thoughts and build upon the sentiments Ron shared earlier on the >> topic. >> >> >> >> And regarding the payload specification >> https://universalpayload.github.io/documentation/ mentioned above, I’m >> happy to present on this design effort in an upcoming OSF meeting, >> including how payloads may relate to the OSF workstream. The payload >> design is intended to be an open process with a code-first workflow that >> doesn’t tie itself to any specific bootloader design, as demonstrated by >> the different bootloaders and payloads ported at >> https://github.com/universalpayload. Although there isn’t a U-Boot >> example ported (I thought I heard mention of U-boot in this thread or >> meeting?), addressing the needs of U-boot and other *boot solutions (e.g., >> oreboot) is definitely part of the design scope intent, too. >> >> >> >> Thanks, >> >> >> >> Vincent >> >> >> >> >> >> -----Original Message----- >> From: OCP-OSF(a)OCP-All.groups.io <OCP-OSF(a)OCP-All.groups.io> On Behalf Of >> ron minnich >> Sent: Thursday, April 15, 2021 3:14 PM >> To: Desimone, Nathaniel L <nathaniel.l.desimone(a)intel.com> >> Cc: OCP-OSF(a)OCP-All.groups.io; Boot Architecture Mailman List < >> boot-architecture(a)lists.linaro.org>; Leif Lindholm <leif(a)nuviainc.com> >> Subject: Re: [OCP-OSF] Firmware: Sustainability vs planned obsolescence >> >> >> >> actually isn't device tree a 1980s design :-) >> >> >> >> anyway, as long as we can hit the things I care so much about, >> >> >> >> self describing >> >> alignment independent >> >> endian independent >> >> names not magic numbers (I mean, you want to put a UUID in there too, >> fine, but I doubt a human-readable string will kill us on space) >> >> >> >> it can be anything you all think best. >> >> >> >> On Thu, Apr 15, 2021 at 2:49 PM Desimone, Nathaniel L < >> nathaniel.l.desimone(a)intel.com> wrote: >> >> > >> >> > On Thu, Apr 15, 2021 at 1:29 -0700, ron minnich wrote: >> >> > >> >> > >I'd rather not take HOB as a given without considering alternatives. >> >> > >It's a very 1990s design. >> >> > >> >> > Device tree is also a very early 90s design for that matter. If we are >> talking about clean slate design, how about something actually new and >> modern like RFC 8949? >> >> > >> >> > From a practical standpoint I don't see HOBs going away very soon but >> I'm open to possibility thinking on a long term basis. >> >> > >> >> > >> >> > >> >> > >> >> >> >> >> >> >> >> >> _._,_._,_ >> ------------------------------ >> Groups.io Links: >> >> You receive all messages sent to this group. >> >> View/Reply Online (#149) >> <https://OCP-All.groups.io/g/OCP-OSF/message/149> | Reply To Group >> <OCP-OSF@OCP-All.groups.io?subject=Re:%20Re%3A%20%5BOCP-OSF%5D%20Firmware%3A%20Sustainability%20vs%20planned%20obsolescence> >> | Reply To Sender >> <vincent.zimmer@intel.com?subject=Private:%20Re:%20Re%3A%20%5BOCP-OSF%5D%20Firmware%3A%20Sustainability%20vs%20planned%20obsolescence> >> | Mute This Topic <https://groups.io/mt/81937262/675475> | New Topic >> <https://OCP-All.groups.io/g/OCP-OSF/post> >> Your Subscription <https://OCP-All.groups.io/g/OCP-OSF/editsub/675475> | Contact >> Group Owner <OCP-OSF+owner(a)OCP-All.groups.io> | Unsubscribe >> <https://OCP-All.groups.io/g/OCP-OSF/leave/10214763/675475/1625423992/xyzzy> >> [francois.ozog(a)linaro.org] >> _._,_._,_ >> >> -- > 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, 6 months

1
0
0 0

Re: [TF-A] Problems building for qemu with SPM (S-EL2) support

by Olivier Deprez

Hi Rebecca, qemu is currently not supported for use with the SPM at S-EL2. The two available options are FVP (https://trustedfirmware-a.readthedocs.io/en/latest/components/secure-partit…) or Total Compute platform (https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-docs…) Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Rebecca Cran via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 16 April 2021 00:02 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Problems building for qemu with SPM (S-EL2) support I'm having problems building TF-A with SPM/S-EL2 support. I can build with PLAT=fvp fine, but building with PLAT=qemu results in the error: LD /home/rebecca/src/arm-trusted-firmware/build/qemu/release/bl31/bl31.elf /home/rebecca/gcc-arm-10.2-2020.11-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-ld: /home/rebecca/src/arm-trusted-firmware/build/qemu/release/bl31/spmd_main.o: in function `spmd_setup': spmd_main.c:(.text.spmd_setup+0x74): undefined reference to `plat_spm_core_manifest_load' spmd_main.c:(.text.spmd_setup+0x74): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `plat_spm_core_manifest_load' make: *** [Makefile:1136: /home/rebecca/src/arm-trusted-firmware/build/qemu/release/bl31/bl31.elf] Error 1 The command line I'm using is: make PLAT=qemu DEBUG=0 \ CROSS_COMPILE=~/gcc-arm-10.2-2020.11-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- \ SPD=spmd CTX_INCLUDE_EL2_REGS=1 BL32=bl32.bin BL33=bl33.bin \ SP_LAYOUT_FILE=sp_layout.json ARM_ARCH_MINOR=4 all fip Adding the following files to BL31_SOURCES in plat/qemu/platform.mk resolves the problem, but I suspect that's not the correct solution? plat/common/plat_spmd_manifest.c common/fdt_wrappers.c -- Rebecca Cran -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 6 months

1
0
0 0

Re: [TF-A] [OCP-OSF] Firmware: Sustainability vs planned obsolescence

by François Ozog

+tf.org as the discussion evolved to a topic discussed there. Le ven. 16 avr. 2021 à 01:25, Zimmer, Vincent <vincent.zimmer(a)intel.com> a écrit : > > > For the wayback machine, the design of HOB’s dates back to early 2000’s. > > > > > > The HOB defin was part of the Intel Framework specs & it was made public > in 2003 through a click-through, as folks noted. HOBs became part of the > UEFI Forum Platform Initialization (PI) spec in 2006. Essentially PI 1.0 > absorbed most of the Framework 0.9x specs (sans datahub, CSM). > > from https://link.springer.com/book/10.1007/978-1-4842-0070-4 > > > > IMHO the biggest bug on the present Type Length Value (TLV)-based HOB > design entails the “L” of the TLV, namely the 16-bit length limitation on > the size of a specific HOB. Servers often bump into this limitation today > given the amount of state discovered in these early initialization flows. > The use of GUID’s w/o strings is also a usability challenge, I’d agree, > that any new design can address. > > > > Going forward > > The more recent proposed use of HOB's for the generic payload interface > https://github.com/universalpayload/documentation launching was more for > convenience since it's a simple TLV encoded mechanism and there are parsing > libraries already in the wild. But the use of HOB’s versus DT versus …. > for the inargs of the payload is definitely open for discussion/change in > the design. The earlier thread suggestions of CBOR/8949 > https://www.rfc-editor.org/rfc/rfc8949.html from Francois/Nate is > interesting. We can update the already open issue on this topic > https://github.com/universalpayload/documentation/issues/9 with some of > these thoughts and build upon the sentiments Ron shared earlier on the > topic. > > > > And regarding the payload specification > https://universalpayload.github.io/documentation/ mentioned above, I’m > happy to present on this design effort in an upcoming OSF meeting, > including how payloads may relate to the OSF workstream. The payload > design is intended to be an open process with a code-first workflow that > doesn’t tie itself to any specific bootloader design, as demonstrated by > the different bootloaders and payloads ported at > https://github.com/universalpayload. Although there isn’t a U-Boot > example ported (I thought I heard mention of U-boot in this thread or > meeting?), addressing the needs of U-boot and other *boot solutions (e.g., > oreboot) is definitely part of the design scope intent, too. > > > > Thanks, > > > > Vincent > > > > > > -----Original Message----- > From: OCP-OSF(a)OCP-All.groups.io <OCP-OSF(a)OCP-All.groups.io> On Behalf Of > ron minnich > Sent: Thursday, April 15, 2021 3:14 PM > To: Desimone, Nathaniel L <nathaniel.l.desimone(a)intel.com> > Cc: OCP-OSF(a)OCP-All.groups.io; Boot Architecture Mailman List < > boot-architecture(a)lists.linaro.org>; Leif Lindholm <leif(a)nuviainc.com> > Subject: Re: [OCP-OSF] Firmware: Sustainability vs planned obsolescence > > > > actually isn't device tree a 1980s design :-) > > > > anyway, as long as we can hit the things I care so much about, > > > > self describing > > alignment independent > > endian independent > > names not magic numbers (I mean, you want to put a UUID in there too, > fine, but I doubt a human-readable string will kill us on space) > > > > it can be anything you all think best. > > > > On Thu, Apr 15, 2021 at 2:49 PM Desimone, Nathaniel L < > nathaniel.l.desimone(a)intel.com> wrote: > > > > > > On Thu, Apr 15, 2021 at 1:29 -0700, ron minnich wrote: > > > > > > >I'd rather not take HOB as a given without considering alternatives. > > > >It's a very 1990s design. > > > > > > Device tree is also a very early 90s design for that matter. If we are > talking about clean slate design, how about something actually new and > modern like RFC 8949? > > > > > > From a practical standpoint I don't see HOBs going away very soon but > I'm open to possibility thinking on a long term basis. > > > > > > > > > > > > > > > > > > > > > _._,_._,_ > ------------------------------ > Groups.io Links: > > You receive all messages sent to this group. > > View/Reply Online (#149) <https://OCP-All.groups.io/g/OCP-OSF/message/149> > | Reply To Group > <OCP-OSF@OCP-All.groups.io?subject=Re:%20Re%3A%20%5BOCP-OSF%5D%20Firmware%3A%20Sustainability%20vs%20planned%20obsolescence> > | Reply To Sender > <vincent.zimmer@intel.com?subject=Private:%20Re:%20Re%3A%20%5BOCP-OSF%5D%20Firmware%3A%20Sustainability%20vs%20planned%20obsolescence> > | Mute This Topic <https://groups.io/mt/81937262/675475> | New Topic > <https://OCP-All.groups.io/g/OCP-OSF/post> > Your Subscription <https://OCP-All.groups.io/g/OCP-OSF/editsub/675475> | Contact > Group Owner <OCP-OSF+owner(a)OCP-All.groups.io> | Unsubscribe > <https://OCP-All.groups.io/g/OCP-OSF/leave/10214763/675475/1625423992/xyzzy> > [francois.ozog(a)linaro.org] > _._,_._,_ > > -- 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, 6 months

1
0
0 0

Re: [TF-A] Adoption of Conventional Commits

by Varun Wadekar

>> Otherwise, we will begin adopting Conventional Commits in the CI at the beginning of April, pending full rollout for everybody in the next release. IIRC, I already proposed another option that builds on the tagging mechanism from Conventional Commits. Did we document the objections somewhere? I remember, CC did get some "nays" on the wiki page. Were all those concerns resolved? From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Chris Kay via TF-A Sent: Thursday, March 18, 2021 5:08 AM To: tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] Adoption of Conventional Commits External email: Use caution opening links or attachments Just a reminder to everybody that we're now most of the way through March, and therefore most of the way through the investigation period. If anybody has any proposals they'd like to make, please do share them as soon as possible so that we have time to brainstorm and come to a conclusion. Otherwise, we will begin adopting Conventional Commits in the CI at the beginning of April, pending full rollout for everybody in the next release. Chris From: Chris Kay <Chris.Kay(a)arm.com<mailto:Chris.Kay@arm.com>> Date: Thursday, 25 February 2021 at 17:30 To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: Re: [TF-A] Adoption of Conventional Commits Thanks to all those who attended the Tech Forum today! It's become apparent that the initial 2 week deadline for alternative proposals or implementations is too short, so - as agreed - we'll push the deadline for the investigation period to the end of March. This period is dedicated to evaluating the changelog automation proposal made, or to identifying alternative solutions. If you have an alternative proposal, any proof-of-concept tooling would be highly appreciated so we can get a clear idea of what sort of work and maintenance is going to be involved. If you do find a solution you wish to propose, please give it just a short name (e.g. "Update it manually") and make it obvious you want to propose it formally - I'll collect up the proposals made on the mailing list thread at the end of March and set up a Wiki poll so we can get a clear picture of where the community wants to take this. Chris From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of Chris Kay via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Reply to: Chris Kay <Chris.Kay(a)arm.com<mailto:Chris.Kay@arm.com>> Date: Thursday, 11 February 2021 at 13:59 To: "tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>" <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: [TF-A] Adoption of Conventional Commits Hi all, Recently we had an internal discussion on the merits of introducing semantics to commit messages pushed to the main TF-A repository, the conclusion being that we would look to adopting the Conventional Commits<https://www.conventionalcommits.org/en/v1.0.0/> specification in the near future. There was one major reason for this, which was to help us in automating the changelog in future releases, but it might also help us to dramatically reduce the overall amount of work needed to make a formal release in the future. This requires some buy-in (or buy-out, in this case) from maintainers because - even though it's to only a relatively minor extent - it does involve an adjustment to everybody's workflow. Notably, commit messages will be expected to adopt the structure defined by the specification, which will be enforced by the CI. Most commits that go upstream today adhere to "something that looks like Conventional Commits", so the change is not exactly sweeping, but any change has the potential be an inconvenience. With that in mind, I propose the following: * We collectively adopt the specification, enforced only for @arm.com contributors until such a time that the majority of maintainers are familiar with the new demands * We suggest - in the prerequisites documentation - the installation of two helper tools: * Commitizen<https://github.com/commitizen/cz-cli> * Commitlint<https://github.com/conventional-changelog/commitlint> Installation of these tools will be optional, but I believe they can help with the transition. In the patches currently in review, they are installed as Git hooks automatically upon execution of npm install, so it requires no manual installation or configuration (other than a relatively up-to-date Node.js installation). You'll find the patches here<https://review.trustedfirmware.org/q/topic:%22ck%252Fconventional-commits%2…>, and specifically the changes to the prerequisites documentation here<https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/8224/1/docs/…>. Feel free to review these changes if you have comments specifically on their implementation. Let me know if you have any questions or concerns. If everybody's on board, we can look to have this upstreamed shortly. Chris

4 years, 6 months

2
3
0 0

Problems building for qemu with SPM (S-EL2) support

by Rebecca Cran

I'm having problems building TF-A with SPM/S-EL2 support. I can build with PLAT=fvp fine, but building with PLAT=qemu results in the error: LD /home/rebecca/src/arm-trusted-firmware/build/qemu/release/bl31/bl31.elf /home/rebecca/gcc-arm-10.2-2020.11-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-ld: /home/rebecca/src/arm-trusted-firmware/build/qemu/release/bl31/spmd_main.o: in function `spmd_setup': spmd_main.c:(.text.spmd_setup+0x74): undefined reference to `plat_spm_core_manifest_load' spmd_main.c:(.text.spmd_setup+0x74): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `plat_spm_core_manifest_load' make: *** [Makefile:1136: /home/rebecca/src/arm-trusted-firmware/build/qemu/release/bl31/bl31.elf] Error 1 The command line I'm using is: make PLAT=qemu DEBUG=0 \ CROSS_COMPILE=~/gcc-arm-10.2-2020.11-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- \ SPD=spmd CTX_INCLUDE_EL2_REGS=1 BL32=bl32.bin BL33=bl33.bin \ SP_LAYOUT_FILE=sp_layout.json ARM_ARCH_MINOR=4 all fip Adding the following files to BL31_SOURCES in plat/qemu/platform.mk resolves the problem, but I suspect that's not the correct solution? plat/common/plat_spmd_manifest.c common/fdt_wrappers.c -- Rebecca Cran

4 years, 6 months

1
0
0 0

Re: [TF-A] Debugging a lock-up in opteed_system_reset

by Jens Wiklander

Hi Jan, On Sat, Apr 10, 2021 at 1:18 PM Jan Kiszka via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > On 09.04.21 14:56, Jan Kiszka wrote: > > Hi all, > > > > I'm currently debugging sporadic lockups in TF-A when calling the system > > reset hook of OP-TEE: opteed_system_reset() gets stuck on > > opteed_synchronous_sp_entry(), and the thread_system_reset_handler of > > OP-TEE is not invoked (I left a debug output on the OP-TEE side). > > Platform is k3, target hardware our IOT2050 device. I was using today's > > master of TF-A and OP-TEE, but also older versions of both. > > > > What could cause this? I would assume that TF-A and OP-TEE are protected > > against overwriting of the non-secure world and we would see exceptions > > in case some reservation is not properly set, possibly misleading Linux. > > > > Turned out that we had a bug in our device tree: "reserved_memory", > rather than "reserved-memory". That caused Linux to ignore the RAM > reservation, eventually accessing the memory that OP-TEE is using. > > But that still does not explain why the secured memory is left behind > unsecured. Who is responsible for that, TF-A or the TEE itself? This might be memory reserved for the static shared memory pool used when communicating between Linux normal world and OP-TEE in secure world. If that's the case it's normal that the memory is accessible from Linux, however if Linux uses it for other purposes too there will be memory corruptions. Cheers, Jens

4 years, 6 months

2
1
0 0

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

by Manish Pandey2

Hi, From TF-A project point of view, we prefer to use existing mechanism to pass parameters across boot stages using linked list of tagged elements (as suggested by Julius). It has support for both generic and SiP-specific tags. Having said that, it does not stop partners to introduce new mechanisms suitable for their usecase in platform port initially and later move to generic code if its suitable for other platforms. To start with, Ampere can introduce a platform specific implementation of memory tag(speed/NUMA topology etc) which can be evaluated and discussed for generalization in future. The tag will be populated in BL2 stage and can be forwarded to further stages(and to BL33) by passing the head of list pointer in one of the registers. Initially any register can be used but going forward a standardization will be needed. The U-boot bloblist mentioned by Simon is conceptually similar to what TF-A is using, if there is consensus of using bloblist/taglist then TF-A tag list may be enhanced to take best of both the implementations. One of the potential problems of having structure used in different projects is maintainability, this can be avoided by having a single copy of these structures in TF-A (kept inside "include/export" which intended to be used by other projects.) Regarding usage of either UUID or tag, I echo the sentiments of Simon and Julius to keep it simple and use tag values. Looking forward to having further discussions on zoom call today. Thanks Manish P ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Julius Werner via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 25 March 2021 02:43 To: Simon Glass <sjg(a)chromium.org> Cc: Harb Abdulhamid OS <abdulhamid(a)os.amperecomputing.com>; Boot Architecture Mailman List <boot-architecture(a)lists.linaro.org>; tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; U-Boot Mailing List <u-boot(a)lists.denx.de>; 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 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<mailto:tf-a@lists.trustedfirmware.org>> wrote: Hi Harb, On Wed, 24 Mar 2021 at 11: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. @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. 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<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 -- [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 -- TF-A mailing list TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- [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 -- TF-A mailing list TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 6 months

6
5
0 0

Debugging a lock-up in opteed_system_reset

by Jan Kiszka

Hi all, I'm currently debugging sporadic lockups in TF-A when calling the system reset hook of OP-TEE: opteed_system_reset() gets stuck on opteed_synchronous_sp_entry(), and the thread_system_reset_handler of OP-TEE is not invoked (I left a debug output on the OP-TEE side). Platform is k3, target hardware our IOT2050 device. I was using today's master of TF-A and OP-TEE, but also older versions of both. What could cause this? I would assume that TF-A and OP-TEE are protected against overwriting of the non-secure world and we would see exceptions in case some reservation is not properly set, possibly misleading Linux. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux

4 years, 6 months

2
2
0 0

TF-A 2.5 Release: Code-Freeze 30th April

by Gary Morrison

Hi, This is to notify that we are planning to target the Trusted Firmware-A 2.5 release during the second week of May 2021 as part of the regular ~6-month cadence. The aim is to consolidate all TF-A work since the 2.4 release. As part of this, a release candidate tag will be created and release activities will commence after the 30th of April. Essentially we will not merge any major enhancements from this date until the release is made. Please ensure any Gerrit Patch Reviews desired to make the 2.5 release are submitted in good time to be complete by last week of Apr 2021. Any major enhancement Gerrit Patch Reviews still open after that date will not be merged until after the release.

4 years, 6 months

1
0
0 0

OpenCI and trusted-firmware-ci organization in github

by Joanna Farley

Hi Everyone, If you get an invite to join the trusted-firmware-ci organization in Github it’s to allow all the project contributors seeded from the TF-A maintainers file (maintainers and code owners) to have the privileges to be able to perform Jenkin job rebuilds from the OpenCI Jenkins pages for the TF-A project. All the TF-A project maintainers will have the admin ability to add new people. Thanks Joanna

4 years, 6 months

1
0
0 0

TF-A Tech Forum Agenda @ Thr 8th April 2021 16:00-1700 BST

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 8th April 2021 16:00 – 17:00 (BST). Agenda: * TF-A OpenCI Update and Q&A * Lead by Joanna Farley * Following the posting in late March https://lists.trustedfirmware.org/pipermail/tf-a/2021-March/001045.html announcing the availability of the OpenCI this session is an update on the status and a run through of what’s available in the OpenCI to project contributors. I will have representatives from the OpenCI infrastructure team from Linaro along side TF-A project members familiar with the TF-A CI testing on the call to help answer any questions. * Attached is an early draft of the OpenCI documentation with Version 1.0 expected soon. Thanks Joanna

4 years, 6 months

1
0
0 0

Trusted Substrate architecture call: HandOverBlocks discussion

by François Ozog

Hi following a mail discussion on trusted-firmware A we will have a discussion on HOBs during this week's Trusted Substrate <http://trusted-substrate.org>architecture council call <https://linaro-org.zoom.us/j/94563644892>. In addition to mail thread, here is a deck <https://docs.google.com/presentation/d/1KyqkyqoGXHUynZSI2hRFBoO_P7sFwgUJWhj…> I'll use to start things up. Cheers FF -- 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, 6 months

2
2
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 12 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 12 of 12 defect(s) ** CID 369886: Uninitialized variables (UNINIT) /drivers/nxp/flexspi/nor/fspi.c: 130 in fspi_op_setup() ________________________________________________________________________________________________________ *** CID 369886: Uninitialized variables (UNINIT) /drivers/nxp/flexspi/nor/fspi.c: 130 in fspi_op_setup() 124 cmd_id2 = FSPI_NOR_CMD_RDSR; 125 break; 126 } 127 128 x_addr = FSPI_LUTREG_OFFSET + (uint32_t)(0x10 * fspi_op_seq_id); 129 if ((F_FLASH_SIZE_BYTES <= SZ_16M_BYTES) || (ignore_flash_sz)) { >>> CID 369886: Uninitialized variables (UNINIT) >>> Using uninitialized value "cmd_id1". 130 x_instr0 = FSPI_INSTR_OPRND0(cmd_id1); 131 x_instr1 = FSPI_INSTR_OPRND1(FSPI_LUT_ADDR24BIT); 132 VERBOSE("CMD_ID = %x offset = 0x%x\n", cmd_id1, x_addr); 133 } else { 134 x_instr0 = FSPI_INSTR_OPRND0(cmd_id2); 135 x_instr1 = FSPI_INSTR_OPRND1(FSPI_LUT_ADDR32BIT); ** CID 369885: Memory - corruptions (ARRAY_VS_SINGLETON) ________________________________________________________________________________________________________ *** CID 369885: Memory - corruptions (ARRAY_VS_SINGLETON) /plat/nxp/common/nv_storage/plat_nv_storage.c: 64 in read_nv_app_data() 58 if (ret != XSPI_SUCCESS) { 59 ERROR("Failed to initialized driver flexspi-nor.\n"); 60 ERROR("exiting warm-reset request.\n"); 61 return -ENODEV; 62 } 63 >>> CID 369885: Memory - corruptions (ARRAY_VS_SINGLETON) >>> Passing "(uint32_t *)&nv_app_data" to function "xspi_read" which uses it as an array. This might corrupt or misinterpret adjacent memory locations. 64 xspi_read(nv_base_addr, 65 (uint32_t *)&nv_app_data, sizeof(nv_app_data_t)); 66 xspi_sector_erase((uint32_t) nv_base_addr, 67 F_SECTOR_ERASE_SZ); 68 #endif 69 return ret; ** CID 369884: Memory - corruptions (ARRAY_VS_SINGLETON) ________________________________________________________________________________________________________ *** CID 369884: Memory - corruptions (ARRAY_VS_SINGLETON) /drivers/brcm/i2c/i2c.c: 669 in i2c_send_byte() 663 struct iproc_xact_info info; 664 665 iproc_i2c_fill_info(&info, bus_id, devaddr, 0U, &value, 666 SMBUS_PROT_SEND_BYTE, 0U); 667 668 /* Refer to i2c_smbus_write_byte params passed. */ >>> CID 369884: Memory - corruptions (ARRAY_VS_SINGLETON) >>> Passing "info.data" via argument "&info" to function "iproc_i2c_data_send" which uses it as an array. This might corrupt or misinterpret adjacent memory locations. 669 rc = iproc_i2c_data_send(&info); 670 671 if (rc < 0) { 672 ERROR("%s: %s error accessing device 0x%x\n", 673 __func__, "Write", devaddr); 674 } ** CID 369883: Memory - illegal accesses (UNINIT) ________________________________________________________________________________________________________ *** CID 369883: Memory - illegal accesses (UNINIT) /drivers/nxp/crypto/caam/src/caam.c: 142 in configure_jr() 136 return -1; 137 } 138 139 start_jr(num); 140 141 /* Do HW configuration of the JR */ >>> CID 369883: Memory - illegal accesses (UNINIT) >>> Using uninitialized value "reg_base_addr" when calling "init_job_ring". 142 job_ring = init_job_ring(SEC_NOTIFICATION_TYPE_POLL, 0, 0, 143 reg_base_addr, 0); 144 145 if (job_ring == NULL) { 146 ERROR("Error in init_job_ring"); 147 return -1; ** CID 369882: (BAD_SHIFT) /drivers/nxp/ddr/phy-gen2/phy.c: 2320 in parse_odt() /drivers/nxp/ddr/phy-gen2/phy.c: 2338 in parse_odt() /drivers/nxp/ddr/phy-gen2/phy.c: 2308 in parse_odt() /drivers/nxp/ddr/phy-gen2/phy.c: 2347 in parse_odt() /drivers/nxp/ddr/phy-gen2/phy.c: 2334 in parse_odt() /drivers/nxp/ddr/phy-gen2/phy.c: 2329 in parse_odt() /drivers/nxp/ddr/phy-gen2/phy.c: 2312 in parse_odt() /drivers/nxp/ddr/phy-gen2/phy.c: 2351 in parse_odt() /drivers/nxp/ddr/phy-gen2/phy.c: 2298 in parse_odt() /drivers/nxp/ddr/phy-gen2/phy.c: 2316 in parse_odt() ________________________________________________________________________________________________________ *** CID 369882: (BAD_SHIFT) /drivers/nxp/ddr/phy-gen2/phy.c: 2320 in parse_odt() 2314 case DDR_ODT_OTHER_DIMM: 2315 for (j = 0; j < DDRC_NUM_CS; j++) { 2316 if ((((cs_d0 & (1 << i)) != 0) && 2317 ((cs_d1 & (1 << j)) != 0)) || 2318 (((cs_d1 & (1 << i)) != 0) && 2319 ((cs_d0 & (1 << j)) != 0))) { >>> CID 369882: (BAD_SHIFT) >>> In expression "1 << i", shifting by a negative amount has undefined behavior. The shift amount, "i", is no more than -1. 2320 odt[j] |= (1 << i) << shift; 2321 } 2322 } 2323 break; 2324 case DDR_ODT_ALL: 2325 for (j = 0; j < DDRC_NUM_CS; j++) { /drivers/nxp/ddr/phy-gen2/phy.c: 2338 in parse_odt() 2332 case DDR_ODT_SAME_DIMM: 2333 for (j = 0; j < DDRC_NUM_CS; j++) { 2334 if ((((cs_d0 & (1 << i)) != 0) && 2335 ((cs_d0 & (1 << j)) != 0)) || 2336 (((cs_d1 & (1 << i)) != 0) && 2337 ((cs_d1 & (1 << j)) != 0))) { >>> CID 369882: (BAD_SHIFT) >>> In expression "1 << i", shifting by a negative amount has undefined behavior. The shift amount, "i", is no more than -1. 2338 odt[j] |= (1 << i) << shift; 2339 } 2340 } 2341 break; 2342 case DDR_ODT_OTHER_CS_ONSAMEDIMM: 2343 for (j = 0; j < DDRC_NUM_CS; j++) { /drivers/nxp/ddr/phy-gen2/phy.c: 2308 in parse_odt() 2302 if (i == j) { 2303 continue; 2304 } 2305 if (((cs_d0 | cs_d1) & (1 << j)) == 0) { 2306 continue; 2307 } >>> CID 369882: (BAD_SHIFT) >>> In expression "1 << i", shifting by a negative amount has undefined behavior. The shift amount, "i", is no more than -1. 2308 odt[j] |= (1 << i) << shift; 2309 } 2310 break; 2311 case DDR_ODT_CS_AND_OTHER_DIMM: 2312 odt[i] |= (1 << i) << 4; 2313 /* fallthrough */ /drivers/nxp/ddr/phy-gen2/phy.c: 2347 in parse_odt() 2341 break; 2342 case DDR_ODT_OTHER_CS_ONSAMEDIMM: 2343 for (j = 0; j < DDRC_NUM_CS; j++) { 2344 if (i == j) { 2345 continue; 2346 } >>> CID 369882: (BAD_SHIFT) >>> In expression "1 << i", shifting by a negative amount has undefined behavior. The shift amount, "i", is no more than -1. 2347 if ((((cs_d0 & (1 << i)) != 0) && 2348 ((cs_d0 & (1 << j)) != 0)) || 2349 (((cs_d1 & (1 << i)) != 0) && 2350 ((cs_d1 & (1 << j)) != 0))) { 2351 odt[j] |= (1 << i) << shift; 2352 } /drivers/nxp/ddr/phy-gen2/phy.c: 2334 in parse_odt() 2328 } 2329 odt[j] |= (1 << i) << shift; 2330 } 2331 break; 2332 case DDR_ODT_SAME_DIMM: 2333 for (j = 0; j < DDRC_NUM_CS; j++) { >>> CID 369882: (BAD_SHIFT) >>> In expression "1 << i", shifting by a negative amount has undefined behavior. The shift amount, "i", is no more than -1. 2334 if ((((cs_d0 & (1 << i)) != 0) && 2335 ((cs_d0 & (1 << j)) != 0)) || 2336 (((cs_d1 & (1 << i)) != 0) && 2337 ((cs_d1 & (1 << j)) != 0))) { 2338 odt[j] |= (1 << i) << shift; 2339 } /drivers/nxp/ddr/phy-gen2/phy.c: 2329 in parse_odt() 2323 break; 2324 case DDR_ODT_ALL: 2325 for (j = 0; j < DDRC_NUM_CS; j++) { 2326 if (((cs_d0 | cs_d1) & (1 << j)) == 0) { 2327 continue; 2328 } >>> CID 369882: (BAD_SHIFT) >>> In expression "1 << i", shifting by a negative amount has undefined behavior. The shift amount, "i", is no more than -1. 2329 odt[j] |= (1 << i) << shift; 2330 } 2331 break; 2332 case DDR_ODT_SAME_DIMM: 2333 for (j = 0; j < DDRC_NUM_CS; j++) { 2334 if ((((cs_d0 & (1 << i)) != 0) && /drivers/nxp/ddr/phy-gen2/phy.c: 2312 in parse_odt() 2306 continue; 2307 } 2308 odt[j] |= (1 << i) << shift; 2309 } 2310 break; 2311 case DDR_ODT_CS_AND_OTHER_DIMM: >>> CID 369882: (BAD_SHIFT) >>> In expression "1 << i", shifting by a negative amount has undefined behavior. The shift amount, "i", is no more than -1. 2312 odt[i] |= (1 << i) << 4; 2313 /* fallthrough */ 2314 case DDR_ODT_OTHER_DIMM: 2315 for (j = 0; j < DDRC_NUM_CS; j++) { 2316 if ((((cs_d0 & (1 << i)) != 0) && 2317 ((cs_d1 & (1 << j)) != 0)) || /drivers/nxp/ddr/phy-gen2/phy.c: 2351 in parse_odt() 2345 continue; 2346 } 2347 if ((((cs_d0 & (1 << i)) != 0) && 2348 ((cs_d0 & (1 << j)) != 0)) || 2349 (((cs_d1 & (1 << i)) != 0) && 2350 ((cs_d1 & (1 << j)) != 0))) { >>> CID 369882: (BAD_SHIFT) >>> In expression "1 << i", shifting by a negative amount has undefined behavior. The shift amount, "i", is no more than -1. 2351 odt[j] |= (1 << i) << shift; 2352 } 2353 } 2354 break; 2355 case DDR_ODT_NEVER: 2356 break; /drivers/nxp/ddr/phy-gen2/phy.c: 2298 in parse_odt() 2292 2293 if (i < 0 || i > 3) { 2294 printf("Error: invalid chip-select value\n"); 2295 } 2296 switch (val) { 2297 case DDR_ODT_CS: >>> CID 369882: (BAD_SHIFT) >>> In expression "1 << i", shifting by a negative amount has undefined behavior. The shift amount, "i", is no more than -1. 2298 odt[i] |= (1 << i) << shift; 2299 break; 2300 case DDR_ODT_ALL_OTHER_CS: 2301 for (j = 0; j < DDRC_NUM_CS; j++) { 2302 if (i == j) { 2303 continue; /drivers/nxp/ddr/phy-gen2/phy.c: 2316 in parse_odt() 2310 break; 2311 case DDR_ODT_CS_AND_OTHER_DIMM: 2312 odt[i] |= (1 << i) << 4; 2313 /* fallthrough */ 2314 case DDR_ODT_OTHER_DIMM: 2315 for (j = 0; j < DDRC_NUM_CS; j++) { >>> CID 369882: (BAD_SHIFT) >>> In expression "1 << i", shifting by a negative amount has undefined behavior. The shift amount, "i", is no more than -1. 2316 if ((((cs_d0 & (1 << i)) != 0) && 2317 ((cs_d1 & (1 << j)) != 0)) || 2318 (((cs_d1 & (1 << i)) != 0) && 2319 ((cs_d0 & (1 << j)) != 0))) { 2320 odt[j] |= (1 << i) << shift; 2321 } ** CID 369881: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 369881: Memory - corruptions (OVERRUN) /drivers/brcm/i2c/i2c.c: 556 in i2c_init() 550 { 551 if (bus_id > MAX_I2C) { 552 WARN("%s: Invalid Bus %u\n", __func__, bus_id); 553 return -1; 554 } 555 >>> CID 369881: Memory - corruptions (OVERRUN) >>> Overrunning callee's array of size 2 by passing argument "bus_id" (which evaluates to 2) in call to "iproc_i2c_init". 556 iproc_i2c_init(bus_id, speed); 557 return 0U; 558 } 559 560 /* 561 * Function Name: i2c_probe ** CID 369880: Error handling issues (CHECKED_RETURN) /drivers/nxp/ddr/nxp-ddr/utility.c: 43 in get_ddr_freq() ________________________________________________________________________________________________________ *** CID 369880: Error handling issues (CHECKED_RETURN) /drivers/nxp/ddr/nxp-ddr/utility.c: 43 in get_ddr_freq() 37 #define CCN_HN_F_SAM_NODEID_DDR1 0x18 38 #endif 39 40 unsigned long get_ddr_freq(struct sysinfo *sys, int ctrl_num) 41 { 42 if (sys->freq_ddr_pll0 == 0) { >>> CID 369880: Error handling issues (CHECKED_RETURN) >>> Calling "get_clocks" without checking return value (as is done elsewhere 4 out of 5 times). 43 get_clocks(sys); 44 } 45 46 switch (ctrl_num) { 47 case 0: 48 return sys->freq_ddr_pll0; ** CID 369879: Memory - corruptions (ARRAY_VS_SINGLETON) ________________________________________________________________________________________________________ *** CID 369879: Memory - corruptions (ARRAY_VS_SINGLETON) /drivers/brcm/i2c/i2c.c: 763 in i2c_write_byte() 757 struct iproc_xact_info info; 758 759 iproc_i2c_fill_info(&info, bus_id, devaddr, regoffset, &value, 760 SMBUS_PROT_WR_BYTE, 1U); 761 762 /* Refer to i2c_smbus_write_byte params passed. */ >>> CID 369879: Memory - corruptions (ARRAY_VS_SINGLETON) >>> Passing "info.data" via argument "&info" to function "iproc_i2c_data_send" which uses it as an array. This might corrupt or misinterpret adjacent memory locations. 763 rc = iproc_i2c_data_send(&info); 764 765 if (rc < 0) { 766 ERROR("%s: %s error accessing device 0x%x\n", 767 __func__, "Write", devaddr); 768 return -1; ** CID 369878: Control flow issues (DEADCODE) /drivers/nxp/ddr/nxp-ddr/utility.c: 169 in disable_unused_ddrc() ________________________________________________________________________________________________________ *** CID 369878: Control flow issues (DEADCODE) /drivers/nxp/ddr/nxp-ddr/utility.c: 169 in disable_unused_ddrc() 163 debug("Both controllers in use.\n"); 164 return 0; 165 } 166 167 for (i = 0; i < num_hnf_nodes; i++) { 168 val = mmio_read_64((uintptr_t)hnf_sam_ctrl); >>> CID 369878: Control flow issues (DEADCODE) >>> Execution cannot reach the expression "i < 4" inside this statement: "nodeid = ((disable_ddrc == ...". 169 nodeid = disable_ddrc == 1 ? CCN_HN_F_SAM_NODEID_DDR1 : 170 (disable_ddrc == 2 ? CCN_HN_F_SAM_NODEID_DDR0 : 171 (i < 4 ? CCN_HN_F_SAM_NODEID_DDR0 172 : CCN_HN_F_SAM_NODEID_DDR1)); 173 if (nodeid != (val & CCN_HN_F_SAM_NODEID_MASK)) { 174 debug("Setting HN-F node %d\n", i); ** CID 369877: Incorrect expression (NO_EFFECT) /drivers/nxp/ddr/nxp-ddr/utility.c: 145 in disable_unused_ddrc() ________________________________________________________________________________________________________ *** CID 369877: Incorrect expression (NO_EFFECT) /drivers/nxp/ddr/nxp-ddr/utility.c: 145 in disable_unused_ddrc() 139 switch (disable_ddrc) { 140 case 1: 141 priv->num_ctlrs = 1; 142 priv->spd_addr = &priv->spd_addr[priv->dimm_on_ctlr]; 143 priv->ddr[0] = priv->ddr[1]; 144 priv->ddr[1] = NULL; >>> CID 369877: Incorrect expression (NO_EFFECT) >>> Assigning "priv->phy[0]" to itself has no effect. 145 priv->phy[0] = priv->phy[0]; 146 priv->phy[1] = NULL; 147 debug("Disable first DDR controller\n"); 148 break; 149 case 2: 150 priv->num_ctlrs = 1; ** CID 369876: Incorrect expression (UNUSED_VALUE) /plat/nxp/soc-lx2160a/lx2160aqds/ddr_init.c: 333 in init_ddr() ________________________________________________________________________________________________________ *** CID 369876: Incorrect expression (UNUSED_VALUE) /plat/nxp/soc-lx2160a/lx2160aqds/ddr_init.c: 333 in init_ddr() 327 info.phy_gen2_fw_img_buf = PHY_GEN2_FW_IMAGE_BUFFER; 328 if (info.clk == 0) { 329 info.clk = get_ddr_freq(&sys, 1); 330 } 331 info.dimm_on_ctlr = DDRC_NUM_DIMM; 332 >>> CID 369876: Incorrect expression (UNUSED_VALUE) >>> Assigning value "DDR_WRM_BOOT_NT_SUPPORTED" to "info.warm_boot_flag" here, but that stored value is overwritten before it can be used. 333 info.warm_boot_flag = DDR_WRM_BOOT_NT_SUPPORTED; 334 #ifdef NXP_WARM_BOOT 335 info.warm_boot_flag = DDR_COLD_BOOT; 336 if (wrm_bt_flg != 0U) { 337 info.warm_boot_flag = DDR_WARM_BOOT; 338 } else { ** CID 369875: Uninitialized variables (UNINIT) /drivers/nxp/flexspi/nor/fspi.c: 134 in fspi_op_setup() ________________________________________________________________________________________________________ *** CID 369875: Uninitialized variables (UNINIT) /drivers/nxp/flexspi/nor/fspi.c: 134 in fspi_op_setup() 128 x_addr = FSPI_LUTREG_OFFSET + (uint32_t)(0x10 * fspi_op_seq_id); 129 if ((F_FLASH_SIZE_BYTES <= SZ_16M_BYTES) || (ignore_flash_sz)) { 130 x_instr0 = FSPI_INSTR_OPRND0(cmd_id1); 131 x_instr1 = FSPI_INSTR_OPRND1(FSPI_LUT_ADDR24BIT); 132 VERBOSE("CMD_ID = %x offset = 0x%x\n", cmd_id1, x_addr); 133 } else { >>> CID 369875: Uninitialized variables (UNINIT) >>> Using uninitialized value "cmd_id2". 134 x_instr0 = FSPI_INSTR_OPRND0(cmd_id2); 135 x_instr1 = FSPI_INSTR_OPRND1(FSPI_LUT_ADDR32BIT); 136 VERBOSE("CMD_ID = %x offset = 0x%x\n", cmd_id2, x_addr); 137 } 138 x_instr0 |= FSPI_INSTR_PAD0(FSPI_LUT_PAD1) 139 | FSPI_INSTR_OPCODE0(FSPI_LUT_CMD); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 6 months

1
0
0 0

Re: [TF-A] please fix incomplete distclean Makefile target

by Nicolas Boulenguez

raghu.ncstate(a)icloud.com: > Are you pushing ssh://<username>@review.trustedfirmware.org:29418/TF-A/trusted-firmware-a HEAD:refs/for/integration? > Note that 29418 port. That tripped me up initially. It is not clear from your earlier emails where you cloned from(review.trustedfirmware.org or git.trustedfirmware.org). [α] links to [β] which recommends # git clone "https://review.trustedfirmware.org/TF-A/trusted-firmware-a" I had an existing repository (most contributors probably do) and used 'git add remote' and 'git fetch' instead. [α] recommends # git push <remote-name> HEAD:refs/for/integration%<topic-branch> As expected, the host requires a password. # git push ssh://<user>@review.trustedfirmware.org:29418/TF-A/trusted-firmware-a HEAD:refs/for/integration? -> fatal: invalid refspec 'HEAD:refs/for/integration?' Anyhow, the host would require an SSH key. [α] https://developer.trustedfirmware.org/w/tf_a/gerrit-getting-started/ [β] https://review.trustedfirmware.org/admin/repos/TF-A%2Ftrusted-firmware-a

4 years, 7 months

1
0
0 0

Re: [TF-A] please fix incomplete distclean Makefile target

by Sandrine Bailleux

Hi Nicolas, On 3/29/21 12:40 AM, Nicolas Boulenguez via TF-A wrote: > Currently, tools/cert_create/cert_create is not removed. > The attached one-line patch fixes this. Thank you for your patch! The TF-A project uses the Gerrit review system for patch reviews, would you mind resending your patch on review.trustedfirmware.org please? If you need help with that, there's a "getting started" guide there (it is a bit outdated but hopefully still helpful): https://developer.trustedfirmware.org/w/tf_a/gerrit-getting-started/ And our project specific contribution guidelines are there: https://trustedfirmware-a.readthedocs.io/en/latest/process/contributing.html Regards, Sandrine

4 years, 7 months

2
6
0 0

Glitching protection

by François Ozog

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

4 years, 7 months

4
8
0 0

Re: [TF-A] Firmware FuSa workshop

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, 7 months

1
0
0 0

please fix incomplete distclean Makefile target

by Nicolas Boulenguez

Hello. Currently, tools/cert_create/cert_create is not removed. The attached one-line patch fixes this.

4 years, 7 months

1
0
0 0

TF-A OpenCI Update

by Joanna Farley

Hi Everyone, I wanted to give an update on the availability of the TF-A OpenCI. Recognised projects contributors can now invoke the OpenCI on patches they submit or patches they review through Gerrit and so view results and fix any issues identified without an Arm reviewer having to intercede and start the Open CI for them. This is achieved in Gerrit patches (https://review.trustedfirmware.org/p/TF-A/trusted-firmware-a/+/dashboard/si…) by setting the Allow-CI label with +1 or +2 where +1 is a light level of testing and +2 includes additional tests on top of the +1 tests. Results are linked to in the Gerrit patch comments. Recognised projects contributors is currently seeded as everybody listed in https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/about… including all maintainers and code-owners. The intent going forward is to include others when vouched for by other recognised projects contributors. In this way we hope to be open to all project contributors to have access to the OpenCI while providing some protection to the OpenCI back end resources. The plan is to have another TF-A Tech-Forum session on the OpenCI on 8th April 2021 where more of the details of the OpenCI can be shared, discussed and questions can be taken. For now please experiment with the OpenCI through your patch submissions or reviews. Please be aware this is a shared resource and use when appropriate during the patch review and be tolerant if its not quite perfect yet. Please rest assured the existing Legacy CI is still available during this transition to the OpenCI where needed to help ensure patches are adequately tested to maintain repository quality levels. I’ll like to say a big thanks to the Linaro team working in the background to provide the OpenCI service to the TF-A project. Cheers Joanna

4 years, 7 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, 7 months

2
2
0 0

Glitching protection

by Tamas Ban

Hi, Recently the same fault injection protection code what is used in MCUboot was added to TF-M project. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7468 It is a library which can be reused in any project to harden the critical call path and condition checks, which are crucial from device security point of view. BR, Tamas Ban

4 years, 7 months

1
1
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, 7 months

1
0
0 0

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

by Peng Fan

Hi Sandeep, I just noticed that your PR is abandoned. Will you resend your PR? Thanks, Peng. ________________________________ From: OP-TEE <op-tee-bounces(a)lists.trustedfirmware.org> on behalf of Peng Fan via OP-TEE <op-tee(a)lists.trustedfirmware.org> Sent: Tuesday, March 23, 2021 10:14 AM To: Sandeep Tripathy <sandeep.tripathy(a)broadcom.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; op-tee(a)lists.trustedfirmware.org <op-tee(a)lists.trustedfirmware.org> Subject: RE: [TF-A] EHF + OPTEE on ARM64 Hi Sandeep > Subject: Re: [TF-A] EHF + OPTEE on ARM64 > > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… > > 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. I was trying using #ifndef SPD_opteed to wrap the secure stuff. Thanks for your patch. I test on i.MX8MM-EVK, it works well. Thanks, Peng. > > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustedfi… > andling.html?highlight=Exception%20Handling%20Framework > > > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

4 years, 7 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, 7 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, 7 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, 7 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, 7 months

1
0
0 0

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, 7 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, 7 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, 7 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, 7 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, 7 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, 7 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, 7 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, 7 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, 7 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, 7 months

1
0
0 0

Re: [TF-A] Deprecating Arm's sgm775 platform

by Joanna Farley

We already have a Deprecated Interfaces removal policy for core interfaces: https://trustedfirmware-a.readthedocs.io/en/latest/about/release-informatio… although this is not quite the same for platforms the proposed purpose is similar of a managed removing of something that someone has a use case for in the short term. The Arm platforms as mentioned by Manish are targeted as reference platforms for other project users to inspect which is perhaps a little different than other platform providers. So I think it is appropriate to have a transition period as those references platforms become outdated and normally replaced as it is with the sgm775 with the tc0 platform. I can understand for other platform providers they might want a more accelerated or removal approach and that’s fine I think. I’m not suggesting we need to create a formal policy but leave it up to individual platform providers to decide how they manage their platforms as they know best how they are used. Ensuring that the OpenCI is not left in a broken state from a build or test perspective during a deprecation period is of course necessary and the steps suggested by Manish look reasonable to me. Hope this helps on the intent here. Joanna From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org> Reply to: Varun Wadekar <vwadekar(a)nvidia.com> Date: Thursday, 11 March 2021 at 22:12 To: Manish Pandey2 <Manish.Pandey2(a)arm.com> Cc: "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Deprecating Arm's sgm775 platform Hi, I was wondering if there is any value in keeping non-compiling code in the tree, hence the question. For Tegra it is straight forward, so it would be easy to pull the plug. -Varun From: Manish Pandey2 <Manish.Pandey2(a)arm.com> Sent: Thursday, March 11, 2021 2:44 AM To: Varun Wadekar <vwadekar(a)nvidia.com> Cc: tf-a(a)lists.trustedfirmware.org Subject: Re: Deprecating Arm's sgm775 platform External email: Use caution opening links or attachments Hi Varun, For Arm reference platforms, we are not sure who all are using it. That is why i proposed to keep in repo for around a year before deleting it. But for NV platforms, if you are sure that nobody is going to require it, you can delete it earlier. Also, instead of proposed step 2 earlier we can have an alternate - 2. Don't allow it to be built by default. (introducing PLATFORM_DEPRECATED build macro) + 2. Instead of purposefully failing the build we can print a warning message (It's also quite possible that someday during cooling off period it stops to build naturally) thanks Manish ________________________________ From: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>> Sent: 11 March 2021 02:35 To: Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> Cc: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: RE: Deprecating Arm's sgm775 platform Hi Manish, Just curious, what would be the reason to keep the platform alive for 2 release cycles? I have one Tegra platform that needs to be deprecated and so would like to understand the thought process. -Varun From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> On Behalf Of Manish Pandey2 via TF-A Sent: Tuesday, March 9, 2021 2:01 PM To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Subject: [TF-A] Deprecating Arm's sgm775 platform External email: Use caution opening links or attachments Hi, The purpose of the email is to notify about deprecation of sgm775 platform and proposed process for deprecating a platform. Arm's System Guidance for Mobile(SGM-775) is an old platform and no longer maintained. It is superseded by Total Compute(tc0) platform. Proposal for deprecating a platform: 1. Keep the code in repository. (at least for 2 release cycles) 2. Don't allow it to be built by default. (introducing PLATFORM_DEPRECATED build macro) 3. Disable CI testing. 4. Create appropriate documentation for deprecated platforms. Let me know if you have any suggestions. Thanks Manish P

4 years, 7 months

1
0
0 0

Re: [TF-A] [EXT] RE: NXP Patch-Set for platform lx2160ardb/lx2160aqds/lx2162aqds

by Pankaj Gupta

Hi, Thank you once again for more of your comments. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/6122<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> to https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/6167 All the patches from the patch-set, are reviewed and all the comments are disposed-off till date. Please share any further action, I need to work on. Looking forward for your continued support. Regards Pankaj From: Varun Wadekar <vwadekar(a)nvidia.com> Sent: Tuesday, February 2, 2021 12:11 AM To: Pankaj Gupta <pankaj.gupta(a)nxp.com>; Manish Pandey2 <Manish.Pandey2(a)arm.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; javier.almansasobrino(a)arm.com; jimmy.brisson(a)arm.com Cc: Joanna Farley <Joanna.Farley(a)arm.com>; Alexei Fedorov <Alexei.Fedorov(a)arm.com>; Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com> Subject: [EXT] RE: NXP Patch-Set for platform lx2160ardb/lx2160aqds/lx2162aqds Caution: EXT Email Thanks Pankaj. I don't have further comments. From: Pankaj Gupta <pankaj.gupta(a)nxp.com<mailto:pankaj.gupta@nxp.com>> Sent: Sunday, January 31, 2021 11:14 PM To: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>>; Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>>; Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>>; javier.almansasobrino(a)arm.com<mailto:javier.almansasobrino@arm.com>; jimmy.brisson(a)arm.com<mailto:jimmy.brisson@arm.com> Cc: Joanna Farley <Joanna.Farley(a)arm.com<mailto:Joanna.Farley@arm.com>>; Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>>; Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com<mailto:Madhukar.Pappireddy@arm.com>> Subject: NXP Patch-Set for platform lx2160ardb/lx2160aqds/lx2162aqds External email: Use caution opening links or attachments Hi all, Thanks to all of you, for your efforts in reviewing the patches. All the patches from the patch-set, are reviewed and all the comments are disposed-off till date. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/6122<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> to https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/6167<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> Please share any further action, I need to work on. Looking forward for your continued support. Thanks & regards Pankaj From: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>> Sent: Friday, December 4, 2020 10:37 PM To: Pankaj Gupta <pankaj.gupta(a)nxp.com<mailto:pankaj.gupta@nxp.com>>; Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> Cc: Joanna Farley <Joanna.Farley(a)arm.com<mailto:Joanna.Farley@arm.com>>; Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>>; Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com<mailto:Madhukar.Pappireddy@arm.com>> Subject: RE: [EXT] RE: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/6122<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> Caution: EXT Email Thanks Pankaj and Manish. Glad to see us agreeing to a path forward. From: Pankaj Gupta <pankaj.gupta(a)nxp.com<mailto:pankaj.gupta@nxp.com>> Sent: Thursday, December 3, 2020 11:39 PM To: Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>>; Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>> Cc: Joanna Farley <Joanna.Farley(a)arm.com<mailto:Joanna.Farley@arm.com>>; Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>>; Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com<mailto:Madhukar.Pappireddy@arm.com>> Subject: RE: [EXT] RE: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/6122<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> External email: Use caution opening links or attachments Hi, Thanks for the email. Your suggestion is good too. But with your suggestion, two lines are need for one line using the macro. My concern is that, there are 6 SoC and 15+ platforms based on these 6 SoC, still pending to be added to this code base. Keeping things simple in soc.mk and platform.mk is of key importance. To achieve it: * Complexity of source file addition is moved away from platform makefile to: o drivers/nxp/driver.mk, and o drivers/nxp/<ip>/<ip>.mk * As a result, the soc.mk & platform.mk is less cluttered. o With the single line addition based on this macro, it is easier to understand, which IP is part of BL2, BL31 or both. o All the complexity about IP files to be included or not is moved to drivers/nxp/<ip>/<ip>.mk. I got your point here. Since it is very much specific to NXP platforms, it is to be moved to "plat/nxp". I have tried this way. It is working and ready for review. Regards Pankaj From: Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> Sent: Friday, December 4, 2020 6:24 AM To: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>>; Pankaj Gupta <pankaj.gupta(a)nxp.com<mailto:pankaj.gupta@nxp.com>> Cc: Joanna Farley <Joanna.Farley(a)arm.com<mailto:Joanna.Farley@arm.com>>; Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>>; Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com<mailto:Madhukar.Pappireddy@arm.com>> Subject: Re: [EXT] RE: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/6122<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> Caution: EXT Email Hi Pankaj, I am still trying to understand the complete patchset, also trying to understand different level of makefiles e.g drivers/nxp/drivers.mk(is it really needed?) I think the main concern is complexity added by intermediate mk files, this complexity can be reduced by declaring most of things in specific platform mk file as we know at compile time which all images need a particular driver. For e.g XSPI driver, it has same source files in all the 3 scenarios (BL2/BL31 & COMMON) and there is no usage of IMAGE_BL31, IMAGE_BL2 in xspi driver suggesting that Image type does not alters functionality of driver. So, what we can do is keeping driver mk file simpler and other details in platform mk file. flexspi_xor.mk will be like: XSPI_BOOT_SOURCES += $(FLEXSPI_DRIVERS_PATH)/flexspi_nor.c \ ${FLEXSPI_DRIVERS_PATH}/fspi.c ifeq ($(DEBUG),1) XSPI_BOOT_SOURCES += ${FLEXSPI_DRIVERS_PATH}/test_fspi.c endif Platform mk file will be like: (say only bl2 needs xspi) XSPI_NEEDED := yes bl2_sources += ${XSPI_BOOT_SOURCES} Regarding NEED_BL31/NEED_BL2, these flags tell if binary for given BL stage needs to be generated or not. Finally, I am not saying that your approach is wrong but what i suggested is currently done by most of the platforms. Also, see my comments on your SET_FLAG patch, if we indeed decide to go ahead with your current approach. Thanks Manish ________________________________ From: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>> Sent: 03 December 2020 17:35 To: Pankaj Gupta <pankaj.gupta(a)nxp.com<mailto:pankaj.gupta@nxp.com>> Cc: Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> Subject: RE: [EXT] RE: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/6122<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> Hi, Can you point me to a change that uses the newly introduced makefile macro? IIUC, you just need a way to differentiate between a BL2 v BL31 build. Manish can you confirm if NEED_BL31 and NEED_BL2 can be helpful in this case? >> I will replace the SET_FLAG macro with these two flags from entire source tree. I suppose you are alluding to the NXP platform port only. Correct? -Varun From: Pankaj Gupta <pankaj.gupta(a)nxp.com<mailto:pankaj.gupta@nxp.com>> Sent: Thursday, December 3, 2020 12:57 AM To: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>> Cc: Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> Subject: RE: [EXT] RE: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/6122<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> External email: Use caution opening links or attachments Hi Varun, Thanks for your email. NXP make files are implemented as : 1. Each IP driver has its own .mk file. 2. Each platform has its own "platform.mk". * Every "platform.mk" includes "soc.mk" for the SoC on which this platform is based. 1. Based on the SoC, mandatory IP(s) are included(soc.mk) to BL2 or BL31 or both. * This requires to pass the flag "<BL2 or BL31 or BL_COMM>_<IP>_NEEDED = yes" from soc.mk to mandatory IP(s) .mk. 1. But for certain IP(s), IP file sources inclusions to either BL2 or BL31, is based on optional features. * This also requires to pass the flag to IP(s) .mk. For instance: * If flexspi_nor as a boot-source, This macro sets 2 flags. i. XSPI_NEEDED = yes * XSPI_NEEDED help identify if the xspi.mk needs to be included or not. ii. BL2_ XSPI_NEEDED = yes * XSPI_NEEDED needs to be included in BL2 * In optional feature WARM_RESET, I need to save the last reset_cause in flexspi_nor in BL31. i. Again need two flags: XSPI_NEEDED = yes & BL31_ XSPI_NEEDED = yes ii. XSPI_NEEDED = yes, is still required as it might happen the boot source is SD. * In this case BL2_XSPI_NEEDED, is not set. What I am gaining with this macros is: * Without this macro, I need to add two lines: * <IP>_NEEDED = yes. * To include this driver. * One of the flag to be added depending on the IP source file inclusion to BL2 or BL31 or BL_COMM: * Flag as BL2_<IP>_NEEDED = yes * Flag as BL31_<IP>_NEEDED = yes. * Flag as BLCOMM_<IP>_NEEDED = yes. * This macros helps me add one line $(eval $(call SET_FLAG, <IP>_NEEDED,BL2)), instead of above two lines. If you suggest to remove the SET_FLAG macro, I will replace the SET_FLAG macro with these two flags from entire source tree. Please share your view. I reviewed the usage of NEED_BL31 and NEED_BL2. They are set to 'yes' in ./Makefile, only when BL2_SOURCES & BL31_SOURCES is non-null; They can be over-ridden, but cannot be used for each IP(s) source file. Regards Pankaj From: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>> Sent: Thursday, December 3, 2020 4:17 AM To: Pankaj Gupta <pankaj.gupta(a)nxp.com<mailto:pankaj.gupta@nxp.com>> Cc: Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> Subject: [EXT] RE: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/6122<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> Caution: EXT Email Hi, >From your description, I think you are including different makefiles from NXP tree for BL31 versus BL2. Can you please help me understand why this decision needs to be taken at the top level makefile? Alternatively, why can't NXP platform decide which files to include? Did you get a chance to review the NEED_BL31, NEED_BL2 makefile variables? >From the gerrit change it is very difficult to understand how the newly introduced macro is used, so trying to suggest already available options to see if they work for you. -Varun From: Pankaj Gupta <pankaj.gupta(a)nxp.com<mailto:pankaj.gupta@nxp.com>> Sent: Wednesday, December 2, 2020 5:21 AM To: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>> Cc: Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> Subject: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/6122<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> External email: Use caution opening links or attachments Hi Varun, As suggested by you, IMAGE_BL31, IMAGE_BL2 etc macros are useful for segregating the code within the same source file. But this will not serve the purpose in our case. Let me try to explain you with an example: -- For one platform; and for a particulate IP driver's source file, if it is true to have in both, then : #if defined(IMAGE_BL2) || #if defined(IMAGE_BL31) -- But for another platform and for the same IP driver's source file, if it is true to have in BL2 only, then: #if defined(IMAGE_BL2) -- And for another SoC and for the same IP driver's source file, it if is true to have in BL31 only, then: #if defined(IMAGE_BL31) It will not be possible to write all the three varying inclusion of code for one IP used across multiple SoC and their platforms. Now, I will explain how this macro helps me with above case: * Taking an example of flexspi_nor as a boot-source: * $(eval $(call SET_FLAG, XSPI_NEEDED,BL2)) * This macro sets 2 flags. * XSPI_NEEDED = yes * XSPI_NEEDED help identify if the xspi.mk needs to be included or not. * BL2_ XSPI_NEEDED = yes * XSPI_NEEDED needs to be included in BL2. * For a conditional feature to enable in BL31, XSPI is to be included in BL31. * BL31_XSPI_NEEDED = yes needs to be set. * The correct solution should be if the feature is enabled, then: $(eval $(call SET_FLAG, XSPI_NEEDED,BL31)) * In this case, I cannot set BL_COMM_XSPI_NEED = yes for all the platforms. I hope, I am able to convey my thoughts to you. This macro is very important for my code orientation. If you think it will not be required by other contributors, then lets rename this macro by prepending it with NXP or any name you suggests. Thanks. Regards Pankaj 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, 7 months

1
1
0 0

Re: [TF-A] Deprecating Arm's sgm775 platform

by Varun Wadekar

Hi Manish, Just curious, what would be the reason to keep the platform alive for 2 release cycles? I have one Tegra platform that needs to be deprecated and so would like to understand the thought process. -Varun From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Manish Pandey2 via TF-A Sent: Tuesday, March 9, 2021 2:01 PM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Deprecating Arm's sgm775 platform External email: Use caution opening links or attachments Hi, The purpose of the email is to notify about deprecation of sgm775 platform and proposed process for deprecating a platform. Arm's System Guidance for Mobile(SGM-775) is an old platform and no longer maintained. It is superseded by Total Compute(tc0) platform. Proposal for deprecating a platform: 1. Keep the code in repository. (at least for 2 release cycles) 2. Don't allow it to be built by default. (introducing PLATFORM_DEPRECATED build macro) 3. Disable CI testing. 4. Create appropriate documentation for deprecated platforms. Let me know if you have any suggestions. Thanks Manish P

4 years, 7 months

2
2
0 0

Cancelled event: TF-A Tech Forum @ Thu 11 Mar 2021 16:00 - 17:00 (GMT) (tf-a@lists.trustedfirmware.org)

by Bill Fletcher

This event has been cancelled. 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 11 Mar 2021 16:00 – 17:00 United Kingdom Time 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 organiser and be added to the guest list, 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, 7 months

1
0
0 0

Re: [TF-A] gerrit issues: not able to add additional email

by Yann Gautier

Hi Gyorgy, I've added a new mail address in gerrit last month. I can see both addresses in gerrit Email Addresses. I've chosen the new one as my preferred address. And I only receive gerrit mails on this preferred address. Best regards, Yann On 3/10/21 4:26 PM, Gyorgy Szing via TF-A wrote: > Hi, > > I just tried it and got the notification e-mail. > > Note: I filled the "New email address" text box and pressing "Send Verification" below. If that adds an additional email or replaces the current one is unknown to me. > > /George > > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Igor Opaniuk via TF-A > Sent: 10 March 2021 13:44 > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] gerrit issues: not able to add additional email > > Hi, > > Gerrit for some reason doesn't send verification emails when adding additional email in account settings [1]. > I've tried to add two different emails, in both cases with no success. > Anyone could quickly check if you can receive verification? > > Thanks > > [1] https://review.trustedfirmware.org/settings#EmailAddresses > > -- > Best regards - Freundliche Grüsse - Meilleures salutations > > Igor Opaniuk > > mailto: igor.opaniuk(a)gmail.com > skype: igor.opanyuk > +380 (93) 836 40 67 > http://ua.linkedin.com/in/iopaniuk > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a >

4 years, 7 months

2
1
0 0

Re: [TF-A] gerrit issues: not able to add additional email

by Gyorgy Szing

Hi, I just tried it and got the notification e-mail. Note: I filled the "New email address" text box and pressing "Send Verification" below. If that adds an additional email or replaces the current one is unknown to me. /George -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Igor Opaniuk via TF-A Sent: 10 March 2021 13:44 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] gerrit issues: not able to add additional email Hi, Gerrit for some reason doesn't send verification emails when adding additional email in account settings [1]. I've tried to add two different emails, in both cases with no success. Anyone could quickly check if you can receive verification? Thanks [1] https://review.trustedfirmware.org/settings#EmailAddresses -- Best regards - Freundliche Grüsse - Meilleures salutations Igor Opaniuk mailto: igor.opaniuk(a)gmail.com skype: igor.opanyuk +380 (93) 836 40 67 http://ua.linkedin.com/in/iopaniuk -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 7 months

1
0
0 0

gerrit issues: not able to add additional email

by Igor Opaniuk

Hi, Gerrit for some reason doesn't send verification emails when adding additional email in account settings [1]. I've tried to add two different emails, in both cases with no success. Anyone could quickly check if you can receive verification? Thanks [1] https://review.trustedfirmware.org/settings#EmailAddresses -- Best regards - Freundliche Grüsse - Meilleures salutations Igor Opaniuk mailto: igor.opaniuk(a)gmail.com skype: igor.opanyuk +380 (93) 836 40 67 http://ua.linkedin.com/in/iopaniuk

4 years, 7 months

1
0
0 0

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

by Joanna Farley

Apologies for the late notice I am cancelling this weeks TF-A Tech forum tomorrow as we don’t have any subjects ready to present this week. We expect to have subjects for the next two sessions on 25th March and 8th April. Any subjects for future Tech-Forums from the contributor community always welcome so please reach out and I will help schedule. These can be more formal presentations or led discussions on subjects of interest to the TF-A project community. Cancellation of the calendar invite will come from trustedformware.org as I don’t own the invite so it may not appear in your calendars until that is sent out. Thanks Joanna

4 years, 7 months

1
0
0 0

Deprecating Arm's sgm775 platform

by Manish Pandey2

Hi, The purpose of the email is to notify about deprecation of sgm775 platform and proposed process for deprecating a platform. Arm's System Guidance for Mobile(SGM-775) is an old platform and no longer maintained. It is superseded by Total Compute(tc0) platform. Proposal for deprecating a platform: 1. Keep the code in repository. (at least for 2 release cycles) 2. Don't allow it to be built by default. (introducing PLATFORM_DEPRECATED build macro) 3. Disable CI testing. 4. Create appropriate documentation for deprecated platforms. Let me know if you have any suggestions. Thanks Manish P

4 years, 7 months

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 367340: Control flow issues (MISSING_BREAK) /plat/mediatek/mt8192/drivers/spm/mt_spm_vcorefs.c: 372 in spm_vcorefs_args() ________________________________________________________________________________________________________ *** CID 367340: Control flow issues (MISSING_BREAK) /plat/mediatek/mt8192/drivers/spm/mt_spm_vcorefs.c: 372 in spm_vcorefs_args() 366 uint64_t spm_vcorefs_args(uint64_t x1, uint64_t x2, uint64_t x3, uint64_t *x4) 367 { 368 uint64_t cmd = x1; 369 uint64_t spm_flags; 370 371 switch (cmd) { >>> CID 367340: Control flow issues (MISSING_BREAK) >>> The case for value "VCOREFS_SMC_CMD_INIT" is not terminated by a "break" statement. 372 case VCOREFS_SMC_CMD_INIT: 373 /* vcore_dvfs init + kick */ 374 mmio_write_32(DVFSRC_SW_REQ5, SW_REQ5_INIT_VAL); 375 spm_dvfsfw_init(0ULL, 0ULL); 376 spm_vcorefs_vcore_setting(x3 & 0xF); 377 spm_flags = SPM_FLAG_RUN_COMMON_SCENARIO; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 8 months

1
0
0 0

Re: [TF-A] Adoption of Conventional Commits

by Joanna Farley

I was away last week for the tech forum and not had time to watch the recording which I need to do before joining some of this discussions but I can clarify the purpose of the Changelog and the difference with the git history. The Changelog is part of the release documentation that summarises the main feature and changes that the release delivers. Its not expected every change in the git log history is included it is about recording the main themes of changes grouped together rather than chronologically. Most importantly it meant to be readable and understandable. I would expect as with any such documentation that some manual editing may be needed but the ask was for suggestions to make this task easier. As it stands today creating the Changelog can take days of manually reading the git history and re-writing, infact it’s the most labour intensive single task we do in a release. So guidance, formatting and tooling in creating commit messages so we can reuse them in release documentation is the ask. If this helps consumption of the git log history for other purposes that’s a great bonus. Tooling and automation makes things more efficient for all. Making submitting patches from developers harder is defiantly not the goal, hopefully the tooling makes the effort easier or at least the same level of effort for the developer, if not the solution being sought needs improving. Now we could do away with the release Changelog as it is today but the git log history is not a replacement for user facing release documentation. Before you know it we do away with all documentation and tell consumers to just read the source code 😉 Quote: “… documentation may mean different things to people in different roles.” Joanna From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Gyorgy Szing via TF-A <tf-a(a)lists.trustedfirmware.org> Reply to: Gyorgy Szing <Gyorgy.Szing(a)arm.com> Date: Wednesday, 3 March 2021 at 13:26 To: Chris Kay <Chris.Kay(a)arm.com>, Varun Wadekar <vwadekar(a)nvidia.com>, "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-A] Adoption of Conventional Commits Hi, I think the basic question is: what is the difference between the change-log and the git history? Depending on how we draw the line between the release notes and the change log the answer can be: not much. The change log mostly filters and extends the git history. And this filtering and extending needs a lot of manual work currently. But why we wanted to have two change-logs then? The real difference is the presentation format (reST/HTML vs git log), and the tooling you need to be able to read. If the above is true, then the git log -> changelog transformation can be automated, but that needs the git history being machine readable. For developers this creates the requirement to properly format the commit message, and for reviewers adds extra work too. But that can be automated too right? And this is why we need tooling. Tooling on commit message authoring can be optional, but validation tools are mandatory. Otherwise we will end up with badly formatted commit messages (yes, manual validation is boring an error prone), failing automated translation, and the whole effort misses it’s main point. (And as a side effect we also get a git hook framework, which is making a step forward with standardizing distributed automation.) /George From: Chris Kay <Chris.Kay(a)arm.com> Sent: 03 March 2021 03:56 To: Varun Wadekar <vwadekar(a)nvidia.com>; Gyorgy Szing <Gyorgy.Szing(a)arm.com>; tf-a(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-A] Adoption of Conventional Commits Hi Varun, > I think you just increased the scope of the problem. We should add that as a new requirement – the commit message header should be pretty. I don't think the scope has increased, but perhaps the requirement that we are able to generate the changelog was lacking clarity; it's not necessarily that the commit message headers should be pretty, but that the changelog should remain so to the extent that it can - it is still user-facing documentation, after all. By extension, we gain nothing from using the commit log to generate the changelog if they just mirror one another. > Honestly, we should also check if in an effort to make the changelog “pretty”, are we losing the traditional git log formatting. Honestly, the git log gets used more than the changelog, so your proposal of changing the commit header has a greater impact. I would like to make this low impact to the developers that create patches on a daily basis. The point I'm trying to emphasise is that there is no traditional Git log formatting - as it stands today, our commit guidelines make no mention of tags. As a result, the tags we do see vary drastically, from none at all to generic "TF-A:" tags, to platforms, drivers and sometimes to specific files. Everybody has their own status quo which they obviously want to maintain, but at some point we have to try to bring everybody onto the same page - commit style rules are not particularly rare for the same reasons code style rules aren't. I don't think the CC rules deviate all that much from the styles we most often see today. > Introducing a completely new way of creating the commit message header or introducing more scripts to create that format is a no-no. There are no mandatory scripts involved - you can continue to write your commits as you do today. The only tangible difference is that we are standardising the tag syntax. > Personally, I feel that you are getting the required information from the git log by just adding tags, which to me, seems like a very low impact approach. Incidentally, it was this very disagreement that brought on this investigation - you can see exactly what the v2.4 changelog looked like<https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/6654/1/docs/…> after basic categorisation, which is where it was decided that a straight dump of the commit log did not suffice for user documentation. > Isnt that an easy fix? We just don’t add tags to such commits. I don’t see how “Conventional Commits” is better. You can avoid tagging the revert commit, but you still need to detect whether the probably-tagged commit it reverts was merged before or after last release, and remove it from the log if the latter. I would suggest Conventional Commits is "better" because we don't even have to consider edge cases like these - we've done the configuration, we know it sorts this out for us, and there's nothing more we need to do to make it just work. > As a maintainer, I feel that forcing developers to unlearn the standard way used by almost all other OSS projects, is disruptive. I am all for automating as long as the process does not get in my way every day. But there is no "standard way" - some projects use "component: xyz" (e.g. Linux), others "[component] xyz" (e.g. LLVM), others yet don't use a tag at all (e.g. Mbed TLS), and I would argue most are like us: lax enough that it's largely down to individual contributors to determine their own. This just happens to be one style among many (and, as far as I know, the only one with an entire tooling ecosystem). I appreciate that you have a favoured variant, but I don't think it's any more useful to debate the most popular commit styles than it is to debate the most popular code styles. As we can see today though, TF-A's existing commit guidelines go largely ignored, and it's our intention to rectify that in a way that allows us to do something useful with information that was previously inaccessible. I won't try to argue that enforcing something that wasn't previously enforced takes some initial getting used to, but I think the emphasis on the "extra work for committers" is severely overrepresented here - realistically, it's a minimal change to how we format the tags that we already write, and it's something some of us have already had to get used to (and have, honestly with very little effort). > I think any proposal should be scalable and forward looking. I’m sure we will hit a scenario where someone needs custom tags and this proposal does not allow us that flexibility. It does afford us that flexibility - we can extend the list of supported types, I'm just unsure of why we might. We would not have settled on this solution if we did not believe it to be scalable and, considering it does already see widespread usage, I would argue it's a relatively safe bet that it can handle most, if not all, of what we need now and in the future. Chris ________________________________ From: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>> Sent: 03 March 2021 01:26 To: Chris Kay <Chris.Kay(a)arm.com<mailto:Chris.Kay@arm.com>>; Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>; tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: [TF-A] Adoption of Conventional Commits Hi Chris, I think you just increased the scope of the problem. We should add that as a new requirement – the commit message header should be pretty. Honestly, we should also check if in an effort to make the changelog “pretty”, are we losing the traditional git log formatting. Honestly, the git log gets used more than the changelog, so your proposal of changing the commit header has a greater impact. I would like to make this low impact to the developers that create patches on a daily basis. Introducing a completely new way of creating the commit message header or introducing more scripts to create that format is a no-no. Personally, I feel that you are getting the required information from the git log by just adding tags, which to me, seems like a very low impact approach. On the two examples, I don’t see a big difference in the supposedly human readable log you posted. But the proposal to get that is disruptive. >> You can see here that it emphasises the scope for each change for human readability, and also omits both the revert commit and the commit it reverts because neither of them have been part of a release Isnt that an easy fix? We just don’t add tags to such commits. I don’t see how “Conventional Commits” is better. >> I think burdening reviewers with additional work is likely to prove unreliable, and certainly counter-productive if we can both largely automate the problem away and provide rapid feedback to developers before ever even having to push for review As a maintainer, I feel that forcing developers to unlearn the standard way used by almost all other OSS projects, is disruptive. I am all for automating as long as the process does not get in my way every day. >> The tooling I proposed does already offer some flexibility for defining our own types and scopes, though the default set is already pretty extensive I think any proposal should be scalable and forward looking. I’m sure we will hit a scenario where someone needs custom tags and this proposal does not allow us that flexibility. -Varun From: Chris Kay <Chris.Kay(a)arm.com<mailto:Chris.Kay@arm.com>> Sent: Tuesday, March 2, 2021 4:21 PM To: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>>; Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>; tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-A] Adoption of Conventional Commits External email: Use caution opening links or attachments Hi guys, Note: a lot of this email relies on HTML formatting to force monospace fonts and emphasis – it probably won’t show up correctly on the mailing lists archives. One major point of contention with this model is that it’s not immediately clear what goes into the changelog. The obvious first answer is “the commit subject”, but let’s investigate that. Here are the last 17 commits from upstream as of right now: plat/marvell/armada: cleanup MSS SRAM if used for copy plat/marvell: cn913x: allow CP1/CP2 mapping at BLE stage plat/marvell/armada/common/mss: use MSS SRAM in secure mode libc: memset: Fix MISRA issues plat:xilinx:zynqmp: Remove the custom crash implementation lib: cpus: aarch32: sanity check pointers before use Revert "spmd: ensure SIMD context is saved/restored on SPMC entry/exit" plat/arm/css: rename rd_n1e1_edge_scmi_plat_info array docs: stm32mp1: correct formatting issues marvell: uart: a3720: Increase TX FIFO EMPTY timeout from 2ms to 3ms marvell: uart: a3720: Update delay code to be compatible with 1200 MHz CPU marvell: uart: a3720: Fix comments in console_a3700_core_init() function nxp: added the makefile helper macros spmd: ensure SIMD context is saved/restored on SPMC entry/exit nand: stm32_fmc_nand: remove dead code plat/arm: juno: Refactor juno_getentropy() bl32: Enable TRNG service build Here it is if we applied Conventional Commits to it: feat(marvell armada): cleanup MSS SRAM if used for copy feat(marvell cn913x): allow CP1/CP2 mapping at BLE stage feat(marvell armada): use MSS SRAM in secure mode fix(libc): fix MISRA issues refactor(xilinx zynqmp): remove the custom crash implementation refactor(aarch32): add sanity check pointers before use revert: fix(spmd): ensure SIMD context is saved/restored on SPMC entry/exit refactor(arm css): rename rd_n1e1_edge_scmi_plat_info array docs(stm32mp1): correct formatting issues refactor(marvell a3720): increase TX FIFO EMPTY timeout from 2ms to 3ms refactor(marvell a3720): update delay code to be compatible with 1200 MHz CPU fix(marvell a3720): fix comments in console_a3700_core_init() function build(nxp): add Makefile helper macros fix(spmd): ensure SIMD context is saved/restored on SPMC entry/exit refactor(stm32 fmc_nand): remove dead code refactor(arm juno): Refactor juno_getentropy() feat(bl32): Enable TRNG service build Side note: the “screen real estate” concern some raised does not actually seem to manifest itself in any meaningful way – the longest line only increases by 3 characters, and the shortest line is actually reduced by 3 characters. To me, immediately, the single subject style is much less mentally taxing to parse. Without it, there are at least four different schemes at play here that we need to interpret for every commit (and we’re only 17 commits deep!): foo/bar/baz: xyz foo: bar: baz: xyz foo/bar: baz: xyz Revert “xyz” So, if we just forget about trying to read the history manually for a moment, without a standardised subject format we end up with a changelog that looks like this: Features: - plat/marvell/armada: cleanup MSS SRAM if used for copy - plat/marvell: cn913x: allow CP1/CP2 mapping at BLE stage - plat/marvell/armada/common/mss: use MSS SRAM in secure mode - bl32: Enable TRNG service build Bug Fixes: - libc: memset: Fix MISRA issues - marvell: uart: a3720: Fix comments in console_a3700_core_init() function - spmd: ensure SIMD context is saved/restored on SPMC entry/exit Build System: - nxp: added the makefile helper macros Code Refactoring: - plat:xilinx:zynqmp: Remove the custom crash implementation - lib: cpus: aarch32: sanity check pointers before use - plat/arm/css: rename rd_n1e1_edge_scmi_plat_info array - marvell: uart: a3720: Increase TX FIFO EMPTY timeout from 2ms to 3ms - marvell: uart: a3720: Update delay code to be compatible with 1200 MHz CPU - nand: stm32_fmc_nand: remove dead code - plat/arm: juno: Refactor juno_getentropy() Documentation: - docs: stm32mp1: correct formatting issues Reverts: - Revert "spmd: ensure SIMD context is saved/restored on SPMC entry/exit" This, in my opinion, still suffers from the same problem: as a human, it’s difficult to interpret. Compare that to how we expect that to look with Conventional Commits: Features: - bl32: enable TRNG service build - marvell armada: cleanup MSS SRAM if used for copy - marvell armada: use MSS SRAM in secure mode - marvell cn913x: allow CP1/CP2 mapping at BLE stage Bug Fixes: - libc: fix MISRA issues - marvell a3720: fix comments in console_a3700_core_init() function Build System: - nxp: add Makefile helper macros Code Refactoring: - aarch32: add sanity check pointers before use - arm css: rename rd_n1e1_edge_scmi_plat_info array - arm juno: refactor juno_getentropy() - marvell a3720: increase TX FIFO EMPTY timeout from 2ms to 3ms - marvell a3720: update delay code to be compatible with 1200 MHz CPU - stm32 fmc_nand: remove dead code - xilinx zynqmp: remove the custom crash implementation Documentation: - stm32mp1: correct formatting issues … and I feel like the value prop of using robust tooling becomes more obvious – this tooling is intended not just to categorise commits, but to understand them. You can see here that it emphasises the scope for each change for human readability, and also omits both the revert commit and the commit it reverts because neither of them have been part of a release. Additionally, without a way to enforce this, we’re not necessarily solving one of the current fundamental problems: our changelogs do not accurately and reliably reflect the changes to the project. I think burdening reviewers with additional work is likely to prove unreliable, and certainly counter-productive if we can both largely automate the problem away and provide rapid feedback to developers before ever even having to push for review. Just a quick note on one of your points: 3. Flexibility to define project specific tags The tooling I proposed does already offer some flexibility for defining our own types and scopes, though the default set is already pretty extensive: * build (Build System) * ci (Continuous Integration) * docs (Documentation) * feat (Features) * fix (Bug Fixes) * perf (Performance Improvements) * refactor (Code Refactoring) * revert (Reverts) * style (Styles) * test (Tests) Chris From: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>> Date: Tuesday, 2 March 2021 at 22:31 To: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>, Chris Kay <Chris.Kay(a)arm.com<mailto:Chris.Kay@arm.com>>, tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>, nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: [TF-A] Adoption of Conventional Commits Hi George, Few clarifications. >> it would need significant investments on tooling [VW] I am not sure why you say that. The only expectation form tooling perspective is to run the ‘git log’ command before the release. >> There is no tool which could help developers crafting the commit message in the right format [VW] I don’t think we need a tool to generate commit messages with the right tags. I expect developers to add the tag manually as the footer. Maintainers will have to check that tags exist as part of the reviews. >> Possibly the easiest would be to modify the javascript machinery available for Conventional Commits [VW] I don’t think we need any tools from the “Conventional Commits” toolbox for this to work. My proposal was from the requirements I heard from Chris in the meeting. If there are any implicit or obvious requirements that I missed, I propose we freeze them first. A solution can only work if the requirements are frozen. -Varun From: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>> Sent: Sunday, February 28, 2021 11:14 PM To: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>>; Chris Kay <Chris.Kay(a)arm.com<mailto:Chris.Kay@arm.com>>; tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: [TF-A] Adoption of Conventional Commits External email: Use caution opening links or attachments Hi Varun, I really like your proposal, but it would need significant investments on tooling. There is no tool which could help developers crafting the commit message in the right format, there is no tool, which can validate the format (and be used i.e. as a git-hook), and there is no tool, which can generate the change history document from git history. Can you please extend the proposal and turn it to be an end-to-end solution? Can you contribute tooling for commit message editing and validation, and for change log document generation? Possibly the easiest would be to modify the javascript machinery available for Conventional Commits. Can you contribute the needed changes? /George From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> On Behalf Of Varun Wadekar via TF-A Sent: 26 February 2021 00:39 To: Chris Kay <Chris.Kay(a)arm.com<mailto:Chris.Kay@arm.com>> Cc: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Subject: Re: [TF-A] Adoption of Conventional Commits Hi, I really like the idea of using tags in the commit message, but the rigidity of the spec puts me off. Frankly, I believe we just need a way to identify commits and their intent. So, I would like to propose an approach that builds on the “Conventional Commits” spec. The approach would be 1. Add an identifier (e.g. Tags: fix) to the commit message footer. 2. At the start of the release window run “git log”* to print a list of features, bug fixes, performance improvements, deprecations etc. 3. Either update the main changelog manually or use a script to append individual sections. *git log v2.4...HEAD --no-merges --pretty='- %s (%C(auto)%h)' --grep "Tags: fix"> ‘git log’ can be easily modified to look for other metadata as long as we agree to add it to the commit message. Advantages 1. Light(er) 2. No impact to the subject header 3. Flexibility to define project specific tags 4. Training needs at par with “Conventional Commits” proposal Thoughts? -Varun From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> On Behalf Of Chris Kay via TF-A Sent: Thursday, February 25, 2021 9:31 AM To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Subject: Re: [TF-A] Adoption of Conventional Commits External email: Use caution opening links or attachments Thanks to all those who attended the Tech Forum today! It’s become apparent that the initial 2 week deadline for alternative proposals or implementations is too short, so – as agreed – we’ll push the deadline for the investigation period to the end of March. This period is dedicated to evaluating the changelog automation proposal made, or to identifying alternative solutions. If you have an alternative proposal, any proof-of-concept tooling would be highly appreciated so we can get a clear idea of what sort of work and maintenance is going to be involved. If you do find a solution you wish to propose, please give it just a short name (e.g. “Update it manually”) and make it obvious you want to propose it formally – I’ll collect up the proposals made on the mailing list thread at the end of March and set up a Wiki poll so we can get a clear picture of where the community wants to take this. Chris From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of Chris Kay via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Reply to: Chris Kay <Chris.Kay(a)arm.com<mailto:Chris.Kay@arm.com>> Date: Thursday, 11 February 2021 at 13:59 To: "tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>" <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: [TF-A] Adoption of Conventional Commits Hi all, Recently we had an internal discussion on the merits of introducing semantics to commit messages pushed to the main TF-A repository, the conclusion being that we would look to adopting the Conventional Commits<https://www.conventionalcommits.org/en/v1.0.0/> specification in the near future. There was one major reason for this, which was to help us in automating the changelog in future releases, but it might also help us to dramatically reduce the overall amount of work needed to make a formal release in the future. This requires some buy-in (or buy-out, in this case) from maintainers because - even though it’s to only a relatively minor extent - it does involve an adjustment to everybody’s workflow. Notably, commit messages will be expected to adopt the structure defined by the specification, which will be enforced by the CI. Most commits that go upstream today adhere to “something that looks like Conventional Commits”, so the change is not exactly sweeping, but any change has the potential be an inconvenience. With that in mind, I propose the following: * We collectively adopt the specification, enforced only for @arm.com contributors until such a time that the majority of maintainers are familiar with the new demands * We suggest - in the prerequisites documentation - the installation of two helper tools: * Commitizen<https://github.com/commitizen/cz-cli> * Commitlint<https://github.com/conventional-changelog/commitlint> Installation of these tools will be optional, but I believe they can help with the transition. In the patches currently in review, they are installed as Git hooks automatically upon execution of npm install, so it requires no manual installation or configuration (other than a relatively up-to-date Node.js installation). You’ll find the patches here<https://review.trustedfirmware.org/q/topic:%22ck%252Fconventional-commits%2…>, and specifically the changes to the prerequisites documentation here<https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/8224/1/docs/…>. Feel free to review these changes if you have comments specifically on their implementation. Let me know if you have any questions or concerns. If everybody’s on board, we can look to have this upstreamed shortly. Chris

4 years, 8 months

3
2
0 0

Re: [TF-A] ATF currently does not use proper printf format specifiers for fixed width types

by Chris Kay

Perhaps we ought to look at doing away with maintaining our own version of freestanding headers like stdint.h in the first place – they’re part of the freestanding portion of the C standard library for good reason (the implementations necessarily come directly from the compiler), and reimplementing them is really prone to portability errors like this (and can frequently confuse static analysers). If we are to continue using it, we should at least look into replacing the definitions with the builtin values provided by the compilers we use, e.g. typedef __UINT64_TYPE__ uint64_t;. Using inttypes.h is the traditional wisdom for this particular specifier issue – `ll` for `long long`, `PRIu64` for `uint64_t. While it’s not particularly pleasant to read/write, it was the solution that the C standards committee came up with, so I approve of the principle of this change but I think a permanent solution would serve us better in the long run. Chris From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Joanna Farley via TF-A <tf-a(a)lists.trustedfirmware.org> Date: Wednesday, 3 March 2021 at 15:43 To: Joanna Farley via TF-A <tf-a(a)lists.trustedfirmware.org> Cc: Scott Branden <scott.branden(a)broadcom.com> Subject: [TF-A] ATF currently does not use proper printf format specifiers for fixed width types Hi All, Back in September Scott posted a query to the group related to a patch he has created relating to printf format specifiers and some of the maintainers from Arm have reservations about and we asked him to get opinions from the broader project community as his patch changes a number of different platforms as well as core code. I’m trying to help him reinvigorate the discussion so reposting his request with patch link below that had stalled. Joanna ________________________________ Scott Branden scott.branden at broadcom.com <mailto:tf-a%40lists.trustedfirmware.org?Subject=Re%3A%20%5BTF-A%5D%20ATF%20currently%20does%20not%20use%20proper%20printf%20format%20specifiers%0A%20for%20fixed%20width%20types&In-Reply-To=%3Cbd3b49f4-e8f9-9016-d11b-d08b81e6b43d%40broadcom.com%3E> Mon Sep 14 18:34:45 UTC 2020 Hello, ATF currently uses non-portable printf format specifiers for fixed width types defined in stdint.h In addition, ATF redefines types defined in gcc for stdint.h with its own custom types causing additional issues. This causes compilation issues when porting code to/from ATF. AND, generates coverity parse errors as int64_t and uint64_t are incorrectly defined in ATF vs. gcc for aarch64. The printf format specifiers in inttypes.h are to be used for the proper format specifiers. And, uint64_t/int64_t should be defined the same as in gcc. I tried fixing up all the instances of int64 printf format specifiers by introducing inttypes.h and redefined the stdint types correctly here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5437 We have checked the change into our local tree so that everything compiles and runs in our system. Please accept change upstream. Regards, Scott

4 years, 8 months

2
2
0 0

ATF currently does not use proper printf format specifiers for fixed width types

by Joanna Farley

Hi All, Back in September Scott posted a query to the group related to a patch he has created relating to printf format specifiers and some of the maintainers from Arm have reservations about and we asked him to get opinions from the broader project community as his patch changes a number of different platforms as well as core code. I’m trying to help him reinvigorate the discussion so reposting his request with patch link below that had stalled. Joanna ________________________________ Scott Branden scott.branden at broadcom.com <mailto:tf-a%40lists.trustedfirmware.org?Subject=Re%3A%20%5BTF-A%5D%20ATF%20currently%20does%20not%20use%20proper%20printf%20format%20specifiers%0A%20for%20fixed%20width%20types&In-Reply-To=%3Cbd3b49f4-e8f9-9016-d11b-d08b81e6b43d%40broadcom.com%3E> Mon Sep 14 18:34:45 UTC 2020 Hello, ATF currently uses non-portable printf format specifiers for fixed width types defined in stdint.h In addition, ATF redefines types defined in gcc for stdint.h with its own custom types causing additional issues. This causes compilation issues when porting code to/from ATF. AND, generates coverity parse errors as int64_t and uint64_t are incorrectly defined in ATF vs. gcc for aarch64. The printf format specifiers in inttypes.h are to be used for the proper format specifiers. And, uint64_t/int64_t should be defined the same as in gcc. I tried fixing up all the instances of int64 printf format specifiers by introducing inttypes.h and redefined the stdint types correctly here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5437 We have checked the change into our local tree so that everything compiles and runs in our system. Please accept change upstream. Regards, Scott

4 years, 8 months

1
0
0 0

Re: [TF-A] Adoption of Conventional Commits

by Gyorgy Szing

Hi Varun, I really like your proposal, but it would need significant investments on tooling. There is no tool which could help developers crafting the commit message in the right format, there is no tool, which can validate the format (and be used i.e. as a git-hook), and there is no tool, which can generate the change history document from git history. Can you please extend the proposal and turn it to be an end-to-end solution? Can you contribute tooling for commit message editing and validation, and for change log document generation? Possibly the easiest would be to modify the javascript machinery available for Conventional Commits. Can you contribute the needed changes? /George From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Varun Wadekar via TF-A Sent: 26 February 2021 00:39 To: Chris Kay <Chris.Kay(a)arm.com> Cc: tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] Adoption of Conventional Commits Hi, I really like the idea of using tags in the commit message, but the rigidity of the spec puts me off. Frankly, I believe we just need a way to identify commits and their intent. So, I would like to propose an approach that builds on the “Conventional Commits” spec. The approach would be 1. Add an identifier (e.g. Tags: fix) to the commit message footer. 2. At the start of the release window run “git log”* to print a list of features, bug fixes, performance improvements, deprecations etc. 3. Either update the main changelog manually or use a script to append individual sections. *git log v2.4...HEAD --no-merges --pretty='- %s (%C(auto)%h)' --grep "Tags: fix"> ‘git log’ can be easily modified to look for other metadata as long as we agree to add it to the commit message. Advantages 1. Light(er) 2. No impact to the subject header 3. Flexibility to define project specific tags 4. Training needs at par with “Conventional Commits” proposal Thoughts? -Varun From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> On Behalf Of Chris Kay via TF-A Sent: Thursday, February 25, 2021 9:31 AM To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Subject: Re: [TF-A] Adoption of Conventional Commits External email: Use caution opening links or attachments Thanks to all those who attended the Tech Forum today! It’s become apparent that the initial 2 week deadline for alternative proposals or implementations is too short, so – as agreed – we’ll push the deadline for the investigation period to the end of March. This period is dedicated to evaluating the changelog automation proposal made, or to identifying alternative solutions. If you have an alternative proposal, any proof-of-concept tooling would be highly appreciated so we can get a clear idea of what sort of work and maintenance is going to be involved. If you do find a solution you wish to propose, please give it just a short name (e.g. “Update it manually”) and make it obvious you want to propose it formally – I’ll collect up the proposals made on the mailing list thread at the end of March and set up a Wiki poll so we can get a clear picture of where the community wants to take this. Chris From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of Chris Kay via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Reply to: Chris Kay <Chris.Kay(a)arm.com<mailto:Chris.Kay@arm.com>> Date: Thursday, 11 February 2021 at 13:59 To: "tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>" <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: [TF-A] Adoption of Conventional Commits Hi all, Recently we had an internal discussion on the merits of introducing semantics to commit messages pushed to the main TF-A repository, the conclusion being that we would look to adopting the Conventional Commits<https://www.conventionalcommits.org/en/v1.0.0/> specification in the near future. There was one major reason for this, which was to help us in automating the changelog in future releases, but it might also help us to dramatically reduce the overall amount of work needed to make a formal release in the future. This requires some buy-in (or buy-out, in this case) from maintainers because - even though it’s to only a relatively minor extent - it does involve an adjustment to everybody’s workflow. Notably, commit messages will be expected to adopt the structure defined by the specification, which will be enforced by the CI. Most commits that go upstream today adhere to “something that looks like Conventional Commits”, so the change is not exactly sweeping, but any change has the potential be an inconvenience. With that in mind, I propose the following: * We collectively adopt the specification, enforced only for @arm.com contributors until such a time that the majority of maintainers are familiar with the new demands * We suggest - in the prerequisites documentation - the installation of two helper tools: * Commitizen<https://github.com/commitizen/cz-cli> * Commitlint<https://github.com/conventional-changelog/commitlint> Installation of these tools will be optional, but I believe they can help with the transition. In the patches currently in review, they are installed as Git hooks automatically upon execution of npm install, so it requires no manual installation or configuration (other than a relatively up-to-date Node.js installation). You’ll find the patches here<https://review.trustedfirmware.org/q/topic:%22ck%252Fconventional-commits%2…>, and specifically the changes to the prerequisites documentation here<https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/8224/1/docs/…>. Feel free to review these changes if you have comments specifically on their implementation. Let me know if you have any questions or concerns. If everybody’s on board, we can look to have this upstreamed shortly. Chris

4 years, 8 months

3
5
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 2 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 367327: Uninitialized variables (UNINIT) ________________________________________________________________________________________________________ *** CID 367327: Uninitialized variables (UNINIT) /services/std_svc/trng/trng_main.c: 32 in trng_rnd32() 26 uint64_t ent[2]; 27 28 if (nbits == 0U || nbits > 96U) { 29 SMC_RET1(handle, TRNG_E_INVALID_PARAMS); 30 } 31 >>> CID 367327: Uninitialized variables (UNINIT) >>> Using uninitialized value "ent[0]" when calling "trng_pack_entropy". 32 if (!trng_pack_entropy(nbits, &ent[0])) { 33 SMC_RET1(handle, TRNG_E_NO_ENTROPY); 34 } 35 36 if ((nbits % 32U) != 0U) { 37 mask >>= 32U - (nbits % 32U); ** CID 367326: Uninitialized variables (UNINIT) ________________________________________________________________________________________________________ *** CID 367326: Uninitialized variables (UNINIT) /services/std_svc/trng/trng_main.c: 68 in trng_rnd64() 62 uint64_t ent[3]; 63 64 if (nbits == 0U || nbits > 192U) { 65 SMC_RET1(handle, TRNG_E_INVALID_PARAMS); 66 } 67 >>> CID 367326: Uninitialized variables (UNINIT) >>> Using uninitialized value "ent[0]" when calling "trng_pack_entropy". 68 if (!trng_pack_entropy(nbits, &ent[0])) { 69 SMC_RET1(handle, TRNG_E_NO_ENTROPY); 70 } 71 72 /* Mask off higher bits if only part of register requested */ 73 if ((nbits % 64U) != 0U) { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 8 months

1
0
0 0

Re: [TF-A] Adoption of Conventional Commits

by Varun Wadekar

Hi, I really like the idea of using tags in the commit message, but the rigidity of the spec puts me off. Frankly, I believe we just need a way to identify commits and their intent. So, I would like to propose an approach that builds on the “Conventional Commits” spec. The approach would be 1. Add an identifier (e.g. Tags: fix) to the commit message footer. 2. At the start of the release window run “git log”* to print a list of features, bug fixes, performance improvements, deprecations etc. 3. Either update the main changelog manually or use a script to append individual sections. *git log v2.4...HEAD --no-merges --pretty='- %s (%C(auto)%h)' --grep "Tags: fix"> ‘git log’ can be easily modified to look for other metadata as long as we agree to add it to the commit message. Advantages 1. Light(er) 2. No impact to the subject header 3. Flexibility to define project specific tags 4. Training needs at par with “Conventional Commits” proposal Thoughts? -Varun From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Chris Kay via TF-A Sent: Thursday, February 25, 2021 9:31 AM To: tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] Adoption of Conventional Commits External email: Use caution opening links or attachments Thanks to all those who attended the Tech Forum today! It’s become apparent that the initial 2 week deadline for alternative proposals or implementations is too short, so – as agreed – we’ll push the deadline for the investigation period to the end of March. This period is dedicated to evaluating the changelog automation proposal made, or to identifying alternative solutions. If you have an alternative proposal, any proof-of-concept tooling would be highly appreciated so we can get a clear idea of what sort of work and maintenance is going to be involved. If you do find a solution you wish to propose, please give it just a short name (e.g. “Update it manually”) and make it obvious you want to propose it formally – I’ll collect up the proposals made on the mailing list thread at the end of March and set up a Wiki poll so we can get a clear picture of where the community wants to take this. Chris From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of Chris Kay via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Reply to: Chris Kay <Chris.Kay(a)arm.com<mailto:Chris.Kay@arm.com>> Date: Thursday, 11 February 2021 at 13:59 To: "tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>" <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: [TF-A] Adoption of Conventional Commits Hi all, Recently we had an internal discussion on the merits of introducing semantics to commit messages pushed to the main TF-A repository, the conclusion being that we would look to adopting the Conventional Commits<https://www.conventionalcommits.org/en/v1.0.0/> specification in the near future. There was one major reason for this, which was to help us in automating the changelog in future releases, but it might also help us to dramatically reduce the overall amount of work needed to make a formal release in the future. This requires some buy-in (or buy-out, in this case) from maintainers because - even though it’s to only a relatively minor extent - it does involve an adjustment to everybody’s workflow. Notably, commit messages will be expected to adopt the structure defined by the specification, which will be enforced by the CI. Most commits that go upstream today adhere to “something that looks like Conventional Commits”, so the change is not exactly sweeping, but any change has the potential be an inconvenience. With that in mind, I propose the following: * We collectively adopt the specification, enforced only for @arm.com contributors until such a time that the majority of maintainers are familiar with the new demands * We suggest - in the prerequisites documentation - the installation of two helper tools: * Commitizen<https://github.com/commitizen/cz-cli> * Commitlint<https://github.com/conventional-changelog/commitlint> Installation of these tools will be optional, but I believe they can help with the transition. In the patches currently in review, they are installed as Git hooks automatically upon execution of npm install, so it requires no manual installation or configuration (other than a relatively up-to-date Node.js installation). You’ll find the patches here<https://review.trustedfirmware.org/q/topic:%22ck%252Fconventional-commits%2…>, and specifically the changes to the prerequisites documentation here<https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/8224/1/docs/…>. Feel free to review these changes if you have comments specifically on their implementation. Let me know if you have any questions or concerns. If everybody’s on board, we can look to have this upstreamed shortly. Chris

4 years, 8 months

1
0
0 0

TF-A Tech Forum Agenda @ Thr 25h February 2021 16:00-1700 GMT

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 25th February 2021 16:00 – 17:00 (GMT). Agenda: * Cross Project: Conventional Commits Sign-off Discussions * Lead by Chris Kay * Following on from the TF-A Mailing list posting last week https://lists.trustedfirmware.org/pipermail/tf-a/2021-February/000972.html and the ongoing discussion on the WIKI page https://developer.trustedfirmware.org/w/tf_a/conventional_commits/ comments section the plan is to use this weeks TF-A Tech forum to have a live discussion about agreeing a common solution that can be used for TF-A and other Trustedfirmware.org projects. If you wish to participate please read the mailing list thread and the WIKI page including the comments. If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled. Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ A scheduling tracking page is also available to help track sessions suggested: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting on the TF-A mailing list. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One 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-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Thanks Joanna

4 years, 8 months

1
0
0 0

TF-A OpenCI : Followup to last Tech Forum meeting

by Joanna Farley

Hi All, After the TF-A Tech-forum on 11th February 2021 (https://www.trustedfirmware.org/meetings/tf-a-technical-forum/) introducing the TF-A OpenCI I wanted to follow up with a posting on how we want to incorporate this new CI workflow into the TF-A project environment and who will have the ability to instigate OpenCI runs for the project. Some guidelines we are looking to follow are: * Be consistent across all Trustedfirmware.org hosted projects (TF-A, TF-M, Hafnium etc) * Be as open as possible to allow project contributors access to the CI. * Protect backend server resources from security attacks. * Be open to tune the workflow process as needs demand. As mentioned in the Tech-forum session the main day to day developer interface with the OpenCI is through Gerrit reviews with the CI+1/CI+2 gerrit labels for patches under review that start two levels of CI coverage. There is also a daily CI run on the integration branch that is started automatically. OpenCI runs for gerrit patch reviews are shown in the patch comments as links into https://ci.trustedfirmware.org/view/TF-A/ where all the Jenkin jobs including the daily build can be found. In addition there is the occasional need to re-trigger CI jobs directly in the Jenkins UI shown above. This can occur if there is an intermittent failure in the CI infrastructure or due to some other cause however its hoped this is only needed to be used rarely and most contributors will not need to use this. The initial plan is allow OpenCI invocation (through Gerrit and Jenkins) to all the TF-A maintainers and Code Owners listed in https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/about… as a list of known project contributors. This list can be extended over time with other individuals nominated by anybody on the initial list. The OpenCI will become the primary and only CI for setting the Gerrit verified label for patches under review. The existing ArmCI will become advisory and triggered separately and will not directly influence the Gerrit verified label for patches under review. The ArmCI will be maintained in parallel for those areas not yet migrated to the OpenCI and will be disabled once the next phases of the OpenCI development complete. Any CI results from the ArmCI will be communicated in patch review comments from Arm contributors as required. Project documentation will be updated to incorporate OpenCI usage and a further Tech-forum will be held to go through the CI usage in more detail once the OpenCI is ready to take over as the primary TF-A CI. This is expected and hoping to take place in the next week or two as the final OpenCI deployment issues are resolved but exactly when will be communicated to this list once we have a firm date. Thanks Joanna

4 years, 8 months

1
0
0 0

Re: [TF-A] Adoption of Conventional Commits

by Varun Wadekar

Hi Chris, This seems like a good proposal to alleviate some of the pain around releases. Some observations/questions. 1. Introducing additional tags will eat into precious real estate. This will be a problem for some changes and developers. 2. In the transition period, the proposal has the potential to "pollute" the history 3. The proposal will add more work for patches cherry-picked from other projects e.g. libfdt 4. How do we handle scenarios where platforms donot want to switch to this policy? I can see how #1 might be of concern to many, but we will have to implement some policy to see how many commits really fall in this category. -Varun From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Chris Kay via TF-A Sent: Thursday, February 11, 2021 5:59 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Adoption of Conventional Commits External email: Use caution opening links or attachments Hi all, Recently we had an internal discussion on the merits of introducing semantics to commit messages pushed to the main TF-A repository, the conclusion being that we would look to adopting the Conventional Commits<https://www.conventionalcommits.org/en/v1.0.0/> specification in the near future. There was one major reason for this, which was to help us in automating the changelog in future releases, but it might also help us to dramatically reduce the overall amount of work needed to make a formal release in the future. This requires some buy-in (or buy-out, in this case) from maintainers because - even though it's to only a relatively minor extent - it does involve an adjustment to everybody's workflow. Notably, commit messages will be expected to adopt the structure defined by the specification, which will be enforced by the CI. Most commits that go upstream today adhere to "something that looks like Conventional Commits", so the change is not exactly sweeping, but any change has the potential be an inconvenience. With that in mind, I propose the following: * We collectively adopt the specification, enforced only for @arm.com contributors until such a time that the majority of maintainers are familiar with the new demands * We suggest - in the prerequisites documentation - the installation of two helper tools: * Commitizen<https://github.com/commitizen/cz-cli> * Commitlint<https://github.com/conventional-changelog/commitlint> Installation of these tools will be optional, but I believe they can help with the transition. In the patches currently in review, they are installed as Git hooks automatically upon execution of npm install, so it requires no manual installation or configuration (other than a relatively up-to-date Node.js installation). You'll find the patches here<https://review.trustedfirmware.org/q/topic:%22ck%252Fconventional-commits%2…>, and specifically the changes to the prerequisites documentation here<https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/8224/1/docs/…>. Feel free to review these changes if you have comments specifically on their implementation. Let me know if you have any questions or concerns. If everybody's on board, we can look to have this upstreamed shortly. Chris

4 years, 8 months

2
4
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 5 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 14 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 5 of 5 defect(s) ** CID 366362: Control flow issues (DEADCODE) /plat/rockchip/rk3399/drivers/dram/dfs.c: 123 in get_dram_drv_odt_val() ________________________________________________________________________________________________________ *** CID 366362: Control flow issues (DEADCODE) /plat/rockchip/rk3399/drivers/dram/dfs.c: 123 in get_dram_drv_odt_val() 117 tmp = ((mr1_val >> 2) & 1) | ((mr1_val >> 5) & 1) | 118 ((mr1_val >> 7) & 1); 119 if (tmp == 0) 120 drv_config->dram_side_dq_odt = 0; 121 else if (tmp == 1) 122 drv_config->dram_side_dq_odt = 60; >>> CID 366362: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "if (tmp == 3U) drv_config...". 123 else if (tmp == 3) 124 drv_config->dram_side_dq_odt = 40; 125 else 126 drv_config->dram_side_dq_odt = 120; 127 break; 128 case LPDDR3: ** CID 366361: (DEADCODE) /drivers/st/fmc/stm32_fmc2_nand.c: 203 in stm32_fmc2_nand_setup_timing() /drivers/st/fmc/stm32_fmc2_nand.c: 250 in stm32_fmc2_nand_setup_timing() /drivers/st/fmc/stm32_fmc2_nand.c: 247 in stm32_fmc2_nand_setup_timing() ________________________________________________________________________________________________________ *** CID 366361: (DEADCODE) /drivers/st/fmc/stm32_fmc2_nand.c: 203 in stm32_fmc2_nand_setup_timing() 197 * tSETUP_MEM > tDS - (tWAIT - tHIZ) 198 */ 199 tset_mem = hclkp; 200 if ((twait < NAND_TCS_MIN) && (tset_mem < (NAND_TCS_MIN - twait))) { 201 tset_mem = NAND_TCS_MIN - twait; 202 } >>> CID 366361: (DEADCODE) >>> Execution cannot reach the expression "tset_mem < 50000UL - twait" inside this statement: "if (twait < 50000UL && tset...". 203 if ((twait < NAND_TALS_MIN) && (tset_mem < (NAND_TALS_MIN - twait))) { 204 tset_mem = NAND_TALS_MIN - twait; 205 } 206 if ((twait > thiz) && ((twait - thiz) < NAND_TDS_MIN) && 207 (tset_mem < (NAND_TDS_MIN - (twait - thiz)))) { 208 tset_mem = NAND_TDS_MIN - (twait - thiz); /drivers/st/fmc/stm32_fmc2_nand.c: 250 in stm32_fmc2_nand_setup_timing() 244 if ((twait < NAND_TCS_MIN) && (tset_att < (NAND_TCS_MIN - twait))) { 245 tset_att = NAND_TCS_MIN - twait; 246 } 247 if ((twait < NAND_TCLS_MIN) && (tset_att < (NAND_TCLS_MIN - twait))) { 248 tset_att = NAND_TCLS_MIN - twait; 249 } >>> CID 366361: (DEADCODE) >>> Execution cannot reach the expression "tset_att < 50000UL - twait" inside this statement: "if (twait < 50000UL && tset...". 250 if ((twait < NAND_TALS_MIN) && (tset_att < (NAND_TALS_MIN - twait))) { 251 tset_att = NAND_TALS_MIN - twait; 252 } 253 if ((thold_mem < NAND_TRHW_MIN) && 254 (tset_att < (NAND_TRHW_MIN - thold_mem))) { 255 tset_att = NAND_TRHW_MIN - thold_mem; /drivers/st/fmc/stm32_fmc2_nand.c: 247 in stm32_fmc2_nand_setup_timing() 241 * tSETUP_ATT > tDS - (tWAIT - tHIZ) 242 */ 243 tset_att = hclkp; 244 if ((twait < NAND_TCS_MIN) && (tset_att < (NAND_TCS_MIN - twait))) { 245 tset_att = NAND_TCS_MIN - twait; 246 } >>> CID 366361: (DEADCODE) >>> Execution cannot reach the expression "tset_att < 50000UL - twait" inside this statement: "if (twait < 50000UL && tset...". 247 if ((twait < NAND_TCLS_MIN) && (tset_att < (NAND_TCLS_MIN - twait))) { 248 tset_att = NAND_TCLS_MIN - twait; 249 } 250 if ((twait < NAND_TALS_MIN) && (tset_att < (NAND_TALS_MIN - twait))) { 251 tset_att = NAND_TALS_MIN - twait; 252 } ** CID 366360: (UNINIT) /lib/zlib/tf_gunzip.c: 87 in gunzip() /lib/zlib/tf_gunzip.c: 83 in gunzip() ________________________________________________________________________________________________________ *** CID 366360: (UNINIT) /lib/zlib/tf_gunzip.c: 87 in gunzip() 81 } 82 83 zret = inflate(&stream, Z_NO_FLUSH); 84 if (zret == Z_STREAM_END) { 85 ret = 0; 86 } else { >>> CID 366360: (UNINIT) >>> Using uninitialized value "stream.msg". 87 if (stream.msg) 88 ERROR("%s\n", stream.msg); 89 ERROR("zlib: inflate failed (ret = %d)\n", zret); 90 ret = (zret == Z_MEM_ERROR) ? -ENOMEM : -EIO; 91 } 92 /lib/zlib/tf_gunzip.c: 83 in gunzip() 77 zret = inflateInit(&stream); 78 if (zret != Z_OK) { 79 ERROR("zlib: inflate init failed (ret = %d)\n", zret); 80 return (zret == Z_MEM_ERROR) ? -ENOMEM : -EIO; 81 } 82 >>> CID 366360: (UNINIT) >>> Using uninitialized value "stream.total_out" when calling "inflate". [Note: The source code implementation of the function has been overridden by a builtin model.] 83 zret = inflate(&stream, Z_NO_FLUSH); 84 if (zret == Z_STREAM_END) { 85 ret = 0; 86 } else { 87 if (stream.msg) 88 ERROR("%s\n", stream.msg); ** CID 366283: Insecure data handling (TAINTED_SCALAR) /mbedtls/library/x509_crt.c: 568 in x509_get_key_usage() ________________________________________________________________________________________________________ *** CID 366283: Insecure data handling (TAINTED_SCALAR) /mbedtls/library/x509_crt.c: 568 in x509_get_key_usage() 562 if( bs.len < 1 ) 563 return( MBEDTLS_ERR_X509_INVALID_EXTENSIONS + 564 MBEDTLS_ERR_ASN1_INVALID_LENGTH ); 565 566 /* Get actual bitstring */ 567 *key_usage = 0; >>> CID 366283: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "bs.len" as a loop boundary. 568 for( i = 0; i < bs.len && i < sizeof( unsigned int ); i++ ) 569 { 570 *key_usage |= (unsigned int) bs.p[i] << (8*i); 571 } 572 573 return( 0 ); ** CID 366277: Insecure data handling (TAINTED_SCALAR) /mbedtls/library/asn1parse.c: 158 in asn1_get_tagged_int() ________________________________________________________________________________________________________ *** CID 366277: Insecure data handling (TAINTED_SCALAR) /mbedtls/library/asn1parse.c: 158 in asn1_get_tagged_int() 152 return( MBEDTLS_ERR_ASN1_INVALID_LENGTH ); 153 /* This is a cryptography library. Reject negative integers. */ 154 if( ( **p & 0x80 ) != 0 ) 155 return( MBEDTLS_ERR_ASN1_INVALID_LENGTH ); 156 157 /* Skip leading zeros. */ >>> CID 366277: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "len" as a loop boundary. 158 while( len > 0 && **p == 0 ) 159 { 160 ++( *p ); 161 --len; 162 } 163 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 8 months

1
0
0 0

Re: [TF-A] Getting BUILD_STRING from FIP file

by Manish Pandey2

Hi Daniele, TBBR specification, from where fip format was introduced, is not very clear about usage of serial number and it can be used in IMP DEFINED manner "ToC Serial Number - 32 - The serial number of this ToC". So, theoretically it's possible to use serial number for the purpose you described and it's a valid use of currently (un)used serial number. Currently, at boot time serial number is checked against a non-zero value, which certainly will hold true if you put a valid timstamp instead of "0x12345678". IMO you can go ahead and implement a mechanism to feed Build timestamp to be used as serial number. Thanks Manish P ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Manish Badarkhe via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 11 February 2021 11:39 To: Daniele Alessandrelli <daniele.alessandrelli(a)linux.intel.com>; tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Getting BUILD_STRING from FIP file Hi Daniele Please see my replies inline. Thanks Manish Badarkhe From: Daniele Alessandrelli <daniele.alessandrelli(a)linux.intel.com> Date: Thursday, 11 February 2021 at 11:22 To: Manish Badarkhe <Manish.Badarkhe(a)arm.com>, tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Getting BUILD_STRING from FIP file Hi Manish, Thank you very much for the information. 16 bits are not enough to store an epoch, but I'll see if I can encode some other unique build information into 16 bits. Just a question, from your answer I assume that I shouldn't use the 'serial_number' field for what I want to do; so I wonder: what is that field meant to be used for? 'serial_number' field is non-zero number provided by the fip creation tool. It is hardcoded value i.e. TOC_HEADER_SERIAL_NUMBER=0x12345678 as of now. Specifically used during the validation of the TOC header in the code. Regards, Daniele On Thu, 2021-02-11 at 10:14 +0000, Manish Badarkhe wrote: > Hi Daniele > > You can use the ‘flag’ field to mention the platform-specific data(in > your case, a build number). Usage of the ‘flag’ field(64 bit) in the > toc_header are as below: > Bits 0-31 -> reserved > Bits 32-47 -> platform defined data > Bits 48-63 -> reserved > You can make use of the flag[32:47] to put build information. I am > not sure if you can accommodate epoch (converted timestamp) into this > field but, you can encode any data to fit into this 16bit flag field > to identify the FIP build. > > You can use a build command: fiptool update/create --plat-toc-flags > <platform defined data> <your fip bin path> to put the platform > defined data in the FIP image. > > Thanks > Manish Badarkhe > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of > Daniele Alessandrelli via TF-A <tf-a(a)lists.trustedfirmware.org> > Date: Wednesday, 10 February 2021 at 17:04 > To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> > Subject: [TF-A] Getting BUILD_STRING from FIP file > > Hi, > > Is there a way to get BUILD_STRING (or a similar string / number that > uniquely identifies the TF-A build, e.g., BUILD_MESSAGE_TIMESTAMP) > from > the FIP file? > > Basically, I'm trying to find a way to know the build number of a FIP > without flashing it. > > I've seen that the FIP TOC header has a 32-bit field named > 'serial_number'. Can it be used to this end? I'm considering > converting BUILD_MESSAGE_TIMESTAMP into an epoch and adding it as > 'serial number', but I'm worried that might be an unintended usage of > the 'serial_number' field. > > Regards, > Daniele > > >

4 years, 8 months

3
3
0 0

Adoption of Conventional Commits

by Chris Kay

Hi all, Recently we had an internal discussion on the merits of introducing semantics to commit messages pushed to the main TF-A repository, the conclusion being that we would look to adopting the Conventional Commits<https://www.conventionalcommits.org/en/v1.0.0/> specification in the near future. There was one major reason for this, which was to help us in automating the changelog in future releases, but it might also help us to dramatically reduce the overall amount of work needed to make a formal release in the future. This requires some buy-in (or buy-out, in this case) from maintainers because - even though it's to only a relatively minor extent - it does involve an adjustment to everybody's workflow. Notably, commit messages will be expected to adopt the structure defined by the specification, which will be enforced by the CI. Most commits that go upstream today adhere to "something that looks like Conventional Commits", so the change is not exactly sweeping, but any change has the potential be an inconvenience. With that in mind, I propose the following: * We collectively adopt the specification, enforced only for @arm.com contributors until such a time that the majority of maintainers are familiar with the new demands * We suggest - in the prerequisites documentation - the installation of two helper tools: * Commitizen<https://github.com/commitizen/cz-cli> * Commitlint<https://github.com/conventional-changelog/commitlint> Installation of these tools will be optional, but I believe they can help with the transition. In the patches currently in review, they are installed as Git hooks automatically upon execution of npm install, so it requires no manual installation or configuration (other than a relatively up-to-date Node.js installation). You'll find the patches here<https://review.trustedfirmware.org/q/topic:%22ck%252Fconventional-commits%2…>, and specifically the changes to the prerequisites documentation here<https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/8224/1/docs/…>. Feel free to review these changes if you have comments specifically on their implementation. Let me know if you have any questions or concerns. If everybody's on board, we can look to have this upstreamed shortly. Chris

4 years, 8 months

1
0
0 0

Re: [TF-A] Getting BUILD_STRING from FIP file

by Manish Badarkhe

Hi Daniele You can use the ‘flag’ field to mention the platform-specific data(in your case, a build number). Usage of the ‘flag’ field(64 bit) in the toc_header are as below: 1. Bits 0-31 -> reserved 2. Bits 32-47 -> platform defined data 3. Bits 48-63 -> reserved You can make use of the flag[32:47] to put build information. I am not sure if you can accommodate epoch (converted timestamp) into this field but, you can encode any data to fit into this 16bit flag field to identify the FIP build. You can use a build command: fiptool update/create --plat-toc-flags <platform defined data> <your fip bin path> to put the platform defined data in the FIP image. Thanks Manish Badarkhe From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Daniele Alessandrelli via TF-A <tf-a(a)lists.trustedfirmware.org> Date: Wednesday, 10 February 2021 at 17:04 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Getting BUILD_STRING from FIP file Hi, Is there a way to get BUILD_STRING (or a similar string / number that uniquely identifies the TF-A build, e.g., BUILD_MESSAGE_TIMESTAMP) from the FIP file? Basically, I'm trying to find a way to know the build number of a FIP without flashing it. I've seen that the FIP TOC header has a 32-bit field named 'serial_number'. Can it be used to this end? I'm considering converting BUILD_MESSAGE_TIMESTAMP into an epoch and adding it as 'serial number', but I'm worried that might be an unintended usage of the 'serial_number' field. Regards, Daniele -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 8 months

2
2
0 0

Getting BUILD_STRING from FIP file

by Daniele Alessandrelli

Hi, Is there a way to get BUILD_STRING (or a similar string / number that uniquely identifies the TF-A build, e.g., BUILD_MESSAGE_TIMESTAMP) from the FIP file? Basically, I'm trying to find a way to know the build number of a FIP without flashing it. I've seen that the FIP TOC header has a 32-bit field named 'serial_number'. Can it be used to this end? I'm considering converting BUILD_MESSAGE_TIMESTAMP into an epoch and adding it as 'serial number', but I'm worried that might be an unintended usage of the 'serial_number' field. Regards, Daniele

4 years, 8 months

1
0
0 0

TF-A Tech Forum Agenda @ Thr 11h February 2021 16:00-1700 GMT

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 11th February 2021 16:00 – 17:00 (GMT). Agenda: * TF-A: Open-CI Introduction & Status * Presented by Joanna Farley with support from Linaro OpenCI Enablement Team * Having a Public CI (Continuous Integration) extensible system has been a goal for a while and this presentation will give an introduction and a high level overview along with the current status. A brief walk through what CI jobs are available, when they are run and how results can be accessed will be shown/demoed. Deeper dives into the OpenCI results and how to analyse will be the subject of future Tech Forum sessions. If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled. Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ A scheduling tracking page is also available to help track sessions suggested: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting on the TF-A mailing list. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One 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-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Thanks Joanna

4 years, 8 months

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 7 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 5 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 7 of 7 defect(s) ** CID 366311: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 366311: Memory - corruptions (OVERRUN) /drivers/renesas/rzg/ddr/ddr_b/boot_init_dram.c: 3156 in rdqdm_man1() 3150 } 3151 } 3152 } 3153 if ((prr_product == PRR_PRODUCT_M3) && 3154 (prr_cut <= PRR_PRODUCT_10)) { 3155 for (slice = 0U; slice < SLICE_CNT; slice++) { >>> CID 366311: Memory - corruptions (OVERRUN) >>> Overrunning callee's array of size 32 by passing argument "slice" (which evaluates to 24) in call to "rdqdm_man1_set". 3156 rdqdm_man1_set(ddr_csn, ch, slice); 3157 } 3158 } 3159 } 3160 ddrphy_regif_idle(); 3161 ** CID 361221: Insecure data handling (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 361221: Insecure data handling (TAINTED_SCALAR) /plat/arm/board/arm_fpga/fpga_bl31_setup.c: 238 in fpga_prepare_dtb() 232 233 if (node >= 0) { 234 fdt_del_node(fdt, node); 235 } 236 } 237 >>> CID 361221: Insecure data handling (TAINTED_SCALAR) >>> Passing tainted variable "fdt->size_dt_struct" to a tainted sink. 238 err = fdt_pack(fdt); 239 if (err < 0) { 240 ERROR("Failed to pack Device Tree at %p: error %d\n", fdt, err); 241 } 242 243 clean_dcache_range((uintptr_t)fdt, fdt_blob_size(fdt)); ** CID 360537: Insecure data handling (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 360537: Insecure data handling (TAINTED_SCALAR) /plat/qemu/common/qemu_bl2_setup.c: 72 in update_dt() 66 67 if (dt_add_psci_cpu_enable_methods(fdt)) { 68 ERROR("Failed to add PSCI cpu enable methods in Device Tree\n"); 69 return; 70 } 71 >>> CID 360537: Insecure data handling (TAINTED_SCALAR) >>> Passing tainted variable "fdt->size_dt_struct" to a tainted sink. 72 ret = fdt_pack(fdt); 73 if (ret < 0) 74 ERROR("Failed to pack Device Tree at %p: error %d\n", fdt, ret); 75 } 76 77 void bl2_platform_setup(void) ** CID 360536: (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 360536: (TAINTED_SCALAR) /plat/rpi/rpi4/rpi4_bl31_setup.c: 214 in rpi4_prepare_dtb() 208 int ret, offs; 209 210 /* Return if no device tree is detected */ 211 if (fdt_check_header(dtb) != 0) 212 return; 213 >>> CID 360536: (TAINTED_SCALAR) >>> Passing tainted variable "dtb->totalsize" to a tainted sink. 214 ret = fdt_open_into(dtb, dtb, 0x100000); 215 if (ret < 0) { 216 ERROR("Invalid Device Tree at %p: error %d\n", dtb, ret); 217 return; 218 } 219 /plat/rpi/rpi4/rpi4_bl31_setup.c: 243 in rpi4_prepare_dtb() 237 gic_int_prop[2] = cpu_to_fdt32(0x0f04); // all cores, level high 238 fdt_setprop(dtb, offs, "interrupts", gic_int_prop, 12); 239 240 offs = fdt_path_offset(dtb, "/chosen"); 241 fdt_setprop_string(dtb, offs, "stdout-path", "serial0"); 242 >>> CID 360536: (TAINTED_SCALAR) >>> Passing tainted variable "dtb->size_dt_struct" to a tainted sink. 243 ret = fdt_pack(dtb); 244 if (ret < 0) 245 ERROR("Failed to pack Device Tree at %p: error %d\n", dtb, ret); 246 247 clean_dcache_range((uintptr_t)dtb, fdt_blob_size(dtb)); 248 INFO("Changed device tree to advertise PSCI.\n"); /plat/rpi/rpi4/rpi4_bl31_setup.c: 214 in rpi4_prepare_dtb() 208 int ret, offs; 209 210 /* Return if no device tree is detected */ 211 if (fdt_check_header(dtb) != 0) 212 return; 213 >>> CID 360536: (TAINTED_SCALAR) >>> Passing tainted variable "dtb->size_dt_strings" to a tainted sink. 214 ret = fdt_open_into(dtb, dtb, 0x100000); 215 if (ret < 0) { 216 ERROR("Invalid Device Tree at %p: error %d\n", dtb, ret); 217 return; 218 } 219 /plat/rpi/rpi4/rpi4_bl31_setup.c: 243 in rpi4_prepare_dtb() 237 gic_int_prop[2] = cpu_to_fdt32(0x0f04); // all cores, level high 238 fdt_setprop(dtb, offs, "interrupts", gic_int_prop, 12); 239 240 offs = fdt_path_offset(dtb, "/chosen"); 241 fdt_setprop_string(dtb, offs, "stdout-path", "serial0"); 242 >>> CID 360536: (TAINTED_SCALAR) >>> Passing tainted variable "dtb->size_dt_struct" to a tainted sink. 243 ret = fdt_pack(dtb); 244 if (ret < 0) 245 ERROR("Failed to pack Device Tree at %p: error %d\n", dtb, ret); 246 247 clean_dcache_range((uintptr_t)dtb, fdt_blob_size(dtb)); 248 INFO("Changed device tree to advertise PSCI.\n"); /plat/rpi/rpi4/rpi4_bl31_setup.c: 243 in rpi4_prepare_dtb() 237 gic_int_prop[2] = cpu_to_fdt32(0x0f04); // all cores, level high 238 fdt_setprop(dtb, offs, "interrupts", gic_int_prop, 12); 239 240 offs = fdt_path_offset(dtb, "/chosen"); 241 fdt_setprop_string(dtb, offs, "stdout-path", "serial0"); 242 >>> CID 360536: (TAINTED_SCALAR) >>> Passing tainted variable "dtb->size_dt_struct" to a tainted sink. 243 ret = fdt_pack(dtb); 244 if (ret < 0) 245 ERROR("Failed to pack Device Tree at %p: error %d\n", dtb, ret); 246 247 clean_dcache_range((uintptr_t)dtb, fdt_blob_size(dtb)); 248 INFO("Changed device tree to advertise PSCI.\n"); /plat/rpi/rpi4/rpi4_bl31_setup.c: 243 in rpi4_prepare_dtb() 237 gic_int_prop[2] = cpu_to_fdt32(0x0f04); // all cores, level high 238 fdt_setprop(dtb, offs, "interrupts", gic_int_prop, 12); 239 240 offs = fdt_path_offset(dtb, "/chosen"); 241 fdt_setprop_string(dtb, offs, "stdout-path", "serial0"); 242 >>> CID 360536: (TAINTED_SCALAR) >>> Passing tainted variable "dtb->size_dt_struct" to a tainted sink. 243 ret = fdt_pack(dtb); 244 if (ret < 0) 245 ERROR("Failed to pack Device Tree at %p: error %d\n", dtb, ret); 246 247 clean_dcache_range((uintptr_t)dtb, fdt_blob_size(dtb)); 248 INFO("Changed device tree to advertise PSCI.\n"); ** CID 360535: Insecure data handling (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 360535: Insecure data handling (TAINTED_SCALAR) /plat/renesas/rcar/bl2_plat_setup.c: 1005 in bl2_el3_early_platform_setup() 999 bl2_lossy_setting(1, LOSSY_ST_ADDR1, LOSSY_END_ADDR1, 1000 LOSSY_FMT1, LOSSY_ENA_DIS1, fcnlnode); 1001 bl2_lossy_setting(2, LOSSY_ST_ADDR2, LOSSY_END_ADDR2, 1002 LOSSY_FMT2, LOSSY_ENA_DIS2, fcnlnode); 1003 #endif 1004 >>> CID 360535: Insecure data handling (TAINTED_SCALAR) >>> Passing tainted variable "fdt->size_dt_struct" to a tainted sink. 1005 fdt_pack(fdt); 1006 NOTICE("BL2: FDT at %p\n", fdt); 1007 1008 if (boot_dev == MODEMR_BOOT_DEV_EMMC_25X1 || 1009 boot_dev == MODEMR_BOOT_DEV_EMMC_50X8) 1010 rcar_io_emmc_setup(); ** CID 346762: (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 346762: (TAINTED_SCALAR) /lib/libfdt/fdt_empty_tree.c: 33 in fdt_create_empty_tree() 27 return err; 28 29 err = fdt_end_node(buf); 30 if (err) 31 return err; 32 >>> CID 346762: (TAINTED_SCALAR) >>> Passing tainted variable "buf->size_dt_strings" to a tainted sink. 33 err = fdt_finish(buf); 34 if (err) 35 return err; 36 37 return fdt_open_into(buf, buf, bufsize); /lib/libfdt/fdt_empty_tree.c: 37 in fdt_create_empty_tree() 31 return err; 32 33 err = fdt_finish(buf); 34 if (err) 35 return err; 36 >>> CID 346762: (TAINTED_SCALAR) >>> Passing tainted variable "buf->size_dt_struct" to a tainted sink. 37 return fdt_open_into(buf, buf, bufsize); /lib/libfdt/fdt_empty_tree.c: 37 in fdt_create_empty_tree() 31 return err; 32 33 err = fdt_finish(buf); 34 if (err) 35 return err; 36 >>> CID 346762: (TAINTED_SCALAR) >>> Passing tainted variable "buf->totalsize" to a tainted sink. 37 return fdt_open_into(buf, buf, bufsize); /lib/libfdt/fdt_empty_tree.c: 37 in fdt_create_empty_tree() 31 return err; 32 33 err = fdt_finish(buf); 34 if (err) 35 return err; 36 >>> CID 346762: (TAINTED_SCALAR) >>> Passing tainted variable "buf->size_dt_strings" to a tainted sink. 37 return fdt_open_into(buf, buf, bufsize); ** CID 342997: (TAINTED_SCALAR) /plat/st/common/stm32mp_dt.c: 79 in fdt_get_status() /plat/st/common/stm32mp_dt.c: 89 in fdt_get_status() ________________________________________________________________________________________________________ *** CID 342997: (TAINTED_SCALAR) /plat/st/common/stm32mp_dt.c: 79 in fdt_get_status() 73 { 74 uint8_t status = DT_DISABLED; 75 int len; 76 const char *cchar; 77 78 cchar = fdt_getprop(fdt, node, "status", &len); >>> CID 342997: (TAINTED_SCALAR) >>> Passing tainted variable "(size_t)len" to a tainted sink. [Note: The source code implementation of the function has been overridden by a builtin model.] 79 if ((cchar == NULL) || 80 (strncmp(cchar, "okay", (size_t)len) == 0)) { 81 status |= DT_NON_SECURE; 82 } 83 84 cchar = fdt_getprop(fdt, node, "secure-status", &len); /plat/st/common/stm32mp_dt.c: 89 in fdt_get_status() 83 84 cchar = fdt_getprop(fdt, node, "secure-status", &len); 85 if (cchar == NULL) { 86 if (status == DT_NON_SECURE) { 87 status |= DT_SECURE; 88 } >>> CID 342997: (TAINTED_SCALAR) >>> Passing tainted variable "(size_t)len" to a tainted sink. [Note: The source code implementation of the function has been overridden by a builtin model.] 89 } else if (strncmp(cchar, "okay", (size_t)len) == 0) { 90 status |= DT_SECURE; 91 } 92 93 return status; 94 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 8 months

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 5 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 14 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 5 of 5 defect(s) ** CID 366362: Control flow issues (DEADCODE) /plat/rockchip/rk3399/drivers/dram/dfs.c: 123 in get_dram_drv_odt_val() ________________________________________________________________________________________________________ *** CID 366362: Control flow issues (DEADCODE) /plat/rockchip/rk3399/drivers/dram/dfs.c: 123 in get_dram_drv_odt_val() 117 tmp = ((mr1_val >> 2) & 1) | ((mr1_val >> 5) & 1) | 118 ((mr1_val >> 7) & 1); 119 if (tmp == 0) 120 drv_config->dram_side_dq_odt = 0; 121 else if (tmp == 1) 122 drv_config->dram_side_dq_odt = 60; >>> CID 366362: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "if (tmp == 3U) drv_config...". 123 else if (tmp == 3) 124 drv_config->dram_side_dq_odt = 40; 125 else 126 drv_config->dram_side_dq_odt = 120; 127 break; 128 case LPDDR3: ** CID 366361: (DEADCODE) /drivers/st/fmc/stm32_fmc2_nand.c: 247 in stm32_fmc2_nand_setup_timing() /drivers/st/fmc/stm32_fmc2_nand.c: 250 in stm32_fmc2_nand_setup_timing() /drivers/st/fmc/stm32_fmc2_nand.c: 203 in stm32_fmc2_nand_setup_timing() ________________________________________________________________________________________________________ *** CID 366361: (DEADCODE) /drivers/st/fmc/stm32_fmc2_nand.c: 247 in stm32_fmc2_nand_setup_timing() 241 * tSETUP_ATT > tDS - (tWAIT - tHIZ) 242 */ 243 tset_att = hclkp; 244 if ((twait < NAND_TCS_MIN) && (tset_att < (NAND_TCS_MIN - twait))) { 245 tset_att = NAND_TCS_MIN - twait; 246 } >>> CID 366361: (DEADCODE) >>> Execution cannot reach the expression "tset_att < 50000UL - twait" inside this statement: "if (twait < 50000UL && tset...". 247 if ((twait < NAND_TCLS_MIN) && (tset_att < (NAND_TCLS_MIN - twait))) { 248 tset_att = NAND_TCLS_MIN - twait; 249 } 250 if ((twait < NAND_TALS_MIN) && (tset_att < (NAND_TALS_MIN - twait))) { 251 tset_att = NAND_TALS_MIN - twait; 252 } /drivers/st/fmc/stm32_fmc2_nand.c: 250 in stm32_fmc2_nand_setup_timing() 244 if ((twait < NAND_TCS_MIN) && (tset_att < (NAND_TCS_MIN - twait))) { 245 tset_att = NAND_TCS_MIN - twait; 246 } 247 if ((twait < NAND_TCLS_MIN) && (tset_att < (NAND_TCLS_MIN - twait))) { 248 tset_att = NAND_TCLS_MIN - twait; 249 } >>> CID 366361: (DEADCODE) >>> Execution cannot reach the expression "tset_att < 50000UL - twait" inside this statement: "if (twait < 50000UL && tset...". 250 if ((twait < NAND_TALS_MIN) && (tset_att < (NAND_TALS_MIN - twait))) { 251 tset_att = NAND_TALS_MIN - twait; 252 } 253 if ((thold_mem < NAND_TRHW_MIN) && 254 (tset_att < (NAND_TRHW_MIN - thold_mem))) { 255 tset_att = NAND_TRHW_MIN - thold_mem; /drivers/st/fmc/stm32_fmc2_nand.c: 203 in stm32_fmc2_nand_setup_timing() 197 * tSETUP_MEM > tDS - (tWAIT - tHIZ) 198 */ 199 tset_mem = hclkp; 200 if ((twait < NAND_TCS_MIN) && (tset_mem < (NAND_TCS_MIN - twait))) { 201 tset_mem = NAND_TCS_MIN - twait; 202 } >>> CID 366361: (DEADCODE) >>> Execution cannot reach the expression "tset_mem < 50000UL - twait" inside this statement: "if (twait < 50000UL && tset...". 203 if ((twait < NAND_TALS_MIN) && (tset_mem < (NAND_TALS_MIN - twait))) { 204 tset_mem = NAND_TALS_MIN - twait; 205 } 206 if ((twait > thiz) && ((twait - thiz) < NAND_TDS_MIN) && 207 (tset_mem < (NAND_TDS_MIN - (twait - thiz)))) { 208 tset_mem = NAND_TDS_MIN - (twait - thiz); ** CID 366360: (UNINIT) /lib/zlib/tf_gunzip.c: 83 in gunzip() /lib/zlib/tf_gunzip.c: 87 in gunzip() ________________________________________________________________________________________________________ *** CID 366360: (UNINIT) /lib/zlib/tf_gunzip.c: 83 in gunzip() 77 zret = inflateInit(&stream); 78 if (zret != Z_OK) { 79 ERROR("zlib: inflate init failed (ret = %d)\n", zret); 80 return (zret == Z_MEM_ERROR) ? -ENOMEM : -EIO; 81 } 82 >>> CID 366360: (UNINIT) >>> Using uninitialized value "stream.total_out" when calling "inflate". [Note: The source code implementation of the function has been overridden by a builtin model.] 83 zret = inflate(&stream, Z_NO_FLUSH); 84 if (zret == Z_STREAM_END) { 85 ret = 0; 86 } else { 87 if (stream.msg) 88 ERROR("%s\n", stream.msg); /lib/zlib/tf_gunzip.c: 87 in gunzip() 81 } 82 83 zret = inflate(&stream, Z_NO_FLUSH); 84 if (zret == Z_STREAM_END) { 85 ret = 0; 86 } else { >>> CID 366360: (UNINIT) >>> Using uninitialized value "stream.msg". 87 if (stream.msg) 88 ERROR("%s\n", stream.msg); 89 ERROR("zlib: inflate failed (ret = %d)\n", zret); 90 ret = (zret == Z_MEM_ERROR) ? -ENOMEM : -EIO; 91 } 92 ** CID 366283: Insecure data handling (TAINTED_SCALAR) /mbedtls/library/x509_crt.c: 568 in x509_get_key_usage() ________________________________________________________________________________________________________ *** CID 366283: Insecure data handling (TAINTED_SCALAR) /mbedtls/library/x509_crt.c: 568 in x509_get_key_usage() 562 if( bs.len < 1 ) 563 return( MBEDTLS_ERR_X509_INVALID_EXTENSIONS + 564 MBEDTLS_ERR_ASN1_INVALID_LENGTH ); 565 566 /* Get actual bitstring */ 567 *key_usage = 0; >>> CID 366283: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "bs.len" as a loop boundary. 568 for( i = 0; i < bs.len && i < sizeof( unsigned int ); i++ ) 569 { 570 *key_usage |= (unsigned int) bs.p[i] << (8*i); 571 } 572 573 return( 0 ); ** CID 366277: Insecure data handling (TAINTED_SCALAR) /mbedtls/library/asn1parse.c: 158 in asn1_get_tagged_int() ________________________________________________________________________________________________________ *** CID 366277: Insecure data handling (TAINTED_SCALAR) /mbedtls/library/asn1parse.c: 158 in asn1_get_tagged_int() 152 return( MBEDTLS_ERR_ASN1_INVALID_LENGTH ); 153 /* This is a cryptography library. Reject negative integers. */ 154 if( ( **p & 0x80 ) != 0 ) 155 return( MBEDTLS_ERR_ASN1_INVALID_LENGTH ); 156 157 /* Skip leading zeros. */ >>> CID 366277: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "len" as a loop boundary. 158 while( len > 0 && **p == 0 ) 159 { 160 ++( *p ); 161 --len; 162 } 163 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 8 months

1
0
0 0

Re: [TF-A] 1023 INTID - closed

by AT&T

All right. Thank you Manish and Olivier for your feedback. You can close this topic. Oliver answered the concern I had regarding implementing a vector table during boot time. Ian Burres Cybersecurity R&D > On Feb 3, 2021, at 3:14 AM, tf-a-request(a)lists.trustedfirmware.org wrote: > > Send TF-A mailing list submissions to > tf-a(a)lists.trustedfirmware.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > or, via email, send a message with subject or body 'help' to > tf-a-request(a)lists.trustedfirmware.org > > You can reach the person managing the list at > tf-a-owner(a)lists.trustedfirmware.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of TF-A digest..." > > > Today's Topics: > > 1. Re: 1023 spurious interrupt (AT&T) > 2. Re: 1023 spurious interrupt (Olivier Deprez) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 2 Feb 2021 18:15:25 -0700 > From: AT&T <iburres(a)att.net> > To: tf-a(a)lists.trustedfirmware.org > Subject: Re: [TF-A] 1023 spurious interrupt > Message-ID: <04497C24-78D2-460F-BCC0-535998937145(a)att.net> > Content-Type: text/plain; charset=utf-8 > > Yep, I had an O not a zero. Don’t see a difference yet, but that definitely needed to be fixed. Thank you. > > Ian Burres > Cybersecurity R&D > > >> On Feb 2, 2021, at 3:53 PM, tf-a-request(a)lists.trustedfirmware.org wrote: >> >> Send TF-A mailing list submissions to >> tf-a(a)lists.trustedfirmware.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.trustedfirmware.org/mailman/listinfo/tf-a >> or, via email, send a message with subject or body 'help' to >> tf-a-request(a)lists.trustedfirmware.org >> >> You can reach the person managing the list at >> tf-a-owner(a)lists.trustedfirmware.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of TF-A digest..." >> >> >> Today's Topics: >> >> 1. Re: Spurious interrupt 1023 (Ian Burres) >> 2. Re: Spurious interrupt 1023 (Manish Pandey2) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Tue, 2 Feb 2021 14:03:05 -0700 >> From: Ian Burres <iburres(a)att.net> >> To: Olivier Deprez <Olivier.Deprez(a)arm.com>, >> "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org> >> Subject: Re: [TF-A] Spurious interrupt 1023 >> Message-ID: <20210202210320.2C48741B32(a)lists.trustedfirmware.org> >> Content-Type: text/plain; charset="utf-8" >> >> UPDATE: I managed to get the Pi to complete the boot process, which is a major hurdle I have been trying to overcome. >> >> As for your questions Olivier: >> >> The vector table is loaded during bl31 (its called in the bl31_main.c main() function, right after bl31_platform_setup()). The Pi 4B uses GICv2 (your assumption was correct) and the BCM2711 chip. >> >> Right now both my irq and fiq handlers use: ID = gicv2_get_pending_interrupt_id(); to read the INTID. >> >> Neither handler does anything else other than print the ID, which returns 1023 for fiq only, using HS_DEBUG(). Nothing returns for irq. >> >> Build options are: PLAT=rpi4 DEBUG=1 LOG_LEVEL=50 RUNTIME_UART=2 GICV2_GO_FOR_EL3=1 >> >> Wasn’t trying to route the UART RX interrupt to EL3, though that’s not a bad idea (FIFO, right?) . However, I have been exploring the idea of generating an ARM timer interrupt (not system timer), but I couldn’t get past the boot issue, which seems to have now been resolved. >> >> Questions: Do you see any reason why loading the vector table during the boot process will prevent interrupts from being routed to EL3 correctly? If you do not, then I think I can take it from here. >> >> Sent from Mail for Windows 10 >> >> From: Olivier Deprez >> Sent: Monday, February 1, 2021 2:36 AM >> To: tf-a(a)lists.trustedfirmware.org; AT&T >> Subject: Re: [TF-A] Spurious interrupt 1023 >> >> Hi Ian, >> >> I guess we'll need a bit more details in order to help you. >> Which platform are you using? which GIC version is it using (looks like GICv2?) ? >> How did you built TF-A for this platform (command line arguments)? >> What is executing on your platform (e.g. linux in the non-secure world)? Is there any component in the SWd (apart from EL3 monitor) like a TEE? >> Are you trying to route the UART RX interrupt to EL3? >> Is this UART instance only owned by the SWd? >> How did you setup the interrupt handler? >> Which function are you using to read the INTID? >> >> Regards, >> Olivier. >> >> ________________________________________ >> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of AT&T via TF-A <tf-a(a)lists.trustedfirmware.org> >> Sent: 29 January 2021 21:08 >> To: tf-a(a)lists.trustedfirmware.org >> Subject: [TF-A] Spurious interrupt 1023 >> >> I asked a similar question before, but I have since made some headway concerning routing fiq interrupts to EL3. I placed an HS_DEBUG command to print the ID, which returns 1023. The RX signal on one of the attached UARTs causes a solid red light and the debug message continuously loops. When I use the functions from gicv2.h, I receive an assertion error regarding MAX_SPI_ID, but the looping stops. >> >> I think the 1023 ID suggests non-secure is receiving a secure interrupt OR I’m dealing with a possible race condition. Any thoughts? Should I attach my code? >> >> >> >> Ian Burres >> Cybersecurity R&D >> >> >> -- >> TF-A mailing list >> TF-A(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/tf-a >> >>

4 years, 9 months

1
0
0 0

Re: [TF-A] 1023 spurious interrupt

by Olivier Deprez

Hi, Stepping back to the initial thread, I now miss the rationale for routing interrupts to EL3. "I have successfully implement a Linux driver that allows me to dump kernel page tables and memory; however, I cannot see user page tables (even after running a CPU intensive program ). I believe the only way to view user page tables is to have interrupts routed to EL3 – a Linux driver is not sufficient." If your intent is to dump user process page tables, that's something to do using the linux kernel mm framework, and not necessarily at EL3. Not sure why a "linux driver is not sufficient". More inputs on this may be beneficial. Nevertheless if you need a service in EL3 to do "introspection", you would rather write a form of SiP service accessed through SMC (not necessarily routing interrupts through FIQ). As for the code snippets, replacing vbar_el3 with your own vector table looks wrong. This will break any service call back into EL3 when linux is booted (e.g. PSCI calls....) If you really want to route interrupts to EL3 you shall use the Interrupt Handling Framework as Manish suggested. e.g. uint64_t fiq_handler(uint32_t id, uint32_t flags, void *handle, void *cookie) { [...] return 0; } void register_my_interrupt(void) { int32_t rc, flags = 0; plat_ic_set_interrupt_type(intid, INTR_TYPE_EL3); set_interrupt_rm_flag(flags, NON_SECURE); rc = register_interrupt_type_handler(INTR_TYPE_EL3, fiq_handler, flags); NOTICE("register_interrupt_type_handler %d\n", rc); } Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of AT&T via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 03 February 2021 02:15 To: tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] 1023 spurious interrupt Yep, I had an O not a zero. Don’t see a difference yet, but that definitely needed to be fixed. Thank you. Ian Burres Cybersecurity R&D > On Feb 2, 2021, at 3:53 PM, tf-a-request(a)lists.trustedfirmware.org wrote: > > Send TF-A mailing list submissions to > tf-a(a)lists.trustedfirmware.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > or, via email, send a message with subject or body 'help' to > tf-a-request(a)lists.trustedfirmware.org > > You can reach the person managing the list at > tf-a-owner(a)lists.trustedfirmware.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of TF-A digest..." > > > Today's Topics: > > 1. Re: Spurious interrupt 1023 (Ian Burres) > 2. Re: Spurious interrupt 1023 (Manish Pandey2) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 2 Feb 2021 14:03:05 -0700 > From: Ian Burres <iburres(a)att.net> > To: Olivier Deprez <Olivier.Deprez(a)arm.com>, > "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org> > Subject: Re: [TF-A] Spurious interrupt 1023 > Message-ID: <20210202210320.2C48741B32(a)lists.trustedfirmware.org> > Content-Type: text/plain; charset="utf-8" > > UPDATE: I managed to get the Pi to complete the boot process, which is a major hurdle I have been trying to overcome. > > As for your questions Olivier: > > The vector table is loaded during bl31 (its called in the bl31_main.c main() function, right after bl31_platform_setup()). The Pi 4B uses GICv2 (your assumption was correct) and the BCM2711 chip. > > Right now both my irq and fiq handlers use: ID = gicv2_get_pending_interrupt_id(); to read the INTID. > > Neither handler does anything else other than print the ID, which returns 1023 for fiq only, using HS_DEBUG(). Nothing returns for irq. > > Build options are: PLAT=rpi4 DEBUG=1 LOG_LEVEL=50 RUNTIME_UART=2 GICV2_GO_FOR_EL3=1 > > Wasn’t trying to route the UART RX interrupt to EL3, though that’s not a bad idea (FIFO, right?) . However, I have been exploring the idea of generating an ARM timer interrupt (not system timer), but I couldn’t get past the boot issue, which seems to have now been resolved. > > Questions: Do you see any reason why loading the vector table during the boot process will prevent interrupts from being routed to EL3 correctly? If you do not, then I think I can take it from here. > > Sent from Mail for Windows 10 > > From: Olivier Deprez > Sent: Monday, February 1, 2021 2:36 AM > To: tf-a(a)lists.trustedfirmware.org; AT&T > Subject: Re: [TF-A] Spurious interrupt 1023 > > Hi Ian, > > I guess we'll need a bit more details in order to help you. > Which platform are you using? which GIC version is it using (looks like GICv2?) ? > How did you built TF-A for this platform (command line arguments)? > What is executing on your platform (e.g. linux in the non-secure world)? Is there any component in the SWd (apart from EL3 monitor) like a TEE? > Are you trying to route the UART RX interrupt to EL3? > Is this UART instance only owned by the SWd? > How did you setup the interrupt handler? > Which function are you using to read the INTID? > > Regards, > Olivier. > > ________________________________________ > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of AT&T via TF-A <tf-a(a)lists.trustedfirmware.org> > Sent: 29 January 2021 21:08 > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] Spurious interrupt 1023 > > I asked a similar question before, but I have since made some headway concerning routing fiq interrupts to EL3. I placed an HS_DEBUG command to print the ID, which returns 1023. The RX signal on one of the attached UARTs causes a solid red light and the debug message continuously loops. When I use the functions from gicv2.h, I receive an assertion error regarding MAX_SPI_ID, but the looping stops. > > I think the 1023 ID suggests non-secure is receiving a secure interrupt OR I’m dealing with a possible race condition. Any thoughts? Should I attach my code? > > > > Ian Burres > Cybersecurity R&D > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > >

4 years, 9 months

1
0
0 0

Re: [TF-A] 1023 spurious interrupt

by AT&T

Yep, I had an O not a zero. Don’t see a difference yet, but that definitely needed to be fixed. Thank you. Ian Burres Cybersecurity R&D > On Feb 2, 2021, at 3:53 PM, tf-a-request(a)lists.trustedfirmware.org wrote: > > Send TF-A mailing list submissions to > tf-a(a)lists.trustedfirmware.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > or, via email, send a message with subject or body 'help' to > tf-a-request(a)lists.trustedfirmware.org > > You can reach the person managing the list at > tf-a-owner(a)lists.trustedfirmware.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of TF-A digest..." > > > Today's Topics: > > 1. Re: Spurious interrupt 1023 (Ian Burres) > 2. Re: Spurious interrupt 1023 (Manish Pandey2) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 2 Feb 2021 14:03:05 -0700 > From: Ian Burres <iburres(a)att.net> > To: Olivier Deprez <Olivier.Deprez(a)arm.com>, > "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org> > Subject: Re: [TF-A] Spurious interrupt 1023 > Message-ID: <20210202210320.2C48741B32(a)lists.trustedfirmware.org> > Content-Type: text/plain; charset="utf-8" > > UPDATE: I managed to get the Pi to complete the boot process, which is a major hurdle I have been trying to overcome. > > As for your questions Olivier: > > The vector table is loaded during bl31 (its called in the bl31_main.c main() function, right after bl31_platform_setup()). The Pi 4B uses GICv2 (your assumption was correct) and the BCM2711 chip. > > Right now both my irq and fiq handlers use: ID = gicv2_get_pending_interrupt_id(); to read the INTID. > > Neither handler does anything else other than print the ID, which returns 1023 for fiq only, using HS_DEBUG(). Nothing returns for irq. > > Build options are: PLAT=rpi4 DEBUG=1 LOG_LEVEL=50 RUNTIME_UART=2 GICV2_GO_FOR_EL3=1 > > Wasn’t trying to route the UART RX interrupt to EL3, though that’s not a bad idea (FIFO, right?) . However, I have been exploring the idea of generating an ARM timer interrupt (not system timer), but I couldn’t get past the boot issue, which seems to have now been resolved. > > Questions: Do you see any reason why loading the vector table during the boot process will prevent interrupts from being routed to EL3 correctly? If you do not, then I think I can take it from here. > > Sent from Mail for Windows 10 > > From: Olivier Deprez > Sent: Monday, February 1, 2021 2:36 AM > To: tf-a(a)lists.trustedfirmware.org; AT&T > Subject: Re: [TF-A] Spurious interrupt 1023 > > Hi Ian, > > I guess we'll need a bit more details in order to help you. > Which platform are you using? which GIC version is it using (looks like GICv2?) ? > How did you built TF-A for this platform (command line arguments)? > What is executing on your platform (e.g. linux in the non-secure world)? Is there any component in the SWd (apart from EL3 monitor) like a TEE? > Are you trying to route the UART RX interrupt to EL3? > Is this UART instance only owned by the SWd? > How did you setup the interrupt handler? > Which function are you using to read the INTID? > > Regards, > Olivier. > > ________________________________________ > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of AT&T via TF-A <tf-a(a)lists.trustedfirmware.org> > Sent: 29 January 2021 21:08 > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] Spurious interrupt 1023 > > I asked a similar question before, but I have since made some headway concerning routing fiq interrupts to EL3. I placed an HS_DEBUG command to print the ID, which returns 1023. The RX signal on one of the attached UARTs causes a solid red light and the debug message continuously loops. When I use the functions from gicv2.h, I receive an assertion error regarding MAX_SPI_ID, but the looping stops. > > I think the 1023 ID suggests non-secure is receiving a secure interrupt OR I’m dealing with a possible race condition. Any thoughts? Should I attach my code? > > > > Ian Burres > Cybersecurity R&D > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > >

4 years, 9 months

1
0
0 0

Re: [TF-A] Spurious interrupt 1023

by Manish Pandey2

I have seen same thing in your previous thread also, could you please confirm that the build option GICV2_G0_FOR_EL3 instead of GICV2_GO_FOR_EL3 (zero instead of "O"). ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Ian Burres via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 02 February 2021 21:03 To: Olivier Deprez <Olivier.Deprez(a)arm.com>; tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Spurious interrupt 1023 UPDATE: I managed to get the Pi to complete the boot process, which is a major hurdle I have been trying to overcome. As for your questions Olivier: The vector table is loaded during bl31 (its called in the bl31_main.c main() function, right after bl31_platform_setup()). The Pi 4B uses GICv2 (your assumption was correct) and the BCM2711 chip. Right now both my irq and fiq handlers use: ID = gicv2_get_pending_interrupt_id(); to read the INTID. Neither handler does anything else other than print the ID, which returns 1023 for fiq only, using HS_DEBUG(). Nothing returns for irq. Build options are: PLAT=rpi4 DEBUG=1 LOG_LEVEL=50 RUNTIME_UART=2 GICV2_GO_FOR_EL3=1 Wasn’t trying to route the UART RX interrupt to EL3, though that’s not a bad idea (FIFO, right?) . However, I have been exploring the idea of generating an ARM timer interrupt (not system timer), but I couldn’t get past the boot issue, which seems to have now been resolved. Questions: Do you see any reason why loading the vector table during the boot process will prevent interrupts from being routed to EL3 correctly? If you do not, then I think I can take it from here. Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 From: Olivier Deprez<mailto:Olivier.Deprez@arm.com> Sent: Monday, February 1, 2021 2:36 AM To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>; AT&T<mailto:iburres@att.net> Subject: Re: [TF-A] Spurious interrupt 1023 Hi Ian, I guess we'll need a bit more details in order to help you. Which platform are you using? which GIC version is it using (looks like GICv2?) ? How did you built TF-A for this platform (command line arguments)? What is executing on your platform (e.g. linux in the non-secure world)? Is there any component in the SWd (apart from EL3 monitor) like a TEE? Are you trying to route the UART RX interrupt to EL3? Is this UART instance only owned by the SWd? How did you setup the interrupt handler? Which function are you using to read the INTID? Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of AT&T via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 29 January 2021 21:08 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Spurious interrupt 1023 I asked a similar question before, but I have since made some headway concerning routing fiq interrupts to EL3. I placed an HS_DEBUG command to print the ID, which returns 1023. The RX signal on one of the attached UARTs causes a solid red light and the debug message continuously loops. When I use the functions from gicv2.h, I receive an assertion error regarding MAX_SPI_ID, but the looping stops. I think the 1023 ID suggests non-secure is receiving a secure interrupt OR I’m dealing with a possible race condition. Any thoughts? Should I attach my code? Ian Burres Cybersecurity R&D -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 9 months

1
0
0 0

Re: [TF-A] Spurious interrupt 1023

by Olivier Deprez

Hi Ian, I guess we'll need a bit more details in order to help you. Which platform are you using? which GIC version is it using (looks like GICv2?) ? How did you built TF-A for this platform (command line arguments)? What is executing on your platform (e.g. linux in the non-secure world)? Is there any component in the SWd (apart from EL3 monitor) like a TEE? Are you trying to route the UART RX interrupt to EL3? Is this UART instance only owned by the SWd? How did you setup the interrupt handler? Which function are you using to read the INTID? Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of AT&T via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 29 January 2021 21:08 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Spurious interrupt 1023 I asked a similar question before, but I have since made some headway concerning routing fiq interrupts to EL3. I placed an HS_DEBUG command to print the ID, which returns 1023. The RX signal on one of the attached UARTs causes a solid red light and the debug message continuously loops. When I use the functions from gicv2.h, I receive an assertion error regarding MAX_SPI_ID, but the looping stops. I think the 1023 ID suggests non-secure is receiving a secure interrupt OR I’m dealing with a possible race condition. Any thoughts? Should I attach my code? Ian Burres Cybersecurity R&D -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 9 months

2
1
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 2 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 366312: Uninitialized variables (UNINIT) /drivers/renesas/rzg/ddr/ddr_b/boot_init_dram.c: 760 in ddrphy_regif_chk() ________________________________________________________________________________________________________ *** CID 366312: Uninitialized variables (UNINIT) /drivers/renesas/rzg/ddr/ddr_b/boot_init_dram.c: 760 in ddrphy_regif_chk() 754 PI_VERSION_CODE = 0x2041U; /* G2M */ 755 } 756 757 ddr_getval_ach(_reg_PI_VERSION, (uint32_t *)tmp_ach); 758 err = 0U; 759 foreach_vch(ch) { >>> CID 366312: Uninitialized variables (UNINIT) >>> Using uninitialized value "PI_VERSION_CODE". 760 if (tmp_ach[ch] != PI_VERSION_CODE) { 761 err = 1U; 762 } 763 } 764 return err; 765 } ** CID 366311: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 366311: Memory - corruptions (OVERRUN) /drivers/renesas/rzg/ddr/ddr_b/boot_init_dram.c: 3156 in rdqdm_man1() 3150 } 3151 } 3152 } 3153 if ((prr_product == PRR_PRODUCT_M3) && 3154 (prr_cut <= PRR_PRODUCT_10)) { 3155 for (slice = 0U; slice < SLICE_CNT; slice++) { >>> CID 366311: Memory - corruptions (OVERRUN) >>> Overrunning callee's array of size 32 by passing argument "slice" (which evaluates to 24) in call to "rdqdm_man1_set". 3156 rdqdm_man1_set(ddr_csn, ch, slice); 3157 } 3158 } 3159 } 3160 ddrphy_regif_idle(); 3161 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 9 months

1
0
0 0

Spurious interrupt 1023

by AT&T

I asked a similar question before, but I have since made some headway concerning routing fiq interrupts to EL3. I placed an HS_DEBUG command to print the ID, which returns 1023. The RX signal on one of the attached UARTs causes a solid red light and the debug message continuously loops. When I use the functions from gicv2.h, I receive an assertion error regarding MAX_SPI_ID, but the looping stops. I think the 1023 ID suggests non-secure is receiving a secure interrupt OR I’m dealing with a possible race condition. Any thoughts? Should I attach my code? Ian Burres Cybersecurity R&D

4 years, 9 months

1
0
0 0

Re: [TF-A] PK hash verify after signature virified

by Manish Badarkhe

Hi Bin Wu, Thanks for coming up with this question. As per the below signature verification code, you raised a valid point that signature gets verified before ROTPK hash verification. 1. Get ROTPK hash from the platform (Using platform implemented method e.g., HW register). 2. Extract ROTPK from the image itself. 3. Use ROTPK to verify the image signature. 4. Calculate the hash of ROTPK and compare it against the hash received in step[1]. But we can't see any concern as the system fails to boot anyways at step [4] if the ROTPK gets corrupted. Regards Manish Badarkhe From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of 吴斌(郅隆) via TF-A <tf-a(a)lists.trustedfirmware.org> Date: Friday, 29 January 2021 at 07:55 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] PK hash verify after signature virified Hi All, I am studying tbbr module in ATF recenlty. I have a little confusion about the ROTPK hash verify flow. In ATF current implementation, we will verify the signature first, then verify the ROTPK hash. But in my understanding, we should verify ROTPK first then verify signature. So, what is the consideration that we use current flow in ATF? Thanks for you patience BRs， Bin Wu

4 years, 9 months

1
0
0 0

PK hash verify after signature virified

by 吴斌(郅隆)

Hi All, I am studying tbbr module in ATF recenlty. I have a little confusion about the ROTPK hash verify flow. In ATF current implementation, we will verify the signature first, then verify the ROTPK hash. But in my understanding, we should verify ROTPK first then verify signature. So, what is the consideration that we use current flow in ATF? Thanks for you patience BRs， Bin Wu

4 years, 9 months

1
0
0 0

TF-A Tech Forum Agenda @ Thr 28th January 2021 16:00-1700 GMT

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 28th January 2021 16:00 – 17:00 (GMT). Agenda: * TF-A: Automotive Enhance (AE) Architecture Support Requirements Discussion * Presented by Manish Pandy and Manish Badarkhe * A discussion on the needs for the Automotive Enhance (AE) space and how TF-A can support that with CPU and GIC capabilities. The goal is to follow-up the recent email to the TF-A mailing list and try and understand project needs in this space by talking to the project community. If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled. Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ A scheduling tracking page is also available to help track sessions suggested: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting on the TF-A mailing list. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One 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-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Thanks Joanna

4 years, 9 months

1
0
0 0

Re: [TF-A] Gather GIC changes required for safety critical machines

by Varun Wadekar

<Cc alias> I guess, something went wrong when I clicked "Reply all" the first time. Manish, can you also talk about the tasks that Arm is willing to work on? Then we can ask for volunteers for the remaining ones. I'm sure, NVIDIA will contribute as this topic is close to our heart. -Varun From: Manish Pandey2 <Manish.Pandey2(a)arm.com> Sent: Monday, January 25, 2021 8:05 AM To: Varun Wadekar <vwadekar(a)nvidia.com> Cc: Filipe Rinaldi <Filipe.Rinaldi(a)arm.com>; Robin Randhawa <Robin.Randhawa(a)ARM.com>; Ed Doxat <Ed.Doxat(a)arm.com>; Joanna Farley <joannafarley(a)icloud.com>; Manish Badarkhe <Manish.Badarkhe(a)arm.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; Matteo Carlini <Matteo.Carlini(a)arm.com>; Doug Richmond <Doug.Richmond(a)arm.com> Subject: Re: Gather GIC changes required for safety critical machines External email: Use caution opening links or attachments ++ Other Arm folks Just realized that Varun has reduced the recipients(guess that was intentional) ________________________________ From: Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> Sent: 25 January 2021 10:15 To: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>> Cc: Filipe Rinaldi <Filipe.Rinaldi(a)arm.com<mailto:Filipe.Rinaldi@arm.com>>; Robin Randhawa <Robin.Randhawa(a)ARM.com<mailto:Robin.Randhawa@ARM.com>>; Ed Doxat <Ed.Doxat(a)arm.com<mailto:Ed.Doxat@arm.com>> Subject: Re: Gather GIC changes required for safety critical machines Hi Varun, We are trying to do both, based on interest from community we will prioritize these tasks. The reason why we can't do all the asks (mentioned in the list) ourselves is, currently we do not have "use cases/platforms" to test all the features, so we would rely on wider community to understand the requirements and work together to develop/test those features. Thanks Manish ________________________________ From: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>> Sent: 22 January 2021 17:46 To: Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> Cc: Filipe Rinaldi <Filipe.Rinaldi(a)arm.com<mailto:Filipe.Rinaldi@arm.com>>; Robin Randhawa <Robin.Randhawa(a)ARM.com<mailto:Robin.Randhawa@ARM.com>>; Ed Doxat <Ed.Doxat(a)arm.com<mailto:Ed.Doxat@arm.com>> Subject: RE: Gather GIC changes required for safety critical machines HI Manish, Thanks for starting this discussion. The list captures all the functionalities that are useful and interesting to us. Trying to understand the ask - are you trying to get feedback to allow you to prioritize the feature list? Or are you asking for the community to rate importance of these requirements? I am afraid, if there isn't enough interest the list might be trimmed which would be an absolute shame. -Varun From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> On Behalf Of Manish Pandey2 via TF-A Sent: Friday, January 22, 2021 8:02 AM To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Cc: Filipe Rinaldi <Filipe.Rinaldi(a)arm.com<mailto:Filipe.Rinaldi@arm.com>>; Robin Randhawa <Robin.Randhawa(a)ARM.com<mailto:Robin.Randhawa@ARM.com>>; Ed Doxat <Ed.Doxat(a)arm.com<mailto:Ed.Doxat@arm.com>> Subject: [TF-A] Gather GIC changes required for safety critical machines External email: Use caution opening links or attachments Hi, GIC600-AE is variant of GIC for safety critical machines, though its TRM is publicly available from quite some time but currently we do not have support in TF-A. Purpose of this email is to kick start discussions around various possible GIC requirements as far as safety critical machines are concerned. We have created following list of requirements based on inputs we got so far, changes are either adding new AE features or enhancements to existing drivers. GIC-600AE feature requirement: - Inject and detect RAS errors using Fault management unit(FMU) - Validating feature parity with GIC600 - Running GIC IP in Dual core Lock-step(DCLS) mode. GIC/RAS driver enhancements: - Read trace and PMU records - Keep RAS error records alive across a reset - Disable GICR frames of fused-off cores - Support for message signalled interrupts - Saving/Restoring additional GIC registers during PM events Feel free to add any additional requirements. If there is enough community interest during the next Tech-forum meeting(28th Jan) we would like to go through these requirements in more detail. Thanks Manish 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, 9 months

1
0
0 0

[PATCHv9 0/3] arm-virt: add secure pl061 for reset/power down

by Maxim Uvarov

v9: - cosmetic changes (move if from patch2 to patch3, rename function name and define). v8: - use gpio 0 and 1, align dtb with kernel gpio-restart, gpio-poweroff, change define names, trigger on upper front. (Peter Maydell). v7: - same as v6, but resplit patches: patch 2 no function changes and refactor gpio setup for virt platfrom and patch 3 adds secure gpio. v6: - 64k align gpio memory region (Andrew Jones) - adjusted memory region to map this address in the corresponding atf patch v5: - removed vms flag, added fdt (Andrew Jones) - added patch3 to combine secure and non secure pl061. It has to be more easy to review if this changes are in the separate patch. v4: rework patches accodring to Peter Maydells comments: - split patches on gpio-pwr driver and arm-virt integration. - start secure gpio only from virt-6.0. - rework qemu interface for gpio-pwr to use 2 named gpio. - put secure gpio to secure name space. v3: added missed include qemu/log.h for qemu_log(.. v2: replace printf with qemu_log (Philippe Mathieu-Daudé) This patch works together with ATF patch: https://github.com/muvarov/arm-trusted-firmware/commit/886965bddb0624bdf851… Maxim Uvarov (3): hw: gpio: implement gpio-pwr driver for qemu reset/poweroff arm-virt: refactor gpios creation arm-virt: add secure pl061 for reset/power down hw/arm/Kconfig | 1 + hw/arm/virt.c | 111 ++++++++++++++++++++++++++++++++++-------- hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 70 ++++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 2 + 6 files changed, 167 insertions(+), 21 deletions(-) create mode 100644 hw/gpio/gpio_pwr.c -- 2.17.1

4 years, 9 months

2
4
0 0

Gather GIC changes required for safety critical machines

by Manish Pandey2

Hi, GIC600-AE is variant of GIC for safety critical machines, though its TRM is publicly available from quite some time but currently we do not have support in TF-A. Purpose of this email is to kick start discussions around various possible GIC requirements as far as safety critical machines are concerned. We have created following list of requirements based on inputs we got so far, changes are either adding new AE features or enhancements to existing drivers. GIC-600AE feature requirement: - Inject and detect RAS errors using Fault management unit(FMU) - Validating feature parity with GIC600 - Running GIC IP in Dual core Lock-step(DCLS) mode. GIC/RAS driver enhancements: - Read trace and PMU records - Keep RAS error records alive across a reset - Disable GICR frames of fused-off cores - Support for message signalled interrupts - Saving/Restoring additional GIC registers during PM events Feel free to add any additional requirements. If there is enough community interest during the next Tech-forum meeting(28th Jan) we would like to go through these requirements in more detail. Thanks Manish

4 years, 9 months

1
0
0 0

[PATCHv8 0/3] arm-virt: add secure pl061 for reset/power down

by Maxim Uvarov

v8: - use gpio 0 and 1, align dtb with kernel gpio-restart, gpio-poweroff, change define names, trigger on upper front. (Peter Maydell). v7: - same as v6, but resplit patches: patch 2 no function changes and refactor gpio setup for virt platfrom and patch 3 adds secure gpio. v6: - 64k align gpio memory region (Andrew Jones) - adjusted memory region to map this address in the corresponding atf patch v5: - removed vms flag, added fdt (Andrew Jones) - added patch3 to combine secure and non secure pl061. It has to be more easy to review if this changes are in the separate patch. v4: rework patches accodring to Peter Maydells comments: - split patches on gpio-pwr driver and arm-virt integration. - start secure gpio only from virt-6.0. - rework qemu interface for gpio-pwr to use 2 named gpio. - put secure gpio to secure name space. v3: added missed include qemu/log.h for qemu_log(.. v2: replace printf with qemu_log (Philippe Mathieu-Daudé) This patch works together with ATF patch: https://github.com/muvarov/arm-trusted-firmware/commit/886965bddb0624bdf851… Maxim Uvarov (3): hw: gpio: implement gpio-pwr driver for qemu reset/poweroff arm-virt: refactor gpios creation arm-virt: add secure pl061 for reset/power down hw/arm/Kconfig | 1 + hw/arm/virt.c | 111 ++++++++++++++++++++++++++++++++++-------- hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 70 ++++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 2 + 6 files changed, 167 insertions(+), 21 deletions(-) create mode 100644 hw/gpio/gpio_pwr.c -- 2.17.1

4 years, 9 months

3
9
0 0

[PATCHv7 0/3] arm-virt: add secure pl061 for reset/power down

by Maxim Uvarov

v7: - same as v6, but resplit patches: patch 2 no function changes and refactor gpio setup for virt platfrom and patch 3 adds secure gpio. v6: - 64k align gpio memory region (Andrew Jones) - adjusted memory region to map this address in the corresponding atf patch v5: - removed vms flag, added fdt (Andrew Jones) - added patch3 to combine secure and non secure pl061. It has to be more easy to review if this changes are in the separate patch. v4: rework patches accodring to Peter Maydells comments: - split patches on gpio-pwr driver and arm-virt integration. - start secure gpio only from virt-6.0. - rework qemu interface for gpio-pwr to use 2 named gpio. - put secure gpio to secure name space. v3: added missed include qemu/log.h for qemu_log(.. v2: replace printf with qemu_log (Philippe Mathieu-Daudé) This patch works together with ATF patch: https://github.com/muvarov/arm-trusted-firmware/commit/7556d07e87f755c602cd… Previus discussion for reboot issue was here: https://www.mail-archive.com/qemu-devel@nongnu.org/msg757705.html Maxim Uvarov (3): hw: gpio: implement gpio-pwr driver for qemu reset/poweroff arm-virt: refactor gpios creation arm-virt: add secure pl061 for reset/power down hw/arm/Kconfig | 1 + hw/arm/virt.c | 117 ++++++++++++++++++++++++++++++++++-------- hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 70 +++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 2 + 6 files changed, 174 insertions(+), 20 deletions(-) create mode 100644 hw/gpio/gpio_pwr.c -- 2.17.1

4 years, 9 months

2
8
0 0

[PATCHv6 0/3] arm-virt: add secure pl061 for reset/power down

by Maxim Uvarov

v6: - 64k align gpio memory region (Andrew Jones) - adjusted memory region to map this address in the corresponding atf patch v5: - removed vms flag, added fdt (Andrew Jones) - added patch3 to combine secure and non secure pl061. It has to be more easy to review if this changes are in the separate patch. v4: rework patches accodring to Peter Maydells comments: - split patches on gpio-pwr driver and arm-virt integration. - start secure gpio only from virt-6.0. - rework qemu interface for gpio-pwr to use 2 named gpio. - put secure gpio to secure name space. v3: added missed include qemu/log.h for qemu_log(.. v2: replace printf with qemu_log (Philippe Mathieu-Daudé) This patch works together with ATF patch: https://github.com/muvarov/arm-trusted-firmware/commit/7556d07e87f755c602cd… Previus discussion for reboot issue was here: https://www.mail-archive.com/qemu-devel@nongnu.org/msg757705.html Maxim Uvarov (3): hw: gpio: implement gpio-pwr driver for qemu reset/poweroff arm-virt: add secure pl061 for reset/power down arm-virt: combine code for secure and non secure pl061 hw/arm/Kconfig | 1 + hw/arm/virt.c | 118 +++++++++++++++++++++++++++++++++++------- hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 70 +++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 2 + 6 files changed, 175 insertions(+), 20 deletions(-) create mode 100644 hw/gpio/gpio_pwr.c -- 2.17.1

4 years, 9 months

2
4
0 0

[PATCHv4 0/2] arm-virt: add secure pl061 for reset/power down

by Maxim Uvarov

v4: rework patches accodring to Peter Maydells comments: - split patches on gpio-pwr driver and arm-virt integration. - start secure gpio only from virt-6.0. - rework qemu interface for gpio-pwr to use 2 named gpio. - put secure gpio to secure name space. v3: added missed include qemu/log.h for qemu_log(.. v2: replace printf with qemu_log (Philippe Mathieu-Daudé) This patch works together with ATF patch: https://github.com/muvarov/arm-trusted-firmware/commit/dd4401d8eb8e0f3018b3… Previus discussion for reboot issue was here: https://www.mail-archive.com/qemu-devel@nongnu.org/msg757705.html Maxim Uvarov (2): hw: gpio: implement gpio-pwr driver for qemu reset/poweroff arm-virt: add secure pl061 for reset/power down hw/arm/Kconfig | 1 + hw/arm/virt.c | 40 +++++++++++++++++++++++++ hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 70 +++++++++++++++++++++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 3 ++ 6 files changed, 118 insertions(+) create mode 100644 hw/gpio/gpio_pwr.c -- 2.17.1

4 years, 9 months

4
14
0 0

Cancelled event with note: TF-A Tech Forum @ Thu 14 Jan 2021 16:00 - 17:00 (GMT) (tf-a@lists.trustedfirmware.org)

by Bill Fletcher

This event has been cancelled with this note: "Cancelled - see the mail from Joanna for more details" 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 14 Jan 2021 16:00 – 17:00 United Kingdom Time 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 organiser and be added to the guest list, 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, 9 months

1
0
0 0

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

by Joanna Farley

Apologies for the late notice I am cancelling this weeks TF-A Tech forum tomorrow as the subject I had hoped to get presented is not ready and I don’t have any alternative for this slot. I will look to have something for the next session on 28th January. Apologies for the late notice. Cancellations of the calendar invite will come from trustedformware.org as I don’t own the invite so it may not appear in your calendars until that is sent out. Thanks Joanna

4 years, 9 months

1
0
0 0

[PATCHv5 0/3] arm-virt: add secure pl061 for reset/power down

by Maxim Uvarov

v5: - removed vms flag, added fdt (Andrew Jones) - added patch3 to combine secure and non secure pl061. It has to be more easy to review if this changes are in the separate patch. v4: rework patches accodring to Peter Maydells comments: - split patches on gpio-pwr driver and arm-virt integration. - start secure gpio only from virt-6.0. - rework qemu interface for gpio-pwr to use 2 named gpio. - put secure gpio to secure name space. v3: added missed include qemu/log.h for qemu_log(.. v2: replace printf with qemu_log (Philippe Mathieu-Daudé) This patch works together with ATF patch: https://github.com/muvarov/arm-trusted-firmware/commit/dd4401d8eb8e0f3018b3… Previus discussion for reboot issue was here: https://www.mail-archive.com/qemu-devel@nongnu.org/msg757705.html Maxim Uvarov (3): hw: gpio: implement gpio-pwr driver for qemu reset/poweroff arm-virt: add secure pl061 for reset/power down arm-virt: combine code for secure and non secure pl061 hw/arm/Kconfig | 1 + hw/arm/virt.c | 118 +++++++++++++++++++++++++++++++++++------- hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 70 +++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 2 + 6 files changed, 175 insertions(+), 20 deletions(-) create mode 100644 hw/gpio/gpio_pwr.c -- 2.17.1

4 years, 9 months

1
3
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 365287: Control flow issues (MISSING_BREAK) /plat/xilinx/zynqmp/pm_service/pm_svc_main.c: 334 in pm_smc_handler() ________________________________________________________________________________________________________ *** CID 365287: Control flow issues (MISSING_BREAK) /plat/xilinx/zynqmp/pm_service/pm_svc_main.c: 334 in pm_smc_handler() 328 SMC_RET1(handle, (uint64_t)ret); 329 330 case PM_SET_MAX_LATENCY: 331 ret = pm_set_max_latency(pm_arg[0], pm_arg[1]); 332 SMC_RET1(handle, (uint64_t)ret); 333 >>> CID 365287: Control flow issues (MISSING_BREAK) >>> The case for value "PM_GET_API_VERSION" is not terminated by a 'break' statement. 334 case PM_GET_API_VERSION: 335 /* Check is PM API version already verified */ 336 if (pm_ctx.api_version >= PM_VERSION) { 337 if (!ipi_irq_flag) { 338 /* 339 * Enable IPI IRQ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 9 months

1
0
0 0

Re: [TF-A] Routing FIQ timer interrupts to EL3 on Raspberry Pi 4B

by Manish Pandey2

Hi To understand the interrupt handling in TF-A, i recommend you go through https://trustedfirmware-a.readthedocs.io/en/latest/design/interrupt-framewo… To debug your problem, you need to first check if the timer interrupt is generated as FIQ and check whether it indeed is trapped in EL3 (checking SCR_EL3.FIQ=1). Regarding build errors while adding .S files and your assembly implementation, it will be better if you share your code (may be pushing a patch on https://review.trustedfirmware.org). Thanks Manish ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Ian Burres via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 06 January 2021 17:56 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Routing FIQ timer interrupts to EL3 on Raspberry Pi 4B I am attempting to route FIQ timer interrupts using the ARM timers (not system timers) to EL3 in order to achieve introspection. I am running TF-A (cross compiled for AArch64/AArch32) on a Raspberry Pi 4B, which uses the Broadcom 2711 chipset. I have written some code, but I am not an embedded software engineer – I’m an IoT pentester. The ARM timers look like this: RPI4_ARM_TIMER_LOAD 0x400 RPI4_ARM_TIMER_VALUE 0x404 ….. RPI4_ARM_TIMER_FREE_COUNTER 0x420 System timers are: RPI4_SYS_TIMER_CLO, RPI4_SYS_TIMER_CS, etc… I have successfully implement a Linux driver that allows me to dump kernel page tables and memory; however, I cannot see user page tables (even after running a CPU intensive program ). I believe the only way to view user page tables is to have interrupts routed to EL3 – a Linux driver is not sufficient. I have 3 UARTs attached with a debug log and screen setup. From what I have read, the Raspberry Pi 4B uses GICv2. TF-A supports EL3 routing when the build option GICV2_GO_FOR_EL3 is enabled, which I have done. >From what I have gathered, the FIQ interrupt has to be written in assembly. So far, I have created a vector table, loaded the vector table, and masked and unmasked interrupts using daifclr, #3 and daifset, #3 instructions, using inline assembly. The timer is initinitialized and handled using C functions. I am using inline assembly, because I am adding code to the TF-A base, and I have not discovered how to add .S files to the build without receiving make errors. I will gladly share the code I have if it helps, but what I am really looking for is if anyone believes I am on the right track or not. Obviously, I am not implementing something correctly since the interrupt is not being handled. Thanks. Thomas Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

4 years, 9 months

2
1
0 0

[PATCHv3] arm-virt: add secure pl061 for reset/power down

by Maxim Uvarov

Add secure pl061 for reset/power down machine from the secure world (Arm Trusted Firmware). Use the same gpio 3 and gpio 4 which were used by non acpi variant of linux power control gpios. Signed-off-by: Maxim Uvarov <maxim.uvarov(a)linaro.org> --- v3: added missed include qemu/log.h for qemu_log(.. v2: replace printf with qemu_log (Philippe Mathieu-Daudé) hw/arm/Kconfig | 1 + hw/arm/virt.c | 24 ++++++++++++ hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 85 +++++++++++++++++++++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 1 + 6 files changed, 115 insertions(+) create mode 100644 hw/gpio/gpio_pwr.c diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig index 0a242e4c5d..13cc42dcc8 100644 --- a/hw/arm/Kconfig +++ b/hw/arm/Kconfig @@ -17,6 +17,7 @@ config ARM_VIRT select PL011 # UART select PL031 # RTC select PL061 # GPIO + select GPIO_PWR select PLATFORM_BUS select SMBIOS select VIRTIO_MMIO diff --git a/hw/arm/virt.c b/hw/arm/virt.c index 96985917d3..eff0345303 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -147,6 +147,7 @@ static const MemMapEntry base_memmap[] = { [VIRT_RTC] = { 0x09010000, 0x00001000 }, [VIRT_FW_CFG] = { 0x09020000, 0x00000018 }, [VIRT_GPIO] = { 0x09030000, 0x00001000 }, + [VIRT_SECURE_GPIO] = { 0x09031000, 0x00001000 }, [VIRT_SECURE_UART] = { 0x09040000, 0x00001000 }, [VIRT_SMMU] = { 0x09050000, 0x00020000 }, [VIRT_PCDIMM_ACPI] = { 0x09070000, MEMORY_HOTPLUG_IO_LEN }, @@ -189,6 +190,7 @@ static const int a15irqmap[] = { [VIRT_GPIO] = 7, [VIRT_SECURE_UART] = 8, [VIRT_ACPI_GED] = 9, + [VIRT_SECURE_GPIO] = 10, [VIRT_MMIO] = 16, /* ...to 16 + NUM_VIRTIO_TRANSPORTS - 1 */ [VIRT_GIC_V2M] = 48, /* ...to 48 + NUM_GICV2M_SPIS - 1 */ [VIRT_SMMU] = 74, /* ...to 74 + NUM_SMMU_IRQS - 1 */ @@ -864,6 +866,24 @@ static void create_gpio(const VirtMachineState *vms) g_free(nodename); } +static void create_gpio_secure(const VirtMachineState *vms) +{ + DeviceState *pl061_dev; + static DeviceState *gpio_pwr_dev; + + hwaddr base = vms->memmap[VIRT_SECURE_GPIO].base; + int irq = vms->irqmap[VIRT_SECURE_GPIO]; + + pl061_dev = sysbus_create_simple("pl061", base, + qdev_get_gpio_in(vms->gic, irq)); + + gpio_pwr_dev = sysbus_create_simple("gpio-pwr", -1, + qdev_get_gpio_in(pl061_dev, 3)); + + qdev_connect_gpio_out(pl061_dev, 3, qdev_get_gpio_in(gpio_pwr_dev, 3)); + qdev_connect_gpio_out(pl061_dev, 4, qdev_get_gpio_in(gpio_pwr_dev, 4)); +} + static void create_virtio_devices(const VirtMachineState *vms) { int i; @@ -1993,6 +2013,10 @@ static void machvirt_init(MachineState *machine) create_gpio(vms); } + if (vms->secure) { + create_gpio_secure(vms); + } + /* connect powerdown request */ vms->powerdown_notifier.notify = virt_powerdown_req; qemu_register_powerdown_notifier(&vms->powerdown_notifier); diff --git a/hw/gpio/Kconfig b/hw/gpio/Kconfig index b6fdaa2586..f0e7405f6e 100644 --- a/hw/gpio/Kconfig +++ b/hw/gpio/Kconfig @@ -8,5 +8,8 @@ config PL061 config GPIO_KEY bool +config GPIO_PWR + bool + config SIFIVE_GPIO bool diff --git a/hw/gpio/gpio_pwr.c b/hw/gpio/gpio_pwr.c new file mode 100644 index 0000000000..0d0680c9f7 --- /dev/null +++ b/hw/gpio/gpio_pwr.c @@ -0,0 +1,85 @@ +/* + * GPIO qemu power controller + * + * Copyright (c) 2020 Linaro Limited + * + * Author: Maxim Uvarov <maxim.uvarov(a)linaro.org> + * + * Virtual gpio driver which can be used on top of pl061 + * to reboot and shutdown qemu virtual machine. One of use + * case is gpio driver for secure world application (ARM + * Trusted Firmware.). + * + * This work is licensed under the terms of the GNU GPL, version 2 or later. + * See the COPYING file in the top-level directory. + * SPDX-License-Identifier: GPL-2.0-or-later + */ + +#include "qemu/osdep.h" +#include "qemu/log.h" +#include "hw/irq.h" +#include "hw/sysbus.h" +#include "sysemu/runstate.h" + +#define TYPE_GPIOPWR "gpio-pwr" +OBJECT_DECLARE_SIMPLE_TYPE(GPIO_PWR_State, GPIOPWR) + +struct GPIO_PWR_State { + SysBusDevice parent_obj; + qemu_irq irq; +}; + +static void gpio_pwr_set_irq(void *opaque, int irq, int level) +{ + GPIO_PWR_State *s = (GPIO_PWR_State *)opaque; + + qemu_set_irq(s->irq, 1); + + if (level) { + return; + } + + switch (irq) { + case 3: + qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_SHUTDOWN); + break; + case 4: + qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET); + break; + default: + qemu_log_mask(LOG_GUEST_ERROR, + "qemu; gpio_pwr: unknown interrupt %d lvl %d\n", + irq, level); + } +} + + +static void gpio_pwr_realize(DeviceState *dev, Error **errp) +{ + GPIO_PWR_State *s = GPIOPWR(dev); + SysBusDevice *sbd = SYS_BUS_DEVICE(dev); + + sysbus_init_irq(sbd, &s->irq); + qdev_init_gpio_in(dev, gpio_pwr_set_irq, 8); +} + +static void gpio_pwr_class_init(ObjectClass *klass, void *data) +{ + DeviceClass *dc = DEVICE_CLASS(klass); + + dc->realize = gpio_pwr_realize; +} + +static const TypeInfo gpio_pwr_info = { + .name = TYPE_GPIOPWR, + .parent = TYPE_SYS_BUS_DEVICE, + .instance_size = sizeof(GPIO_PWR_State), + .class_init = gpio_pwr_class_init, +}; + +static void gpio_pwr_register_types(void) +{ + type_register_static(&gpio_pwr_info); +} + +type_init(gpio_pwr_register_types) diff --git a/hw/gpio/meson.build b/hw/gpio/meson.build index 5c0a7d7b95..79568f00ce 100644 --- a/hw/gpio/meson.build +++ b/hw/gpio/meson.build @@ -1,5 +1,6 @@ softmmu_ss.add(when: 'CONFIG_E500', if_true: files('mpc8xxx.c')) softmmu_ss.add(when: 'CONFIG_GPIO_KEY', if_true: files('gpio_key.c')) +softmmu_ss.add(when: 'CONFIG_GPIO_PWR', if_true: files('gpio_pwr.c')) softmmu_ss.add(when: 'CONFIG_MAX7310', if_true: files('max7310.c')) softmmu_ss.add(when: 'CONFIG_PL061', if_true: files('pl061.c')) softmmu_ss.add(when: 'CONFIG_PUV3', if_true: files('puv3_gpio.c')) diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h index abf54fab49..77a4523cc7 100644 --- a/include/hw/arm/virt.h +++ b/include/hw/arm/virt.h @@ -81,6 +81,7 @@ enum { VIRT_GPIO, VIRT_SECURE_UART, VIRT_SECURE_MEM, + VIRT_SECURE_GPIO, VIRT_PCDIMM_ACPI, VIRT_ACPI_GED, VIRT_NVDIMM_ACPI, -- 2.17.1

4 years, 9 months

3
3
0 0

Routing FIQ timer interrupts to EL3 on Raspberry Pi 4B

by Ian Burres

I am attempting to route FIQ timer interrupts using the ARM timers (not system timers) to EL3 in order to achieve introspection. I am running TF-A (cross compiled for AArch64/AArch32) on a Raspberry Pi 4B, which uses the Broadcom 2711 chipset. I have written some code, but I am not an embedded software engineer – I’m an IoT pentester. The ARM timers look like this: RPI4_ARM_TIMER_LOAD 0x400 RPI4_ARM_TIMER_VALUE 0x404 ….. RPI4_ARM_TIMER_FREE_COUNTER 0x420 System timers are: RPI4_SYS_TIMER_CLO, RPI4_SYS_TIMER_CS, etc… I have successfully implement a Linux driver that allows me to dump kernel page tables and memory; however, I cannot see user page tables (even after running a CPU intensive program ). I believe the only way to view user page tables is to have interrupts routed to EL3 – a Linux driver is not sufficient. I have 3 UARTs attached with a debug log and screen setup. >From what I have read, the Raspberry Pi 4B uses GICv2. TF-A supports EL3 routing when the build option GICV2_GO_FOR_EL3 is enabled, which I have done. >From what I have gathered, the FIQ interrupt has to be written in assembly. So far, I have created a vector table, loaded the vector table, and masked and unmasked interrupts using daifclr, #3 and daifset, #3 instructions, using inline assembly. The timer is initinitialized and handled using C functions. I am using inline assembly, because I am adding code to the TF-A base, and I have not discovered how to add .S files to the build without receiving make errors. I will gladly share the code I have if it helps, but what I am really looking for is if anyone believes I am on the right track or not. Obviously, I am not implementing something correctly since the interrupt is not being handled. Thanks. Thomas Sent from Mail for Windows 10

4 years, 9 months

1
0
0 0

[PATCHv2] arm-virt: add secure pl061 for reset/power down

by Maxim Uvarov

Add secure pl061 for reset/power down machine from the secure world (Arm Trusted Firmware). Use the same gpio 3 and gpio 4 which were used by non acpi variant of linux power control gpios. Signed-off-by: Maxim Uvarov <maxim.uvarov(a)linaro.org> --- v2: replace printf with qemu_log (Philippe Mathieu-Daudé) hw/arm/Kconfig | 1 + hw/arm/virt.c | 24 +++++++++++++ hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 84 +++++++++++++++++++++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 1 + 6 files changed, 114 insertions(+) create mode 100644 hw/gpio/gpio_pwr.c diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig index 0a242e4c5d..13cc42dcc8 100644 --- a/hw/arm/Kconfig +++ b/hw/arm/Kconfig @@ -17,6 +17,7 @@ config ARM_VIRT select PL011 # UART select PL031 # RTC select PL061 # GPIO + select GPIO_PWR select PLATFORM_BUS select SMBIOS select VIRTIO_MMIO diff --git a/hw/arm/virt.c b/hw/arm/virt.c index 96985917d3..eff0345303 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -147,6 +147,7 @@ static const MemMapEntry base_memmap[] = { [VIRT_RTC] = { 0x09010000, 0x00001000 }, [VIRT_FW_CFG] = { 0x09020000, 0x00000018 }, [VIRT_GPIO] = { 0x09030000, 0x00001000 }, + [VIRT_SECURE_GPIO] = { 0x09031000, 0x00001000 }, [VIRT_SECURE_UART] = { 0x09040000, 0x00001000 }, [VIRT_SMMU] = { 0x09050000, 0x00020000 }, [VIRT_PCDIMM_ACPI] = { 0x09070000, MEMORY_HOTPLUG_IO_LEN }, @@ -189,6 +190,7 @@ static const int a15irqmap[] = { [VIRT_GPIO] = 7, [VIRT_SECURE_UART] = 8, [VIRT_ACPI_GED] = 9, + [VIRT_SECURE_GPIO] = 10, [VIRT_MMIO] = 16, /* ...to 16 + NUM_VIRTIO_TRANSPORTS - 1 */ [VIRT_GIC_V2M] = 48, /* ...to 48 + NUM_GICV2M_SPIS - 1 */ [VIRT_SMMU] = 74, /* ...to 74 + NUM_SMMU_IRQS - 1 */ @@ -864,6 +866,24 @@ static void create_gpio(const VirtMachineState *vms) g_free(nodename); } +static void create_gpio_secure(const VirtMachineState *vms) +{ + DeviceState *pl061_dev; + static DeviceState *gpio_pwr_dev; + + hwaddr base = vms->memmap[VIRT_SECURE_GPIO].base; + int irq = vms->irqmap[VIRT_SECURE_GPIO]; + + pl061_dev = sysbus_create_simple("pl061", base, + qdev_get_gpio_in(vms->gic, irq)); + + gpio_pwr_dev = sysbus_create_simple("gpio-pwr", -1, + qdev_get_gpio_in(pl061_dev, 3)); + + qdev_connect_gpio_out(pl061_dev, 3, qdev_get_gpio_in(gpio_pwr_dev, 3)); + qdev_connect_gpio_out(pl061_dev, 4, qdev_get_gpio_in(gpio_pwr_dev, 4)); +} + static void create_virtio_devices(const VirtMachineState *vms) { int i; @@ -1993,6 +2013,10 @@ static void machvirt_init(MachineState *machine) create_gpio(vms); } + if (vms->secure) { + create_gpio_secure(vms); + } + /* connect powerdown request */ vms->powerdown_notifier.notify = virt_powerdown_req; qemu_register_powerdown_notifier(&vms->powerdown_notifier); diff --git a/hw/gpio/Kconfig b/hw/gpio/Kconfig index b6fdaa2586..f0e7405f6e 100644 --- a/hw/gpio/Kconfig +++ b/hw/gpio/Kconfig @@ -8,5 +8,8 @@ config PL061 config GPIO_KEY bool +config GPIO_PWR + bool + config SIFIVE_GPIO bool diff --git a/hw/gpio/gpio_pwr.c b/hw/gpio/gpio_pwr.c new file mode 100644 index 0000000000..f5868653b3 --- /dev/null +++ b/hw/gpio/gpio_pwr.c @@ -0,0 +1,84 @@ +/* + * GPIO qemu power controller + * + * Copyright (c) 2020 Linaro Limited + * + * Author: Maxim Uvarov <maxim.uvarov(a)linaro.org> + * + * Virtual gpio driver which can be used on top of pl061 + * to reboot and shutdown qemu virtual machine. One of use + * case is gpio driver for secure world application (ARM + * Trusted Firmware.). + * + * This work is licensed under the terms of the GNU GPL, version 2 or later. + * See the COPYING file in the top-level directory. + * SPDX-License-Identifier: GPL-2.0-or-later + */ + +#include "qemu/osdep.h" +#include "hw/irq.h" +#include "hw/sysbus.h" +#include "sysemu/runstate.h" + +#define TYPE_GPIOPWR "gpio-pwr" +OBJECT_DECLARE_SIMPLE_TYPE(GPIO_PWR_State, GPIOPWR) + +struct GPIO_PWR_State { + SysBusDevice parent_obj; + qemu_irq irq; +}; + +static void gpio_pwr_set_irq(void *opaque, int irq, int level) +{ + GPIO_PWR_State *s = (GPIO_PWR_State *)opaque; + + qemu_set_irq(s->irq, 1); + + if (level) { + return; + } + + switch (irq) { + case 3: + qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_SHUTDOWN); + break; + case 4: + qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET); + break; + default: + qemu_log_mask(LOG_GUEST_ERROR, + "qemu; gpio_pwr: unknown interrupt %d lvl %d\n", + irq, level); + } +} + + +static void gpio_pwr_realize(DeviceState *dev, Error **errp) +{ + GPIO_PWR_State *s = GPIOPWR(dev); + SysBusDevice *sbd = SYS_BUS_DEVICE(dev); + + sysbus_init_irq(sbd, &s->irq); + qdev_init_gpio_in(dev, gpio_pwr_set_irq, 8); +} + +static void gpio_pwr_class_init(ObjectClass *klass, void *data) +{ + DeviceClass *dc = DEVICE_CLASS(klass); + + dc->realize = gpio_pwr_realize; +} + +static const TypeInfo gpio_pwr_info = { + .name = TYPE_GPIOPWR, + .parent = TYPE_SYS_BUS_DEVICE, + .instance_size = sizeof(GPIO_PWR_State), + .class_init = gpio_pwr_class_init, +}; + +static void gpio_pwr_register_types(void) +{ + type_register_static(&gpio_pwr_info); +} + +type_init(gpio_pwr_register_types) diff --git a/hw/gpio/meson.build b/hw/gpio/meson.build index 5c0a7d7b95..79568f00ce 100644 --- a/hw/gpio/meson.build +++ b/hw/gpio/meson.build @@ -1,5 +1,6 @@ softmmu_ss.add(when: 'CONFIG_E500', if_true: files('mpc8xxx.c')) softmmu_ss.add(when: 'CONFIG_GPIO_KEY', if_true: files('gpio_key.c')) +softmmu_ss.add(when: 'CONFIG_GPIO_PWR', if_true: files('gpio_pwr.c')) softmmu_ss.add(when: 'CONFIG_MAX7310', if_true: files('max7310.c')) softmmu_ss.add(when: 'CONFIG_PL061', if_true: files('pl061.c')) softmmu_ss.add(when: 'CONFIG_PUV3', if_true: files('puv3_gpio.c')) diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h index abf54fab49..77a4523cc7 100644 --- a/include/hw/arm/virt.h +++ b/include/hw/arm/virt.h @@ -81,6 +81,7 @@ enum { VIRT_GPIO, VIRT_SECURE_UART, VIRT_SECURE_MEM, + VIRT_SECURE_GPIO, VIRT_PCDIMM_ACPI, VIRT_ACPI_GED, VIRT_NVDIMM_ACPI, -- 2.17.1

4 years, 9 months

1
0
0 0

[PATCH] arm-virt: add secure pl061 for reset/power down

by Maxim Uvarov

Add secure pl061 for reset/power down machine from the secure world (Arm Trusted Firmware). Use the same gpio 3 and gpio 4 which were used by non acpi variant of linux power control gpios. Signed-off-by: Maxim Uvarov <maxim.uvarov(a)linaro.org> --- This patch works together with ATF patch: https://github.com/muvarov/arm-trusted-firmware/commit/dd4401d8eb8e0f3018b3… Previus discussion for reboot issue was here: https://www.mail-archive.com/qemu-devel@nongnu.org/msg757705.html Regards, Maxim. hw/arm/Kconfig | 1 + hw/arm/virt.c | 24 +++++++++++++ hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 83 +++++++++++++++++++++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 1 + 6 files changed, 113 insertions(+) create mode 100644 hw/gpio/gpio_pwr.c diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig index 0a242e4c5d..13cc42dcc8 100644 --- a/hw/arm/Kconfig +++ b/hw/arm/Kconfig @@ -17,6 +17,7 @@ config ARM_VIRT select PL011 # UART select PL031 # RTC select PL061 # GPIO + select GPIO_PWR select PLATFORM_BUS select SMBIOS select VIRTIO_MMIO diff --git a/hw/arm/virt.c b/hw/arm/virt.c index 96985917d3..eff0345303 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -147,6 +147,7 @@ static const MemMapEntry base_memmap[] = { [VIRT_RTC] = { 0x09010000, 0x00001000 }, [VIRT_FW_CFG] = { 0x09020000, 0x00000018 }, [VIRT_GPIO] = { 0x09030000, 0x00001000 }, + [VIRT_SECURE_GPIO] = { 0x09031000, 0x00001000 }, [VIRT_SECURE_UART] = { 0x09040000, 0x00001000 }, [VIRT_SMMU] = { 0x09050000, 0x00020000 }, [VIRT_PCDIMM_ACPI] = { 0x09070000, MEMORY_HOTPLUG_IO_LEN }, @@ -189,6 +190,7 @@ static const int a15irqmap[] = { [VIRT_GPIO] = 7, [VIRT_SECURE_UART] = 8, [VIRT_ACPI_GED] = 9, + [VIRT_SECURE_GPIO] = 10, [VIRT_MMIO] = 16, /* ...to 16 + NUM_VIRTIO_TRANSPORTS - 1 */ [VIRT_GIC_V2M] = 48, /* ...to 48 + NUM_GICV2M_SPIS - 1 */ [VIRT_SMMU] = 74, /* ...to 74 + NUM_SMMU_IRQS - 1 */ @@ -864,6 +866,24 @@ static void create_gpio(const VirtMachineState *vms) g_free(nodename); } +static void create_gpio_secure(const VirtMachineState *vms) +{ + DeviceState *pl061_dev; + static DeviceState *gpio_pwr_dev; + + hwaddr base = vms->memmap[VIRT_SECURE_GPIO].base; + int irq = vms->irqmap[VIRT_SECURE_GPIO]; + + pl061_dev = sysbus_create_simple("pl061", base, + qdev_get_gpio_in(vms->gic, irq)); + + gpio_pwr_dev = sysbus_create_simple("gpio-pwr", -1, + qdev_get_gpio_in(pl061_dev, 3)); + + qdev_connect_gpio_out(pl061_dev, 3, qdev_get_gpio_in(gpio_pwr_dev, 3)); + qdev_connect_gpio_out(pl061_dev, 4, qdev_get_gpio_in(gpio_pwr_dev, 4)); +} + static void create_virtio_devices(const VirtMachineState *vms) { int i; @@ -1993,6 +2013,10 @@ static void machvirt_init(MachineState *machine) create_gpio(vms); } + if (vms->secure) { + create_gpio_secure(vms); + } + /* connect powerdown request */ vms->powerdown_notifier.notify = virt_powerdown_req; qemu_register_powerdown_notifier(&vms->powerdown_notifier); diff --git a/hw/gpio/Kconfig b/hw/gpio/Kconfig index b6fdaa2586..f0e7405f6e 100644 --- a/hw/gpio/Kconfig +++ b/hw/gpio/Kconfig @@ -8,5 +8,8 @@ config PL061 config GPIO_KEY bool +config GPIO_PWR + bool + config SIFIVE_GPIO bool diff --git a/hw/gpio/gpio_pwr.c b/hw/gpio/gpio_pwr.c new file mode 100644 index 0000000000..dded12381b --- /dev/null +++ b/hw/gpio/gpio_pwr.c @@ -0,0 +1,83 @@ +/* + * GPIO qemu power controller + * + * Copyright (c) 2020 Linaro Limited + * + * Author: Maxim Uvarov <maxim.uvarov(a)linaro.org> + * + * Virtual gpio driver which can be used on top of pl061 + * to reboot and shutdown qemu virtual machine. One of use + * case is gpio driver for secure world application (ARM + * Trusted Firmware.). + * + * This work is licensed under the terms of the GNU GPL, version 2 or later. + * See the COPYING file in the top-level directory. + * SPDX-License-Identifier: GPL-2.0-or-later + */ + +#include "qemu/osdep.h" +#include "hw/irq.h" +#include "hw/sysbus.h" +#include "sysemu/runstate.h" + +#define TYPE_GPIOPWR "gpio-pwr" +OBJECT_DECLARE_SIMPLE_TYPE(GPIO_PWR_State, GPIOPWR) + +struct GPIO_PWR_State { + SysBusDevice parent_obj; + qemu_irq irq; +}; + +static void gpio_pwr_set_irq(void *opaque, int irq, int level) +{ + GPIO_PWR_State *s = (GPIO_PWR_State *)opaque; + + qemu_set_irq(s->irq, 1); + + if (level) { + return; + } + + switch (irq) { + case 3: + qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_SHUTDOWN); + break; + case 4: + qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET); + break; + default: + printf("qemu; gpio_pwr: unknown interrupt %d lvl %d\n", + irq, level); + } +} + + +static void gpio_pwr_realize(DeviceState *dev, Error **errp) +{ + GPIO_PWR_State *s = GPIOPWR(dev); + SysBusDevice *sbd = SYS_BUS_DEVICE(dev); + + sysbus_init_irq(sbd, &s->irq); + qdev_init_gpio_in(dev, gpio_pwr_set_irq, 8); +} + +static void gpio_pwr_class_init(ObjectClass *klass, void *data) +{ + DeviceClass *dc = DEVICE_CLASS(klass); + + dc->realize = gpio_pwr_realize; +} + +static const TypeInfo gpio_pwr_info = { + .name = TYPE_GPIOPWR, + .parent = TYPE_SYS_BUS_DEVICE, + .instance_size = sizeof(GPIO_PWR_State), + .class_init = gpio_pwr_class_init, +}; + +static void gpio_pwr_register_types(void) +{ + type_register_static(&gpio_pwr_info); +} + +type_init(gpio_pwr_register_types) diff --git a/hw/gpio/meson.build b/hw/gpio/meson.build index 5c0a7d7b95..79568f00ce 100644 --- a/hw/gpio/meson.build +++ b/hw/gpio/meson.build @@ -1,5 +1,6 @@ softmmu_ss.add(when: 'CONFIG_E500', if_true: files('mpc8xxx.c')) softmmu_ss.add(when: 'CONFIG_GPIO_KEY', if_true: files('gpio_key.c')) +softmmu_ss.add(when: 'CONFIG_GPIO_PWR', if_true: files('gpio_pwr.c')) softmmu_ss.add(when: 'CONFIG_MAX7310', if_true: files('max7310.c')) softmmu_ss.add(when: 'CONFIG_PL061', if_true: files('pl061.c')) softmmu_ss.add(when: 'CONFIG_PUV3', if_true: files('puv3_gpio.c')) diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h index abf54fab49..77a4523cc7 100644 --- a/include/hw/arm/virt.h +++ b/include/hw/arm/virt.h @@ -81,6 +81,7 @@ enum { VIRT_GPIO, VIRT_SECURE_UART, VIRT_SECURE_MEM, + VIRT_SECURE_GPIO, VIRT_PCDIMM_ACPI, VIRT_ACPI_GED, VIRT_NVDIMM_ACPI, -- 2.17.1

4 years, 9 months

2
1
0 0

Build error with GCC 10.2-2020.11

by Manish Badarkhe

Hi Carlo Alexei created a patch for testing TF-A/TFTF builds with the toolchain GCC 10.2-2020.11 https://review.trustedfirmware.org/c/ci/tf-a-ci-scripts/+/7733 which flagged build errors for plat/amlogic/axg platform, please see below: Build command lines: make CROSS_COMPILE=aarch64-none-elf- PLAT=axg SPD=opteed DEBUG=1 V=1 fiptool all make AML_USE_ATOS=1 CROSS_COMPILE=aarch64-none-elf- PLAT=axg DEBUG=1 V=1 fiptool all plat/amlogic/axg/axg_pm.c: In function 'axg_pwr_domain_off': plat/amlogic/axg/axg_pm.c:124:43: error: array subscript 2 is above array bounds of 'const plat_local_state_t[2]' {aka 'const unsigned char[2]'} [-Werror=array-bounds] 124 | if (target_state->pwr_domain_state[MPIDR_AFFLVL2] == | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~ In file included from plat/amlogic/axg/axg_pm.c:14: include/lib/psci/psci.h:270:28: note: while referencing 'pwr_domain_state' 270 | plat_local_state_t pwr_domain_state[PLAT_MAX_PWR_LVL + U(1)]; | ^~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors Makefile:1103: recipe for target '/work/workspace/workspace/tf-worker/trusted_firmware/build/axg/debug/bl31/axg_pm.o' failed make: *** [/work/workspace/workspace/tf-worker/trusted_firmware/build/axg/debug/bl31/axg_pm.o] Error 1 Please help to resolve this issue. Thanks Manish Badarkhe

4 years, 10 months

1
0
0 0

Re: [TF-A] Interrupt about ff-a spec

by Achin Gupta

Hi Feng, On Fri, Dec 18, 2020 at 04:41:37PM +0000, Chen Feng via TF-A wrote: > Hi, > > While reading the Arm Firmware Framework for Armv8-A > https://developer.arm.com/documentation/den0077/latest > > I do not find the API that for a sp to request vIRQ, or do I miss something. > > Is this some private API that is implementing defined FF-A IDs? Is what you have in mind is an ABI that allows SP0 to raise an interrupt in SP1? Could you please provide more information about your use case? cheers, Achin > > > -- > cheers, > feng > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 10 months

3
3
0 0

Re: [TF-A] Does TF-A support to load and run both TEE and SPM_MM?

by Chen Feng

Hi all, I have a similar but different question here :) Why not the tf-a support both smpd and tspd. Since the vendor's teeos that has not support ff-a interface currently. With armv8.4-sel2, is there a choice to disable scr.eel2 with origin vendor's theeos IDs, and enable scr.eel2 with new ff-a services? It seems to need some tlb maintenance, but it seems work. On 2020/11/23 3:27 下午, Achin Gupta via TF-A wrote: > Hi Heyi, > > Happy to discuss the detail but the short answer is no. > > Instead, it is possible to run an MM partition in S-EL0 under the TEE. This work is being done with OP-TEE. > > From a SW architecture standpoint, it did not seem like a good idea to let EL3 run its "application" i.e. MM SP alongside a TEE which also runs its own applications. It is better to let the TEE own S-EL1 and run all applications in S-EL0 under it. > > Cheers, > Achin > > On 23/11/2020, 05:36, "TF-A on behalf of Heyi Guo via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: > > Hi All, > > On some platforms there may be requirements to run both TEE and SPM_MM > instances, such as providing TEE services on server platforms. > > Do TF-A support this scenario? If it doesn't, do it make sense to add > such support? > > Thanks, > > Heyi > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > -- cheers, feng

4 years, 10 months

2
3
0 0

Interrupt about ff-a spec

by Chen Feng

Hi, While reading the Arm Firmware Framework for Armv8-A https://developer.arm.com/documentation/den0077/latest I do not find the API that for a sp to request vIRQ, or do I miss something. Is this some private API that is implementing defined FF-A IDs? -- cheers, feng

4 years, 10 months

1
0
0 0

TF-A Tech Forum Agenda @ Thr 17th December 2020 16:00-1700 GMT: Introduction to the Trusted Services project

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 17th December 2020 16:00 – 17:00 (GMT). As well as being posted to the TF-A mailing list this has been cross posted to OPTEE mailing list. For OPTEE attendees the Zoom call details are included below. Agenda: * An introduction to the Trusted Services project * Presented by Julian Hall * Summary * The Trusted Services project is a new trustedfirmware.org project that provides a home for security related service components that can run in the different isolated processing environments available on Arm Cortex-A. The project attempts to promote reuse and standardization to enable a consistent set of services to be provided by firmware, independent of which isolation technology is used. If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled. Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ A scheduling tracking page is also available to help track sessions suggested and being prepared: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting and shared on the TF-A mailing list. This is the last TF-A Tech Forum session until January 2021. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One 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-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Thanks Joanna

4 years, 10 months

1
0
0 0

Re: [TF-A] Question about validity period of X509 certificate

by Andrej Butok

Hello Masato Fukumori, To check a "validity period" of a X 509 certificate, you must be sure that your system date & time is set, correct and not changed. Do you have a reliable way to achieve this? Best regards, Andrej Butok From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of fukumori.masato--- via TF-A Sent: Thursday, December 10, 2020 2:23 PM To: 'tf-a(a)lists.trustedfirmware.org' <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Question about validity period of X509 certificate Hello. I have a question about checking the X 509 certificate with tf-a. My understanding is that tf-a does not check the "validity period" of the X 509 certificate. I 'm not sure why tf-a doesn't check. Does anyone know this background? Best Regards, Masato Fukumori

4 years, 10 months

2
4
0 0

Question about validity period of X509 certificate

by fukumori.masato＠fujitsu.com

Hello. I have a question about checking the X 509 certificate with tf-a. My understanding is that tf-a does not check the "validity period" of the X 509 certificate. I 'm not sure why tf-a doesn't check. Does anyone know this background? Best Regards, Masato Fukumori

4 years, 10 months

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 3 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 364146: Control flow issues (DEADCODE) /plat/mediatek/mt8192/plat_pm.c: 301 in plat_validate_power_state() ________________________________________________________________________________________________________ *** CID 364146: Control flow issues (DEADCODE) /plat/mediatek/mt8192/plat_pm.c: 301 in plat_validate_power_state() 295 { 296 unsigned int pstate = psci_get_pstate_type(power_state); 297 unsigned int aff_lvl = psci_get_pstate_pwrlvl(power_state); 298 unsigned int cpu = plat_my_core_pos(); 299 300 if (aff_lvl > PLAT_MAX_PWR_LVL) { >>> CID 364146: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "return -2;". 301 return PSCI_E_INVALID_PARAMS; 302 } 303 304 if (pstate == PSTATE_TYPE_STANDBY) { 305 req_state->pwr_domain_state[0] = PLAT_MAX_RET_STATE; 306 } else { ** CID 364145: Integer handling issues (NO_EFFECT) /plat/mediatek/mt8192/drivers/ptp3/mtk_ptp3_main.c: 42 in ptp3_init() ________________________________________________________________________________________________________ *** CID 364145: Integer handling issues (NO_EFFECT) /plat/mediatek/mt8192/drivers/ptp3/mtk_ptp3_main.c: 42 in ptp3_init() 36 * API 37 ************************************************/ 38 void ptp3_init(unsigned int core) 39 { 40 unsigned int _core; 41 >>> CID 364145: Integer handling issues (NO_EFFECT) >>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "core >= 0U". 42 if (core >= PTP3_CFG1_CPU_START_ID) { 43 if (core < NR_PTP3_CFG1_CPU) { 44 /* update ptp3_cfg1 */ 45 ptp3_write( 46 ptp3_cfg1[core][PTP3_CFG_ADDR], 47 ptp3_cfg1[core][PTP3_CFG_VALUE]); ** CID 364144: Integer handling issues (NO_EFFECT) /plat/mediatek/mt8192/drivers/ptp3/mtk_ptp3_main.c: 76 in ptp3_deinit() ________________________________________________________________________________________________________ *** CID 364144: Integer handling issues (NO_EFFECT) /plat/mediatek/mt8192/drivers/ptp3/mtk_ptp3_main.c: 76 in ptp3_deinit() 70 } 71 } 72 } 73 74 void ptp3_deinit(unsigned int core) 75 { >>> CID 364144: Integer handling issues (NO_EFFECT) >>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "core >= 0U". 76 if (core >= PTP3_CFG1_CPU_START_ID) { 77 if (core < NR_PTP3_CFG1_CPU) { 78 /* update ptp3_cfg1 */ 79 ptp3_write( 80 ptp3_cfg1[core][PTP3_CFG_ADDR], 81 ptp3_cfg1[core][PTP3_CFG_VALUE] & 82 ~PTP3_CFG1_MASK); 83 } 84 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 10 months

1
0
0 0

Cancelled event: TF-A Tech Forum @ Thu 31 Dec 2020 16:00 - 17:00 (GMT) (tf-a@lists.trustedfirmware.org)

by Bill Fletcher

This event has been cancelled. 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 31 Dec 2020 16:00 – 17:00 United Kingdom Time 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 organiser and be added to the guest list, 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, 11 months

1
0
0 0

Cancelled event: TF-A Tech Forum @ Thu 3 Dec 2020 16:00 - 17:00 (GMT) (tf-a@lists.trustedfirmware.org)

by Bill Fletcher

This event has been cancelled. 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 3 Dec 2020 16:00 – 17:00 United Kingdom Time 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 organiser and be added to the guest list, 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, 11 months

1
0
0 0

Re: [TF-A] Does TF-A support to load and run both TEE and SPM_MM?

by Achin Gupta

Hi Heyi, Happy to discuss the detail but the short answer is no. Instead, it is possible to run an MM partition in S-EL0 under the TEE. This work is being done with OP-TEE. From a SW architecture standpoint, it did not seem like a good idea to let EL3 run its "application" i.e. MM SP alongside a TEE which also runs its own applications. It is better to let the TEE own S-EL1 and run all applications in S-EL0 under it. Cheers, Achin On 23/11/2020, 05:36, "TF-A on behalf of Heyi Guo via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi All, On some platforms there may be requirements to run both TEE and SPM_MM instances, such as providing TEE services on server platforms. Do TF-A support this scenario? If it doesn't, do it make sense to add such support? Thanks, Heyi -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 11 months

3
7
0 0

Re: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a@lists.trustedfirmware.org)

by Joanna Farley

Apologies, I need to cancel this weeks TF-A Tech Forum session on 3rd December due to clashing events for Arm attendees. Next meeting will be 17th December which will be the last session of 2020. 31st December session is also cancelled with the first 2021 session being 14th January 2021. Thanks Joanna From: linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com When: 16:00 - 17:00 3 December 2020 Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org) You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> 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/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One 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-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.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://www.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 organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>.

4 years, 11 months

1
0
0 0

Does TF-A support to load and run both TEE and SPM_MM?

by Heyi Guo

Hi All, On some platforms there may be requirements to run both TEE and SPM_MM instances, such as providing TEE services on server platforms. Do TF-A support this scenario? If it doesn't, do it make sense to add such support? Thanks, Heyi

4 years, 11 months

1
0
0 0

Re: [TF-A] [PATCH] plat/qemu/qemu_sbsa: Include libraries for Cortex-A72

by Jens Wiklander

Hi Tanmay, Please upload the patch at https://review.trustedfirmware.org/, for details see https://trustedfirmware-a.readthedocs.io/en/latest/process/contributing.html Thanks, Jens On Thu, Nov 19, 2020 at 7:28 PM Tanmay Jagdale <tanmay.jagdale(a)linaro.org> wrote: > > Include libraries needed to emulate Cortex-A72 in sbsa-ref target of Qemu. > > Signed-off-by: Tanmay Jagdale <tanmay.jagdale(a)linaro.org> > --- > plat/qemu/qemu_sbsa/platform.mk | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/plat/qemu/qemu_sbsa/platform.mk b/plat/qemu/qemu_sbsa/platform.mk > index 1a4a2db02..a8036f622 100644 > --- a/plat/qemu/qemu_sbsa/platform.mk > +++ b/plat/qemu/qemu_sbsa/platform.mk > @@ -43,7 +43,8 @@ BL1_SOURCES += drivers/io/io_semihosting.c \ > > BL1_SOURCES += lib/cpus/aarch64/aem_generic.S \ > lib/cpus/aarch64/cortex_a53.S \ > - lib/cpus/aarch64/cortex_a57.S > + lib/cpus/aarch64/cortex_a57.S \ > + lib/cpus/aarch64/cortex_a72.S > > BL2_SOURCES += drivers/io/io_semihosting.c \ > drivers/io/io_storage.c \ > @@ -72,6 +73,7 @@ QEMU_GIC_SOURCES := ${GICV3_SOURCES} \ > BL31_SOURCES += lib/cpus/aarch64/aem_generic.S \ > lib/cpus/aarch64/cortex_a53.S \ > lib/cpus/aarch64/cortex_a57.S \ > + lib/cpus/aarch64/cortex_a72.S \ > lib/semihosting/semihosting.c \ > lib/semihosting/${ARCH}/semihosting_call.S \ > plat/common/plat_psci_common.c \ > -- > 2.29.2 >

4 years, 11 months

2
1
0 0

Hafnium / TF-A v2.4 first tagged release is available

by Olivier Deprez

Hi All, Following the announcement of the Trusted Firmware-A/Trusted Firmware-A-tests v2.4 release: We are pleased to announce the first tagged release of Hafnium [1] implementing the SPMC according to the FF-A v1.0 specification [2]. As a reminder, Hafnium has been transferred to trustedfirmware.org back in May 2020 to become the reference open source S-EL2 firmware, under an Arm/Google co-maintainership. Contributions are open to partners in trustedfirmware.org The Secure Partition Manager documentation is available at [3] Please also refer to the change log at [4] The companion TF-A test suite permits the validation of FF-A ABIs and NWd/SWd communication by the use of bare-metal S-EL1 secure partitions. Thanks to all who contributed to make it happen. Regards, Olivier. [1] https://git.trustedfirmware.org/hafnium/hafnium.git/tag/?h=v2.4 [2] https://developer.arm.com/documentation/den0077/latest [3] https://trustedfirmware-a.readthedocs.io/en/latest/components/secure-partit… [4] https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/HEAD/d… ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Manish Badarkhe via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 18 November 2020 14:35 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Trusted Firmware-A & Trusted Firmware-A-tests version 2.4 is now available Hi All, Trusted Firmware-A and Trusted Firmware-A-tests version 2.4 is now available and can be found here: Trusted Firmware-A: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.4 Trusted Firmware-A-tests: https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.4 Please refer to the change log of Trusted Firmware-A and Trusted Firmware-A-tests for further information here: Trusted Firmware-A: https://trustedfirmware-a.readthedocs.io/en/v2.4/change-log.html Trusted Firmware-A-tests: https://trustedfirmware-a-tests.readthedocs.io/en/v2.4/change-log.html Thanks Manish Badarkhe

4 years, 11 months

1
0
0 0

TF-A Tech Forum Agenda @ Thr 19th November 2020 16:00-1700 GMT

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 19th November 2020 16:00 – 17:00 (GMT). Please note UK entered Daylight Saving on 25th October when clocks went back one hour to go to GMT from BST. A reoccurring meeting invite has been sent out to the subscribers of this TF-A mailing list. If you don’t have this please let me know. Agenda: * Trace-based Code Coverage Tooling for Firmware Projects * Presented by Basil Eljuse & Saul Romero * Summary * TF-A has adopted a code coverage system to measure the effectiveness of the various runtime testing performed and this is achieved without doing code instrumentation. This presentation is an overview of that approach which has applicability beyond the TF-A project. * Optional TF-A Mailing List Topic Discussions If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled. Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ A scheduling tracking page is also available to help track sessions suggested and being prepared: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting and shared on the TF-A mailing list. Thanks Joanna

4 years, 11 months

1
0
0 0

Trusted Firmware-A & Trusted Firmware-A-tests version 2.4 is now available

by Manish Badarkhe

Hi All, Trusted Firmware-A and Trusted Firmware-A-tests version 2.4 is now available and can be found here: Trusted Firmware-A: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.4 Trusted Firmware-A-tests: https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.4 Please refer to the change log of Trusted Firmware-A and Trusted Firmware-A-tests for further information here: Trusted Firmware-A: https://trustedfirmware-a.readthedocs.io/en/v2.4/change-log.html Trusted Firmware-A-tests: https://trustedfirmware-a-tests.readthedocs.io/en/v2.4/change-log.html Thanks Manish Badarkhe

4 years, 11 months

1
0
0 0

atf-a with optee-os for firefly-rk3399

by Piotr Lobacz

Hi All, i've been trying for a couple of days to load current optee together with atf from the github, with no luck. For that i have been using manuals (https://trustedfirmware-a.readthedocs.io/en/latest/plat/rockchip.html , http://opensource.rock-chips.com/wiki_ATF ) for rockchip and what i have succeded is to run very old atf tag 1.3 with optee blob from rockchip which i suspect is also very old. And if i try to use any newer atf >= 1.4 than i suspect that it does not load, because i do not see any LOGS from it, no matter that LOG_LEVEL was set to 50... Can anybody help me solving this issue or point me to some solution? Thanks in advance. BR Piotr Łobacz [https://softgent.com/wp-content/uploads/2020/01/Zasob-14.png]<https://www.softgent.com> Softgent Sp. z o.o., Budowlanych 31d, 80-298 Gdansk, POLAND KRS: 0000674406, NIP: 9581679801, REGON: 367090912 www.softgent.com Sąd Rejonowy Gdańsk-Północ w Gdańsku, VII Wydział Gospodarczy Krajowego Rejestru Sądowego KRS 0000674406, Kapitał zakładowy: 25 000,00 zł wpłacony w całości.

4 years, 11 months

1
0
0 0

Re: [TF-A] Alignment fault checking in EL3

by Soby Mathew

Hi Julius, The TF-A build sets the `-mstrict-align` compiler option, that means that the compiler will generate only aligned accesses as default. So disabling the check at runtime, seems `unaligned` with the compiler option IMO. The programmer can induce unaligned access though, although I am struggling to understand why the programmer would want to do that. The case you have pointed out seems like an error which needs to be corrected in platform code IMO. > Well, my assumption is that performing an unaligned access cannot be a > vulnerability. TF-A has linker symbol references and non-trivial linker section manipulations at runtime and these have previously triggered alignment errors when binary layout changed due to code issues. Disabling the alignment check at runtime means these errors would have remained undetected and would have resulted in more obscure crash at runtime or even a vulnerablility. In some cases, only the RELEASE builds (DEBUG=0) triggered the alignment fault. > There are scenarios where unaligned accesses can be intentional, but I am not too worried about those -- there are ways to work around that, and if we make it policy that those accesses always need to be written that way I'm okay with that. What I am worried about is mistakes and oversights that slip through testing and then cause random or even attacker-controllable crashes in production. If the main reason you're enabling this flag is to help with early detection of coding mistakes, I wonder if the best approach would be to enable it for DEBUG=1 and disable it for DEBUG=0 (of course, if there are really security issues associated with it like you mentioned above, that wouldn't make sense). Agree. But I am failing to understand why the unaligned accesses came to be there in the first place. My worry is, if this was not intended by the programmer, this might as well be a bug that will remain undetected if the alignment check is disabled. Best Regards Soby Mathew > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Julius > Werner via TF-A > Sent: 10 November 2020 02:31 > To: raghu.ncstate(a)icloud.com > Cc: tf-a <tf-a(a)lists.trustedfirmware.org> > Subject: Re: [TF-A] Alignment fault checking in EL3 > > > >>. What I am worried about is mistakes and oversights that slip > > >>through testing and then cause random or even attacker-controllable > > >>crashes in production > > > > Why would this not be the case even with SCTLR.A bit set? I'm not seeing > the relation between the crash and SCTLR.A bit. If there are oversights that > slip through testing and an attacker can cause a crash, there is > vulnerability/bug. > > If there is something that slipped through, that causes a data > abort(perhaps address not mapped in the translation tables), would we turn > off the MMU ? > > Well, my assumption is that performing an unaligned access cannot be a > vulnerability. If you have examples to the contrary please let me know, but > as far as I am aware letting an unaligned access through should always work > and will always result in the behavior the programmer intended (other than > maybe contrived cases where device address space is mapped with a non- > Device memory type, which is already very wrong for plenty of other reasons > and should never happen). The only negative consequence is that the access > may take slightly longer than if it were aligned. I do understand the desire to > be able to shake out unaligned accesses during development and testing > > I don't think the comparison to a data abort works because obviously with a > data abort the program usually can't just continue and still assume its internal > state is valid.

4 years, 11 months

2
2
0 0

FW: [Linaro-open-discussions] Kickoff: Extend PSCI with OS-initiated mode in TF-A

by Matteo Carlini

Cross-posting on the TF-A mailing list too for interested people to attend the kickoff meeting listed below hosted by Linaro. Thanks Matteo -----Original Message----- From: Linaro-open-discussions <linaro-open-discussions-bounces(a)op-lists.linaro.org> On Behalf Of Ulf Hansson via Linaro-open-discussions Sent: 10 November 2020 10:21 To: linaro-open-discussions(a)op-lists.linaro.org Subject: [Linaro-open-discussions] Kickoff: Extend PSCI with OS-initiated mode in TF-A Hi all, As previously announced we are hosting a kickoff meeting for the above topic/project. The meeting has been added to the linaro-open-discussions calendar, according to the below. Feel free to join us on Thursday this week! Kind regards Ulf Hansson, Linaro KWG When: Thursday Nov 12, 16:00-17:00 CET. Agenda: 1. Introduction. 2. Update of the current support in Linux. 3. Collaborations. 4. Technical things. 5. Other matters. To join the Zoom Meeting: https://linaro-org.zoom.us/j/97261221687 Meeting ID: 972 6122 1687 One tap mobile +13462487799,,97261221687# US (Houston) +16465588656,,97261221687# US (New York) Dial by your location +1 346 248 7799 US (Houston) +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) +1 253 215 8782 US (Tacoma) +1 301 715 8592 US (Germantown) +1 312 626 6799 US (Chicago) Meeting ID: 972 6122 1687 Find your local number: https://linaro-org.zoom.us/u/acg3UrpmdE -- Linaro-open-discussions mailing list https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home https://op-lists.linaro.org/mailman/listinfo/linaro-open-discussions

4 years, 11 months

1
0
0 0

Re: [TF-A] Alignment fault checking in EL3

by Julius Werner

> >>. What I am worried about is mistakes and > >>oversights that slip through testing and then cause random or even > >>attacker-controllable crashes in production > > Why would this not be the case even with SCTLR.A bit set? I'm not seeing the relation between the crash and SCTLR.A bit. If there are oversights that slip through testing and an attacker can cause a crash, there is vulnerability/bug. > If there is something that slipped through, that causes a data abort(perhaps address not mapped in the translation tables), would we turn off the MMU ? Well, my assumption is that performing an unaligned access cannot be a vulnerability. If you have examples to the contrary please let me know, but as far as I am aware letting an unaligned access through should always work and will always result in the behavior the programmer intended (other than maybe contrived cases where device address space is mapped with a non-Device memory type, which is already very wrong for plenty of other reasons and should never happen). The only negative consequence is that the access may take slightly longer than if it were aligned. I do understand the desire to be able to shake out unaligned accesses during development and testing, but at least in a production build I think taking that performance hit would always be preferable to a crash. I don't think the comparison to a data abort works because obviously with a data abort the program usually can't just continue and still assume its internal state is valid.

4 years, 11 months

1
0
0 0

Re: [TF-A] Alignment fault checking in EL3

by Joanna Farley

Hi Julius, A lot of the rationale for the default initialization is not listed in the documentation and I do think perhaps we can do better as at the end of the day it’s decisions around platform ports and how they are going to be deployed in products that may influence decisions here for changing the defaults. Your thoughts around attacker control able crashes are a valid one. I don’t think any one setting is all pros with no cons and platform providers need to make decisions but I think the default code with the settings is more likely to flush out alignment bugs and although I don’t have specific examples any bug could play a part in future vulnerability so best to flush them out rather than lie hidden. It could be said that in the reference implementation a known crash may be better than a more nebulous unknown behaviour that could come with an undetected bug that could later be taken advantage of. The use a DEBUG flag is an idea but we have all seen debug builds not operating like production builds so the value may be lost here. It’s why on reviewing our documentation on seeing your post I think we could do better to explain the rationale for the settings in TF-A so platform owners can be better informed and override default settings if they really feel they have the need. Cheers Joanna ________________________________ From: Julius Werner Sent: Monday, November 9, 2020 10:42 PM To: Joanna Farley Cc: raghu.ncstate(a)icloud.com; tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] Alignment fault checking in EL3 Hi Joanna, Thank you for your detailed response. I was mostly wondering if this was a deliberate choice or just something someone wrote this way once and nobody ever thought about again. Since it sounds like it is intentional, I'll try to understand your rationale better. > Maintaining these settings in production is also advised as best practice as it is known any such defects can possibly play a part in allowing an actor to take advantage of the defect as part of a vulnerability and memory related defects in particular can be taken advantage of. So it seems prudent to guard against them. I'm curious, can you elaborate on that? I can't really think of a scenario where lack of alignment checking can really make code behave in an unintentional way. (I don't think Raghu's scenario of accessing MMIO registers works because those registers should be mapped with a Device memory type anyway, and that memory type enforces aligned accesses regardless of the SCTLR.A flag.) If there truly are security concerns with this I can understand your approach much better. > Saying all this for those few cases where unaligned accesses are correct and intentional we could look to define better ways to handle these and provide that in reference code as an option to try and get the best for robustness and debuggability which seemed a big part of the concern in your post. Team members in Arm have ideas on how that could be provided but it needs broader discussion on the implications for security and performance before taking forward. There are scenarios where unaligned accesses can be intentional, but I am not too worried about those -- there are ways to work around that, and if we make it policy that those accesses always need to be written that way I'm okay with that. What I am worried about is mistakes and oversights that slip through testing and then cause random or even attacker-controllable crashes in production. If the main reason you're enabling this flag is to help with early detection of coding mistakes, I wonder if the best approach would be to enable it for DEBUG=1 and disable it for DEBUG=0 (of course, if there are really security issues associated with it like you mentioned above, that wouldn't make sense).

4 years, 11 months

1
0
0 0

Re: [TF-A] Alignment fault checking in EL3

by Joanna Farley

Hi Julius, Talking to the team here its has always been felt it is best practise to forbid unaligned data accesses in Arm's embedded projects. That's the reason TF-A also enforces the build options: -mno-unaligned-access (AArch32) and -mstrict-align (AArch64). In the TF-A documentation [1] SCTLR_EL3.A and other settings are listed in the Architectural Initialisation section. There is thought to be only a few cases where unaligned access are correct and intentional and most are defects that should be caught early and not in production and as such it is better to detect unaligned data access conditions early in a platform porting, rather than in the field especially if there is no firmware update capability. Alignment faults should be treated as fatal as they should never happen in production when components have been designed as such from the beginning. Maintaining these settings in production is also advised as best practice as it is known any such defects can possibly play a part in allowing an actor to take advantage of the defect as part of a vulnerability and memory related defects in particular can be taken advantage of. So it seems prudent to guard against them. We can of course provide better rationalisation based on the above in our documentation to provide platforms porting efforts better guidance. It is after all up to partners in their platform ports to make appropriate decisions for their ports where settings could be changed however the upstreamed reference code should follow the settings we have which are felt to be best practices for TF-A. It is known other projects follow other practices and that is fine if that works for them. Once a project enables unaligned accesses, it's very hard to go back again since it's likely that code that does unaligned accesses will slowly get added to the project. However for TF-A maintaining the current settings is felt to be the best approach when weighing up the costs and benefits. Saying all this for those few cases where unaligned accesses are correct and intentional we could look to define better ways to handle these and provide that in reference code as an option to try and get the best for robustness and debuggability which seemed a big part of the concern in your post. Team members in Arm have ideas on how that could be provided but it needs broader discussion on the implications for security and performance before taking forward. Thanks Joanna [1] https://trustedfirmware-a.readthedocs.io/en/latest/design/firmware-design.h… On 09/11/2020, 17:47, "TF-A on behalf of Raghu Krishnamurthy via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi Julius, I tend to agree with your argument about not using SCTLR.A bit but I think the unexpected crashes or instability is due buggy code and insufficient validation of invariants such as aligned pointers, irrespective of whether SCTRLR.A is set or unset. Even if we allow unaligned accesses, we could have buggy code that access registers that typically have to be size aligned and we wouldn’t catch those bugs with SCTLR.A. Worse, some hardware implementations have undefined/impdef behavior when there are unaligned access to MMIO registers for ex, in which case, I would rather take an alignment fault at the core than allow triggering of undefined behavior. So I don’t think stability/reliability and the use of SCTLR.A bit are related. If TF-A's position is that we want to allow only aligned accesses in EL3(for whatever reason, I can only think of efficiency), it is the code's responsibility to enforce this invariants using asserts or explicit checks. >> I am still wondering why we choose to set the SCTLR_EL3.A I think this is the relevant question. If there are good security reasons(which I don’t know about), I would say we should keep it. If it is for efficiency, given the way recent ARM64 cores are performing, I wouldn't have a problem with SCTLR.A=0. Thanks Raghu -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Julius Werner via TF-A Sent: Friday, November 6, 2020 6:38 PM To: tf-a <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Alignment fault checking in EL3 Hi, I just debugged a TF-A boot crash that turned out to be caused by an alignment fault in platform code. Someone had defined some static storage space as a uint8_t array, and then accessed it by dereferencing uint16_t pointers. Of course this is ultimately a bug in the platform code that should be fixed, but I am still wondering why we choose to set the SCTLR_EL3.A (Alignment fault checking) flag in TF-A? In an ideal world, maybe we could say that code which can generate alignment faults should not exist -- but, unfortunately, people make mistakes, and this kind of mistake may linger unnoticed for a long time in the codebase before randomly getting triggered due to subtle shifts in the binary's memory layout. (Worse, in some situations this could get affected by SMC parameters passed in from lower exception levels, so it would only be noticeable and could possibly be intentionally triggered if the lower exception level passes in just the right values.) For that reason, most other environments I know (e.g. Linux) always keep that flag cleared. There's no harm in that -- as far as I'm aware all aarch64 cores are required to support unaligned accesses to cached memory types, and the worst that would happen is a slight performance penalty for the access. I think that flag is mostly meant as a debugging feature to be able to shake out accidental unaligned accesses from your code? If our goal is to be stable and reliable firmware, shouldn't we disable it to reduce the chance of unexpected crashes? -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 11 months

3
2
0 0

Re: [TF-A] Alignment fault checking in EL3

by raghu.ncstate＠icloud.com

Hi Julius, I tend to agree with your argument about not using SCTLR.A bit but I think the unexpected crashes or instability is due buggy code and insufficient validation of invariants such as aligned pointers, irrespective of whether SCTRLR.A is set or unset. Even if we allow unaligned accesses, we could have buggy code that access registers that typically have to be size aligned and we wouldn’t catch those bugs with SCTLR.A. Worse, some hardware implementations have undefined/impdef behavior when there are unaligned access to MMIO registers for ex, in which case, I would rather take an alignment fault at the core than allow triggering of undefined behavior. So I don’t think stability/reliability and the use of SCTLR.A bit are related. If TF-A's position is that we want to allow only aligned accesses in EL3(for whatever reason, I can only think of efficiency), it is the code's responsibility to enforce this invariants using asserts or explicit checks. >> I am still wondering why we choose to set the SCTLR_EL3.A I think this is the relevant question. If there are good security reasons(which I don’t know about), I would say we should keep it. If it is for efficiency, given the way recent ARM64 cores are performing, I wouldn't have a problem with SCTLR.A=0. Thanks Raghu -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Julius Werner via TF-A Sent: Friday, November 6, 2020 6:38 PM To: tf-a <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Alignment fault checking in EL3 Hi, I just debugged a TF-A boot crash that turned out to be caused by an alignment fault in platform code. Someone had defined some static storage space as a uint8_t array, and then accessed it by dereferencing uint16_t pointers. Of course this is ultimately a bug in the platform code that should be fixed, but I am still wondering why we choose to set the SCTLR_EL3.A (Alignment fault checking) flag in TF-A? In an ideal world, maybe we could say that code which can generate alignment faults should not exist -- but, unfortunately, people make mistakes, and this kind of mistake may linger unnoticed for a long time in the codebase before randomly getting triggered due to subtle shifts in the binary's memory layout. (Worse, in some situations this could get affected by SMC parameters passed in from lower exception levels, so it would only be noticeable and could possibly be intentionally triggered if the lower exception level passes in just the right values.) For that reason, most other environments I know (e.g. Linux) always keep that flag cleared. There's no harm in that -- as far as I'm aware all aarch64 cores are required to support unaligned accesses to cached memory types, and the worst that would happen is a slight performance penalty for the access. I think that flag is mostly meant as a debugging feature to be able to shake out accidental unaligned accesses from your code? If our goal is to be stable and reliable firmware, shouldn't we disable it to reduce the chance of unexpected crashes?

4 years, 11 months

1
0
0 0

Alignment fault checking in EL3

by Julius Werner

Hi, I just debugged a TF-A boot crash that turned out to be caused by an alignment fault in platform code. Someone had defined some static storage space as a uint8_t array, and then accessed it by dereferencing uint16_t pointers. Of course this is ultimately a bug in the platform code that should be fixed, but I am still wondering why we choose to set the SCTLR_EL3.A (Alignment fault checking) flag in TF-A? In an ideal world, maybe we could say that code which can generate alignment faults should not exist -- but, unfortunately, people make mistakes, and this kind of mistake may linger unnoticed for a long time in the codebase before randomly getting triggered due to subtle shifts in the binary's memory layout. (Worse, in some situations this could get affected by SMC parameters passed in from lower exception levels, so it would only be noticeable and could possibly be intentionally triggered if the lower exception level passes in just the right values.) For that reason, most other environments I know (e.g. Linux) always keep that flag cleared. There's no harm in that -- as far as I'm aware all aarch64 cores are required to support unaligned accesses to cached memory types, and the worst that would happen is a slight performance penalty for the access. I think that flag is mostly meant as a debugging feature to be able to shake out accidental unaligned accesses from your code? If our goal is to be stable and reliable firmware, shouldn't we disable it to reduce the chance of unexpected crashes?

4 years, 11 months

1
0
0 0

[RFC PATCH] hw/arm/virt: use sbsa-ec for reboot and poweroff in secure mode

by Maxim Uvarov

If we're emulating EL3 then the EL3 guest firmware is responsible for providing the PSCI ABI, including reboot, core power down, etc. sbsa-ref machine has an embedded controller to do reboot, poweroff. Machine virt,secure=on can reuse this code to do reboot inside ATF. Signed-off-by: Maxim Uvarov <maxim.uvarov(a)linaro.org> --- Hello, This patch implements reboot for the secure machine inside ATF firmware. I.e. current qemu patch should be used with [1] ATF patch. It looks like that Embedded Controller qemu driver (sbsa-ec) can be common and widely used for other emulated machines. While if there are plans to extend sbsa-ec then we might find some other solution. So for the long term it looks like machine virt was used as an initial playground for secure firmware. While the original intent was a runner for kvm guests. Relation between kvm guest and firmware is not very clear now. If everyone agree it might be good solution to move secure firmware things from virt machine to bsa-ref and make this machine reference for secure boot, firmware updates etc. [1] https://github.com/muvarov/arm-trusted-firmware/commit/6d3339a0081f6f2b45d9… Best regards, Maxim. hw/arm/virt.c | 9 +++++++++ include/hw/arm/virt.h | 2 ++ 2 files changed, 11 insertions(+) diff --git a/hw/arm/virt.c b/hw/arm/virt.c index e465a988d6..6b77912f02 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -152,6 +152,7 @@ static const MemMapEntry base_memmap[] = { [VIRT_ACPI_GED] = { 0x09080000, ACPI_GED_EVT_SEL_LEN }, [VIRT_NVDIMM_ACPI] = { 0x09090000, NVDIMM_ACPI_IO_LEN}, [VIRT_PVTIME] = { 0x090a0000, 0x00010000 }, + [VIRT_EC] = { 0x090c0000, 0x00001000 }, [VIRT_MMIO] = { 0x0a000000, 0x00000200 }, /* ...repeating for a total of NUM_VIRTIO_TRANSPORTS, each of that size */ [VIRT_PLATFORM_BUS] = { 0x0c000000, 0x02000000 }, @@ -1729,6 +1730,13 @@ static void virt_cpu_post_init(VirtMachineState *vms, int max_cpus, } } +static void init_ec_controller(VirtMachineState *vms) +{ + vms->ec = qdev_new("sbsa-ec"); + + sysbus_mmio_map(SYS_BUS_DEVICE(vms->ec), 0, vms->memmap[VIRT_EC].base); +} + static void machvirt_init(MachineState *machine) { VirtMachineState *vms = VIRT_MACHINE(machine); @@ -1797,6 +1805,7 @@ static void machvirt_init(MachineState *machine) */ if (vms->secure && firmware_loaded) { vms->psci_conduit = QEMU_PSCI_CONDUIT_DISABLED; + init_ec_controller(vms); } else if (vms->virt) { vms->psci_conduit = QEMU_PSCI_CONDUIT_SMC; } else { diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h index aad6d69841..6f2ce4e4ff 100644 --- a/include/hw/arm/virt.h +++ b/include/hw/arm/virt.h @@ -85,6 +85,7 @@ enum { VIRT_ACPI_GED, VIRT_NVDIMM_ACPI, VIRT_PVTIME, + VIRT_EC, VIRT_LOWMEMMAP_LAST, }; @@ -163,6 +164,7 @@ struct VirtMachineState { DeviceState *gic; DeviceState *acpi_dev; Notifier powerdown_notifier; + DeviceState *ec; }; #define VIRT_ECAM_ID(high) (high ? VIRT_HIGH_PCIE_ECAM : VIRT_PCIE_ECAM) -- 2.17.1

4 years, 12 months

5
7
0 0

TF-A Tech Forum Agenda @ Thr 5th November 2020 16:00-1700 GMT

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 5th November 2020 16:00 – 17:00 (GMT). Please note UK entered Daylight Saving on 25th October when clocks went back one hour to go to GMT from BST. A reoccurring meeting invite has been sent out to the subscribers of this TF-A mailing list. If you don’t have this please let me know. Agenda: * TF-A Tests Framework Overview * Presented by Varun Wadekar * Summary * Trusted Firmware-A Tests (TF-A Tests) is a suite of baremetal tests to exercise the Trusted Firmware-A (TF-A) features from the Normal World. * Optional TF-A Mailing List Topic Discussions If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled. Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ A scheduling tracking page is also available to help track sessions suggested and being prepared: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting and shared on the TF-A mailing list. Thanks Joanna

4 years, 12 months

1
0
0 0

Mbed TLS Virtual Workshop Tomorrow

by Shebu Varghese Kuriakose

Hi All, Gentle reminder about the Mbed TLS workshop tomorrow (Tuesday, November 3rd) from 2 to 6pm GMT. See agenda and zoom link here - https://www.trustedfirmware.org/meetings/mbed-tls-workshop/ Thanks, Shebu -----Original Appointment----- From: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com> Sent: Friday, October 23, 2020 12:32 AM To: Trusted Firmware Public Meetings; Shebu Varghese Kuriakose; mbed-tls(a)lists.trustedfirmware.org; Don Harbin; psa-crypto(a)lists.trustedfirmware.org; Dave Rodgman Subject: Mbed TLS Virtual Workshop When: Tuesday, November 3, 2020 2:00 PM-6:00 PM (UTC+00:00) Dublin, Edinburgh, Lisbon, London. Where: Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… You have been invited to the following event. Mbed TLS Virtual Workshop When Tue Nov 3, 2020 7am – 11am Mountain Standard Time - Phoenix Where Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… (map<https://www.google.com/maps/search/Zoom:+https:%2F%2Flinaro-org.zoom.us%2Fj…>) Calendar shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> Who • Don Harbin - creator • shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> • mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> • psa-crypto(a)lists.trustedfirmware.org<mailto:psa-crypto@lists.trustedfirmware.org> • dave.rodgman(a)arm.com<mailto:dave.rodgman@arm.com> more details »<https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…> Hi, Trustedfirmware.org community project would like to invite you to the Mbed TLS Virtual Workshop. The purpose of the workshop is to bring together the Mbed TLS community including maintainers, contributors and users to discuss * The future direction of the project and * Ways to improve community collaboration Here is the agenda for the workshop. Topic Time (in GMT) Welcome 2.00 - 2.10pm Constant-time code 2.10 – 2.30pm Processes - how does work get scheduled? 2.30 – 2.50pm PSA Crypto APIs 2.50 – 3.20pm PSA Crypto for Silicon Labs Wireless MCUs - Why, What, Where and When 3.20 – 3.50pm Break Roadmap, TLS1.3 Update 4.10 – 4.30pm Mbed TLS 3.0 Plans, Scope 4.30 – 5.00pm How do I contribute my first review and be an effective Mbed TLS reviewer 5.00 – 5.30pm Regards, Don Harbin Trusted Firmware Community Manager ==============Zoom details below:==================== Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: Mbed TLS Virtual Workshop Time: Nov 3, 2020 02:00 PM Greenwich Mean Time Join Zoom Meeting https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9531520…> Meeting ID: 953 1520 0315 Passcode: 143755 One tap mobile +16699009128,,95315200315# US (San Jose) +12532158782,,95315200315# US (Tacoma) Dial by your location +1 669 900 9128 US (San Jose) +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 646 558 8656 US (New York) +1 301 715 8592 US (Germantown) +1 312 626 6799 US (Chicago) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 953 1520 0315 Find your local number: https://linaro-org.zoom.us/u/apL3hgti4<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fu%2FapL3hgt…> Going (shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com>)? Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> 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://www.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<https://support.google.com/calendar/answer/37135#forwarding>.

4 years, 12 months

1
0
0 0

Re: [TF-A] Questions raised about Measured Boot + fTPM test case

by Ruchika Gupta

Hi, *For [1] - Would be good if the test infrastructure(the TPM TA) can compile in AARCH64. I thought I heard on the tf-a call that there already is a Microsoft FW TPM port for aarch64 already. Please let me know if I misunderstood.* You can check the implementation at https://github.com/microsoft/MSRSec This compiles for aarch64. I had a few queries for chips having physical TPM. Case 1. Should all entities doing the measurement (BL1, BL2) have the TPM driver to extend the measurements as they are done. This would be the most secure flow. Case 2. If BL1 and BL2 don't have the TPM driver as mentioned in Case 1 above, who would be responsible for extending the measurements for secure world entities. -- Should there be a TPM driver in Secure EL0/EL1 which does this ? -- Event log is also passed to the BL33. In case there is no TPM driver at all in the secure world - is it expected that BL33 should extend the measurements in PCR ? Regards, Ruchika On Mon, 26 Oct 2020 at 21:03, Stuart Yoder via TF-A < tf-a(a)lists.trustedfirmware.org> wrote: > Regarding measuring TB_FW_CONFIG-- > > BL1 could measure the unmodified TB_FW_CONFIG image as it was loaded from > flash. It could then update TB_FW_CONFIG with that measurement which > reflects the image as it was on flash. This could allow detection of > tampering with flash. I would recommend doing this, as TB_FW_CONFIG is > critical data. > > BL2 could make a measurement of the TB_FW_CONFIG image as it was passed to > it in memory. > > Thanks, > Stuart > > > On 10/26/20 6:16 AM, Alexei Fedorov wrote: > > Hi Javer, > > Please see my comments below. > > [3] Provide platform hooks in tpm_record_measurement function for a > platform to actually extend those measurements to a physical TPM right when > they are measured. > > These hooks can be implemented in the next phase #2 of Measured Boot > implementation. > > [4] On platforms that use FCONF, the FW_CONFIG and TB_FW_CONFIG should > also be measured since they are images being loaded as well. See > arm_bl1_setup.c where these images are loaded but not measured(unless I’m > missing something). > > FW_CONFIG and TB_FW_CONFIG images are loaded by BL1 but not BL2. > BL1 calculates BL2 hash and passes the measurement to BL2 in TB_FW_CONFIG. > It can also pass FW_CONFIG hash in the same DTB, but it is not clear how > own TB_FW_CONFIG hash can be passed in itself. > > Stuart, do you have opinion on that? > > Regards. > > Alexei > ------------------------------ > *From:* TF-A <tf-a-bounces(a)lists.trustedfirmware.org> > <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Javier Almansa > Sobrino via TF-A <tf-a(a)lists.trustedfirmware.org> > <tf-a(a)lists.trustedfirmware.org> > *Sent:* 26 October 2020 10:25 > *To:* raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com> > <raghu.ncstate(a)icloud.com> > *Cc:* tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> > <tf-a(a)lists.trustedfirmware.org> > *Subject:* Re: [TF-A] Questions raised about Measured Boot + fTPM test > case > > Hi Raghu, > > Thank you very much for your comments and for your feedback. > > With regards to the (f)TPM service and as discussed during the last TF-A > Tech Forum call, we will discuss internally the need of a new > implementation, probably after the next TF-A release, and we will schedule > the work (in case we decide to go ahead with it) for the upcoming months. > We will announce any decision we make through the mailing list and/or on > future TF-A Tech Forum calls . > > Regarding to changes to TF-A to include extra functionality/APIs/hooks, I > guess my colleague Alexei can provide further details about the next > features planned for Measured Boot, if any. > > To finish, I would just like to clarify one of the questions raised on > your email: > > [1] Would be good if the test infrastructure(the TPM TA) can compile in > AARCH64. I thought I heard on the tf-a call that there already is a > Microsoft FW TPM port for aarch64 already. Please let me know if I > misunderstood. > > > - Microsoft has a reference implementation of the TPM 2.0 > specification. That implementation is in the form of an architecture > agnostic library that implements the specification. Along with the library, > there are a couple of example applications for different platforms built > around the former, one of them being the fTPM we used for testing. That > application was written for AARCH32 and seemed to be outdated (I don't know > if it was abandoned, actually), so we updated it and added support for > Measured Boot to it. > > > Best regards, > Javier > > -----Original Message----- > *From*: raghu.ncstate(a)icloud.com > *To*: 'Javier Almansa Sobrino' <Javier.AlmansaSobrino(a)arm.com > <'Javier%20Almansa%20Sobrino'%20%3cJavier.AlmansaSobrino(a)arm.com%3e>> > *Cc*: tf-a(a)lists.trustedfirmware.org > *Subject*: RE: [TF-A] Questions raised about Measured Boot + fTPM test > case > *Date*: Sun, 25 Oct 2020 14:31:10 -0700 > > Hi Javier, > > > > As discussed during the TF-A call, here are some suggestions/feedback that > can be incorporated when time permits based on priorities, schedule, > resources etc: > > 1. Would be good if the test infrastructure(the TPM TA) can compile in > AARCH64. I thought I heard on the tf-a call that there already is a > Microsoft FW TPM port for aarch64 already. Please let me know if I > misunderstood. > 2. Would be good if the TPM TA works on FF-A as opposed to proprietary > OPTEE API’s. > 3. Provide platform hooks in tpm_record_measurement function for a > platform to actually extend those measurements to a physical TPM right when > they are measured. This is a requirement from a security perspective to not > wait until the tpm TA is loaded to be able to extend the measurements into > a tpm. I understand this can be done in the platform hook that calls > tpm_record_measurement but it is convenient place to put tpm related > platform hooks. > 4. On platforms that use FCONF, the FW_CONFIG and TB_FW_CONFIG should > also be measured since they are images being loaded as well. See > arm_bl1_setup.c where these images are loaded but not measured(unless I’m > missing something). > > > > Thanks > > Raghu > > > > *From:* TF-A <tf-a-bounces(a)lists.trustedfirmware.org> > <tf-a-bounces(a)lists.trustedfirmware.org> *On Behalf Of *Javier Almansa > Sobrino via TF-A > *Sent:* Friday, October 9, 2020 10:51 AM > *To:* tf-a(a)lists.trustedfirmware.org > *Subject:* [TF-A] Questions raised about Measured Boot + fTPM test case > > > > Hello all, > > > > Following up the question raised yesterday during the TF-A Tech Forum with > regards to any modification needed on the Linux Kernel to run the test case > that I was presenting (Measured Boot + fTPM service), I double checked > today and I ran some tests on system and I can confirm that the test case > works with the mainline Linux Kernel, with no modification other than > enabling the driver on the DTB. > > > > The modules involved on the interaction with the fTPM (for this particular > example) are: > > > > * optee.ko: Allows communication between the REE (unsecure world), the > Trusted OS (secure world) and the tee-supplicant (unsecure world). > > * tpm_ftpm_tee.ko: Module to communicate with a firmware TPM through a > char device. This also includes the reference implementation used on the > test case. > > > > In order to use the fTPM service, the test case makes use of IBM's TPM 2.0 > TSS, a user space TSS for TPM 2.0 that uses services provided by the fTPM. > > > > I would also like to highlight the following points: > > > > A) The test case is only meant to test the ability of the Measured Boot > Driver and a TPM 2.0 compliant device to interact with each other. As such, > we are not providing an fTPM meant to be used on a production environment. > Instead, we are using an existing reference implementation to which we > added support for Measured Boot to fulfil our needs for the test and use it > as a functional example. The implementation details on how to interact with > a particular TPM device (either firmware or discrete) can differ from the > ones used on the test case as those details can be platform dependent. For > example, we use an OPTEE TA fTPM on this example, but other platforms might > use a discrete TPM or an fTPM running on a different Trusted OS. > > > > B) As stated on the presentation, we are undergoing internal review of the > contributions done for the fTPM service to make it compatible with Measured > Boot. Once the review is completed and the changes merged into the TPM repo > mainline, we will update the TF-A documentation with instructions on how to > download and build all the components to run the tests manually. > > > > Please, let me know in case you have any more questions. > > > > Best regards, > > Javier > > > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a >

5 years

3
2
0 0

Re: [TF-A] [Linaro-open-discussions] Extend TF-A with PSCI OS-initiated mode

by Matteo Carlini

Cross-posting to the TF-A mailing list as well for interested partners. > -----Original Message----- > From: Linaro-open-discussions <linaro-open-discussions-bounces@op- > lists.linaro.org> On Behalf Of Ulf Hansson via Linaro-open-discussions > Sent: 28 October 2020 15:45 > To: linaro-open-discussions(a)op-lists.linaro.org > Cc: Lauren Wehrmeister <Lauren.Wehrmeister(a)arm.com>; Lina Iyer > <ilina(a)codeaurora.org>; Dan Handley <Dan.Handley(a)arm.com>; Madhukar > Pappireddy <Madhukar.Pappireddy(a)arm.com>; Bhutada Harshad > <hbhutada(a)qti.qualcomm.com>; Gabriel FERNANDEZ > <gabriel.fernandez(a)st.com> > Subject: [Linaro-open-discussions] Extend TF-A with PSCI OS-initiated mode > > Hi all, > > In the Linux kernel v5.6, we introduced the basic support for PSCI OS-initiated > mode. Linaro is still working on evolving the support, step by step. > Additionally, we are helping some of our members with corresponding SoC > deployment, which is planned to continue for a while. > > Basically, the PSCI OS-initiated mode allows Linux to be in charge of idlestate > decisions for a group of CPUs (aka CPU cluster), which may share idlestates. > In some cases this enables improvements in regards to performance/energy, > but could also be used to help manage resources that may share power- > /clock-domains with CPUs. > > Moving forward, we are now planning to extend the corresponding PSCI > implementation in the Trusted Firmware-A (TF-A) with the OS-initiated mode, > together with our members and member engineers. Currently, only the > default PSCI platform-coordinated mode is supported by the TF-A. > > We seek for additional collaborations and input to the new project! > Please get in touch, if you have any feedback and/or find this project > interesting. > > Finally, a kickoff meeting is about to be scheduled and held within a few > weeks. Let me know if you want to join the discussions. > > Kind regards > Ulf Hansson, Linaro Kernel Working Group > -- > Linaro-open-discussions mailing list > https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home > https://op-lists.linaro.org/mailman/listinfo/linaro-open-discussions

5 years

1
0
0 0

Re: [TF-A] BL31 as bootloader

by rkohli2000 gmail

Hi Alexei, I'm able to eliminate the warning using the -j .text and see the image load and run ok. The issue I am seeing is that the bsp I am using expects my bot loader bl31.bin to power on the UART and do the low level init that makes PCIe controller accessible. I think at exit from bl31.bin I don't have this initialization. Can you point me the TFA code to enable LPUART and make PCIe controller accessible in imx8qm before handoff to BL33 ? Regards Ravi > On Oct 28, 2020, at 11:33 AM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Alexei, Thanks for the hint. Yes, my App.bin image has a bunch of header info > and that's the root cause of the undef ARM instructions. I grabbed a pure ELF image > I built using the integrity compiler and see the following warning on trying to convert ELF to > raw binary on linux. The conversion is not permitted. Do I need some flags ? > > Regards > Ravi > > ravi:~/imx8qm/gcc-arm-9.2-2019.12-x86_64-aarch64-none-elf/bin$ ./aarch64-none-elf-readelf -h ~/imx8qm/imx-mkimage/iMX8QM/example_app.elf > ELF Header: > Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 > Class: ELF64 > Data: 2's complement, little endian > Version: 1 (current) > OS/ABI: UNIX - System V > ABI Version: 0 > Type: EXEC (Executable file) > Machine: AArch64 > Version: 0x1 > Entry point address: 0xffffff8080200000 > Start of program headers: 64 (bytes into file) > Start of section headers: 866208 (bytes into file) > Flags: 0x0 > Size of this header: 64 (bytes) > Size of program headers: 56 (bytes) > Number of program headers: 49 > Size of section headers: 64 (bytes) > Number of section headers: 78 > Section header string table index: 77 > > ravi:~/imx8qm/gcc-arm-9.2-2019.12-x86_64-aarch64-none-elf/bin$ ./aarch64-none-elf-objcopy -O binary ~/imx8qm/imx-mkimage/iMX8QM/example_app.elf ~/imx8qm/imx-mkimage/iMX8QM/dummy.bin > ./aarch64-none-elf-objcopy: warning: writing section `.example_virtual.text' at huge (ie negative) file offset > ./aarch64-none-elf-objcopy: warning: writing section `.example_virtual.rodata' at huge (ie negative) file offset > ./aarch64-none-elf-objcopy: warning: writing section `.example_virtual.rodata' at huge (ie negative) file offset > ./aarch64-none-elf-objcopy: warning: writing section `.example_virtual.data' at huge (ie negative) file offset > ./aarch64-none-elf-objcopy: warning: writing section `.boottable' at huge (ie negative) file offset > ./aarch64-none-elf-objcopy: warning: writing section `.secinfo' at huge (ie negative) file offset > ./aarch64-none-elf-objcopy:/home/ravi/imx8qm/imx-mkimage/iMX8QM/dummy.bin[.example_virtual.text]: file truncated > > > > > > On Wed, Oct 28, 2020 at 10:09 AM Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: > Hi Ravi, > > Is App.bin generated by the tool you use is a "pure" binary or contains some extra entries at the start of the image (e.g. 0x7F 0x45 0x4C 0x46 = "ELF" )? > This might also help: > https://stackoverflow.com/questions/49814470/u-boot-how-to-run-a-standalone… <https://stackoverflow.com/questions/49814470/u-boot-how-to-run-a-standalone…> > > Alexei > From: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> > Sent: 27 October 2020 22:03 > To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> > Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > Subject: Re: [TF-A] BL31 as bootloader > > Hi Alexei, > No, we don't see the same behavior when launching our hello world app (using Integrity178 rtos) > from U-boot. The only change uboot needed was related to size of the image (i don't have specifics about this change). > But, the hello app runs fine from U-boot printing normally on the imx8qm MEK board. > > I don't see this test app write to the UART launching from bl31.bin at 0x80020000. I can see the > handoff is successful setting a breakpoint at 0x80020000 from my Lauterbach debugger probe. > > The test app is prepared using the GHS tools (elf to bin) using gmemfile.exe and then uboot's mkimage > command: mkimage -A arm64 -O u-boot -T kernel -C none -a 0x80200000 -e 0x80200000 -n "INTEG" -d tmp.bin App.bin. > This generates the App.bin that tftpboots boots fine from any given address on my board. This very same image > does not work booting from bl31.bin. > > Can you suggest what could be going on ? > > Regards > Ravi > > > > > > On Oct 27, 2020, at 8:34 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: > > > > Hi Ravi, > > > > It is good to know that you have some progress with your problem. > > > > "I'm seeing some undef instruction, etc, etc." > > Do you see the same behaviour when launching BL33 from U-Boot? > > > > Regards. > > Alexei > > From: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> > > Sent: 26 October 2020 20:23 > > To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> > > Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > > Subject: Re: [TF-A] BL31 as bootloader > > > > Hi Alexei, Manish, > > > > I had some better luck with my debugger this time. I can see > > the handoff from bl31.bin (imx-atf) to BL33 entry point (0x80020000) > > in my debugger now. > > > > The problem was in setting up the debugger properly which was > > preventing me from seeing the breakpoint. My bad. > > > > Now, I can see the handoff and execution of instruction of the > > test app. This app is an integrity178 app and I'm seeing some undef > > instruction, etc, etc. Likely specific to the rtos we are using for this app. > > So, I will follow up on that end. Thanks for your debug support and > > helping me experiment with TFA for our product. > > > > Regards > > Ravi > > > > > >> On Oct 26, 2020, at 4:44 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: > >> > >> Hi Ravi > >> > >> As you can see in debugger that memory at 0x80020000 address is populated correctly, can you set a breakpoint at it to check if execuion reaches it? If you cannot set a breakpoint I would suggest to add a few assembler instructions in the start of your BL33 entry point to write any specific character, e.g. '!' to debug UART data port and branch to the next instruction in an infinite loop with "b .". Seeing ! char on debug console would prove that control to BL33 image has been passed. > >> > >> Regards. > >> Alexei > >> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >> Sent: 24 October 2020 22:48 > >> To: Ravi Kohli <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> > >> Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >> Subject: Re: [TF-A] BL31 as bootloader > >> > >> Hi Alexei, Manish, > >> > >> I instrumented the imx8QM platform code and saw normal execution with bl31_main() > >> exiting normally with entry point for my BL33 image. But, I haven't seen the handoff > >> work yet. Can you suggest what else I can try to debug this ? I have an image copied > >> at 0x80020000 from what I can see in the debugger. Thanks in advance. > >> > >> Regards > >> Ravi > >> > >> > >> > >> > >> On Fri, Oct 23, 2020 at 3:43 PM rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> wrote: > >> Hi Manish, > >> > >> I have been able to copy the test app (BL33) to entry point address 0x80020000. > >> I confirmed from the Debugger that RAM address 0x80020000 is populated. I had to modify imx-atf > >> makefile target to use the "-data" option as follows: > >> flash_test_8: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin App.bin imx8qm-mek-ca53.dtb > >> ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -data App.bin 0x80020000 -data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin > >> The -data option appears to copy the image at the 0x80020000 address. Now, I think we should > >> be able to handoff since PC (program counter) is set : > >> bl33_image_ep_info.pc = plat_get_ns_image_entrypoint(); > >> > >> I don't see any serial console output using an image that works when using u-boot. I am not using > >> u-boot for certification reasons. Is there some way I can confirm that the handoff is happening from bl31.bin to > >> the App.bin ? At which BL31 function or module does the handoff occur ? > >> > >> I don't see my HW breakpoint trigger at location location 0x80020000. > >> > >> Regards > >> Ravi > >> > >>> On Oct 23, 2020, at 9:25 AM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> wrote: > >>> > >>> Hi Manish, > >>> > >>> Can you please point me to any example or a BL2 module which does the copy to RAM from Flash ? > >>> Maybe I can try to copy the image to 0x80020000 before exiting BL31 from bl31_main(). > >>> > >>> The bl31.bin image boot fine on the target board (imx8qm) from location 0x80000000 > >>> to start with. That copy to 0x80000000 must happen as well. I'm not sure where assuming > >>> its some NXP firmware doing it. Do you know where it could be ? > >>> > >>> Regards > >>> Ravi > >>> > >>> > >>>> On Oct 23, 2020, at 4:46 AM, Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> wrote: > >>>> > >>>> Hi Ravi, > >>>> > >>>> This is normal behaviour when you RESET_TO_BL31. > >>>> The loading of images (from flash to RAM) is part of BL2 code and in case of directly jumping to BL31, you need a mechanism to Load these images at proper location. > >>>> Some platforms have a separate firmware which does this before starting execution of BL31, so that when BL31 hands over to BL33 it gets valid image there. > >>>> > >>>> thanks > >>>> Manish > >>>> From: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> > >>>> Sent: 23 October 2020 05:08 > >>>> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>>; Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> > >>>> Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>> Subject: Re: [TF-A] BL31 as bootloader > >>>> > >>>> Hi Alexei, Manish, > >>>> > >>>> I repeated the test (below) a few times and see the same result. > >>>> > >>>> (1) Do I need to copy my BL33 (non-secure) image from > >>>> flash.bin some how to RAM 0x80020000 entry point address ? > >>>> Is there any example of how to copy the flash.bin image ? I not sure > >>>> what address or where to copy it from. > >>>> > >>>> (2) Is there some existing debug code that I can use > >>>> to dump/print the ARMv8 RAM address space from inside > >>>> BL31.bin ? > >>>> > >>>> I only found some TF-A tf_log macros in debug.h. > >>>> I would like to dump some memory address contents > >>>> (like 0x80020000) from inside bl31.bin to console just for > >>>> debugging at run-time. > >>>> > >>>>> On Oct 22, 2020, at 4:28 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> wrote: > >>>>> > >>>>> Hi Alexei, > >>>>> > >>>>> I captured the LOG_LEVEL=50 log (attached putty-ser0.log) from TF-A bl31.bin. > >>>>> I see bl31 boots normally but never hands off to the BL33 normal world image (App.bin) > >>>>> > >>>>> The flash.bin image I am running is constructed using imx-mkimage tool with the following target: > >>>>>> flash_test_7: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin App.bin imx8qm-mek-ca53.dtb > >>>>>> ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c -flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -p3 -ap App.bin a53 0x80020000 -data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin > >>>>> > >>>>> I used UUU tool to flash eMMC with flash.bin on the imx8QM MEK board. > >>>>> > >>>>> I inspected RAM using a trace32 debugger SW after using a while (1) to halt the execution at the end of bl31.bin main function (bl31_main()). > >>>>>> diff --git a/bl31/bl31_main.c b/bl31/bl31_main.c > >>>>>> index 92a2027dd..51afb13ea 100644 > >>>>>> --- a/bl31/bl31_main.c > >>>>>> > >>>>>> +++ b/bl31/bl31_main.c > >>>>>> @@ -147,6 +147,11 @@ void bl31_main(void) > >>>>>> * from BL31 > >>>>>> */ > >>>>>> bl31_plat_runtime_setup(); > >>>>>> + > >>>>>> + INFO("BL31: leaving bl31_main\n"); > >>>>>> + INFO("entering while(1)\n"); > >>>>>> + > >>>>>> + while (1) {}; > >>>>>> } > >>>>> It appears that there's no data or image at 0x80020000 just before exiting bl31_main(). See the debugger RAM dump at > >>>>> address 0x80000000 (bl31.bin entry point) and 0x80020000 (BL33 or App.bin normal world app entry point). > >>>>> See the debugger output. > >>>>> > >>>>> When should the flash image provided in flash.bin get copied to the RAM entry point 0x80020000 ? Should bl31.bin > >>>>> copy the image from flash to RAM ? > >>>>> > >>>>> Can you suggest what could be going on ? > >>>>> > >>>>> Regards > >>>>> Ravi > >>>>> > >>>>> > >>>>> > >>>>>> On Oct 22, 2020, at 6:15 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: > >>>>>> > >>>>>> Hi Ravi, > >>>>>> > >>>>>> TFTF image can be built from https://git.trustedfirmware.org/TF-A/tf-a-tests.git <https://git.trustedfirmware.org/TF-A/tf-a-tests.git> > >>>>>> > >>>>>> You can also try to increase TF-A log level by setting LOG_LEVEL=50 and check if BL33 memory region is mapped correctly. > >>>>>> Before passing control to BL33 and could add code to dump initial memory at BL33 start address to see if the image was loaded with no issues. > >>>>>> > >>>>>> Regards. > >>>>>> Alexei > >>>>>> > >>>>>> From: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> > >>>>>> Sent: 21 October 2020 19:59 > >>>>>> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> > >>>>>> Cc: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>>; tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>>>> Subject: Re: [TF-A] BL31 as bootloader > >>>>>> > >>>>>> Alexei, > >>>>>> > >>>>>> I don't have a DS-5 debugger setup/licensed. I am hoping > >>>>>> on getting something shortly. > >>>>>> > >>>>>> Can you point me to the TFTF image that I can use to > >>>>>> test the BL33 handoff ? > >>>>>> > >>>>>> Sorry, I'm not familiar at this time. > >>>>>> > >>>>>> Regards > >>>>>> Ravi > >>>>>> > >>>>>> > >>>>>>> On Oct 21, 2020, at 12:35 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: > >>>>>>> > >>>>>>> You can also use TFTF image as BL33. > >>>>>>> > >>>>>>> Alexei > >>>>>>> > >>>>>>> From: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> > >>>>>>> Sent: 21 October 2020 15:26 > >>>>>>> To: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>>; Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> > >>>>>>> Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>>>>> Subject: Re: [TF-A] BL31 as bootloader > >>>>>>> > >>>>>>> The best way to figure out whether handing off to BL33 happened or not is by attaching a debugger(DS-5). > >>>>>>> > >>>>>>> is there any other A53 (or A72) test image (hello world like) I can validate with to further debug ? > >>>>>>> - You can use a linux image and device tree to test it > >>>>>>> Refer to plat/brcm/common/brcm_bl31_setup.c -> "brcm_bl31_early_platform_setup()" function > >>>>>>> For linux as BL33 payload please use coder under "ARM_LINUX_KERNEL_AS_BL33" > >>>>>>> > >>>>>>> > >>>>>>> From: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> > >>>>>>> Sent: 21 October 2020 12:12 > >>>>>>> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> > >>>>>>> Cc: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>>; tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>>>>> Subject: Re: [TF-A] BL31 as bootloader > >>>>>>> > >>>>>>> Hi Alexei, Manish, > >>>>>>> > >>>>>>> I tried the following patch to plat/imx/imx8qm/imx8qm_bl31_setup.c: > >>>>>>>> @@ -483,11 +486,15 @@ void bl31_early_platform_setup2(u_register_t arg0, u_register_t arg1, > >>>>>>>> bl32_image_ep_info.args.arg3 = BL32_FDT_OVERLAY_ADDR; > >>>>>>>> #endif > >>>>>>>> #endif > >>>>>>>> + // DEBUG ONLY - FIXME > >>>>>>>> + SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); > >>>>>>>> + > >>>>>>>> SET_SECURITY_STATE(bl33_image_ep_info.h.attr, NON_SECURE); > >>>>>>>> > >>>>>>>> /* init the first cluster's cci slave interface */ > >>>>>>>> cci_init(PLAT_CCI_BASE, imx8qm_cci_map, PLATFORM_CLUSTER_COUNT); > >>>>>>>> cci_enable_snoop_dvm_reqs(MPIDR_AFFLVL1_VAL(read_mpidr_el1())); > >>>>>>>> + > >>>>>>>> } > >>>>>>> But no luck. > >>>>>>> > >>>>>>> Is there some way to confirm my bl31.bin is handing off to any BL33 (normal world) test image ? > >>>>>>> In other words, is there any other A53 (or A72) test image (hello world like) I can validate with to further debug ? > >>>>>>>> > >>>>>>> Thanks. > >>>>>>> > >>>>>>> > >>>>>>>> On Oct 21, 2020, at 6:10 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: > >>>>>>>> > >>>>>>>> Hi Ravi, > >>>>>>>> > >>>>>>>> You can take a look at arm_bl31_early_platform_setup() in plat\arm\common\arm_bl31_setup.c: > >>>>>>>> > >>>>>>>> /* Populate entry point information for BL33 */ > >>>>>>>> SET_PARAM_HEAD(&bl33_image_ep_info, > >>>>>>>> PARAM_EP, > >>>>>>>> VERSION_1, > >>>>>>>> 0); > >>>>>>>> /* > >>>>>>>> * Tell BL31 where the non-trusted software image > >>>>>>>> * is located and the entry state information > >>>>>>>> */ > >>>>>>>> bl33_image_ep_info.pc = plat_get_ns_image_entrypoint(); > >>>>>>>> > >>>>>>>> bl33_image_ep_info.spsr = arm_get_spsr_for_bl33_entry(); > >>>>>>>> SET_SECURITY_STATE(bl33_image_ep_info.h.attr, NON_SECURE); > >>>>>>>> > >>>>>>>> Regards. > >>>>>>>> Alexei > >>>>>>>> > >>>>>>>> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>>>>>> Sent: 21 October 2020 10:57 > >>>>>>>> To: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> > >>>>>>>> Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>>>>>> Subject: Re: [TF-A] BL31 as bootloader > >>>>>>>> > >>>>>>>> Hi Manish, > >>>>>>>> > >>>>>>>> The test image should not have any dependency on device tree (dtb?) > >>>>>>>> for console init. > >>>>>>>> I used the NXP provided imx8qm-mek-ca53.dtb file which should match > >>>>>>>> the MEK board. > >>>>>>>> I have tested removing "--data imx8qm-mek-ca53.dtb 0x83000000" (below) > >>>>>>>> as well but no luck. > >>>>>>>> I don't believe PC is getting set to the 0x80020000 entry point. > >>>>>>>> > >>>>>>>> The test image has validated with u-boot using these tftpboot settings: > >>>>>>>> setenv ipaddr x.x.x.x > >>>>>>>> setenv serverip x.x.x.x > >>>>>>>> tftpboot 0xf0000000 App.bin > >>>>>>>> bootm 0xf0000000 > >>>>>>>> > >>>>>>>> I don't see any console output on the screen running it with bl31.bin as below. > >>>>>>>> Is there any debug I can add somewhere to help troubleshoot? > >>>>>>>> > >>>>>>>> Can you please provide me instructions on where to patch this missing code : > >>>>>>>> "SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0);" > >>>>>>>> I can try it to see if any change in behavior. > >>>>>>>> > >>>>>>>> Thanks in advance. > >>>>>>>> Regards > >>>>>>>> Ravi > >>>>>>>> > >>>>>>>> > >>>>>>>> On Wed, Oct 21, 2020 at 5:15 AM Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> wrote: > >>>>>>>> > > >>>>>>>> > Hi Ravi, > >>>>>>>> > > >>>>>>>> > Can you please confirm if control reached "test image" ? I guess, yes, as PC has right value. > >>>>>>>> > Also, does your "test image" depends on device tree for console initialization? > >>>>>>>> > > >>>>>>>> > One thing i see missing in "plat/imx/imx8qm/imx8qm_bl31_setup.c +352" is bl33 header initialization > >>>>>>>> > SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); > >>>>>>>> > > >>>>>>>> > thanks > >>>>>>>> > Manish > >>>>>>>> > > >>>>>>>> > ________________________________ > >>>>>>>> > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>>>>>> > Sent: 21 October 2020 00:10 > >>>>>>>> > To: Ravi Kohli <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> > >>>>>>>> > Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>>>>>> > Subject: Re: [TF-A] BL31 as bootloader > >>>>>>>> > > >>>>>>>> > Hi Alexei, > >>>>>>>> > > >>>>>>>> > I built my TF-A (imx-atf) b31.bin image using the RESET_TO_BL31 build option for the i.MX8QM MEK dev kit. > >>>>>>>> > > >>>>>>>> > make DEBUG=1 RESET_TO_BL31=1 PLAT=imx8qm bl31 > >>>>>>>> > > >>>>>>>> > I used the imx-mkimage tool to generate a flash.bin (flash bootable image) with the following target to run on the MEK: > >>>>>>>> > > >>>>>>>> > flash_cortex_a53: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin MyA53Serial.bin imx8qm-mek-ca53.dtb > >>>>>>>> > ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -c -p3 -ap MyA53Serial.bin a53 0x80020000 -p4 --data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin > >>>>>>>> > > >>>>>>>> > Here, I allocated bl31.bin to boot from 0x80000000 and a test image at BL33 (normal world) entry point 0x80020000 (both for Cortex-A53). > >>>>>>>> > I can see DEBUG console output from the bl31.bin image but no serial output from my test image I am trying to boot from 0x80020000. > >>>>>>>> > > >>>>>>>> > NOTICE: Memreg 3 0x38000000 -- 0x3bffffff > >>>>>>>> > NOTICE: Memreg 4 0x60000000 -- 0x6fffffff > >>>>>>>> > NOTICE: Memreg 5 0x70000000 -- 0x7fffffff > >>>>>>>> > NOTICE: Memreg 6 0x80000000 -- 0xffffffff > >>>>>>>> > NOTICE: Memreg 7 0x400000000 -- 0x43fffffff > >>>>>>>> > NOTICE: Memreg 8 0x880000000 -- 0x97fffffff > >>>>>>>> > NOTICE: Non-secure Partitioning Succeeded > >>>>>>>> > NOTICE: BL31: v2.2(debug):imx_5.4.24_er3-1-g06450210f-dirty > >>>>>>>> > NOTICE: BL31: Built : 17:33:32, Oct 20 2020 > >>>>>>>> > INFO: bl31_platform_setup is called > >>>>>>>> > INFO: GICv3 with legacy support detected. ARM GICv3 driver initialized in EL3 > >>>>>>>> > INFO: BL31: Initializing runtime services > >>>>>>>> > INFO: BL31: cortex_a53: CPU workaround for 855873 was applied > >>>>>>>> > INFO: BL31: Preparing for EL3 exit to normal world > >>>>>>>> > INFO: Entry point address = 0x80020000 > >>>>>>>> > INFO: SPSR = 0x3c9 > >>>>>>>> > INFO: BL31: DEBUG: image_type is: normal > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > Can anyone please suggest what could be the issue here that I don't see the test image console output ? > >>>>>>>> > Note, the same test image works fine using u-boot. > >>>>>>>> > > >>>>>>>> > Regards > >>>>>>>> > Ravi > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > On Oct 7, 2020, at 12:43 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> wrote: > >>>>>>>> > > >>>>>>>> > Hi Alexei, > >>>>>>>> > > >>>>>>>> > Thanks for your reply. I have not verified the RESET_TO_BL1 for imx8qm yet. > >>>>>>>> > I will try it out and confirm. And, thanks for this suggestion. > >>>>>>>> > > >>>>>>>> > Regards > >>>>>>>> > Ravi > >>>>>>>> > > >>>>>>>> > On Oct 7, 2020, at 12:12 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: > >>>>>>>> > > >>>>>>>> > Hi Ravi, > >>>>>>>> > > >>>>>>>> > Have you tried to use RESET_TO_BL31 build option for your platform? > >>>>>>>> > > >>>>>>>> > Regards. > >>>>>>>> > Alexei > >>>>>>>> > ________________________________ > >>>>>>>> > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>>>>>> > Sent: 07 October 2020 17:01 > >>>>>>>> > To: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>>>>>> > Subject: [TF-A] BL31 as bootloader > >>>>>>>> > > >>>>>>>> > Hi, > >>>>>>>> > I'm a new user and sorry for some basic TF-A questions. Any guidance is appreciated. > >>>>>>>> > > >>>>>>>> > I'm am able boot the TF-A bl31.bin image itself on my i.MX8QM MEK platform without using u-boot. > >>>>>>>> > I can use the imx-mkimage tool to create a flash or eMMC bootable image (flash.bin). Here, I can > >>>>>>>> > specify this container image with both bl31.bin and a separate custom app at a give flash address. > >>>>>>>> > This is without any security requirements or dependencies. > >>>>>>>> > > >>>>>>>> > Can I use the T-FA bl31.bin image to act as a first stage bootloader (without u-boot) and then launch > >>>>>>>> > a "custom" bare metal app for Cortex-A53 (for example) on the i.MX8QM at the given (BL33) entry point > >>>>>>>> > 0x80020000 address ? > >>>>>>>> > > >>>>>>>> > Thanks in advance. > >>>>>>>> > Ravi > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > -- > >>>>>>>> > TF-A mailing list > >>>>>>>> > TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> > >>>>>>>> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > -- > >>>>>>>> > TF-A mailing list > >>>>>>>> > TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> > >>>>>>>> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> > >>>>>>>> > > >>>>>>>> > > >>>>>>>> -- > >>>>>>>> TF-A mailing list > >>>>>>>> TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> > >>>>>>>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> > >>>>> > >>>>> > >>>>> -- > >>>>> TF-A mailing list > >>>>> TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> > >>>>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> > >>> > >>> -- > >>> TF-A mailing list > >>> TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> > >>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years

1
0
0 0

Re: [TF-A] BL31 as bootloader

by Alexei Fedorov

Hi Ravi As you can see in debugger that memory at 0x80020000 address is populated correctly, can you set a breakpoint at it to check if execuion reaches it? If you cannot set a breakpoint I would suggest to add a few assembler instructions in the start of your BL33 entry point to write any specific character, e.g. '!' to debug UART data port and branch to the next instruction in an infinite loop with "b .". Seeing ! char on debug console would prove that control to BL33 image has been passed. Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 24 October 2020 22:48 To: Ravi Kohli <rkohli2000(a)gmail.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] BL31 as bootloader Hi Alexei, Manish, I instrumented the imx8QM platform code and saw normal execution with bl31_main() exiting normally with entry point for my BL33 image. But, I haven't seen the handoff work yet. Can you suggest what else I can try to debug this ? I have an image copied at 0x80020000 from what I can see in the debugger. Thanks in advance. Regards Ravi On Fri, Oct 23, 2020 at 3:43 PM rkohli2000 gmail <rkohli2000(a)gmail.com<mailto:rkohli2000@gmail.com>> wrote: Hi Manish, I have been able to copy the test app (BL33) to entry point address 0x80020000. I confirmed from the Debugger that RAM address 0x80020000 is populated. I had to modify imx-atf makefile target to use the "-data" option as follows: flash_test_8: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin App.bin imx8qm-mek-ca53.dtb ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -data App.bin 0x80020000 -data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin The -data option appears to copy the image at the 0x80020000 address. Now, I think we should be able to handoff since PC (program counter) is set : bl33_image_ep_info.pc = plat_get_ns_image_entrypoint(); I don't see any serial console output using an image that works when using u-boot. I am not using u-boot for certification reasons. Is there some way I can confirm that the handoff is happening from bl31.bin to the App.bin ? At which BL31 function or module does the handoff occur ? I don't see my HW breakpoint trigger at location location 0x80020000. Regards Ravi On Oct 23, 2020, at 9:25 AM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> wrote: Hi Manish, Can you please point me to any example or a BL2 module which does the copy to RAM from Flash ? Maybe I can try to copy the image to 0x80020000 before exiting BL31 from bl31_main(). The bl31.bin image boot fine on the target board (imx8qm) from location 0x80000000 to start with. That copy to 0x80000000 must happen as well. I'm not sure where assuming its some NXP firmware doing it. Do you know where it could be ? Regards Ravi On Oct 23, 2020, at 4:46 AM, Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> wrote: Hi Ravi, This is normal behaviour when you RESET_TO_BL31. The loading of images (from flash to RAM) is part of BL2 code and in case of directly jumping to BL31, you need a mechanism to Load these images at proper location. Some platforms have a separate firmware which does this before starting execution of BL31, so that when BL31 hands over to BL33 it gets valid image there. thanks Manish ________________________________ From: rkohli2000 gmail <rkohli2000(a)gmail.com<mailto:rkohli2000@gmail.com>> Sent: 23 October 2020 05:08 To: Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>>; Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> Cc: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: Re: [TF-A] BL31 as bootloader Hi Alexei, Manish, I repeated the test (below) a few times and see the same result. (1) Do I need to copy my BL33 (non-secure) image from flash.bin some how to RAM 0x80020000 entry point address ? Is there any example of how to copy the flash.bin image ? I not sure what address or where to copy it from. (2) Is there some existing debug code that I can use to dump/print the ARMv8 RAM address space from inside BL31.bin ? I only found some TF-A tf_log macros in debug.h. I would like to dump some memory address contents (like 0x80020000) from inside bl31.bin to console just for debugging at run-time. On Oct 22, 2020, at 4:28 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> wrote: Hi Alexei, I captured the LOG_LEVEL=50 log (attached putty-ser0.log<https://www.dropbox.com/s/bi3hngmljksxl3a/putty-ser0.log?dl=0>) from TF-A bl31.bin. I see bl31 boots normally but never hands off to the BL33 normal world image (App.bin) The flash.bin image I am running is constructed using imx-mkimage<https://source.codeaurora.org/external/imx/imx-mkimage/tree/README?h=imx_4.…> tool with the following target: flash_test_7: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin App.bin imx8qm-mek-ca53.dtb ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c -flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -p3 -ap App.bin a53 0x80020000 -data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin I used UUU tool to flash eMMC with flash.bin on the imx8QM MEK board. I inspected RAM using a trace32 debugger SW after using a while (1) to halt the execution at the end of bl31.bin main function (bl31_main()). diff --git a/bl31/bl31_main.c b/bl31/bl31_main.c index 92a2027dd..51afb13ea 100644 --- a/bl31/bl31_main.c +++ b/bl31/bl31_main.c @@ -147,6 +147,11 @@ void bl31_main(void) * from BL31 */ bl31_plat_runtime_setup(); + + INFO("BL31: leaving bl31_main\n"); + INFO("entering while(1)\n"); + + while (1) {}; } It appears that there's no data or image at 0x80020000 just before exiting bl31_main(). See the debugger RAM dump at address 0x80000000 (bl31.bin entry point) and 0x80020000 (BL33 or App.bin normal world app entry point). See the debugger output<https://www.dropbox.com/s/revv4qev2ky5djj/ksnip_20201022-153339.png?dl=0>. When should the flash image provided in flash.bin get copied to the RAM entry point 0x80020000 ? Should bl31.bin copy the image from flash to RAM ? Can you suggest what could be going on ? Regards Ravi On Oct 22, 2020, at 6:15 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> wrote: Hi Ravi, TFTF image can be built from https://git.trustedfirmware.org/TF-A/tf-a-tests.git You can also try to increase TF-A log level by setting LOG_LEVEL=50 and check if BL33 memory region is mapped correctly. Before passing control to BL33 and could add code to dump initial memory at BL33 start address to see if the image was loaded with no issues. Regards. Alexei ________________________________ From: rkohli2000 gmail <rkohli2000(a)gmail.com<mailto:rkohli2000@gmail.com>> Sent: 21 October 2020 19:59 To: Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> Cc: Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>>; tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: Re: [TF-A] BL31 as bootloader Alexei, I don't have a DS-5 debugger setup/licensed. I am hoping on getting something shortly. Can you point me to the TFTF image that I can use to test the BL33 handoff ? Sorry, I'm not familiar at this time. Regards Ravi On Oct 21, 2020, at 12:35 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> wrote: You can also use TFTF image as BL33. Alexei ________________________________ From: Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> Sent: 21 October 2020 15:26 To: rkohli2000 gmail <rkohli2000(a)gmail.com<mailto:rkohli2000@gmail.com>>; Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> Cc: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: Re: [TF-A] BL31 as bootloader The best way to figure out whether handing off to BL33 happened or not is by attaching a debugger(DS-5). is there any other A53 (or A72) test image (hello world like) I can validate with to further debug ? - You can use a linux image and device tree to test it Refer to plat/brcm/common/brcm_bl31_setup.c -> "brcm_bl31_early_platform_setup()" function For linux as BL33 payload please use coder under "ARM_LINUX_KERNEL_AS_BL33" ________________________________ From: rkohli2000 gmail <rkohli2000(a)gmail.com<mailto:rkohli2000@gmail.com>> Sent: 21 October 2020 12:12 To: Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> Cc: Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>>; tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: Re: [TF-A] BL31 as bootloader Hi Alexei, Manish, I tried the following patch to plat/imx/imx8qm/imx8qm_bl31_setup.c: @@ -483,11 +486,15 @@ void bl31_early_platform_setup2(u_register_t arg0, u_register_t arg1, bl32_image_ep_info.args.arg3 = BL32_FDT_OVERLAY_ADDR; #endif #endif + // DEBUG ONLY - FIXME + SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); + SET_SECURITY_STATE(bl33_image_ep_info.h.attr, NON_SECURE); /* init the first cluster's cci slave interface */ cci_init(PLAT_CCI_BASE, imx8qm_cci_map, PLATFORM_CLUSTER_COUNT); cci_enable_snoop_dvm_reqs(MPIDR_AFFLVL1_VAL(read_mpidr_el1())); + } But no luck. Is there some way to confirm my bl31.bin is handing off to any BL33 (normal world) test image ? In other words, is there any other A53 (or A72) test image (hello world like) I can validate with to further debug ? Thanks. On Oct 21, 2020, at 6:10 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> wrote: Hi Ravi, You can take a look at arm_bl31_early_platform_setup() in plat\arm\common\arm_bl31_setup.c: /* Populate entry point information for BL33 */ SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); /* * Tell BL31 where the non-trusted software image * is located and the entry state information */ bl33_image_ep_info.pc = plat_get_ns_image_entrypoint(); bl33_image_ep_info.spsr = arm_get_spsr_for_bl33_entry(); SET_SECURITY_STATE(bl33_image_ep_info.h.attr, NON_SECURE); Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Sent: 21 October 2020 10:57 To: Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> Cc: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: Re: [TF-A] BL31 as bootloader Hi Manish, The test image should not have any dependency on device tree (dtb?) for console init. I used the NXP provided imx8qm-mek-ca53.dtb file which should match the MEK board. I have tested removing "--data imx8qm-mek-ca53.dtb 0x83000000" (below) as well but no luck. I don't believe PC is getting set to the 0x80020000 entry point. The test image has validated with u-boot using these tftpboot settings: setenv ipaddr x.x.x.x setenv serverip x.x.x.x tftpboot 0xf0000000 App.bin bootm 0xf0000000 I don't see any console output on the screen running it with bl31.bin as below. Is there any debug I can add somewhere to help troubleshoot? Can you please provide me instructions on where to patch this missing code : "SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0);" I can try it to see if any change in behavior. Thanks in advance. Regards Ravi On Wed, Oct 21, 2020 at 5:15 AM Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> wrote: > > Hi Ravi, > > Can you please confirm if control reached "test image" ? I guess, yes, as PC has right value. > Also, does your "test image" depends on device tree for console initialization? > > One thing i see missing in "plat/imx/imx8qm/imx8qm_bl31_setup.c +352" is bl33 header initialization > SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); > > thanks > Manish > > ________________________________ > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> > Sent: 21 October 2020 00:10 > To: Ravi Kohli <rkohli2000(a)gmail.com<mailto:rkohli2000@gmail.com>> > Cc: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> > Subject: Re: [TF-A] BL31 as bootloader > > Hi Alexei, > > I built my TF-A (imx-atf) b31.bin image using the RESET_TO_BL31 build option for the i.MX8QM MEK dev kit. > > make DEBUG=1 RESET_TO_BL31=1 PLAT=imx8qm bl31 > > I used the imx-mkimage tool to generate a flash.bin (flash bootable image) with the following target to run on the MEK: > > flash_cortex_a53: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin MyA53Serial.bin imx8qm-mek-ca53.dtb > ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -c -p3 -ap MyA53Serial.bin a53 0x80020000 -p4 --data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin > > Here, I allocated bl31.bin to boot from 0x80000000 and a test image at BL33 (normal world) entry point 0x80020000 (both for Cortex-A53). > I can see DEBUG console output from the bl31.bin image but no serial output from my test image I am trying to boot from 0x80020000. > > NOTICE: Memreg 3 0x38000000 -- 0x3bffffff > NOTICE: Memreg 4 0x60000000 -- 0x6fffffff > NOTICE: Memreg 5 0x70000000 -- 0x7fffffff > NOTICE: Memreg 6 0x80000000 -- 0xffffffff > NOTICE: Memreg 7 0x400000000 -- 0x43fffffff > NOTICE: Memreg 8 0x880000000 -- 0x97fffffff > NOTICE: Non-secure Partitioning Succeeded > NOTICE: BL31: v2.2(debug):imx_5.4.24_er3-1-g06450210f-dirty > NOTICE: BL31: Built : 17:33:32, Oct 20 2020 > INFO: bl31_platform_setup is called > INFO: GICv3 with legacy support detected. ARM GICv3 driver initialized in EL3 > INFO: BL31: Initializing runtime services > INFO: BL31: cortex_a53: CPU workaround for 855873 was applied > INFO: BL31: Preparing for EL3 exit to normal world > INFO: Entry point address = 0x80020000 > INFO: SPSR = 0x3c9 > INFO: BL31: DEBUG: image_type is: normal > > > Can anyone please suggest what could be the issue here that I don't see the test image console output ? > Note, the same test image works fine using u-boot. > > Regards > Ravi > > > On Oct 7, 2020, at 12:43 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> wrote: > > Hi Alexei, > > Thanks for your reply. I have not verified the RESET_TO_BL1 for imx8qm yet. > I will try it out and confirm. And, thanks for this suggestion. > > Regards > Ravi > > On Oct 7, 2020, at 12:12 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> wrote: > > Hi Ravi, > > Have you tried to use RESET_TO_BL31 build option for your platform? > > Regards. > Alexei > ________________________________ > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> > Sent: 07 October 2020 17:01 > To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> > Subject: [TF-A] BL31 as bootloader > > Hi, > I'm a new user and sorry for some basic TF-A questions. Any guidance is appreciated. > > I'm am able boot the TF-A bl31.bin image itself on my i.MX8QM MEK platform without using u-boot. > I can use the imx-mkimage tool to create a flash or eMMC bootable image (flash.bin). Here, I can > specify this container image with both bl31.bin and a separate custom app at a give flash address. > This is without any security requirements or dependencies. > > Can I use the T-FA bl31.bin image to act as a first stage bootloader (without u-boot) and then launch > a "custom" bare metal app for Cortex-A53 (for example) on the i.MX8QM at the given (BL33) entry point > 0x80020000 address ? > > Thanks in advance. > Ravi > > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > -- TF-A mailing list TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years

2
6
0 0

Re: [TF-A] Questions raised about Measured Boot + fTPM test case

by Alexei Fedorov

Hi Javer, Please see my comments below. [3] Provide platform hooks in tpm_record_measurement function for a platform to actually extend those measurements to a physical TPM right when they are measured. These hooks can be implemented in the next phase #2 of Measured Boot implementation. [4] On platforms that use FCONF, the FW_CONFIG and TB_FW_CONFIG should also be measured since they are images being loaded as well. See arm_bl1_setup.c where these images are loaded but not measured(unless I’m missing something). FW_CONFIG and TB_FW_CONFIG images are loaded by BL1 but not BL2. BL1 calculates BL2 hash and passes the measurement to BL2 in TB_FW_CONFIG. It can also pass FW_CONFIG hash in the same DTB, but it is not clear how own TB_FW_CONFIG hash can be passed in itself. Stuart, do you have opinion on that? Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Javier Almansa Sobrino via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 26 October 2020 10:25 To: raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Questions raised about Measured Boot + fTPM test case Hi Raghu, Thank you very much for your comments and for your feedback. With regards to the (f)TPM service and as discussed during the last TF-A Tech Forum call, we will discuss internally the need of a new implementation, probably after the next TF-A release, and we will schedule the work (in case we decide to go ahead with it) for the upcoming months. We will announce any decision we make through the mailing list and/or on future TF-A Tech Forum calls . Regarding to changes to TF-A to include extra functionality/APIs/hooks, I guess my colleague Alexei can provide further details about the next features planned for Measured Boot, if any. To finish, I would just like to clarify one of the questions raised on your email: [1] Would be good if the test infrastructure(the TPM TA) can compile in AARCH64. I thought I heard on the tf-a call that there already is a Microsoft FW TPM port for aarch64 already. Please let me know if I misunderstood. * Microsoft has a reference implementation of the TPM 2.0 specification. That implementation is in the form of an architecture agnostic library that implements the specification. Along with the library, there are a couple of example applications for different platforms built around the former, one of them being the fTPM we used for testing. That application was written for AARCH32 and seemed to be outdated (I don't know if it was abandoned, actually), so we updated it and added support for Measured Boot to it. Best regards, Javier -----Original Message----- From: raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com> To: 'Javier Almansa Sobrino' <Javier.AlmansaSobrino(a)arm.com<mailto:'Javier%20Almansa%20Sobrino'%20%3cJavier.AlmansaSobrino(a)arm.com%3e>> Cc: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Subject: RE: [TF-A] Questions raised about Measured Boot + fTPM test case Date: Sun, 25 Oct 2020 14:31:10 -0700 Hi Javier, As discussed during the TF-A call, here are some suggestions/feedback that can be incorporated when time permits based on priorities, schedule, resources etc: 1. Would be good if the test infrastructure(the TPM TA) can compile in AARCH64. I thought I heard on the tf-a call that there already is a Microsoft FW TPM port for aarch64 already. Please let me know if I misunderstood. 2. Would be good if the TPM TA works on FF-A as opposed to proprietary OPTEE API’s. 3. Provide platform hooks in tpm_record_measurement function for a platform to actually extend those measurements to a physical TPM right when they are measured. This is a requirement from a security perspective to not wait until the tpm TA is loaded to be able to extend the measurements into a tpm. I understand this can be done in the platform hook that calls tpm_record_measurement but it is convenient place to put tpm related platform hooks. 4. On platforms that use FCONF, the FW_CONFIG and TB_FW_CONFIG should also be measured since they are images being loaded as well. See arm_bl1_setup.c where these images are loaded but not measured(unless I’m missing something). Thanks Raghu From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Javier Almansa Sobrino via TF-A Sent: Friday, October 9, 2020 10:51 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Questions raised about Measured Boot + fTPM test case Hello all, Following up the question raised yesterday during the TF-A Tech Forum with regards to any modification needed on the Linux Kernel to run the test case that I was presenting (Measured Boot + fTPM service), I double checked today and I ran some tests on system and I can confirm that the test case works with the mainline Linux Kernel, with no modification other than enabling the driver on the DTB. The modules involved on the interaction with the fTPM (for this particular example) are: * optee.ko: Allows communication between the REE (unsecure world), the Trusted OS (secure world) and the tee-supplicant (unsecure world). * tpm_ftpm_tee.ko: Module to communicate with a firmware TPM through a char device. This also includes the reference implementation used on the test case. In order to use the fTPM service, the test case makes use of IBM's TPM 2.0 TSS, a user space TSS for TPM 2.0 that uses services provided by the fTPM. I would also like to highlight the following points: A) The test case is only meant to test the ability of the Measured Boot Driver and a TPM 2.0 compliant device to interact with each other. As such, we are not providing an fTPM meant to be used on a production environment. Instead, we are using an existing reference implementation to which we added support for Measured Boot to fulfil our needs for the test and use it as a functional example. The implementation details on how to interact with a particular TPM device (either firmware or discrete) can differ from the ones used on the test case as those details can be platform dependent. For example, we use an OPTEE TA fTPM on this example, but other platforms might use a discrete TPM or an fTPM running on a different Trusted OS. B) As stated on the presentation, we are undergoing internal review of the contributions done for the fTPM service to make it compatible with Measured Boot. Once the review is completed and the changes merged into the TPM repo mainline, we will update the TF-A documentation with instructions on how to download and build all the components to run the tests manually. Please, let me know in case you have any more questions. Best regards, Javier

5 years

2
1
0 0

Re: [TF-A] Questions raised about Measured Boot + fTPM test case

by raghu.ncstate＠icloud.com

Hi Javier, As discussed during the TF-A call, here are some suggestions/feedback that can be incorporated when time permits based on priorities, schedule, resources etc: 1. Would be good if the test infrastructure(the TPM TA) can compile in AARCH64. I thought I heard on the tf-a call that there already is a Microsoft FW TPM port for aarch64 already. Please let me know if I misunderstood. 2. Would be good if the TPM TA works on FF-A as opposed to proprietary OPTEE API’s. 3. Provide platform hooks in tpm_record_measurement function for a platform to actually extend those measurements to a physical TPM right when they are measured. This is a requirement from a security perspective to not wait until the tpm TA is loaded to be able to extend the measurements into a tpm. I understand this can be done in the platform hook that calls tpm_record_measurement but it is convenient place to put tpm related platform hooks. 4. On platforms that use FCONF, the FW_CONFIG and TB_FW_CONFIG should also be measured since they are images being loaded as well. See arm_bl1_setup.c where these images are loaded but not measured(unless I’m missing something). Thanks Raghu From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Javier Almansa Sobrino via TF-A Sent: Friday, October 9, 2020 10:51 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Questions raised about Measured Boot + fTPM test case Hello all, Following up the question raised yesterday during the TF-A Tech Forum with regards to any modification needed on the Linux Kernel to run the test case that I was presenting (Measured Boot + fTPM service), I double checked today and I ran some tests on system and I can confirm that the test case works with the mainline Linux Kernel, with no modification other than enabling the driver on the DTB. The modules involved on the interaction with the fTPM (for this particular example) are: * optee.ko: Allows communication between the REE (unsecure world), the Trusted OS (secure world) and the tee-supplicant (unsecure world). * tpm_ftpm_tee.ko: Module to communicate with a firmware TPM through a char device. This also includes the reference implementation used on the test case. In order to use the fTPM service, the test case makes use of IBM's TPM 2.0 TSS, a user space TSS for TPM 2.0 that uses services provided by the fTPM. I would also like to highlight the following points: A) The test case is only meant to test the ability of the Measured Boot Driver and a TPM 2.0 compliant device to interact with each other. As such, we are not providing an fTPM meant to be used on a production environment. Instead, we are using an existing reference implementation to which we added support for Measured Boot to fulfil our needs for the test and use it as a functional example. The implementation details on how to interact with a particular TPM device (either firmware or discrete) can differ from the ones used on the test case as those details can be platform dependent. For example, we use an OPTEE TA fTPM on this example, but other platforms might use a discrete TPM or an fTPM running on a different Trusted OS. B) As stated on the presentation, we are undergoing internal review of the contributions done for the fTPM service to make it compatible with Measured Boot. Once the review is completed and the changes merged into the TPM repo mainline, we will update the TF-A documentation with instructions on how to download and build all the components to run the tests manually. Please, let me know in case you have any more questions. Best regards, Javier

5 years

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A