- TF-A - lists.trustedfirmware.org

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

2 years, 10 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

2 years, 10 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?

2 years, 11 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

2 years, 11 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

2 years, 11 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

2 years, 11 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

2 years, 11 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

2 years, 11 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

2 years, 11 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

2 years, 11 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A