- TF-A - lists.trustedfirmware.org

by Jens Wiklander

Hi, The recent patch [1] for the OP-TEE Dispatcher in TF-A proposes a way of post-boot loading OP-TEE by the Linux kernel with signature verification in the normal world only. This has previously been discussed in this mail thread [2] about half a year ago. Ultimately, it was concluded that this should in principle be accepted upstream as a platform choice to allow this or not. There are concerns that what we have in upstream TF-A should serve as good examples, and trusting the normal world to verify secure world software might not meet that criterion. There are also concerns about adding signature verification to BL31 Leaving the secure world wide open until the Linux kernel has been able to successfully load and verify an OP-TEE binary seems very risky. Even if it's claimed that the normal world can be trusted at this point, we're still giving up a critical level of defense without a good reason. I've started to review [1], but it should not be accepted for merging without support and approval from other maintainers. I would like to explore other options in this mail thread. In [2] it was suggested that a remnant of bl2 could be kept to verify OP-TEE before starting to execute it. This could be taken one step further and load a limited OP-TEE at boot which later is updated live, almost like what's discussed in [3]. This should minimize the impact on TF-A and also leave OP-TEE in charge of accepting an update instead of a divided responsibility between the normal world and TF-A. [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/18635 [2] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… [3] https://github.com/OP-TEE/optee_os/issues/5699 Thanks, Jens

3 years, 1 month

3
3
0 0

New vulnerability: Out-of-bounds read in TF-A X.509 parser

by Sandrine Bailleux

Hello everyone, A new security vulnerability has been identified in TF-A X.509 parser, used for trusted boot in BL1 and BL2. Please note that this vulnerability is *not* exploitable in TF-A upstream code. Only downstream code might be affected under specific circumstances. The security advisory has been published in TF-A documentation and has all the details: https://trustedfirmware-a.readthedocs.io/en/latest/security_advisories/secu… Patches to fix the identified bugs have already been merged in TF-A tree. The advisory lists the relevant patches. I would like to thank Demi Marie Obenour from Invisible Things Lab for responsibly disclosing this security vulnerability to TrustedFirmware.org, for providing patches to fix the identified bugs and further harden the X.509 parser, for providing a detailed impact analysis and for helping put this security advisory together. Best regards, Sandrine Bailleux, on behalf of TF-A security team.

3 years, 1 month

1
0
0 0

Updated invitation with note: TF-A Tech Forum @ Thu Jan 26, 2023 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated with a note: "Correcting the deletion of the wrong Techforum." Changed: time TF-A Tech Forum Thursday Jan 26, 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 View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Reply for tf-a(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Your attendance is optional. ~~//~~ 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

3 years, 1 month

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Jan 26, 2023 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been canceled with a note: "No topic this week. Cancelling. Joanna" TF-A Tech Forum Thursday Jan 26, 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

3 years, 1 month

1
0
0 0

TF-A Tech Forum Sessions Jan/Feb

by Joanna Farley

Hi all, With the start of the new year I’m looking to see what TF-A Techforums should cover over the next few sessions. As folks may know these are held every two weeks on a Thursday at 4pm GMT. If you need an invite do reach out to me. If folks have anything they would like to present to the TF-A community please do reach out to me as we often need topics. If we don’t have anything to present on upcoming sessions I will cancel the sessions the day before they are due to be held. Currently I tentatively have the following for the first 4 sessions which will be confirmed nearer the dates: * 12th January – No topic * 26th January – LTS Update * 9th February – No topic * 23rd February - Tech talk for PSCI OS-initiated mode Thanks Joanna

3 years, 1 month

1
2
0 0

Runtime loading of SEL-1

by Jeffrey Kardatzke

Hello, I'm working on a project for ChromeOS where we would like to be able to load the BL32 payload (OpTee) for SEL-1 after the linux kernel has booted rather than during the usual BL32 stage. We would do this via an SMC we would add which would take the OpTee image from linux and then have EL3 load it and perform the init for SEL-1 at that time. The reasoning behind this is that it's much easier to update the rootfs than the FW on our devices, and we can still ensure the integrity of the OpTee image if we load it early enough after the kernel boots. The main questions I have are if there are any issues people would be aware of by loading it after linux boots rather than during the usual BL32 stage? And I would definitely want to upstream this work if it's something we can do. Thanks, Jeffrey Kardatzke Google, Inc.

3 years, 2 months

7
14
1 0

Question about using rme for smmuv3

by Chenxu Wang

Hi all, I test the SMMUv3 on FVP_Base_RevC-2xAEMvA_11.20_15, and my TF-A is the branch "arm_cca_v0.3". When I boot my FVP, I set the following commands: -C pci.pci_smmuv3.mmu.SMMU_ROOT_IDR0=3 \ -C pci.pci_smmuv3.mmu.SMMU_ROOT_IIDR=0x43B \ -C pci.pci_smmuv3.mmu.root_register_page_offset=0x20000 \ -C cluster0.rme_support_level=2 \ -C cluster1.rme_support_level=2 \ Based on the FVP manual, the SMMU base is 0x2b40_0000, and I think the SMMU Root Control Page should be 0x2b42_0000. Thus, I add the mapping to this region in plat_arm_mmap[], as: MAP_REGION_FLAT(0x2b420000,(0x2b430000-0x2b420000),MT_MEMORY | MT_RW |MT_ROOT) Then I try to access the SMMU_ROOT_IDR0 register in TF-A. Based on the manual, its offset is 0x0, so I read 0x2b42_0000. However, it returns 0x0, which is not what I configured in the boot commands (I think it should be 0x3). Can someone tell me the reason for this? Sincerely, WANG Chenxu

3 years, 2 months

2
3
0 0

TF-A Tech-Forum Agenda for Thursday 15-Dec-22 at 4pm BST

by Bipin Ravi

Topic: QEMU Support in TF-A OpenCI Presented by: Harrison Mutai Agenda: Following the recent addition of QEMU support in TF-A OpenCI [1], we'd like to: * Do a quick demo on how to navigate the OpenCI services (Jenkins, LAVA) and find the QEMU boot tests results. * Do a quick demo on how to run these tests on your local machine through TF-A CI scripts. * Give a high-level overview of the changes in TF-A CI scripts and OpenCI infrastructure that made this possible. [1] Supporting QEMU in OpenCI - TF-A - lists.trustedfirmware.org<https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…> ================================================= 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…> Thanks & best regards, --Bipin Ravi

3 years, 2 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 382272: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/xilinx/common/ipi_mailbox_service/ipi_mailbox_svc.c: 78 in ipi_smc_handler() ________________________________________________________________________________________________________ *** CID 382272: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/xilinx/common/ipi_mailbox_service/ipi_mailbox_svc.c: 78 in ipi_smc_handler() 72 uint32_t is_secure; 73 74 ipi_local_id = x1 & UNSIGNED32_MASK; 75 ipi_remote_id = x2 & UNSIGNED32_MASK; 76 77 if ((GET_SMC_OEN(smc_fid) >= OEN_TAP_START) && >>> CID 382272: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "((smc_fid >> 24U) & 0x3fU) <= 63U" is always true regardless of the values of its operands. This occurs as the logical second operand of "&&". 78 (GET_SMC_OEN(smc_fid) <= OEN_TOS_END)) { 79 is_secure = 1; 80 } else { 81 is_secure = 0; 82 } 83 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

3 years, 2 months

1
0
0 0

Upcoming "Stricter ASN.1 certificate parsing" patches

by Sandrine Bailleux

Hello everyone, I'd like to draw your attention on the following patch stack (contribution from Demi Marie Obenour, thank you!): https://review.trustedfirmware.org/q/owner:demiobenour%2540gmail.com+is:open These patches refactor the X.509 certificate parser leveraged by the trusted boot implementation in TF-A, such that the parser more closely follows the X.509 format specification [1] and ASN.1/DER encoding rules [2]. In a nutshell, this means that the X.509 parser is now stricter. Some ill-formatted certificates which TF-A would have previously accepted are now rejected. All trusted boot tests in the TF-A OpenCI have passed with these patches but I realize that this does not cover all platforms and use cases. Thus, I'd like to allow time for all platform maintainers that wish it to conduct their own testing and report any issue they're seeing on the mailing list. If we don't hear anything by end of Wednesday (14/12), we'll merge the patches. Best regards, Sandrine [1] See RFC5280, https://datatracker.ietf.org/doc/html/rfc5280 [2] ITU-T X.690, https://www.itu.int/ITU-T/studygroups/com10/languages/X.690_1297.pdf

3 years, 3 months

1
0
0 0

[PATCH 1/1] plat/qemu: Improve aarch32 build support

by Rebecca Cran

While aarch32 isn't currently supported on qemu, platform.mk for both qemu and qemu_sbsa contain bugs that cause the build to fail earlier than it otherwise should. Correct usage of ${ARCH} and hardcoded aarch64 strings so that the correct files are built when ARCH=aarch32 is specified. Signed-off-by: Rebecca Cran <rebecca(a)quicinc.com> --- plat/qemu/qemu/platform.mk | 12 ++++++------ plat/qemu/qemu_sbsa/platform.mk | 2 +- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/plat/qemu/qemu/platform.mk b/plat/qemu/qemu/platform.mk index dfc5de2ce43a..7b69ff76f3d6 100644 --- a/plat/qemu/qemu/platform.mk +++ b/plat/qemu/qemu/platform.mk @@ -45,7 +45,7 @@ PLAT_INCLUDES := -Iinclude/plat/arm/common/ \ -Iinclude/common/tbbr ifeq (${ARM_ARCH_MAJOR},8) -PLAT_INCLUDES += -Iinclude/plat/arm/common/${ARCH} +PLAT_INCLUDES += -Iinclude/plat/arm/common/aarch64 endif PLAT_BL_COMMON_SOURCES := ${PLAT_QEMU_COMMON_PATH}/qemu_common.c \ @@ -138,11 +138,11 @@ BL1_SOURCES += drivers/io/io_semihosting.c \ ${PLAT_QEMU_COMMON_PATH}/qemu_bl1_setup.c ifeq (${ARM_ARCH_MAJOR},8) -BL1_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/cpus/aarch64/qemu_max.S \ +BL1_SOURCES += lib/cpus/${ARCH}/aem_generic.S \ + lib/cpus/${ARCH}/cortex_a53.S \ + lib/cpus/${ARCH}/cortex_a57.S \ + lib/cpus/${ARCH}/cortex_a72.S \ + lib/cpus/${ARCH}/qemu_max.S \ else BL1_SOURCES += lib/cpus/${ARCH}/cortex_a15.S diff --git a/plat/qemu/qemu_sbsa/platform.mk b/plat/qemu/qemu_sbsa/platform.mk index 5a6b1e11e812..05a66f81314f 100644 --- a/plat/qemu/qemu_sbsa/platform.mk +++ b/plat/qemu/qemu_sbsa/platform.mk @@ -30,7 +30,7 @@ PLAT_INCLUDES := -Iinclude/plat/arm/common/ \ -I${PLAT_QEMU_PATH}/include \ -Iinclude/common/tbbr -PLAT_INCLUDES += -Iinclude/plat/arm/common/${ARCH} +PLAT_INCLUDES += -Iinclude/plat/arm/common/aarch64 PLAT_BL_COMMON_SOURCES := ${PLAT_QEMU_COMMON_PATH}/qemu_common.c \ ${PLAT_QEMU_COMMON_PATH}/qemu_console.c \ -- 2.30.2

3 years, 3 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. 1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 2 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 1 of 1 defect(s) ** CID 382227: Error handling issues (CHECKED_RETURN) /plat/intel/soc/common/socfpga_sip_svc.c: 70 in intel_fpga_sdm_write_buffer() ________________________________________________________________________________________________________ *** CID 382227: Error handling issues (CHECKED_RETURN) /plat/intel/soc/common/socfpga_sip_svc.c: 70 in intel_fpga_sdm_write_buffer() 64 current_buffer %= FPGA_CONFIG_BUFFER_SIZE; 65 } else { 66 args[2] = bytes_per_block; 67 } 68 69 buffer->size_written += args[2]; >>> CID 382227: Error handling issues (CHECKED_RETURN) >>> Calling "mailbox_send_cmd_async" without checking return value (as is done elsewhere 9 out of 10 times). 70 mailbox_send_cmd_async(&send_id, MBOX_RECONFIG_DATA, args, 71 3U, CMD_INDIRECT); 72 73 buffer->subblocks_sent++; 74 max_blocks--; 75 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

3 years, 3 months

1
0
0 0

Trusted Services v1.0.0-beta release

by Gyorgy Szing

Hi all, We are pleased to announce that the Trusted Services project has made the first tagged public release, v1.0.0-beta. The release includes Trusted Services which can be deployed on Cortex-A devices to meet PSA Certified requirements. The release also includes necessary build and test infrastructure and documentation. The release includes: * PSA Crypto, Storage and Attestation Secure Partitions exposing the PSA Certified Functional APIs, the same APIs available today on Arm v8-M Cortex-M platforms via Trusted Firmware-M. * Additionally, UEFI SMM services are available through the SMM Gateway Secure Partition. * The services within the Secure Partitions can be invoked by applications for secure operations. * OP-TEE in 3.17 and later releases support Secure Partition Manager Core (SPMC). Details can be found here<https://developer.trustedfirmware.org/w/trusted-services/op-tee-spmc/>. This release was validated with OP-TEE v3.19 For more information, please refer to the following resources: * Change log and release notes: https://trusted-services.readthedocs.io/en/v1.0.0-beta/project/change-log.h… * Documentation: https://trusted-services.readthedocs.io/en/v1.0.0-beta/ * Source code: https://git.trustedfirmware.org/TS/trusted-services.git/tag/?h=v1.0.0-beta * Test results including information on the set-up tests were executed with: https://developer.trustedfirmware.org/w/trusted-services/test-reports/v1.0.… * Roadmap for future development: https://developer.trustedfirmware.org/w/trusted-services/roadmap If you have any questions or comments do not hesitate to contact us via the mailing list, or by dropping an email to Shebu.VargheseKuriakose(a)arm.com<mailto:Shebu.VargheseKuriakose@arm.com> or gyorgy.szing(a)arm.com<mailto:gyorgy.szing@arm.com>. Kind Regards György Szing

3 years, 3 months

1
0
0 0

Cancelled TF-A TechForum 1st December + update for 15th December

by Joanna Farley

Hi All, I’m cancelling the TF-A Techforum for this Thursday as we have no topic. However, we do plan a session for 15th December. Following the recent addition of QEMU support in TF-A OpenCI [1], we'd like to: Do a quick demo on how to navigate the OpenCI services (Jenkins, LAVA) and find the QEMU boot tests results. * Possibly do a quick demo on how to run these tests on your local machine through TF-A CI scripts. * Give a high-level overview of the changes in TF-A CI scripts and OpenCI infrastructure that made this possible.Following the recent addition of QEMU support in TF-A OpenCI [1], we'd like to: [1] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…<https://www.google.com/url?q=https://lists.trustedfirmware.org/archives/lis…> Joanna

3 years, 3 months

1
0
0 0

Updated invitation with note: TF-A Tech Forum @ Thu Dec 15, 2022 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated with a note: "Update for subject on 15th December TF-A Tech Forum" Changed: description TF-A Tech Forum Thursday Dec 15, 2022 ⋅ 4pm – 5pm United Kingdom Time NOTE this is for 15th December 2022Following the recent addition of QEMU support in TF-A OpenCI [1], we'd like to:Do a quick demo on how to navigate the OpenCI services (Jenkins, LAVA) and find the QEMU boot tests results.Possibly do a quick demo on how to run these tests on your local machine through TF-A CI scripts.Give a high-level overview of the changes in TF-A CI scripts and OpenCI infrastructure that made this possible.Following the recent addition of QEMU support in TF-A OpenCI [1], we'd like to:[1]  https://lists.trustedfirmware.org/archives/list/tf-a@list… 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 View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Reply for tf-a(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Your attendance is optional. ~~//~~ 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

3 years, 3 months

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Dec 1, 2022 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been canceled with a note: "No topics this week so cancelling. We do have a topic for 2 weeks time on 15th December." TF-A Tech Forum Thursday Dec 1, 2022 ⋅ 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

3 years, 3 months

1
0
0 0

[PATCH] fix(console): fix crash on spin_unlock with cache disabled

by Baruch Siach

Current code skips load of spinlock address when cache is disabled. The following call to spin_unlock stores into the random location that x0 points to. Move spinlock address load earlier so that x0 is always valid on spin_unlock call. Change-Id: Iac640289725dce2518f2fed483d7d36ca748ffe8 Signed-off-by: Baruch Siach <baruch(a)tkos.co.il> --- I'm posting this patch here since I have found no way to upload to review.trustedfirmware.org. I logged in via github, but I can not add SSH keys ("New SSH Key" grayed out), and "GENERATE NEW PASSWORD" shows Error 500. Hope this is not too wrong. --- plat/common/aarch64/crash_console_helpers.S | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/plat/common/aarch64/crash_console_helpers.S b/plat/common/aarch64/crash_console_helpers.S index e2950f5f7c55..75b420893325 100644 --- a/plat/common/aarch64/crash_console_helpers.S +++ b/plat/common/aarch64/crash_console_helpers.S @@ -68,12 +68,12 @@ func plat_crash_console_init mov x4, x30 /* x3 and x4 are not clobbered by spin_lock() */ mov x3, #0 /* return value */ + adrp x0, crash_console_spinlock + add x0, x0, :lo12:crash_console_spinlock + mrs x1, sctlr_el3 tst x1, #SCTLR_C_BIT beq skip_spinlock /* can't synchronize when cache disabled */ - - adrp x0, crash_console_spinlock - add x0, x0, :lo12:crash_console_spinlock bl spin_lock skip_spinlock: -- 2.35.1

3 years, 3 months

2
1
0 0

Supporting QEMU in OpenCI

by Harrison Mutai

Hello everyone, Following our recent release, I'm pleased to provide more details on recent developments in our CI for QEMU. Linaro’s continuous integration platform OpenCI supports running emulated tests on QEMU. The tests are kicked off on Jenkins and deployed through the Linaro Automation and Validation Architecture LAVA. The obvious benefit of this is it makes it relatively easy to test TF-A in CI without a complex hardware setup, much like we do with FVPs. For this reason, we have added scripts to our OpenCI scripts repository to enable running this form of automated tests on QEMU. The initial patches provide a set of end-to-end boot tests (TF-A -> Linux shell prompt) that are included in our daily job [1]. The long term plan is to use this and further QEMU tests to gate patch submission (CI +1, +2), however, this is will only happen when we have confidence in their stability. You can view a sample test run here [2]. You can also reproduce the test setup manually in OpenCI or locally. In OpenCI this is done by running the tf-a-builder job with `qemu-boot-tests` as the test group [3]. In your local setup, this is done with the following command line: ``` $ test_run=1 \ workspace=$(mktemp -d) \ nfs_volume="$workspace" tfa_downloads="https://downloads.trustedfirmware.org/tf-a" tf_root="/path/to/trusted-firmware-a/" \ tftf_root="/path/to/tf-a-tests/" \ test_groups="qemu-boot-tests/qemu-default:qemu-linux.rootfs-fip.uefi-virt" \ bash -x $ci_root/script/run_local_ci.sh ``` We highly encourage you to contribute to the QEMU CI scripts if you can! Whether that be helping extend the tests or providing enhancements. We are also looking for help maintaining this specific area and the infrastructure around it - if this of interest, please do reach out! Cheers! Harrison [1] https://ci.trustedfirmware.org/job/tf-a-main [2] https://tf.validation.linaro.org/scheduler/job/1168495 [3] https://ci.trustedfirmware.org/job/tf-a-builder/

3 years, 3 months

1
0
0 0

Re: 回复： building secure boot tf-a images without ROTK controlled by SW build engineer

by Neely, Brian

Hello, Just following up on my question regarding HSMs (pasted below). Do any of the maintainers of cert_create have feedback on this? Thanks! -Brian Just a quick follow-up on this question of using an HSM (or in general, some form of Key Management Infrastructure) to sign TF-A images. U-Boot has support for this with its mkimage utility (see https://github.com/u-boot/u-boot/blob/master/doc/uImage.FIT/signature.txt#L5...). This appears to a custom engine in OpenSSL (and in this case, the pkcs11 engine). My questions are: 1. Does TF-A’s cert_create tool support using custom OpenSSL engines? 2. If so, is there a procedure for using this? 3. If not, is there a plan to add support for this in the roadmap somewhere? * Or, in general, is there a plan to add HSM support for TF-A image signing?

3 years, 3 months

2
1
0 0

Trusted Firmware-A v2.8 Release Announcement

by Joanna Farley

We are pleased to announce the release of Trusted Firmware-A version 2.8 bundle of project deliverables. This includes Trusted Firmware-A version 2.8, Trusted Firmware-A Tests version 2.8, Hafnium version 2.8 and TF-A OpenCI Scripts/Jobs 2.8 Releases involving the tagging of multiple repositories. These went live on 21st November 2022. The repositories are now open again to take patches under review. On behalf of the TF-A project maintainers, I would like to thank all of the Trustedfirmware.org TF-A Project community for their efforts since the last release. Notable Features of the Version 2.8 Release across repositories are as follows: TF-A Project Repository * Architectural enablement (Arm v8.8 etc) * Added Branch Record Buffer Extension (FEAT_BRBE) * Added Pointer Authentication Extension helper support for QARMA3 (FEAT_PACQARMA3) * Partial support for trapping support for RNDR/RNDRRS (FEAT_RNG_TRAP) * Added Trace Buffer Extension (FEAT_TRBE) * Added SVE fall back if SME not available (FEAT_SME) * Support full SVE vector Length (FEAT_SVE) * Added support for DRTM (Dynamic Root of Trust Measurement ) * Hunter ELP CPU support added * Twenty Four (24) Errata Mitigations for Cortex-A710 , A510, X3, X2, A76, A77, A78C, Neoverse N1, N2, GIC-600 * Ethos-N Driver support for SMMU * Secure Payload Dispatcher added for ProvenCore RTOS * EL3 SPMC feature hardening * CCA Bootflow chain of trust support for AEM FVP * CCA RME development to support TF-RMM upstreaming Hafnium Project Repository * FF-A v1.1 EAC0 additions * Partition runtime model and CPU cycle allocation modes. * Interrupt handling and managed exit flows. * Memory sharing. * Framework notifications and indirect messaging. * Added FF-A console log ABI. * Added support for GICv3.1 extended INTID ranges. * Image footprint optimisation. * Improved SVE support and test coverage. * FF-A v1.0 ACS test suite integration in Open CI. TF-A Tests Project Repository * TF-A Tests support for 4 new platforms (N1SDP, RD-N2, RD-N2-Cfg1, RD-V1) * TF-A Tests CCA RME Realm Payload Testing * TF-A Tests FF-A v1.1 Secure interrupts Testing Platform Support * Three (3) new platforms added including Arm TC2 * Thirty (30) platforms updated * Initial support within TF-A OpenCI CI scripts repository for automating end-to-end boot tests (TF-A -> Linux shell prompt) on QEMU Patch Statistics Across all Repositories * Approx 1100 Patches merged since v2.7 June 2022 release Please refer to the TF-A [1], Hafnium [2] and TF-A Tests [3] changelogs for the complete summary of changes from the previous release. TF-A [4], TF-A Test [5], Hafnium [6], TF-A OpenCI Scripts [7] and TF-A OpenCI Jobs [8] repositories are available along with the compatible TF-RMM repository [9] and documentation [10]. [1] https://trustedfirmware-a.readthedocs.io/en/v2.8/change-log.html#id1 [2] https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/HEAD/d… - v2_8<https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/HEAD/d…> [3] https://trustedfirmware-a-tests.readthedocs.io/en/v2.8/change-log.html#vers… [4] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.8 [5] https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.8 [6] https://git.trustedfirmware.org/hafnium/hafnium.git/tag/?h=v2.8 [7] https://git.trustedfirmware.org/ci/tf-a-ci-scripts.git/tag/?h=v2.8 [8] https://git.trustedfirmware.org/ci/tf-a-job-configs.git/tag/?h=v2.8 [9] https://git.trustedfirmware.org/TF-RMM/tf-rmm.git/tag/?h=tf-rmm-v0.2.0 [10] https://tf-rmm.readthedocs.io/en/tf-rmm-v0.2.0/

3 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. 87 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 1 of 1 defect(s) ** CID 382009: (OVERRUN) ________________________________________________________________________________________________________ *** CID 382009: (OVERRUN) /lib/psci/psci_on.c: 80 in psci_cpu_on_start() 74 * CPU_ON platform hooks have been implemented. 75 */ 76 assert((psci_plat_pm_ops->pwr_domain_on != NULL) && 77 (psci_plat_pm_ops->pwr_domain_on_finish != NULL)); 78 79 /* Protect against multiple CPUs trying to turn ON the same target CPU */ >>> CID 382009: (OVERRUN) >>> Overrunning callee's array of size 8 by passing argument "target_idx" (which evaluates to 4294967295) in call to "psci_spin_lock_cpu". 80 psci_spin_lock_cpu(target_idx); 81 82 /* 83 * Generic management: Ensure that the cpu is off to be 84 * turned on. 85 * Perform cache maintanence ahead of reading the target CPU state to /lib/psci/psci_on.c: 160 in psci_cpu_on_start() 154 psci_set_aff_info_state_by_idx(target_idx, AFF_STATE_OFF); 155 flush_cpu_data_by_index(target_idx, 156 psci_svc_cpu_data.aff_info_state); 157 } 158 159 exit: >>> CID 382009: (OVERRUN) >>> Overrunning callee's array of size 8 by passing argument "target_idx" (which evaluates to 4294967295) in call to "psci_spin_unlock_cpu". 160 psci_spin_unlock_cpu(target_idx); 161 return rc; 162 } 163 164 /******************************************************************************* 165 * The following function finish an earlier power on request. They ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

3 years, 3 months

1
0
0 0

TF-A TechForum this week

by Joanna Farley

Hello TF-A Community, The meeting invite this week has been updated with an agenda. In case you have not seen this the details are: The TF-RMM component was published last week and was announced in this mailing list: https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… This week Javier Almansa Sobrino of the TF-RMM team would like to present on the TF-RMM Unit test framework The TF-RMM Unit test framework allows the exercising and validation of the software components of TF-RMM to be performed natively on the development host, making the development of new features, as well as the debugging of existing ones, easier. This talk will introduce this framework as well as the fake_host architecture for TF-RMM which allows the building and running of TF-RMM natively on the development host. We will also discuss how to implement unit tests for different components and we will introduce some features such as code coverage test for TF-RMM. Thanks Joanna Meeting details are: Join Zoom Meeting https://armltd.zoom.us/j/97858987231?pwd=U3NxdEk2YjI0OS90NzE1WEdHWE10Zz09&f… Meeting ID: 978 5898 7231 Passcode: 472153 One tap mobile +16465189805,,97858987231#,,,,*472153# US (New York) +13462487799,,97858987231#,,,,*472153# US (Houston) Dial by your location +1 646 518 9805 US (New York) +1 346 248 7799 US (Houston) +1 408 638 0968 US (San Jose) Meeting ID: 978 5898 7231 Passcode: 472153 Find your local number: https://armltd.zoom.us/u/adRXFKP35m Join by SIP 97858987231(a)zoomcrc.com Join by H.323 162.255.37.11 (US West) 162.255.36.11 (US East) 115.114.131.7 (India Mumbai) 115.114.115.7 (India Hyderabad) 213.19.144.110 (Amsterdam Netherlands) 213.244.140.110 (Germany) 103.122.166.55 (Australia Sydney) 103.122.167.55 (Australia Melbourne) 209.9.211.110 (Hong Kong SAR) 149.137.40.110 (Singapore) 64.211.144.160 (Brazil) 69.174.57.160 (Canada Toronto) 65.39.152.160 (Canada Vancouver) 207.226.132.110 (Japan Tokyo) 149.137.24.110 (Japan Osaka) Meeting ID: 978 5898 7231 Passcode: 472153

3 years, 3 months

1
0
0 0

Updated invitation with note: TF-A Tech Forum @ Thu Nov 17, 2022 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated with a note: "The TF-A Tech Forum will be running this week." Changed: description TF-A Tech Forum Thursday Nov 17, 2022 ⋅ 4pm – 5pm United Kingdom Time The TF-A Tech Forum is being run this week.The TF-RMM component was published last week and was announced in this mailing list posting https://lists.trustedfirmware.org/archives/list/tf-a@lists.tru… week the Javier Almansa Sobrino of the TF-RMM team would like to present on the TF-RMM Unit test frameworkThe TF-RMM Unit test framework allows the exercising and validation of the software components of TF-RMM to be performed natively on the development host, making the development of new features, as well as the debugging of existing ones, easier. This talk will introduce this framework as well as the fake_host architecture for TF-RMM which allows the building and running of TF-RMM natively on the development host. We will also discuss how to implement unit tests for different components and we will introduce some features such as code coverage test for TF-RMM.=======================================================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 View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Reply for tf-a(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Your attendance is optional. ~~//~~ 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

3 years, 3 months

1
0
0 0

Minimal kernel/firmware on Rock64 (rk3328)

by Robert Meissner

Hello, i found TF a very interesting project, however I would like to get booted with a really minimal firmware/kernel. I have a Rock64 with RK3328 Rockchip which I am trying to boot from sdcard with following sources: https://gitlab.com/jahro_me/sos/-/tree/master/ I have tried to setup UART for the device as described in the manual https://opensource.rock-chips.com/images/9/97/Rockchip_RK3328TRM_V1.1-Part1… On page 13 it states, the BOOT_ROM, INT_RAM is located at 0xffff0000. I have used this adress in kernel_entry https://gitlab.com/jahro_me/sos/-/blob/master/boot.s and in the main section https://gitlab.com/jahro_me/sos/-/blob/master/link.lds However, I could not get the kernel booted. I am not sure, if I need to remap the memory and how to do it. I guess, i should enable it with SGRF_SOC_CON2. Could anyone please help out to get the output, "Hello, You Rock!"? Best regards, Bob

3 years, 3 months

1
0
0 0

Submitting a patch to TF-A

by Jérôme Forissier

Hi, I am trying to send a patch to review.trustedfirmware.org but I get a Permission denied error. =========================== $ git push jforissier@review.trustedfirmware.org:29418/TF-A/trusted-firmware-a HEAD:refs/for/integration jforissier(a)review.trustedfirmware.org: Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. $ git clone "ssh:// jforissier@review.trustedfirmware.org:29418/TF-A/trusted-firmware-a" Cloning into 'trusted-firmware-a'... fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. $ ssh -p 29418 jforissier(a)review.trustedfirmware.org jforissier(a)review.trustedfirmware.org: Permission denied (publickey). =========================== I can see my ssh key at https://review.trustedfirmware.org/settings/. I tried to upload it again, I also added -i to the ssh command to make sure the right key is used. What am I doing wrong? Thanks, -- Jerome

3 years, 3 months

4
8
0 0

Changelog for v2.8 Release

by Lauren Wehrmeister

Hi All, Please take a look at the changelog for your respective platforms ahead of the TF-A v2.8 release. The changelog is autogenerated from the commit messages of the patches that have been merged since the v2.7 release. Here's your chance to give us guidance on any small manual adjustments you would like to see. Patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/17804/ Rendered Version: https://ci-builds.trustedfirmware.org/static-files/51m1_XLaarhS4BLLm1c3Mjdz… Thanks, Lauren

3 years, 3 months

1
0
0 0

Support for SVE + FP in TF-A

by Okash Khawaja

Hi, Currently TF-A doesn't support enabling both SVE and FP for both worlds. What can we do to support both SVE and FP in either world? Thanks, Okash

3 years, 3 months

2
2
0 0

PSCI OS-initiated mode

by Wing Li

Hi, The PSCI specification defines two different power state coordination modes for CPU_SUSPEND that can be used to put a core or a group of cores into a low-power state. These modes are the platform-coordinated mode (default) and the OS-initiated mode (optional). OS-initiated mode is currently not supported by TF-A, while both modes are supported by the Linux Kernel. Requesting reviews for the patches [1] adding support for OS-initiated mode in TF-A and the corresponding tests in TF-A-Tests. Any feedback and comments are much appreciated. Thanks in advance! Wing [1] https://review.trustedfirmware.org/q/topic:psci-osi

3 years, 4 months

1
0
0 0

PSCI OS-initiated mode

by Wing Li

Hi, The PSCI specification defines two different power state coordination modes for CPU_SUSPEND that can be used to put a core or a group of cores into a low-power state. These modes are the platform-coordinated mode (default) and the OS-initiated mode (optional). OS-initiated mode is currently not supported by TF-A, while both modes are supported by the Linux Kernel. Requesting reviews for the patches [1] adding support for OS-initiated mode in TF-A and the corresponding tests in TF-A-Tests. Any feedback and comments are much appreciated. Thanks in advance! Wing [1] https://review.trustedfirmware.org/q/topic:psci-osi

3 years, 4 months

1
0
0 0

Announcing TF-RMM v0.1.0

by Soby Mathew

Hi Everyone The TF-RMM team is pleased to announce the first public release of RMM implementation aligned to RMM Beta0 Specification [1] . The RMM is a software component that runs at Realm EL2 and forms part of a system which implements the Arm Confidential Compute Architecture (Arm CCA). The implementation can create Realm VMs in the Realm PAS and the Realm contents can be attested as specified in the RMM specification. The official trustedfirmware.org git repo can be found at : https://git.trustedfirmware.org/TF-RMM/tf-rmm.git/. There is also a github read-only mirror and can be found at https://github.com/TF-RMM/tf-rmm . Contributions will be accepted via TF-RMM gerrit at trustedfirmware.org : https://review.trustedfirmware.org/q/project:TF-RMM%252Ftf-rmm Please see the readme [2] and the getting started guide [3] to get started with RMM. We expect patches for supporting Realm Management Extension (RME) in linux kernel and related kvm-unit-tests to be available in the coming months. The patch to exercise Realm creation and execution via TF-A-Tests is in review at the moment [4] and the OOB instructions for the same can be found in TF-A RME documentation [5]. We expect these patches to be part of the upcoming TF-A v2.8 release. The mailing list for the project is tf-rmm(a)lists.trustedfirmware.org<mailto:tf-rmm@lists.trustedfirmware.org>. Looking forward to fruitful community engagement and successful deployment Arm CCA systems in future. Best Regards Soby Mathew PS : We hope to setup readthedocs documentation in the coming days, but till then , please bear with the github rendering of the rst documentation. [1] https://developer.arm.com/documentation/den0137/1-0bet0/?lang=en [2] https://github.com/TF-RMM/tf-rmm/blob/main/docs/readme.rst [3] https://github.com/TF-RMM/tf-rmm/blob/main/docs/getting_started/getting-sta… [4] https://review.trustedfirmware.org/c/TF-A/tf-a-tests/+/17221 [5] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/17610

3 years, 4 months

1
0
0 0

V2.8 Release code freeze notification

by Joanna Farley

Hi all, As documented in the Release Cadence section of the TF-A documentation (https://trustedfirmware-a.readthedocs.io/en/latest/about/release-informatio…) the v2.8 release has an expected code freeze date of 3rd week of November 2022. That equates to the start of that week Monday 14th November which is one calendar month away from tomorrow when the rc0 tag will be applied. Closing out the release takes around 6-10 working days normally over the last few releases. We want to ensure that planned feature patches for the release are submitted in good time for the review process to conclude. Preparations for v2.8 release is already underway. Thanks Joanna

3 years, 4 months

1
1
0 0

Conditional CMOs

by Okash Khawaja

Hi, When a core is in debug recovery mode its caches are not invalidated upon reset, so the L1 and L2 cache contents from before reset are observable after reset. Similarly, debug recovery mode of DynamIQ cluster ensures that contents of the shared L3 cache are also not invalidated upon transition to On mode. A common use case of booting cores in debug recovery mode is to boot with caches disabled and preserve the caches until a point where software can dump the caches and retrieve their contents. TF-A however unconditionally cleans and invalidates caches at multiple points during boot, e.g. in bl31_entrypoint when cleaning bss and .data sections. This will not only lose the cache content needed for debugging but will potentially corrupt memory as well, leading to bugs when booting in recovery mode. Can we make CMOs in lib/aarch64/cache_helpers.S conditional upon some platform hook to address above scenario? Happy to work on a patch if the idea of conditional CMOs makes sense. Thanks, Okash

3 years, 4 months

3
5
0 0

Canceled event with note: TF-A Tech Forum @ Thu Nov 3, 2022 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been canceled with a note: "No topics received so cancelling this week." TF-A Tech Forum Thursday Nov 3, 2022 ⋅ 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

3 years, 4 months

1
0
0 0

TF-A TechForum this Thursday 3rd November at 4pm GMT

by Joanna Farley

Hi Everyone, We have a TF-A Tech forum scheduled for this Thursday at 4pm GMT. Note the UK clocks moved to GMT from BST last weekend so the meeting may appear an hour different than in previous weeks in your calendar. At this time I do not have any topics to present. Please do reach out to me if you have any topics you would like to present to the TF-A community. If I do not find a topic or hear from the community that they have a topic I will cancel end of day this coming Wednesday 2nd November. Thanks Joanna

3 years, 4 months

1
1
0 0

Inconsistencies with PLAT_XLAT_TABLES_DYNAMIC

by Jeffrey Kardatzke

Hello, Is there a reason there are inconsistencies in the handling of PLAT_XLAT_TABLES_DYNAMIC? Specifically I'm referring to in some places it uses #ifdef logic: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/lib/utils/… and then in others it's using #if: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/include/li… Also in some places it uses add_define: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/services/s… and in others it's explicitly adding the define (w/ or w/out a value) to the _FLAGS for an image. https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/imx/i… https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/arm/b… I wanted to make use of this config option and noticed it wasn't getting picked up even when it was set and was considering cleaning up the usage of it by adding it to make_helpers/defaults.mk and then changing all the #ifdef's for it to be #if's. Thanks, -- Jeffrey Kardatzke jkardatzke(a)google.com Google, Inc.

3 years, 4 months

1
0
0 0

Re: 回复： building secure boot tf-a images without ROTK controlled by SW build engineer

by Neely, Brian

Hello, Just a quick follow-up on this question of using an HSM (or in general, some form of Key Management Infrastructure) to sign TF-A images. U-Boot has support for this with its mkimage utility (see https://github.com/u-boot/u-boot/blob/master/doc/uImage.FIT/signature.txt#L…). This appears to a custom engine in OpenSSL (and in this case, the pkcs11 engine). My questions are: 1. Does TF-A’s cert_create tool support using custom OpenSSL engines? 2. If so, is there a procedure for using this? 3. If not, is there a plan to add support for this in the roadmap somewhere? * Or, in general, is there a plan to add HSM support for TF-A image signing? Thanks, Brian

3 years, 4 months

1
0
0 0

Multi DTBs support in TF-A

by Ayoub Zaki

hello List, Is there anyway to support Multi DTBs in TF-A ? Mit freundlichen Grüßen / Kind regards -- Ayoub Zaki Embedded Systems Consultant

3 years, 4 months

2
3
0 0

Making the first byte of the stack canary a NULL for better security

by zjw88282740＠gmail.com

Hello, After learning the current implementation of plat_get_stack_protector_canary in TF-A, i am curious about why we not make the first byte of canary an NULL byte for better security?

3 years, 4 months

2
1
0 0

Debug RME feature on FVP_Base_RevC-2xAEMvA_11.19_14

by Ádám Tóth

Hello, I am about to debug RME feature with ARM DS on FVP_Base_RevC-2xAEMvA_11.19_14 platform. I am using the Trusted Firmware with RME extension based on this description https://trustedfirmware-a.readthedocs.io/en/latest/components/realm-managem… My observation is running plainly the model, everything looks ok, the VFP can run the SW without any problem. (I can see the consol windows with normal booting procedure) In case I would like to set up the ARM debugger in ARM DS, the simulation immediately stops after start with a popup window: "Unable to connect to device ARMAEM-a_MP_0 Error opening connection to device 16 Socket is closed(E_io_error) Socket is closed" Apparently my Debug settings are good: With the same settings I can run/debug the complete ARM Reference Solution (Linux, u-boot, TrustedFirmware) based on this description: https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-docs… but if I add additional flags for FVP: (-C cluster0.rme_support_level=2 -C cluster1.rme_support_level=2) I still can run the model, but cannot debug so when I activate the RME feature the ARM debugger do the previously mentioned behavior (stops right after start) How can I workaround this? What is the most efficient way to debug FVP with RME support. Any help is welcome here. Bye, Adam

3 years, 4 months

2
2
0 0

回复： building secure boot tf-a images without ROTK controlled by SW build engineer

by Ben

Hi Xin, I my opion, it should base on product lifecyle phase. In development phase, the SW engineer can use dev ROT keys & certificates. ATF have tools to generate them. In deployment stage, use KMI to manage keys&certificates are more better. BRs,Ben ----------回复的邮件信息---------- Xin.Xu--- via TF-A<tf-a(a)lists.trustedfirmware.xn--org> 2022-10-19-jw84b 周三 23:56写道： product ROT private key is controlled by KMI team. our plan is (1) SW build engineer builds  tf-a with a temporary development ROT key, save all other generated keys (2) remove fip image and all certificates built, send build images and generated keys to KMI team (3) KMI team uses cert_create to re-generate all certificates with product ROTK (4) KMI team sends all images, certificates, ROTPK hash to SW build engineer (5)  SW build engineer uses fiptool to generate final fip image my question: is there a better way to deal with this situation? (SW build engineer doesn't have control of ROT key) Thanks -Xin -- TF-A mailing list -- tf-a(a)lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave(a)lists.trustedfirmware.org

3 years, 4 months

1
0
0 0

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

by joanna.farley＠arm.com

This event has been canceled with a note: "As indicated on the TF-A ML no topics this week so cancelling. Joanna" TF-A Tech Forum Thursday Oct 20, 2022 ⋅ 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

3 years, 4 months

1
0
0 0

TF-A Tech Forum This Thursday

by Joanna Farley

Hi All, In the calendar we have a TF-A Tech Forum for this Thursday. I currently have no topic for discussion. If anybody in the community has a topic please let me know by Wednesday this week otherwise I will cancel. Thanks Joanna

3 years, 4 months

1
1
0 0

building secure boot tf-a images without ROTK controlled by SW build engineer

by Xin.Xu＠analog.com

product ROT private key is controlled by KMI team. our plan is (1) SW build engineer builds tf-a with a temporary development ROT key, save all other generated keys (2) remove fip image and all certificates built, send build images and generated keys to KMI team (3) KMI team uses cert_create to re-generate all certificates with product ROTK (4) KMI team sends all images, certificates, ROTPK hash to SW build engineer (5) SW build engineer uses fiptool to generate final fip image my question: is there a better way to deal with this situation? (SW build engineer doesn't have control of ROT key) Thanks -Xin

3 years, 4 months

1
0
0 0

New TrustedFirwmare Maillist - TF-A LTS

by Don Harbin

Hi All, As TF is moving forward with a TF-A LTS per the proposals that have been presented, I've created a new mail list for this purpose. Please feel free to subscribe. https://lists.trustedfirmware.org/mailman3/lists/tfa-lts.lists.trustedfirmw… Thanks, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

3 years, 4 months

1
0
0 0

Platform issues with mitigations of powerdown errata

by Boyan Karatotev

Hello everyone, There is a type of errata on a few CPUs where if they initiate a power down request which gets denied then attempting to power down again can fail in a deadlock. In essence, after the PE's power down sequence which ends on a WFI, but before actual power down, there exists a small window where an external event can interrupt the power down and cause the PE to continue after the WFI. Attempting to power down again after that can result in a deadlock. Affected CPUs are the Neoverse N2, Makalu ELP (Cortex X3), and Cortex A710. The SDEN [1] suggests to set the chicken bit CPUACTLR2_EL1[36] before the power down sequence and to clear it after coming out of the WFI (on anything other than RESET). The mitigations [2] set the bit in the `core_pwr_dwn` of each CPU but never clear it. This is because in the generic TF-A code path the WFI ends up being called in an infinite loop with the only way to come out of it being RESET. Most platforms with custom `pwr_domain_pwr_down_wfi` end up in the same loop or unrelated hardware reset mechanisms that avoid the errata. However, a few platforms could continue running as normal without going through a hardware reset which would require special treatment. The four problematic platforms are: * amlogic gxl and g12a: they fake a reset by manually calling the reset entrypoint on their primary CPUs only. This will leave the chicken bit set after reset. * socionext uniphier: same as amlogic but on all CPUs. * nxp (common code): I hope I understand what the platform is trying to do but there are 2 paths that raise an eyebrow: `_psci_sys_pwrdn_wfi` which has a single non-looped wfi (which could return as above) and `_psci_cpu_off_wfi` which seems to accept waking up as normal behaviour. The former path is a simple fix but the latter is the same case as amlogic and socionext. Due to its complexity I have not proposed any modification on either path. Finally, nvidia tegra and renesas (common code) have acceptable behaviour as far as the errata are concerned, however, they end up in the wfi loop only after a panic sequence. Although not problematic, this stands out. For all six platforms above there are a few options on how to proceed, the preferred one being to bring them in line with what everyone else does. Alternatively, ignoring the errata would be ok if these platforms never intend to use these CPUs. It must be noted, however, that it appears to be a family of errata, and these may not be all CPUs affected. [1]: the wording is identical for all 3 cores. For Neoverse N2: https://developer.arm.com/documentation/SDEN1982442/latest/ [2]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/17157/1 Regards, Boyan

3 years, 5 months

1
0
0 0

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

by joanna.farley＠arm.com

This event has been canceled with a note: "No topics arranged for this week so cancelling. At this time we don't have a topic for 20th September either. Something may well appear before then from Arm however if anybody in the broader community has a topic they would like to present please reach out me (Joanna.farley(a)arm.com)." TF-A Tech Forum Thursday Oct 6, 2022 ⋅ 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

3 years, 5 months

2
1
0 0

security: BL2 at EL3 on v8a based system

by sandeep tripathy

Hi, With the RME feature BL2 has to run at EL3 instead of EL1_S. EL3 has a separate PAS not accessible to EL1_S. Is there any harm in choosing to run BL2 at EL3 instead of BL2 at S_EL1 even for non-RME(v8a) systems? Given that EL3 and EL1_S have access to the same PAS. I am trying to revisit the motivation to run BL2 at EL1_S. I see there was an old discussion at https://github.com/ARM-software/tf-issues/issues/445 The reasoning was not pointing to any issue in specific but a generic principle of less permissiveness. Thanks Sandeep

3 years, 5 months

2
4
1 0

Re: security: BL2 at EL3 on v8a based system

by Tripathy, Sandeep

Hi Manish, >>The existing name is more suitable for configuration where the platform has BL1 in it and BL2 can run at EL3 instead of S-EL1. Well, that is a minor thing to take care. V9 implementation does that in a way. >>This configuration is currently not available in TF-A but having this flexibility is not a bad idea and it can be platform's choice. That's my answer! And the default choice costs some memory with probably no increase in security (V8). >>BL31 can mask the secure world. Cant be done reliably on V8 (with root world V9 or EL2_S there is potential to compartmentalize the secure services as PAS isolation is feasible) Ex: EL1S can always overwrite the BL31 Xlat tables and take control of the vectors and many other ways depending on the platform. It's the same PAS! Thanks Sandeep

3 years, 5 months

1
0
0 0

[PATCH TF-A] fix(plat/rcar3): Fix RPC-IF device node name

by Geert Uytterhoeven

According to the Generic Names Recommendation in the Devicetree Specification Release v0.3, and the DT Bindings for the Renesas Reduced Pin Count Interface, the node name for a Renesas RPC-IF device should be "spi". The node name matters, as the node is enabled by passing a DT fragment from TF-A to subsequent software. Fix this by renaming the device nodes from "rpc" to "spi". Fixes: 12c75c8886a0ee69 ("feat(plat/rcar3): emit RPC status to DT fragment if RPC unlocked") Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be> --- Background: On Renesas R-Car Gen3 platforms, the SPI Multi I/O Bus Controllers (RPC-IF) provide access to HyperFlash or QSPI storage. On production systems, they are typically locked by the TF-A firmware, unless TF-A is built with RCAR_RPC_HYPERFLASH_LOCKED=0. When unlocked, TF-A communicates this to subsequent software by passing a DT fragment that sets the "status" property of the RPC-IF device node to "okay". Unfortunately there are several issues preventing this from working all the way to Linux: 1. TF-A (and U-Boot on the receiving side) uses a device node name that does not conform to the DT specification nor the DT bindings for RPC-IF, 2. While U-Boot receives the RPC-IF enablement from TF-A, it does not propagate it to Linux yet, 3. The DTS files that are part of Linux do not have RPC HyperFlash support yet. This patch takes care of the first issue in TF-A. The related patches for U-Boot are [1]. Patches to enable RPC-IF support in Linux are available at [2]. Thanks for your comments! [1] "[PATCH u-boot 0/3] renesas: Fix RPC-IF enablement" https://lore.kernel.org/r/cover.1648544792.git.geert+renesas@glider.be [2] "[PATCH 0/5] arm64: dts: renesas: rcar-gen3: Enable HyperFlash support" https://lore.kernel.org/r/cover.1648548339.git.geert+renesas@glider.be --- plat/renesas/rcar/bl2_plat_setup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/plat/renesas/rcar/bl2_plat_setup.c b/plat/renesas/rcar/bl2_plat_setup.c index bbfa16927d6c2384..f85db8d650c6b1a5 100644 --- a/plat/renesas/rcar/bl2_plat_setup.c +++ b/plat/renesas/rcar/bl2_plat_setup.c @@ -574,7 +574,7 @@ static void bl2_add_rpc_node(void) goto err; } - node = ret = fdt_add_subnode(fdt, node, "rpc@ee200000"); + node = ret = fdt_add_subnode(fdt, node, "spi@ee200000"); if (ret < 0) { goto err; } -- 2.25.1

3 years, 5 months

3
7
1 0

Adding Openssl3 build capability to TF-A

by Gyorgy Szing

Hi, As you may know, the build system was changed, and the tip of master depends on Openssl3. This version is quite new and is not available in many old (or not so old) but still supported operating systems. (Ubuntu 18.04 is an example.) I made a quick and dirty fix to allow building Opessl3 right from TF-A if the source is pre-fetched. You can find this change here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/16800 For our downstream project this is a perfect solution as the same component introducing the new dependency carries the solution. Thus, my build environment is not becoming TF-A version specific. From TF-A point of view the situation is not so simple. The above patch extends TF-A with "build environment provisioning" responsibility. Before this patch TF-A assumed, all "common" dependencies are available in the build environment, and this patch changes that. Yes, some strongly TF-A specific components were owned and built by TF-A, but openssl is different. Thus, my modification is a "game changer" in some ways. A few things to consider: * Openssl becomes a special kind of TPIP which the project will need to manage (e.g. look for security risks, version updates, compatibility to different OSs and OS versions, etc...). * This is a system wide component. There is a risk of breaking something the build uses. Hidden things like a python module depending on openssl and now picking up an incompatible version. * This change might be considered as layer bleeding since it "melds" responsibilities of the TF-A project and the "owner of the build environment". IMHO this might be a significant difference from supply-chain security perspectives. There are alternatives which might be considered better: * making the build system and host side tooling (e.g. cert_tool) backwards compatible with openssl2 * hosting pre-built static binaries somewhere, which would simplify build environment updates As I mentioned above, this is a "good enough" fix for my use-case, but not sure if this is the right approach from TF-A perspectives. I am happy to tidy up this patch and push it trough the review, but the efforts needed to implement "other options" are beyond my capacity. I am looking for feedback both from TF-A maintainers and from "build environment owners". Thanks! /George Ps.: Apologies for not doing "my homework". I know there is a ticket somewhere in Phabricator and I did not invest the needed time to find it.

3 years, 5 months

2
2
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-A