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
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
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
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.
TL;DR: Attached is the TF-A LTS proposal doc. Please review and share
your thoughts.
Hello everyone,
Long term support for TF-A has a long history. As a community we have
flirted with it for a while, and like any flirtation, it started with
gossip -- in our case, over mailing list [1] -- more than two years
ago. Then Varun Wadekar did a wonderful tech forum presentation [2]
which demonstrated interest in the topic and raised interesting
questions about LTS.
After some time, the affair lost headline status, only to be revived
again [3], earlier this year. This time however, there is a formal
proposal (no pun intended). After the mailing list discussion and
feedback from TF-A tech forum [4], we have put together a draft which
attempts to give a concrete idea about what the TF-A LTS will look
like.
Please spare some time to read through it and share your feedback. The
plan is to put LTS into action this November.
Cheers!
Okash
[1] https://lists.trustedfirmware.org/archives/search?mlist=tf-a%40lists.truste…
[2] https://www.trustedfirmware.org/docs/TF-A-LTS.pdf
[3] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…
[4] https://www.trustedfirmware.org/docs/TForg_LTS_proposal.pdf
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 370380: Code maintainability issues (UNUSED_VALUE)
/plat/xilinx/versal/pm_service/pm_svc_main.c: 128 in pm_setup()
________________________________________________________________________________________________________
*** CID 370380: Code maintainability issues (UNUSED_VALUE)
/plat/xilinx/versal/pm_service/pm_svc_main.c: 128 in pm_setup()
122 int32_t status, ret = 0;
123
124 status = pm_ipi_init(primary_proc);
125
126 if (status < 0) {
127 INFO("BL31: PM Service Init Failed, Error Code %d!\n", status);
>>> CID 370380: Code maintainability issues (UNUSED_VALUE)
>>> Assigning value from "status" to "ret" here, but that stored value is overwritten before it can be used.
128 ret = status;
129 } else {
130 pm_up = true;
131 }
132
133 /*
________________________________________________________________________________________________________
To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…
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.
1 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 380957: Integer handling issues (NO_EFFECT)
/drivers/arm/gic/v3/gicv3_main.c: 1109 in gicv3_raise_sgi()
________________________________________________________________________________________________________
*** CID 380957: Integer handling issues (NO_EFFECT)
/drivers/arm/gic/v3/gicv3_main.c: 1109 in gicv3_raise_sgi()
1103 u_register_t target)
1104 {
1105 unsigned int tgt, aff3, aff2, aff1, aff0;
1106 uint64_t sgi_val;
1107
1108 /* Verify interrupt number is in the SGI range */
>>> CID 380957: Integer handling issues (NO_EFFECT)
>>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "sgi_num >= 0U".
1109 assert((sgi_num >= MIN_SGI_ID) && (sgi_num < MIN_PPI_ID));
1110
1111 /* Extract affinity fields from target */
1112 aff0 = MPIDR_AFFLVL0_VAL(target);
1113 aff1 = MPIDR_AFFLVL1_VAL(target);
1114 aff2 = MPIDR_AFFLVL2_VAL(target);
________________________________________________________________________________________________________
To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…
This event has been updated with a note:
"Firmer Agenda for 22md Sept session"
Changed: description
TF-A Tech Forum
Thursday Sep 22, 2022 ⋅ 4pm – 5pm
United Kingdom Time
Agenda for Techforum session on Sept 22nd 2022Firmware update
implementation in Total Compute (TC) Arm Reference Software Stack[1]:Brief
overview of Firmware update mechanism as per the Firmware update
specification [2]Implementation of FWU specification in Total
ComputeDiscuss partner's view on this mechanismPresenter: Davidson
Kumaresan and Manish
Badarkhe[1] https://developer.arm.com/Tools%20and%20Software/Total%20C…
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
Okash Khawaja
santantonioswap(a)gmail.com
don.harbin(a)linaro.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
Hi All,
Sorry if this is the wrong list, I'm trying to submit a patch for tf-a and
I'm currently unable to add an ssh key or generate an https password to use
for authentication.
Perhaps I am doing something wrong?
I'm trying to use the settings here:
https://review.trustedfirmware.org/settings/#HTTPCredentials to add an ssh
key and I get the error message
"Error 500 (Server Error): Internal server error Endpoint:
/accounts/self/sshkeys"
Any help is greatly appreciated.
Thanks,
Scott (sparlane)