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 …
[View More]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
[View Less]
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 …
[View More]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
[View Less]
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:…
[View More] is there a better way to deal with this situation? (SW build engineer doesn't have control of ROT key)
Thanks
-Xin
[View Less]
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 …
[View More]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
[View Less]
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 …
[View More]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
[View Less]
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 …
[View More]principle of less
permissiveness.
Thanks
Sandeep
[View Less]
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 …
[View More]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
[View Less]
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 …
[View More]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
[View Less]