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?
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
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
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
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
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
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
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
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