TF-A May 2023

tf-a@lists.trustedfirmware.org

8 participants
14 discussions

[RFC] Common API to retrieve pre-allocated share memory for Transfer List

by Raymond Mao

Hi, I am currently doing research to implement the Transfer List to comply with Arm's firmware handoff spec ( https://github.com/FirmwareHandoff/firmware_handoff) in order to have a standardized handoff approach between different firmware stages during boot. The idea is to create a Transfer List in BL2 and cache it into a pre-allocated memory in SRAM that can be shared between BL2 and BL3x. A prototype currently available is creating APIs under qemu platform code to retrieve the pre-defined memory address (The shared memory region is defined in platform_def.h). But I think we need to define a common API for this purpose to support all platforms. Please share your views or any suggestions. Thanks. Regards, Raymond

11 months, 4 weeks

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 384887: Uninitialized variables (UNINIT) /mbedtls/library/x509.c: 1396 in mbedtls_x509_parse_subject_alt_name() ________________________________________________________________________________________________________ *** CID 384887: Uninitialized variables (UNINIT) /mbedtls/library/x509.c: 1396 in mbedtls_x509_parse_subject_alt_name() 1390 if (ret != 0) { 1391 return ret; 1392 } 1393 1394 memset(san, 0, sizeof(mbedtls_x509_subject_alternative_name)); 1395 san->type = MBEDTLS_X509_SAN_OTHER_NAME; >>> CID 384887: Uninitialized variables (UNINIT) >>> Using uninitialized value "other_name". Field "other_name.type_id" is uninitialized when calling "memcpy". [Note: The source code implementation of the function has been overridden by a builtin model.] 1396 memcpy(&san->san.other_name, 1397 &other_name, sizeof(other_name)); 1398 1399 } 1400 break; 1401 /* ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

12 months

[RFC] Proposed location to host the firmware handoff specification.

by Jose Marinho

Hi, Arm worked to draft a firmware handoff [1] specification, evolving it based on community feedback. This activity followed the request of some members of the Arm ecosystem [2]. The spec (still at ALP – feedback/comments welcome!) standardizes how information is propagated between different firmware components during boot. The spec hopes to remove the reliance on bespoke/platform-specific information handoff mechanisms, thus reducing the code maintenance burden. The concept of entry types is present in the spec – these are data structure layouts that carry a specific type of data. New types are meant to be added, following the needs and use-cases of the different communities. Thus, these communities should be empowered to request new types! To enable community contributions, the specification must be hosted in a location that is friendly to change requests. We propose to host the spec in trustedfirmware.org (tf.org). Tf.org hosts several open-source projects and already has an open governance model. TF-A, and the associated community, rely on tf.org, and thus are already well equipped to maintain this specification and keep it up to date. Tf.org is agnostic of any downstream projects that would adopt this specification (e.g. U-boot, EDK2, etc.). We welcome the views of the communities and want to understand if there are any strong objections to what’s being proposed! If anyone has objections, we are happy to consider alternatives and associated trade-offs. Regards [1] https://developer.arm.com/documentation/den0135/latest [2] Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages - TF-A - lists.trustedfirmware.org<https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…>

12 months

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

by joanna.farley＠arm.com

This event has been canceled. TF-A Tech Forum Thursday May 4, 2023 ⋅ 4pm – 5pm United Kingdom Time 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   Guests 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 email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

1 year

2024

2023

2022

2021

2020

2019

2018

TF-A May 2023