- TF-A - lists.trustedfirmware.org

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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 7 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, 7 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, 7 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, 7 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, 7 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, 7 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, 7 months

2
2
0 0

Finally, a TF-A LTS Proposal!

by Okash Khawaja

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

3 years, 7 months

5
7
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 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…

3 years, 7 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. 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…

3 years, 7 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. 4 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 4 of 4 defect(s) ** CID 380859: Integer handling issues (BAD_SHIFT) /drivers/arm/gic/v3/gic600_multichip.c: 290 in gic700_multichip_validate_data() ________________________________________________________________________________________________________ *** CID 380859: Integer handling issues (BAD_SHIFT) /drivers/arm/gic/v3/gic600_multichip.c: 290 in gic700_multichip_validate_data() 284 } 285 multichip_spi_blocks |= blocks_of_32; 286 } 287 288 /* ESPI IDs overlap check */ 289 if (spi_id_max > GIC700_ESPI_ID_MIN) { >>> CID 380859: Integer handling issues (BAD_SHIFT) >>> In expression "1 << (spi_id_max - 4096U + 1U >> 5)", left shifting by more than 31 bits has undefined behavior. The shift amount, "spi_id_max - 4096U + 1U >> 5", is as much as 32. 290 blocks_of_32 = BLOCKS_OF_32(spi_id_min - GIC700_ESPI_ID_MIN, 291 spi_id_max - GIC700_ESPI_ID_MIN); 292 if ((multichip_espi_blocks & blocks_of_32) != 0) { 293 ERROR("SPI IDs of Chip %u overlapping\n", i); 294 panic(); 295 } ** CID 380858: Control flow issues (DEADCODE) /drivers/nxp/crypto/caam/src/rng.c: 45 in is_hw_rng_instantiated() ________________________________________________________________________________________________________ *** CID 380858: Control flow issues (DEADCODE) /drivers/nxp/crypto/caam/src/rng.c: 45 in is_hw_rng_instantiated() 39 40 /*Check if either of the two state handles has been instantiated */ 41 if (rdsta & RNG_STATE0_HANDLE_INSTANTIATED) { 42 *state_handle = 0; 43 ret_code = 1; 44 } else if (rdsta & RNG_STATE0_HANDLE_INSTANTIATED) { >>> CID 380858: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "*state_handle = 1U;". 45 *state_handle = 1; 46 ret_code = 1; 47 } 48 49 return ret_code; 50 } ** CID 380857: Control flow issues (DEADCODE) /drivers/st/fmc/stm32_fmc2_nand.c: 284 in stm32_fmc2_nand_setup_timing() ________________________________________________________________________________________________________ *** CID 380857: Control flow issues (DEADCODE) /drivers/st/fmc/stm32_fmc2_nand.c: 284 in stm32_fmc2_nand_setup_timing() 278 if ((tset_mem < NAND_TADL_MIN) && 279 (thold_att < (NAND_TADL_MIN - tset_mem))) { 280 thold_att = NAND_TADL_MIN - tset_mem; 281 } 282 if ((tset_mem < NAND_TWH_MIN) && 283 (thold_att < (NAND_TWH_MIN - tset_mem))) { >>> CID 380857: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "thold_att = 30000UL - tset_...". 284 thold_att = NAND_TWH_MIN - tset_mem; 285 } 286 if ((tset_mem < NAND_TWHR_MIN) && 287 (thold_att < (NAND_TWHR_MIN - tset_mem))) { 288 thold_att = NAND_TWHR_MIN - tset_mem; 289 } ** CID 380856: Integer handling issues (BAD_SHIFT) /plat/intel/soc/common/drivers/qspi/cadence_qspi.c: 583 in cad_qspi_init() ________________________________________________________________________________________________________ *** CID 380856: Integer handling issues (BAD_SHIFT) /plat/intel/soc/common/drivers/qspi/cadence_qspi.c: 583 in cad_qspi_init() 577 578 cap_code = CAD_QSPI_STIG_RDID_CAPACITYID(rdid); 579 580 if (!(((cap_code >> 4) > 0x9) || ((cap_code & 0xf) > 0x9))) { 581 uint32_t decoded_cap = ((cap_code >> 4) * 10) + 582 (cap_code & 0xf); >>> CID 380856: Integer handling issues (BAD_SHIFT) >>> In expression "1 << decoded_cap + 6U", left shifting by more than 31 bits has undefined behavior. The shift amount, "decoded_cap + 6U", is as much as 105. 583 qspi_device_size = 1 << (decoded_cap + 6); 584 INFO("QSPI Capacity: %x\n\n", qspi_device_size); 585 586 } else { 587 ERROR("Invalid CapacityID encountered: 0x%02x\n", 588 cap_code); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

3 years, 8 months

1
0
0 0

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

by joanna.farley＠arm.com

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

3 years, 8 months

1
0
0 0

Issue with adding ssh key to review server

by sparlane＠gmail.com

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)

3 years, 8 months

2
2
0 0

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

by joanna.farley＠arm.com

This event has been updated with a note: "We have a proposed subject for this TF-A Tech Forum. Joanna" Changed: description TF-A Tech Forum Thursday Sep 22, 2022 ⋅ 4pm – 5pm United Kingdom Time Proposed session for this Tech Forum will be an update to Firmware Update capabilities.More details to follow.....------------------------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, 8 months

1
0
0 0

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

by joanna.farley＠arm.com

This event has been updated with a note: "Updated Agenda for 8th September session." Changed: description TF-A Tech Forum Thursday Sep 8, 2022 ⋅ 4pm – 5pm United Kingdom Time The plan is to use this Tech Forum session to discuss the LTS proposal and review comments received.See the TF-A Mailing list for details of the proposal and review comments: https://lists.trustedfirmware.org/archives/list/tf-a@lists.t… will be led by Okash Khawaja and Varun Wadekar.ThanksJoanna Farley-------------------------------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, 8 months

1
0
0 0

How to trap aborts caused by TZASC?

by Chenxu Wang

Hi all, I want to test how to trap the aborts caused by TZASC. For example, when I use NS-EL1 (e.g., OS) to access a Secure region (configured in TZASC), it will generate an abort. But I am not sure how to trap it. I think it is an external abort, so I enable the SCR_EL3.EA=1 and write a handler. However I cannot trap it. Also, my other handlers in EL3 still do not report the abort. Thus, how can I trap a TZASC abort? If I want to route it into EL3 to handle, how can I do it? Sincerely, WANG Chenxu

3 years, 8 months

3
7
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. 3 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 3 of 3 defect(s) ** CID 380536: Control flow issues (NO_EFFECT) /bl32/tsp/tsp_ffa_main.c: 220 in test_memory_send() ________________________________________________________________________________________________________ *** CID 380536: Control flow issues (NO_EFFECT) /bl32/tsp/tsp_ffa_main.c: 220 in test_memory_send() 214 ERROR("Failed [%u] mmap_add_dynamic_region %u (%lx) (%lx) (%x)!\n", 215 i, ret, 216 (uint64_t)composite->address_range_array[i].address, 217 size, mem_attrs); 218 219 /* Remove mappings created in this transaction. */ >>> CID 380536: Control flow issues (NO_EFFECT) >>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "i >= 0U". 220 for (i--; i >= 0U; i--) { 221 ret = mmap_remove_dynamic_region( 222 (uint64_t)ptr, 223 composite->address_range_array[i].page_count * PAGE_SIZE); 224 225 if (ret != 0) { ** CID 380535: Null pointer dereferences (REVERSE_INULL) /bl32/tsp/ffa_helpers.c: 154 in memory_retrieve() ________________________________________________________________________________________________________ *** CID 380535: Null pointer dereferences (REVERSE_INULL) /bl32/tsp/ffa_helpers.c: 154 in memory_retrieve() 148 uint32_t *total_length) 149 { 150 smc_args_t ret; 151 uint32_t descriptor_size; 152 struct ffa_mtd *memory_region = (struct ffa_mtd *)mb->tx_buffer; 153 >>> CID 380535: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "mb" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 154 if (retrieved == NULL || mb == NULL) { 155 ERROR("Invalid parameters!\n"); 156 return false; 157 } 158 159 /* Clear TX buffer. */ ** CID 380534: API usage errors (SWAPPED_ARGUMENTS) ________________________________________________________________________________________________________ *** CID 380534: API usage errors (SWAPPED_ARGUMENTS) /bl32/tsp/tsp_ffa_main.c: 476 in handle_partition_message() 470 471 default: 472 INFO("TSP Tests: Unknown request ID %d--\n", (int) arg3); 473 } 474 475 /* Swap the sender and receiver in the response. */ >>> CID 380534: API usage errors (SWAPPED_ARGUMENTS) >>> The positions of arguments in the call to "ffa_msg_send_direct_resp" do not match the ordering of the parameters: * "receiver" is passed to "sender". * "sender" is passed to "receiver". 476 return ffa_msg_send_direct_resp(receiver, sender, status, 0, 0, 0, 0); 477 } 478 479 /******************************************************************************* 480 * This function implements the event loop for handling FF-A ABI invocations. 481 ******************************************************************************/ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

3 years, 8 months

1
0
0 0

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

by joanna.farley＠arm.com

This event has been canceled with a note: "Apologies for the short notice. We have no topic this week and some key folks are out on vacations. I'm hoping the Techforum on the 8th September can be a followup LTS discussion on the proposal submitted to the Mailing list. I'll formally organise that for the 8th next week." TF-A Tech Forum Thursday Aug 25, 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, 8 months

1
0
0 0

Does FVP and current TF-A support the SVE/SVE2 programming?

by Chenxu Wang

Hi all, I want to perform some encryption/decryption in TF-A. I find that Arm provides some hardware-assisted instructions for encryption and integrity verification (e.g., AESE, SHA1...). But it seems that FVP does not support them. I recently read Armv9 and know that Arm purposes SVE/SVE2 to accelerate the matrix computation. It seems that it can be another approach to accelerate the encryption. Since I am a novice in Armv9 (and in FVP), thus, I want to ask: (1) Do FVP and TF-A support the SVE? If yes, how to configure it? (2) Do FVP and TF-A support the SVE2? If yes, how to configure it? Looking forward to your reply! Sincerely, WANG Chenxu

3 years, 8 months

2
2
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. 3 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 3 of 3 defect(s) ** CID 380533: Null pointer dereferences (NULL_RETURNS) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 283 in spmc_shmem_obj_validate_id() ________________________________________________________________________________________________________ *** CID 380533: Null pointer dereferences (NULL_RETURNS) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 283 in spmc_shmem_obj_validate_id() 277 size_t emad_size; 278 struct ffa_emad_v1_0 *emad; 279 280 emad = spmc_shmem_obj_get_emad(desc, i, 281 MAKE_FFA_VERSION(1, 1), 282 &emad_size); >>> CID 380533: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing "emad", which is known to be "NULL". 283 if (sp_id == emad->mapd.endpoint_id) { 284 found = true; 285 break; 286 } 287 } 288 return found; ** CID 380532: Insecure data handling (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 380532: Insecure data handling (TAINTED_SCALAR) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1754 in spmc_ffa_mem_relinquish() 1748 req->endpoint_array[0], sp_ctx->sp_id); 1749 ret = FFA_ERROR_INVALID_PARAMETER; 1750 goto err_unlock_all; 1751 } 1752 1753 /* Validate the caller is a valid participant. */ >>> CID 380532: Insecure data handling (TAINTED_SCALAR) >>> Passing tainted expression "obj->desc.emad_count" to "spmc_shmem_obj_validate_id", which uses it as a loop boundary. 1754 if (!spmc_shmem_obj_validate_id(&obj->desc, sp_ctx->sp_id)) { 1755 WARN("%s: Invalid endpoint ID (0x%x).\n", 1756 __func__, req->endpoint_array[0]); 1757 ret = FFA_ERROR_INVALID_PARAMETER; 1758 goto err_unlock_all; 1759 } ** CID 380531: Integer handling issues (SIGN_EXTENSION) /bl32/tsp/tsp_ffa_main.c: 34 in send_ffa_pm_success() ________________________________________________________________________________________________________ *** CID 380531: Integer handling issues (SIGN_EXTENSION) /bl32/tsp/tsp_ffa_main.c: 34 in send_ffa_pm_success() 28 29 static ffa_endpoint_id16_t tsp_id, spmc_id; 30 31 static smc_args_t *send_ffa_pm_success(void) 32 { 33 return set_smc_args(FFA_MSG_SEND_DIRECT_RESP_SMC32, >>> CID 380531: Integer handling issues (SIGN_EXTENSION) >>> Suspicious implicit sign extension: "tsp_id" with type "ffa_endpoint_id16_t" (16 bits, unsigned) is promoted in "(tsp_id << 16U) | spmc_id" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned). If "(tsp_id << 16U) | spmc_id" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1. 34 tsp_id << FFA_DIRECT_MSG_SOURCE_SHIFT | 35 spmc_id, 36 FFA_FWK_MSG_BIT | 37 (FFA_PM_MSG_PM_RESP & FFA_FWK_MSG_MASK), 38 0, 0, 0, 0, 0); 39 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

3 years, 8 months

1
0
0 0

TF-A RME support

by Shameerali Kolothum Thodi

Hi, I am trying to setup and run the RME support in TF-A, using the steps described here, https://trustedfirmware-a.readthedocs.io/en/latest/components/realm-managem… Build goes smoothly and when I launch FVP to run the RME tests using the command line mentioned in the link, the FVP terminal_0 seems to be get stuck at the below line, Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.7(debug):v2.7.0-235-g1631f9c75 NOTICE: BL1: Built : 11:44:37, Aug 22 2022 INFO: BL1: RAM 0x4035000 - 0x403c000 INFO: Loading image id=31 at address 0x4001010 INFO: Image id=31 loaded: 0x4001010 - 0x4001258 INFO: FCONF: Config file with image ID:31 loaded at address = 0x4001010 INFO: Loading image id=24 at address 0x4001300 INFO: Image id=24 loaded: 0x4001300 - 0x40015e4 INFO: FCONF: Config file with image ID:24 loaded at address = 0x4001300 INFO: BL1: Loading BL2 INFO: Loading image id=1 at address 0x4022000 INFO: Image id=1 loaded: 0x4022000 - 0x402cca1 NOTICE: BL1: Booting BL2 INFO: Entry point address = 0x4022000 INFO: SPSR = 0x3cd INFO: Configuring TrustZone Controller INFO: Total 6 regions set. Both the tf-a-tests.git and trusted-firmware-a.git are master branch and I am using the FVP_Base_RevC-2xAEMvA v11.18.16. I am totally new to this setup and maybe I am missing something here. Appreciate any help to get this resolved or tips to debug further. Thanks, Shameer

3 years, 8 months

3
6
0 0

TF-A CI often fail due to missing rebase

by Julius Werner

Hi Glen, Don, and others, I've seen that a couple of TF-A patches I've been CCed on recently often seem to fail the CI run (Allow-CI+1) due to some strange build-time errors that don't seem to have anything to do with the patch at hand, and then one of the maintainers usually suggests that the patch needs a rebase, and the next CI run succeeds after that. Here are two recent examples: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/16160 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/14666 I was wondering if this is a known problem and if the CI can do anything here to mitigate it and save developers from this extra layer of friction? I'm not really sure why a rebase was necessary in either of these examples or why the CI run failed before it (unless the whole repository was in a bad state that didn't build, but since all submissions are guarded by the CI that shouldn't have been possible?). But I also don't really understand why the rebase would make a difference for the CI anyway. Generally, when a patch is submitted in Gerrit, that means it is cherry-picked onto the current master (regardless of what parent commit it was uploaded with). Since the CI is supposed to be a test run for submission, I would expect that the CI should also test a patch by cherry-picking it onto the current master, not just by building the patch on top of whatever parent commit it was uploaded with. But since rebasing a patch evidently seems to make a difference to the CI, that suggests that it's currently doing the latter strategy? Should that maybe be changed to the former to avoid these kinds of issues? If this isn't a known problem yet maybe it would be worth adding it to the JIRA? Thanks, Julius

3 years, 8 months

4
6
0 0

A problem about TZASC in Armv9

by Chenxu Wang

Greetings, Armv9 introduces the RME and GPT technology. The GPT will separates the memory into unlimited regions with specific attributes. However, when I read the Armv9 manual and source code of TF-A, I still have some problems: 1. It seems that GPT is a feature on CPU, but not on a specific device (e.g.,TZC-400). Thus, will GPT conflict with TZC-400? I mean, when performing VA->PA on RAM, what is the detailed process if I enable both GPT and TZC-400? 2. I use the Arm FVP with Armv9 and RME extension enabled, and TF-A is "arm_cca" branch (with TF-A v2.5). Thus, in this version, what is the configuration for TZC-400 and GPT? Will it disable TZC-400 (I mean, GPT only) when booting Normal World? 3. Does GPT handle peripheral access (e.g., from DMA, GPU, Sensors... etc.)? I know TZC-400 will do it with NSAID. 4. Will GPT configures Read/Write/Execute features? All comments are valuable! SIncerely, WANG Chenxu

3 years, 8 months

3
7
0 0

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

by joanna.farley＠arm.com

This event has been canceled with a note: "Cancelling this week. I have no topics ready for presenting also many folks are out on summer holidays. " TF-A Tech Forum Thursday Aug 11, 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, 9 months

1
0
0 0

TF-A TechForum 19th May Cancelled

by Bipin Ravi

All, This is to inform you all that the TF-A Techforum for Thursday, 19th May 2022 is cancelled as we didn't receive any topic for this week. The next meeting will now be Thursday, 2nd June 2022 at 16:00 - 17:00 BST. Thanks, Bipin Ravi

3 years, 9 months

1
1
0 0

Re: Question about disable MMU in BL1

by 邬金平

Hi, I have tried this before, there is a problem. on Armv8, when MMU disabled, the default attribute of memory is device, and device memory access has alignment requirements. For example, accessing address (0x1) will result in fault. Ben via TF-A <tf-a(a)lists.trustedfirmware.org> 于2022年7月19日周二 17:02写道： > Hello, > > To decrease feature in BL1, I plan to disable MMU in BL1 stage. > Are there any potential issues besides performance issues? > > BRs > > ------------------------------ > Ben(a)tsingmicro.com > -- > 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, 9 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 379362: Memory - illegal accesses (OVERRUN) /lib/psci/psci_common.c: 1046 in psci_is_last_on_cpu_safe() ________________________________________________________________________________________________________ *** CID 379362: Memory - illegal accesses (OVERRUN) /lib/psci/psci_common.c: 1046 in psci_is_last_on_cpu_safe() 1040 unsigned int i = 0; 1041 1042 /* 1043 * Traverse the forest of PSCI nodes, nodes with no parents 1044 * (invalid-nodes) are the root nodes. 1045 */ >>> CID 379362: Memory - illegal accesses (OVERRUN) >>> Overrunning array "psci_non_cpu_pd_nodes" of 5 16-byte elements at element index 5 (byte offset 95) using index "i" (which evaluates to 5). 1046 while ((psci_non_cpu_pd_nodes[i].parent_node == 1047 PSCI_PARENT_NODE_INVALID) && 1048 (i < PSCI_NUM_NON_CPU_PWR_DOMAINS)) { 1049 psci_get_parent_pwr_domain_nodes( 1050 psci_non_cpu_pd_nodes[i].cpu_start_idx, 1051 PLAT_MAX_PWR_LVL, parent_nodes); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

3 years, 9 months

1
0
0 0

Question about disable MMU in BL1

by Ben

Hello, To decrease feature in BL1, I plan to disable MMU in BL1 stage. Are there any potential issues besides performance issues? BRs Ben(a)tsingmicro.com

3 years, 10 months

1
0
0 0

Question about maximum TF-A BL31 memory usage

by Peng Fan

Hi All, Is there any public BL31 memory usage data, such as static image size and runtime memory usage, with different feature enabled? For example, typical PSCI feature would require image size XXKB, runtime memory XXKB. enabling FFA would enlarge image size by XXKB, runtime memory enlarge XXKB. we are evaluating how much On-Chip RAM could be assigned for BL31, if there are any public data available, that would be great. Thanks, Peng.

3 years, 10 months

2
1
0 0

Rebooting LTS discussion

by Okash Khawaja

Hi, There have been discussions about having long term support releases for TF-A, e.g. the email thread [1] and a tech forum [2]. For partners releasing TF-A in their production devices, LTS is very much needed. From the previous discussions, it seems like there is an agreement that LTS is a good idea but we need to build consensus on how to support it. Any thoughts on this? Thanks, Okash [1] https://lists.trustedfirmware.org/archives/search?mlist=tf-a%40lists.truste… [2] https://www.trustedfirmware.org/docs/TF-A-LTS.pdf

3 years, 10 months

4
11
0 0

Question about FVP's dts

by Chenxu Wang

Hi all, I am using FVP base RevC. Recently I heard that this FVP supports a Mali G76 GPU, and I want to test it. To configure it, initially I add a node in linux/arch/arm64/boot/dts/arm/fvp-base-aemv8a-aemv8a.dtsi, but it doesn't work. Finally, I find that I should configure trusted-firmware-a/fdts/fvp-base-gicv3-psci-1t.dts, and I can see a mali GPU node in /proc/device-tree. One of my booting command (sorry, the entire booting command is TOO long) is "--data cluster0.cpu0=arm-reference-platform/output/fvp/fvp-oe/uboot/fvp-base-aemv8a-aemv8a.dtb@0x82000000". And I use the following shell command to compile the TF-A: make PLAT=fvp all CROSS_COMPILE=aarch64-none-elf- ENABLE_RME=1 DEBUG=1 ARCH=aarch64 fip BL33=arm-reference-platform/output/fvp/components/fvp/uboot.bin FVP_HW_CONFIG_DTS=fdts/fvp-base-gicv3-psci-1t.dts ARM_DISABLE_TRUSTED_WDOG=1. So, I wonder, why the real DTS is in TF-A, instead of Linux? BTW, I wanna ask another question (although it is not proper to ask here, I cannot find FVP's mailing list): Can someone provide a proper dts configurations for FVP's Mali G76 GPU? Sincerely, WANG Chenxu

3 years, 10 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. 4 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 4 of 4 defect(s) ** CID 379252: Concurrent data access violations (MISSING_LOCK) /plat/imx/imx8m/ddr/dram.c: 254 in dram_dvfs_handler() ________________________________________________________________________________________________________ *** CID 379252: Concurrent data access violations (MISSING_LOCK) /plat/imx/imx8m/ddr/dram.c: 254 in dram_dvfs_handler() 248 } else if (dram_info.dram_type == DDRC_DDR4) { 249 ddr4_swffc(&dram_info, fsp_index); 250 } 251 252 dram_info.current_fsp = fsp_index; 253 wait_ddrc_hwffc_done = false; >>> CID 379252: Concurrent data access violations (MISSING_LOCK) >>> Accessing "wfe_done" without holding lock "dfs_lock". Elsewhere, "wfe_done" is accessed with "dfs_lock" held 1 out of 2 times (1 of these accesses strongly imply that it is necessary). 254 wfe_done = 0; 255 dsb(); 256 sev(); 257 isb(); 258 } 259 260 SMC_RET1(handle, 0); ** CID 379251: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 379251: Memory - corruptions (OVERRUN) /plat/imx/imx8m/ddr/dram.c: 246 in dram_dvfs_handler() 240 } 241 242 /* flush the L1/L2 cache */ 243 dcsw_op_all(DCCSW); 244 245 if (dram_info.dram_type == DDRC_LPDDR4) { >>> CID 379251: Memory - corruptions (OVERRUN) >>> Overrunning callee's array of size 3 by passing argument "fsp_index" (which evaluates to 3) in call to "lpddr4_swffc". 246 lpddr4_swffc(&dram_info, dev_fsp, fsp_index); 247 dev_fsp = (~dev_fsp) & 0x1; 248 } else if (dram_info.dram_type == DDRC_DDR4) { 249 ddr4_swffc(&dram_info, fsp_index); 250 } 251 ** CID 379250: (COPY_PASTE_ERROR) /plat/imx/imx8m/imx8mm/gpc.c: 182 in imx_gpc_pm_domain_enable() /plat/imx/imx8m/imx8mn/gpc.c: 81 in imx_gpc_pm_domain_enable() ________________________________________________________________________________________________________ *** CID 379250: (COPY_PASTE_ERROR) /plat/imx/imx8m/imx8mm/gpc.c: 182 in imx_gpc_pm_domain_enable() 176 /* HSIOMIX has no PU bit, so skip for it */ 177 if (domain_id != HSIOMIX) { 178 /* clear the PGC bit */ 179 mmio_clrbits_32(IMX_GPC_BASE + pwr_domain->pgc_offset, 0x1); 180 181 /* power up the domain */ >>> CID 379250: (COPY_PASTE_ERROR) >>> "mmio_setbits_32" in "mmio_setbits_32(809107704UL, pwr_domain->pwr_req)" looks like a copy-paste error. 182 mmio_setbits_32(IMX_GPC_BASE + PU_PGC_UP_TRG, pwr_domain->pwr_req); 183 184 /* wait for power request done */ 185 while (mmio_read_32(IMX_GPC_BASE + PU_PGC_UP_TRG) & pwr_domain->pwr_req) { 186 ; 187 } /plat/imx/imx8m/imx8mn/gpc.c: 81 in imx_gpc_pm_domain_enable() 75 /* HSIOMIX has no PU bit, so skip for it */ 76 if (domain_id != HSIOMIX) { 77 /* clear the PGC bit */ 78 mmio_clrbits_32(IMX_GPC_BASE + pwr_domain->pgc_offset, 0x1); 79 80 /* power up the domain */ >>> CID 379250: (COPY_PASTE_ERROR) >>> "mmio_setbits_32" in "mmio_setbits_32(809107704UL, pwr_domain->pwr_req)" looks like a copy-paste error. 81 mmio_setbits_32(IMX_GPC_BASE + PU_PGC_UP_TRG, pwr_domain->pwr_req); 82 83 /* wait for power request done */ 84 while (mmio_read_32(IMX_GPC_BASE + PU_PGC_UP_TRG) & pwr_domain->pwr_req) { 85 ; 86 } ** CID 379249: Memory - illegal accesses (OVERRUN) /plat/imx/imx8m/ddr/dram.c: 151 in dram_info_init() ________________________________________________________________________________________________________ *** CID 379249: Memory - illegal accesses (OVERRUN) /plat/imx/imx8m/ddr/dram.c: 151 in dram_info_init() 145 break; 146 } 147 } 148 dram_info.num_fsp = i; 149 150 /* check if has bypass mode support */ >>> CID 379249: Memory - illegal accesses (OVERRUN) >>> Overrunning array "dram_info.timing_info->fsp_table" of 4 4-byte elements at element index 4294967295 (byte offset 17179869183) using index "i - 1U" (which evaluates to 4294967295). 151 if (dram_info.timing_info->fsp_table[i-1] < 666) { 152 dram_info.bypass_mode = true; 153 } else { 154 dram_info.bypass_mode = false; 155 } 156 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

3 years, 10 months

1
0
0 0

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

by joanna.farley＠arm.com

This event has been updated with a note: "Updated Agenda for 14th July TF-A TechForum session next week." Changed: description TF-A Tech Forum Thursday Jul 14, 2022 ⋅ 4pm – 5pm United Kingdom Time AgendaLTS (Long Term Support) Releases DiscussionLed by Okash Khawaja (Google) and Varun Wadekar (NVIDIA)An initial discussion on some of the requirements and open questions of providing TF-A LTS releases. This initial session will concentrate on the technical aspects of LTS releases with suggestions and examples. Latter sessions can be expected to bring into the discussion resourcing and funding considerations.The hope is to establish and exchange views of the project community interest on this topic.==============================================================================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 thordur(a)google.com 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, 10 months

1
0
0 0

Re: Cannot successfully jump to the UEFI Boot Loader in the normal world with the RME enabled FVP_Base_RevC_2xAEMvA

by Erhu Feng

Hi, Thanks for the detailed documentation about how to enable RME in tf-a. I try to replace the tftf.bin with the normal boot firmware (edk2) to load the Linux in the normal world, but it fails. The log message from terminal_0 is shown below: INFO: RMM init start. INFO: RMM init end. INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x88000000 INFO: SPSR = 0x3c9 I found a possible solution from the archives: [https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…]. I try to modify the dts file under edk2-platform/Platform/ARM/VExpressPkg/DeviceTree/ to change the DDR memory range, which is similar to the modification for RME in [https://github.com/ARM-software/arm-trusted-firmware/blob/master/fdts/fvp-b…], but it does not solve the problem. So, how can I boot Linux in the normal world with RME enabled? Thanks,

3 years, 10 months

1
0
0 0

Manish Badarkhe added to maintainer list

by Manish Pandey2

Hi, I would like to introduce "Manish Badarkhe" <Manish.Badarkhe(a)arm.com> who has been added to the list of maintainers. This is based on his contribution to the project recently. Congratulations Manish B! Thanks Manish Pandey

3 years, 10 months

1
0
0 0

Addition of write() capability to IO MTD layer

by brian.neely＠analog.com

Hello, A project I’m working on requires write capability for a NOR flash device in BL2 (to update a small boot mux partition). I am considering adding this capability to the IO MTD layer (https://github.com/ARM-software/arm-trusted-firmware/blob/master/drivers/io…), but before doing so wanted to confirm this is in line with the architecture of this subsystem. Can someone confirm if this is an acceptable change? Regards, Brian

3 years, 10 months

2
3
0 0

Version 1.2.12 of zlib was released

by mikemcternan＠google.com

Hi! It looks like TF-A contains zlib 1.2.11 e.g. https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/lib/zlib/z… zlib.net gives their last release as 1.2.12 (March 27, 2022) with the following changelog: "Fix a deflate bug when using the Z_FIXED strategy that can result in out-of-bound accesses. Fix a deflate bug when the window is full in deflate_stored(). Speed up CRC-32 computations by a factor of 1.5 to 3. Use the hardware CRC-32 instruction on ARMv8 processors. Speed up crc32_combine() with powers of x tables. Add crc32_combine_gen() and crc32_combine_op() for fast combines. Due to the bug fixes, any installations of 1.2.11 should be replaced with 1.2.12." I'm not sure if this is significant as I couldn't find usages of deflate, but thought I would mention it in case others are relying on this functionality and wish to update. Kind regards, Mike

3 years, 10 months

2
1
0 0

synopsis emcc adma2/3 modes

by gauravverma999＠gmail.com

Hello all, I need to load Bl2 boot image file from emmc interface from 'Synopsys DesignWare Cores Mobile Storage Host Controller'. I can see an existing emmc driver for synopsis controller but it seems to have only support SDMA mode and not ADMA2 and ADMA3 modes. https://github.com/ARM-software/arm-trusted-firmware/blob/master/drivers/sy… Is my understanding correct. Is there a specific reason why ADMA2/3 modes are not supported in existing driver. Any plan to update them soon? I can see adma2/3 mode support available in Linux driver though. https://github.com/torvalds/linux/blob/master/drivers/mmc/host/sdhci-of-dwc…

3 years, 10 months

1
0
0 0

Invitation with note: TF-A Tech Forum (additional) @ Thu Jun 23, 2022 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

You have been invited to the following event with this note: "An additional TF-A Techforum this week." Title: TF-A Tech Forum (additional) I'm creating an additional TF-A Techforum this week as we have a batch of topics coming up so this is an additional meeting to our normal bi weekly meetings. This session will. be recorded and made available on our TF0 Tech forum pagesThis week we would like to present on: Arm CCA RMM <-> EL3 interfacePresenter : Javier Almansa Sobrino Description: Covering the communication interface between RMM and EL3. This comprises of the Boot Interface and the RMM-EL3 runtime interface.Patches under review. This will also cover the RMM <> EL3 world switch register conventionRelated patch stack under review: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+… 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  Organizer: Trusted Firmware Public MeetingsTrusted Firmware Public Meetings When: Thu Jun 23, 2022 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * joanna.farley(a)arm.com - organizer * don.harbin(a)linaro.org * tf-a(a)lists.trustedfirmware.org * okash.khawaja(a)gmail.com * marek.bykowski(a)gmail.com Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=MnBubWJoYTBkYmRt… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 10 months

1
0
0 0

Re: Cannot successfully jump to the UEFI Boot Loader in the normal world with the RME enabled FVP_Base_RevC_2xAEMvA

by 冯二虎

Hi, Thanks for the detailed documentation about how to enable RME in tf-a. I try to replace the tftf.bin with the normal boot firmware (edk2) to load the Linux in the normal world, but it fails. The log message from terminal_0 is shown below: INFO: RMM init start. INFO: RMM init end. INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x88000000 INFO: SPSR = 0x3c9 I found a possible solution from the archives: [https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…]. I try to modify the dts file under edk2-platform/Platform/ARM/VExpressPkg/DeviceTree/ to change the DDR memory range, which is similar to the modification for RME in [https://github.com/ARM-software/arm-trusted-firmware/blob/master/fdts/fvp-b…], but it does not solve the problem. So, how can I boot Linux in the normal world with RME enabled? Thanks,

3 years, 10 months

2
1
0 0

Updated invitation: TF-A Tech Forum @ Thu Jun 30, 2022 4pm - 5:30pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated Changed: time, description TF-A Tech Forum Thursday Jun 30, 2022 ⋅ 4pm – 5:30pm United Kingdom Time Extending next week to 90 minutes as we will have two topics we hope to cover this week. More details nearer the time but the topics will cover the SPMC@EL3 recently released in v2.7 and some un related DRTM work to be released soon.Session will be recorded and shared as previous sessions.Joanna======================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, 10 months

1
0
0 0

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

by joanna.farley＠arm.com

This event has been canceled with a note: "Apologies. I have three topics being prepared but none of them are ready to present this week. If any of these are ready for next week I will try to run an additional session next week on 23rd June otherwise we will have something ready for 30th June. I believe on the ML there has been thread where there is the suggestion for another LTS discussion however those interested have not requested to host a new session on that topic. See https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… " TF-A Tech Forum Thursday Jun 16, 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, 11 months

1
0
0 0

Invitation: TF-A Tech Forum @ Thu Jun 16, 2022 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

TF-A Tech Forum Thursday Jun 16, 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 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, 11 months

1
0
0 0

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

by joanna.farley＠arm.com

This event has been canceled. TF-A Tech Forum Thursday Jun 16, 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, 11 months

1
0
0 0

Measured boot and external TPM modules

by Ramon Fried

Hi, I'm currently working on porting TFA to our upcoming SOC. We plan to support Measured boot using external I2C TPM module. I'm wondering about the implementation of that in BL1. Do you think that I need to write the measurements directly to the I2C module in BL1 ? I'm asking because I would like to have the least source of problems in BL1 which I can't upgrade. I thought of storing the measurements in secure RAM and perhaps copy later. Would love to hear your thoughts. PS. Actually I would love to have the option to choose to implement TPM also in SW (fTPM using optee - as was done in the POC). I think that if I store the measurement of BL2 in secure RAM I can later change the specific TPM while upgrading only BL2/BL31... Thanks, Ramon

3 years, 11 months

4
9
0 0

Trusted Firmware version 2.7 is now available

by Daniel Boulby

Hi TF-A Community, We are pleased to announce the formal release of Trusted Firmware-A version 2.7, Trusted Firmware-A Tests version 2.7 , Hafnium version 2.7 and TF-A OpenCI Scripts 2.7 Releases now involve the tagging of multiple sub repositories. These went live on 1st June 2022. Notable Features of the Version 2.7 Release across all repositories include: * Poseidon CPU Library * Branch Record Buffer Extension (FEAT_BRBE) for Non-secure World support (Armv9.2) * Statistical Profiling Extension (FEAT_SPEV1P2) support (Armv8.7) * WFE and WFI instructions with Timeout (FEAT_WFxT) support (Armv8.7) * Alternate Floating-Point (FEAT_AFP) support (Armv8.7) * Extended Cache Index (FEAT_CCIDX) support (Armv8.3) * Twenty-Five Errata Mitigations covering Cortex-A710, A510, A78, X2 * Spectre Branch History Buffer (BHB) mitigations * New Architectural Features Detection Mechanism (Experimental Feature) * System Memory Management Unit (SMMU) Granule Protection Checks (GPC) for Secure and Non-secure World transactions * Measured Boot Driver improvements * Threat Model Documentation updates * Hafnium Firmware Framework for Arm A-profile (FF-A) v1.1 continued support * Hafnium Memory Tagging Extension (MTE) stack tagging support * FF-A Secure Partition Manager (SPM) operating at EL3 added (Experimental Feature) * Eight (8) new platforms added * Thirty-Eight (38) platforms updated Please refer to the TF-A [1], Hafnium [2] and TF-A Tests [3] changelogs for the complete summary of changes the previous release. TF-A [4], TF-A Test [5], Hafnium [6] and TF-A OpenCI Scripts [7] repositories are available. [1] https://trustedfirmware-a.readthedocs.io/en/latest/change-log.html#version-…<https://trustedfirmware-a.readthedocs.io/en/latest/change-log.html#version-…> [2] https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/HEAD/d…<https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/HEAD/d…> [3] Change Log & Release Notes — Trusted Firmware-A Tests documentation (trustedfirmware-a-tests.readthedocs.io)<https://trustedfirmware-a-tests.readthedocs.io/en/latest/change-log.html#> [4] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.7 [5] https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.7 [6] https://git.trustedfirmware.org/hafnium/hafnium.git/tag/?h=v2.7 [7] https://git.trustedfirmware.org/ci/tf-a-ci-scripts.git/tag/?h=v2.7 <https://git.trustedfirmware.org/ci/tf-a-ci-scripts.git/tag/?h=v2.7> Thanks, and best regards, Daniel Boulby

3 years, 11 months

1
0
0 0

[REGRESSION] v2.7-rc0 broken for STM32MP boards: lxa-mc1, avenger96, odyssey

by Ahmad Fatoum

Hello Yann, Hello Pascal, I've tried booting v2.7-rc0 on the lxa-mc1 and TF-A panics: NOTICE: CPU: STM32MP157C?? Rev.B NOTICE: Model: Linux Automation MC-1 board ERROR: regul ldo3: max value 750 is invalid PANIC at PC : 0x2ffeebb7 because the driver takes great offense at the content of the device tree. The parts in question were copy-pasted from ST DTs, but those ST DTs were fixed by commit 67d95409baae ("refactor(stm32mp1-fdts): update regulator description"). I can understand ST hesistancy to touch device trees of 'unofficial' boards, but I would appreciate that new features then, such as this regulator sanity checking, be made optional and off by default to not needlessly break other boards. Thanks, Ahmad -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

3 years, 11 months

1
0
0 0

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

by joanna.farley＠arm.com

This event has been canceled with this note: "Public holiday in the UK so cancelling with week." Title: TF-A Tech Forum 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   When: Thu Jun 2, 2022 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher - creator * 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 courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 11 months

1
0
0 0

Floating point math

by Bartus, Dan

We are using an arm ARCH-64 (A55) and we need to do some floating point math in BL2. It seems this is not enabled. Is there a reason why I cannot do FP math (security issue?) and if I can, how do I enable it? I am seeing this error when I use floats "-mgeneral-regs-only" thanks

3 years, 11 months

4
9
0 0

arm-trustedfirmware whether has unit test

by 郭浙伟(本记)

hi, I has quality engineer from china. I would to start study the Arm profile-A trustedfirmware and try to test it. I has read trustedfirmware documetion , From the Processes & policies Chap about CI part. "https://trustedfirmware-a.readthedocs.io/en/latest/process/contributing.htm… " Find ATF has Coverity Scan and test image build. but I would to know, trustedfirmware-a whether has unit test part in the code level quality check. Brs Tony

3 years, 11 months

2
1
0 0

ChangeLog-v2.7

by Jayanth Dodderi Chidanand

Hello All, Kindly take a look at the Changelog section (rendered version) for your respective platforms, as we approach closer to TF-A release v2.7. Please share your comments at review.trustedfirmware.org as we can address them accordingly. External Patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/15282 Rendered Version: https://ci-builds.trustedfirmware.org/static-files/La0ImPrSWDqkNWMSfH1vNhIR… Best regards, Jayanth

3 years, 11 months

2
1
0 0

Add neoverse-n1 support to QEMU SBSA

by Itaru Kitayama

Hi, I'd like to boot SBSA ref board with neoverse-n1 CPU, is anyone working on this? Itaru.

3 years, 11 months

2
8
1 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. 10 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 10 of 10 defect(s) ** CID 378520: (OVERRUN) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 441 in spmc_shm_convert_shmem_obj_from_v1_0() /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 441 in spmc_shm_convert_shmem_obj_from_v1_0() ________________________________________________________________________________________________________ *** CID 378520: (OVERRUN) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 441 in spmc_shm_convert_shmem_obj_from_v1_0() 435 emad_array_in = mtd_orig->emad; 436 emad_array_out = (struct ffa_emad_v1_0 *) 437 ((uint8_t *) out + out->emad_offset); 438 439 /* Copy across the emad structs. */ 440 for (unsigned int i = 0U; i < out->emad_count; i++) { >>> CID 378520: (OVERRUN) >>> Overrunning array of 48 bytes at byte offset 48 by dereferencing pointer "&emad_array_out[i]". [Note: The source code implementation of the function has been overridden by a builtin model.] 441 memcpy(&emad_array_out[i], &emad_array_in[i], 442 sizeof(struct ffa_emad_v1_0)); 443 } 444 445 /* Place the mrd descriptors after the end of the emad descriptors.*/ 446 mrd_in_offset = emad_array_in->comp_mrd_offset; /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 441 in spmc_shm_convert_shmem_obj_from_v1_0() 435 emad_array_in = mtd_orig->emad; 436 emad_array_out = (struct ffa_emad_v1_0 *) 437 ((uint8_t *) out + out->emad_offset); 438 439 /* Copy across the emad structs. */ 440 for (unsigned int i = 0U; i < out->emad_count; i++) { >>> CID 378520: (OVERRUN) >>> Calling "memcpy" with "&emad_array_in[i]" and "16UL" is suspicious because "emad_array_in" points into a buffer of 16 bytes and the function call may access "(char *)&emad_array_in[i] + 15UL". [Note: The source code implementation of the function has been overridden by a builtin model.] 441 memcpy(&emad_array_out[i], &emad_array_in[i], 442 sizeof(struct ffa_emad_v1_0)); 443 } 444 445 /* Place the mrd descriptors after the end of the emad descriptors.*/ 446 mrd_in_offset = emad_array_in->comp_mrd_offset; ** CID 378519: Memory - corruptions (OVERRUN) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 525 in spmc_shm_convert_mtd_to_v1_0() ________________________________________________________________________________________________________ *** CID 378519: Memory - corruptions (OVERRUN) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 525 in spmc_shm_convert_mtd_to_v1_0() 519 ((uint8_t *) mtd_orig + mtd_orig->emad_offset); 520 emad_array_out = out->emad; 521 522 /* Copy across the emad structs. */ 523 emad_in = emad_array_in; 524 for (unsigned int i = 0U; i < out->emad_count; i++) { >>> CID 378519: Memory - corruptions (OVERRUN) >>> Calling "memcpy" with "&emad_array_out[i]" and "16UL" is suspicious because "emad_array_out" points into a buffer of 16 bytes and the function call may access "(char *)&emad_array_out[i] + 15UL". [Note: The source code implementation of the function has been overridden by a builtin model.] 525 memcpy(&emad_array_out[i], emad_in, 526 sizeof(struct ffa_emad_v1_0)); 527 528 emad_in += mtd_orig->emad_size; 529 } 530 ** CID 378518: Program hangs (ORDER_REVERSAL) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1689 in spmc_ffa_mem_relinquish() ________________________________________________________________________________________________________ *** CID 378518: Program hangs (ORDER_REVERSAL) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1689 in spmc_ffa_mem_relinquish() 1683 if (req->endpoint_count == 0) { 1684 WARN("%s: endpoint count cannot be 0.\n", __func__); 1685 ret = FFA_ERROR_INVALID_PARAMETER; 1686 goto err_unlock_mailbox; 1687 } 1688 >>> CID 378518: Program hangs (ORDER_REVERSAL) >>> Calling "spin_lock" acquires lock "spmc_shmem_obj_state.lock" while holding lock "mailbox.lock" (count: 2 / 5). 1689 spin_lock(&spmc_shmem_obj_state.lock); 1690 1691 obj = spmc_shmem_obj_lookup(&spmc_shmem_obj_state, req->handle); 1692 if (obj == NULL) { 1693 ret = FFA_ERROR_INVALID_PARAMETER; 1694 goto err_unlock_all; ** CID 378517: Program hangs (ORDER_REVERSAL) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1338 in spmc_ffa_mem_retrieve_req() ________________________________________________________________________________________________________ *** CID 378517: Program hangs (ORDER_REVERSAL) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1338 in spmc_ffa_mem_retrieve_req() 1332 WARN("%s: invalid length %u < %zu\n", __func__, total_length, 1333 min_desc_size); 1334 ret = FFA_ERROR_INVALID_PARAMETER; 1335 goto err_unlock_mailbox; 1336 } 1337 >>> CID 378517: Program hangs (ORDER_REVERSAL) >>> Calling "spin_lock" acquires lock "spmc_shmem_obj_state.lock" while holding lock "mailbox.lock" (count: 2 / 5). 1338 spin_lock(&spmc_shmem_obj_state.lock); 1339 1340 obj = spmc_shmem_obj_lookup(&spmc_shmem_obj_state, req->handle); 1341 if (obj == NULL) { 1342 ret = FFA_ERROR_INVALID_PARAMETER; 1343 goto err_unlock_all; ** CID 378516: Null pointer dereferences (REVERSE_INULL) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1005 in spmc_ffa_fill_desc() ________________________________________________________________________________________________________ *** CID 378516: Null pointer dereferences (REVERSE_INULL) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1005 in spmc_ffa_fill_desc() 999 } 1000 1001 /* Get a new obj to store the v1.1 descriptor. */ 1002 v1_1_obj = 1003 spmc_shmem_obj_alloc(&spmc_shmem_obj_state, v1_1_desc_size); 1004 >>> CID 378516: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "obj" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 1005 if (!obj) { 1006 ret = FFA_ERROR_NO_MEMORY; 1007 goto err_arg; 1008 } 1009 1010 /* Perform the conversion from v1.0 to v1.1. */ ** CID 378515: (TAINTED_SCALAR) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1446 in spmc_ffa_mem_retrieve_req() /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1407 in spmc_ffa_mem_retrieve_req() ________________________________________________________________________________________________________ *** CID 378515: (TAINTED_SCALAR) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1483 in spmc_ffa_mem_retrieve_req() 1477 1478 /* 1479 * If the caller is v1.0 convert the descriptor, otherwise copy 1480 * directly. 1481 */ 1482 if (ffa_version == MAKE_FFA_VERSION(1, 0)) { >>> CID 378515: (TAINTED_SCALAR) >>> Passing tainted expression "obj->emad_count" to "spmc_populate_ffa_v1_0_descriptor", which uses it as a loop boundary. 1483 ret = spmc_populate_ffa_v1_0_descriptor(resp, obj, buf_size, 0, 1484 &copy_size, 1485 &out_desc_size); 1486 if (ret != 0U) { 1487 ERROR("%s: Failed to process descriptor.\n", __func__); 1488 goto err_unlock_all; /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1483 in spmc_ffa_mem_retrieve_req() 1477 1478 /* 1479 * If the caller is v1.0 convert the descriptor, otherwise copy 1480 * directly. 1481 */ 1482 if (ffa_version == MAKE_FFA_VERSION(1, 0)) { >>> CID 378515: (TAINTED_SCALAR) >>> Passing tainted expression "obj->address_range_count" to "spmc_populate_ffa_v1_0_descriptor", which uses it as an offset. 1483 ret = spmc_populate_ffa_v1_0_descriptor(resp, obj, buf_size, 0, 1484 &copy_size, 1485 &out_desc_size); 1486 if (ret != 0U) { 1487 ERROR("%s: Failed to process descriptor.\n", __func__); 1488 goto err_unlock_all; /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1483 in spmc_ffa_mem_retrieve_req() 1477 1478 /* 1479 * If the caller is v1.0 convert the descriptor, otherwise copy 1480 * directly. 1481 */ 1482 if (ffa_version == MAKE_FFA_VERSION(1, 0)) { >>> CID 378515: (TAINTED_SCALAR) >>> Passing tainted expression "obj->desc" to "spmc_populate_ffa_v1_0_descriptor", which uses it as an offset. 1483 ret = spmc_populate_ffa_v1_0_descriptor(resp, obj, buf_size, 0, 1484 &copy_size, 1485 &out_desc_size); 1486 if (ret != 0U) { 1487 ERROR("%s: Failed to process descriptor.\n", __func__); 1488 goto err_unlock_all; /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1483 in spmc_ffa_mem_retrieve_req() 1477 1478 /* 1479 * If the caller is v1.0 convert the descriptor, otherwise copy 1480 * directly. 1481 */ 1482 if (ffa_version == MAKE_FFA_VERSION(1, 0)) { >>> CID 378515: (TAINTED_SCALAR) >>> Passing tainted expression "obj->emad_size" to "spmc_populate_ffa_v1_0_descriptor", which uses it as an offset. 1483 ret = spmc_populate_ffa_v1_0_descriptor(resp, obj, buf_size, 0, 1484 &copy_size, 1485 &out_desc_size); 1486 if (ret != 0U) { 1487 ERROR("%s: Failed to process descriptor.\n", __func__); 1488 goto err_unlock_all; /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1446 in spmc_ffa_mem_retrieve_req() 1440 &emad_size); 1441 if (emad == NULL) { 1442 ret = FFA_ERROR_INVALID_PARAMETER; 1443 goto err_unlock_all; 1444 } 1445 >>> CID 378515: (TAINTED_SCALAR) >>> Using tainted variable "obj->desc.emad_count" as a loop boundary. 1446 for (size_t j = 0; j < obj->desc.emad_count; j++) { 1447 other_emad = spmc_shmem_obj_get_emad( 1448 &obj->desc, j, MAKE_FFA_VERSION(1, 1), 1449 &emad_size); 1450 1451 if (other_emad == NULL) { /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1407 in spmc_ffa_mem_retrieve_req() 1401 ret = FFA_ERROR_INVALID_PARAMETER; 1402 goto err_unlock_all; 1403 } 1404 } 1405 1406 /* Validate that the provided emad offset and structure is valid.*/ >>> CID 378515: (TAINTED_SCALAR) >>> Using tainted variable "req->emad_count" as a loop boundary. 1407 for (size_t i = 0; i < req->emad_count; i++) { 1408 size_t emad_size; 1409 struct ffa_emad_v1_0 *emad; 1410 1411 emad = spmc_shmem_obj_get_emad(req, i, ffa_version, 1412 &emad_size); ** CID 378514: (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 378514: (TAINTED_SCALAR) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1604 in spmc_ffa_mem_frag_rx() 1598 * If the caller is v1.0 convert the descriptor, otherwise copy 1599 * directly. 1600 */ 1601 if (ffa_version == MAKE_FFA_VERSION(1, 0)) { 1602 size_t out_desc_size; 1603 >>> CID 378514: (TAINTED_SCALAR) >>> Passing tainted expression "obj->emad_count" to "spmc_populate_ffa_v1_0_descriptor", which uses it as a loop boundary. 1604 ret = spmc_populate_ffa_v1_0_descriptor(mbox->rx_buffer, obj, 1605 buf_size, 1606 fragment_offset, 1607 &copy_size, 1608 &out_desc_size); 1609 if (ret != 0U) { /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1604 in spmc_ffa_mem_frag_rx() 1598 * If the caller is v1.0 convert the descriptor, otherwise copy 1599 * directly. 1600 */ 1601 if (ffa_version == MAKE_FFA_VERSION(1, 0)) { 1602 size_t out_desc_size; 1603 >>> CID 378514: (TAINTED_SCALAR) >>> Passing tainted expression "obj->emad_size" to "spmc_populate_ffa_v1_0_descriptor", which uses it as an offset. 1604 ret = spmc_populate_ffa_v1_0_descriptor(mbox->rx_buffer, obj, 1605 buf_size, 1606 fragment_offset, 1607 &copy_size, 1608 &out_desc_size); 1609 if (ret != 0U) { /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1604 in spmc_ffa_mem_frag_rx() 1598 * If the caller is v1.0 convert the descriptor, otherwise copy 1599 * directly. 1600 */ 1601 if (ffa_version == MAKE_FFA_VERSION(1, 0)) { 1602 size_t out_desc_size; 1603 >>> CID 378514: (TAINTED_SCALAR) >>> Passing tainted expression "obj->address_range_count" to "spmc_populate_ffa_v1_0_descriptor", which uses it as an offset. 1604 ret = spmc_populate_ffa_v1_0_descriptor(mbox->rx_buffer, obj, 1605 buf_size, 1606 fragment_offset, 1607 &copy_size, 1608 &out_desc_size); 1609 if (ret != 0U) { /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1604 in spmc_ffa_mem_frag_rx() 1598 * If the caller is v1.0 convert the descriptor, otherwise copy 1599 * directly. 1600 */ 1601 if (ffa_version == MAKE_FFA_VERSION(1, 0)) { 1602 size_t out_desc_size; 1603 >>> CID 378514: (TAINTED_SCALAR) >>> Passing tainted expression "obj->desc" to "spmc_populate_ffa_v1_0_descriptor", which uses it as an offset. 1604 ret = spmc_populate_ffa_v1_0_descriptor(mbox->rx_buffer, obj, 1605 buf_size, 1606 fragment_offset, 1607 &copy_size, 1608 &out_desc_size); 1609 if (ret != 0U) { ** CID 378513: Null pointer dereferences (FORWARD_NULL) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1320 in spmc_ffa_mem_retrieve_req() ________________________________________________________________________________________________________ *** CID 378513: Null pointer dereferences (FORWARD_NULL) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1320 in spmc_ffa_mem_retrieve_req() 1314 __func__); 1315 ret = FFA_ERROR_INVALID_PARAMETER; 1316 goto err_unlock_mailbox; 1317 } 1318 1319 if (req->emad_count == 0U) { >>> CID 378513: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "obj". 1320 WARN("%s: unsupported attribute desc count %u.\n", 1321 __func__, obj->desc.emad_count); 1322 return -EINVAL; 1323 } 1324 1325 /* Determine the appropriate minimum descriptor size. */ ** CID 378512: Null pointer dereferences (NULL_RETURNS) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1714 in spmc_ffa_mem_relinquish() ________________________________________________________________________________________________________ *** CID 378512: Null pointer dereferences (NULL_RETURNS) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1714 in spmc_ffa_mem_relinquish() 1708 struct ffa_emad_v1_0 *emad; 1709 1710 for (unsigned int j = 0; j < obj->desc.emad_count; j++) { 1711 emad = spmc_shmem_obj_get_emad(&obj->desc, j, 1712 MAKE_FFA_VERSION(1, 1), 1713 &emad_size); >>> CID 378512: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing "emad", which is known to be "NULL". 1714 if (req->endpoint_array[i] == 1715 emad->mapd.endpoint_id) { 1716 found = true; 1717 break; 1718 } 1719 } ** CID 378511: Memory - corruptions (OVERRUN) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 681 in spmc_shmem_check_obj() ________________________________________________________________________________________________________ *** CID 378511: Memory - corruptions (OVERRUN) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 681 in spmc_shmem_check_obj() 675 } 676 677 /* 678 * Validate the calculated emad address resides within the 679 * descriptor. 680 */ >>> CID 378511: Memory - corruptions (OVERRUN) >>> "(uint8_t *)&obj->desc + obj->desc_size" evaluates to an address that is at byte offset 64 of an array of 48 bytes. 681 if ((uintptr_t) emad >= 682 (uintptr_t)((uint8_t *) &obj->desc + obj->desc_size)) { 683 WARN("Invalid emad access.\n"); 684 return -EINVAL; 685 } 686 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

3 years, 12 months

1
0
0 0

[Question] fix(security): apply SMCCC_ARCH_WORKAROUND_3 to A73/A75/A72/A57

by JY Ho (何駿彥)

Dear Sirs, I’m TF-A developer of MediaTek and have a situation of CVE patch (https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/14298) with CA73. In CA73 platform with 64-bit TF-A v2.4 and 64-bit OP-TEE v3.16, system will occur halt during boot flow after we applied fix(security): apply SMCCC_ARCH_WORKAROUND_3 to A73/A75/A72/A57<https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/14298>. We used ICE to trace boot flow step by step, and found S-EL1 will ask EL3 its SMC_VERSION. In the fastcall, TF-A will execute wa_cve_2017_5715_bpiall_vbar()<https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/14298/11/lib…> which back up some setting and switch processor from AArch-64 to AArch-32 and does BPIALL<https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/14298/11/lib…>. But AArch32 cannot access and run over than 4G bus address without LPAE. (Suppose the TF-A and OP-TEE are locate on over than 4G bus address.) Maybe can we replace AArch32_stub with IC IALLU ? Or add LPAE setting before do AArch32_stub? (I don’t know it make sense or not) Thank you. JY

3 years, 12 months

3
3
1 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. 6 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 3 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 6 of 6 defect(s) ** CID 378487: Integer handling issues (INCOMPATIBLE_CAST) ________________________________________________________________________________________________________ *** CID 378487: Integer handling issues (INCOMPATIBLE_CAST) /plat/intel/soc/common/socfpga_sip_svc.c: 738 in sip_smc_handler_v1() 732 733 case INTEL_SIP_SMC_RSU_NOTIFY: 734 status = intel_rsu_notify(x1); 735 SMC_RET1(handle, status); 736 737 case INTEL_SIP_SMC_RSU_RETRY_COUNTER: >>> CID 378487: Integer handling issues (INCOMPATIBLE_CAST) >>> Pointer "rsu_respbuf" points to an object whose effective type is "unsigned long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness. 738 status = intel_rsu_retry_counter((uint32_t *)rsu_respbuf, 739 ARRAY_SIZE(rsu_respbuf), &retval); 740 if (status) { 741 SMC_RET1(handle, status); 742 } else { 743 SMC_RET2(handle, status, retval); ** CID 378486: Control flow issues (NO_EFFECT) /plat/intel/soc/common/sip/socfpga_sip_fcs.c: 1734 in intel_fcs_aes_crypt_update_finalize() ________________________________________________________________________________________________________ *** CID 378486: Control flow issues (NO_EFFECT) /plat/intel/soc/common/sip/socfpga_sip_fcs.c: 1734 in intel_fcs_aes_crypt_update_finalize() 1728 1729 if (is_finalised != 0U) { 1730 memset((void *)&fcs_aes_init_payload, 0, 1731 sizeof(fcs_aes_init_payload)); 1732 } 1733 >>> CID 378486: Control flow issues (NO_EFFECT) >>> This less-than-zero comparison of an unsigned value is never true. "status < 0U". 1734 if (status < 0U) { 1735 return INTEL_SIP_SMC_STATUS_ERROR; 1736 } 1737 1738 return INTEL_SIP_SMC_STATUS_OK; ** CID 378485: Null pointer dereferences (FORWARD_NULL) /lib/psa/measured_boot.c: 26 in print_byte_array() ________________________________________________________________________________________________________ *** CID 378485: Null pointer dereferences (FORWARD_NULL) /lib/psa/measured_boot.c: 26 in print_byte_array() 20 21 if (array == NULL || len == 0U) { 22 (void)printf("\n"); 23 } 24 25 for (i = 0U; i < len; ++i) { >>> CID 378485: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "array". 26 (void)printf(" %02x", array[i]); 27 if ((i & U(0xF)) == U(0xF)) { 28 (void)printf("\n"); 29 if (i < (len - 1U)) { 30 INFO("\t\t:"); 31 } ** CID 378484: Null pointer dereferences (FORWARD_NULL) /plat/intel/soc/common/soc/socfpga_mailbox.c: 244 in mailbox_read_response_async() ________________________________________________________________________________________________________ *** CID 378484: Null pointer dereferences (FORWARD_NULL) /plat/intel/soc/common/soc/socfpga_mailbox.c: 244 in mailbox_read_response_async() 238 ret_resp_len = MBOX_RESP_LEN(mailbox_resp_ctr.payload->header); 239 if ((ret_resp_len > 0) && (response == NULL) && resp_len) { 240 if (*resp_len > ret_resp_len) { 241 *resp_len = ret_resp_len; 242 } 243 >>> CID 378484: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "response" to "memcpy", which dereferences it. [Note: The source code implementation of the function has been overridden by a builtin model.] 244 memcpy((uint8_t *) response, 245 (uint8_t *) mailbox_resp_ctr.payload->data, 246 *resp_len * MBOX_WORD_BYTE); 247 } 248 249 /* reset async response param */ ** CID 378483: Integer handling issues (INCOMPATIBLE_CAST) ________________________________________________________________________________________________________ *** CID 378483: Integer handling issues (INCOMPATIBLE_CAST) /plat/intel/soc/common/socfpga_sip_svc.c: 881 in sip_smc_handler_v1() 875 case INTEL_SIP_SMC_FCS_ATTESTATION_MEASUREMENTS: 876 status = intel_fcs_get_measurement(x1, x2, x3, 877 (uint32_t *) &x4, &mbox_error); 878 SMC_RET4(handle, status, mbox_error, x3, x4); 879 880 case INTEL_SIP_SMC_FCS_GET_ATTESTATION_CERT: >>> CID 378483: Integer handling issues (INCOMPATIBLE_CAST) >>> Pointer "&x3" points to an object whose effective type is "unsigned long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness. 881 status = intel_fcs_get_attestation_cert(x1, x2, 882 (uint32_t *) &x3, &mbox_error); 883 SMC_RET4(handle, status, mbox_error, x2, x3); 884 885 case INTEL_SIP_SMC_FCS_CREATE_CERT_ON_RELOAD: 886 status = intel_fcs_create_cert_on_reload(x1, &mbox_error); ** CID 378482: (INCOMPATIBLE_CAST) ________________________________________________________________________________________________________ *** CID 378482: (INCOMPATIBLE_CAST) /plat/intel/soc/common/socfpga_sip_svc.c: 871 in sip_smc_handler_v1() 865 866 case INTEL_SIP_SMC_FCS_CHIP_ID: 867 status = intel_fcs_chip_id(&retval, &retval2, &mbox_error); 868 SMC_RET4(handle, status, mbox_error, retval, retval2); 869 870 case INTEL_SIP_SMC_FCS_ATTESTATION_SUBKEY: >>> CID 378482: (INCOMPATIBLE_CAST) >>> Pointer "&x4" points to an object whose effective type is "unsigned long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness. 871 status = intel_fcs_attestation_subkey(x1, x2, x3, 872 (uint32_t *) &x4, &mbox_error); 873 SMC_RET4(handle, status, mbox_error, x3, x4); 874 875 case INTEL_SIP_SMC_FCS_ATTESTATION_MEASUREMENTS: 876 status = intel_fcs_get_measurement(x1, x2, x3, /plat/intel/soc/common/socfpga_sip_svc.c: 876 in sip_smc_handler_v1() 870 case INTEL_SIP_SMC_FCS_ATTESTATION_SUBKEY: 871 status = intel_fcs_attestation_subkey(x1, x2, x3, 872 (uint32_t *) &x4, &mbox_error); 873 SMC_RET4(handle, status, mbox_error, x3, x4); 874 875 case INTEL_SIP_SMC_FCS_ATTESTATION_MEASUREMENTS: >>> CID 378482: (INCOMPATIBLE_CAST) >>> Pointer "&x4" points to an object whose effective type is "unsigned long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness. 876 status = intel_fcs_get_measurement(x1, x2, x3, 877 (uint32_t *) &x4, &mbox_error); 878 SMC_RET4(handle, status, mbox_error, x3, x4); 879 880 case INTEL_SIP_SMC_FCS_GET_ATTESTATION_CERT: 881 status = intel_fcs_get_attestation_cert(x1, x2, ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

3 years, 12 months

1
0
0 0

imx8mn and HAB

by Heiko Thiery

Hi, We use mainline TF-A and have problems using the HAB API in the U-Boot. We see for example that the hab_auth_img command fails in the mainline U-Boot. If we switch to the downstream NXP TF-A it works. Is this to be expected? -- Heiko

3 years, 12 months

3
5
0 0

Issue about passing arguments between the BL1 and BL2 in Arch32

by 邬金平

Hi Arguments between the BL1 and BL2 is overlap by zeromem when BL2 start. 1. BL2 save r3 to r12 arm-trusted-firmware/bl2/aarch32/bl2_entrypoint.S /*--------------------------------------------- * Save arguments x0 - x3 from BL1 for future * use. * --------------------------------------------- */ mov r9, r0 mov r10, r1 mov r11, r2 mov r12, r3 2. BL2 call zeromem to clear bss arm-trusted-firmware/bl2/aarch32/bl2_entrypoint.S ldr r0, =__BSS_START__ ldr r1, =__BSS_END__ sub r1, r1, r0 bl zeromem arm-trusted-firmware/lib/aarch32/misc_helpers.S tmp .req r12 /* Temporary scratch register */ r12 used as scratch register 3. r3 restore from r12 arm-trusted-firmware/bl2/aarch32/bl2_entrypoint.S mov r0, r9 mov r1, r10 mov r2, r11 mov r3, r12 I can try to save it in other registers, but can not guarantee that the register will not be damaged. Is there any better way to deal with this problem? Thanks.

3 years, 12 months

2
1
0 0

ECLAIR for static analysis

by Varun Wadekar

Hi @Joanna<mailto:Joanna.Farley@arm.com>, I am glad that tf.org has taken this step to improve code quality with the latest announcement [1]. Some questions to understand the model a bit better. 1. Is the tool available to the community? 2. Can people run this before submission? Or is it restricted to a certain group? 3. Will full reports be released to the community? 4. What will the deployment model look like? I suggest we discuss this in a tech forum to reach the entire community. -Varun [1] https://www.trustedfirmware.org/news/BugSeng_press_release/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.trust…> https://www.bugseng.com/eclair<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.bugse…> https://www.bugseng.com/sites/default/files/resources/ECLAIR_TUV-SUD_Certif…<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.bugse…>

4 years

2
1
0 0

About SVE issue

by Ming Huang

Hi, We use TF-A v2.5 with ENABLE_SVE_FOR_NS=1 and SPM_MM=1 and boot linux kernel is ok. Atfer upgrade TF-A with patch fix(spm_mm): do not compile if SVE/SME is enabled (4333f95bedb), we set ENABLE_SVE_FOR_NS=0 to fix compile error, but we get exception and hang in EL3 when boot kernel: ----------------------------------------------------------------------------------- [ 0.000000] Linux version 5.10.23-003debug.ali5000.alios7.aarch64 (root(a)j66e01291.sqa.eu95) (gcc (GCC) 10.2.1 20200825 (Alibaba 10.2.1-3 2.17) ...... [ 0.000000] pcpu-alloc: [1] 80 [1] 81 [1] 82 [1] 83 [1] 84 [1] 85 [1] 86 [1] 87 [ 0.000000] pcpu-alloc: [1] 88 [1] 89 [1] 90 [1] 91 [1] 92 [1] 93 [1] 94 [1] 95 ERROR: Excepton received on 0x81000000, spsr_el3:89,reason:1 esr_el3:0x66000000 Exception Class = 19: Access to SVE functionality trapped as a result of CPACR_EL1.ZEN,CPTR_EL2.ZEN, CPTR_EL2.TZ, or CPTR_EL3.EZ. ----------------------------------------------------------------------------------- How to fix the exception issue? Can we remove the below lines? ifeq (${ENABLE_SVE_FOR_NS},1) $(error "Error: SPM_MM is not compatible with ENABLE_SVE_FOR_NS") endif Regards, Ming Huang

4 years

2
2
0 0

Trusted Firmware-A v2.7 release activities in May

by Daniel Boulby

TF-A Community, This is to notify that we are planning to target the Trusted Firmware-A 2.7 release during the 4th week of May as part of the regular 6 month cadence. The aim is to consolidate all TF-A work since the 2.6 release. As part of this, a release candidate tag will be created and release activities will commence from 23rd May across all TF-A repositories. Essentially, we will not merge any major enhancements from this date until the release is made. Please ensure any patches desired to make the 2.7 release are submitted in good time to be complete by 20th May. Any major enhancement patches still open after that date will not be merged until after the release. This will involve the various repositories making up the broader TF-A project including the TF-A mainline, TF-A Tests, Hafnium, TF-A CI Scripts and TF-A CI Jobs. We will endeavour minimise the disruption on patch merging and complete release activities ASAP after we start. Thanks, Daniel

4 years

1
0
0 0

Issue in HW config consumption by secure BL components

by Manish Badarkhe

Hi All, Currently, in Arm platforms, BL2 loads HW config in the non-secure memory so that it can be consumed by both non-secure components (BL33) and secure (BL31, BL32) components. In most cases, this shouldn't be an issue since no software runs in non-secure world at this time (i.e. non-secure world has not been started yet) However, it doesn't provide a guarantee though since any malicious external NS-agents (such as an external debugger)can take control of this memory region for update/corruption after BL2 loads this region and before BL31 consumes it. Consider below scenario: 1. BL2 loads HW_CONFIG from flash to NS DRAM. 2. BL2 authenticates HW_CONFIG in NS DRAM. 3. A malicious non-secure agent modifies the contents of HW_CONFIG in NS DRAM, such that it induces a different behaviour in BL31. 1. BL31 consumes HW_CONFIG without noticing it has changed. To overcome this issue, I created a patch [1] to load the HW-config into secure memory, and that eventually will be used by BL31/sp_min and BL32 components. Additionally, BL31/sp_min copies the HW-config present in secure memory to a non-secure location before passing it on to BL33. In order to accomplish this, mapped secure DRAM in BL31/sp_min and BL32, and non-secure DRAM in BL31/sp_min. I believe some platforms may have similar kind of issue i.e. HW config placed in non-secure memory consumed by both secure and non-secure components. It is appreciated if you review the patch [1] I posted and provide feedback. This patch [1] also mitigates threat ID #3 for FVP platform as per the TF-A threat model [2] (Bypass image authentication scenario). [1]: https://review.trustedfirmware.org/q/topic:%22refactor-hw-config-load%22+(s… [2]: https://trustedfirmware-a.readthedocs.io/en/latest/threat_model/threat_mode… Thanks, Manish Badarkhe

4 years

1
1
0 0

TF-A Tech-Forum Agenda for Thursday 05-May-22 at 4pm BST

by Bipin Ravi

Topic: FF-A v1.1 Boot protocol implementation Presented by: Joao Alves Agenda: This session presents the recently introduced FF-A v1.1 Boot protocol implementation, motivations and challenges. The change set spans across TF-A, Hafnium and TF-A-tests repositories. The presentation covers the TF-A build flow and Secure Partitions packaging, how Hafnium consumes the new SP package format and passes boot data to SPs. Link to changes: FF-A v1.1 boot protocol<https://review.trustedfirmware.org/q/topic:%22ja%252Fboot_protocol%22+(stat…> ================================================= 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.g… Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974https://www.google.com/url?q=https://zoom.us/j/… 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/ad27hc6t7hhttps://www.google.com/url?q=https://zoom.us/u/… Thanks & best regards, --Bipin Ravi

4 years

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. 3 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 378361: Null pointer dereferences (NULL_RETURNS) /plat/arm/board/fvp/fvp_bl2_setup.c: 84 in plat_get_next_bl_params() ________________________________________________________________________________________________________ *** CID 378361: Null pointer dereferences (NULL_RETURNS) /plat/arm/board/fvp/fvp_bl2_setup.c: 84 in plat_get_next_bl_params() 78 79 /* To retrieve actual size of the HW_CONFIG */ 80 param_node = get_bl_mem_params_node(HW_CONFIG_ID); 81 assert(param_node != NULL); 82 83 /* Copy HW config from Secure address to NS address */ >>> CID 378361: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing "hw_config_info", which is known to be "NULL". 84 memcpy((void *)hw_config_info->ns_config_addr, 85 (void *)hw_config_info->config_addr, 86 (size_t)param_node->image_info.image_size); 87 88 /* 89 * Ensure HW-config device tree committed to memory, as there is ** CID 378360: (NULL_RETURNS) /plat/renesas/rzg/bl2_plat_setup.c: 411 in bl2_plat_handle_post_image_load() /plat/renesas/rcar/bl2_plat_setup.c: 446 in bl2_plat_handle_post_image_load() /plat/st/stm32mp1/bl2_plat_setup.c: 466 in bl2_plat_handle_post_image_load() /plat/renesas/rcar/bl2_plat_setup.c: 465 in bl2_plat_handle_post_image_load() /plat/renesas/rzg/bl2_plat_setup.c: 407 in bl2_plat_handle_post_image_load() /plat/st/stm32mp1/bl2_plat_setup.c: 472 in bl2_plat_handle_post_image_load() /plat/renesas/rcar/bl2_plat_setup.c: 448 in bl2_plat_handle_post_image_load() /plat/renesas/rcar/bl2_plat_setup.c: 440 in bl2_plat_handle_post_image_load() /plat/renesas/rzg/bl2_plat_setup.c: 397 in bl2_plat_handle_post_image_load() /plat/renesas/rzg/bl2_plat_setup.c: 404 in bl2_plat_handle_post_image_load() /plat/st/stm32mp1/bl2_plat_setup.c: 529 in bl2_plat_handle_post_image_load() ________________________________________________________________________________________________________ *** CID 378360: (NULL_RETURNS) /plat/renesas/rzg/bl2_plat_setup.c: 411 in bl2_plat_handle_post_image_load() 405 } 406 407 memcpy(&params->bl32_ep_info, &bl_mem_params->ep_info, 408 sizeof(entry_point_info_t)); 409 break; 410 case BL33_IMAGE_ID: >>> CID 378360: (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "&bl_mem_params->ep_info" when calling "memcpy". [Note: The source code implementation of the function has been overridden by a builtin model.] 411 memcpy(&params->bl33_ep_info, &bl_mem_params->ep_info, 412 sizeof(entry_point_info_t)); 413 break; 414 default: 415 break; 416 } /plat/renesas/rcar/bl2_plat_setup.c: 446 in bl2_plat_handle_post_image_load() 440 bl_mem_params->image_info.image_base = dest; 441 break; 442 case BL32_IMAGE_ID: 443 ret = rcar_get_dest_addr_from_cert(TRUSTED_OS_FW_CONTENT_CERT_ID, 444 &dest); 445 if (!ret) >>> CID 378360: (NULL_RETURNS) >>> Dereferencing "bl_mem_params", which is known to be "NULL". 446 bl_mem_params->image_info.image_base = dest; 447 448 memcpy(&params->bl32_ep_info, &bl_mem_params->ep_info, 449 sizeof(entry_point_info_t)); 450 break; 451 case BL33_IMAGE_ID: /plat/st/stm32mp1/bl2_plat_setup.c: 466 in bl2_plat_handle_post_image_load() 460 switch (image_ids[i]) { 461 case BL32_IMAGE_ID: 462 bl_mem_params->ep_info.pc = config_info->config_addr; 463 464 /* In case of OPTEE, initialize address space with tos_fw addr */ 465 pager_mem_params = get_bl_mem_params_node(BL32_EXTRA1_IMAGE_ID); >>> CID 378360: (NULL_RETURNS) >>> Dereferencing "pager_mem_params", which is known to be "NULL". 466 pager_mem_params->image_info.image_base = config_info->config_addr; 467 pager_mem_params->image_info.image_max_size = 468 config_info->config_max_size; 469 470 /* Init base and size for pager if exist */ 471 paged_mem_params = get_bl_mem_params_node(BL32_EXTRA2_IMAGE_ID); /plat/renesas/rcar/bl2_plat_setup.c: 465 in bl2_plat_handle_post_image_load() 459 } else { 460 /* plain image, copy it in place */ 461 memcpy((void *)BL33_BASE, (void *)BL33_COMP_BASE, 462 bl_mem_params->image_info.image_size); 463 } 464 #endif >>> CID 378360: (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "&bl_mem_params->ep_info" when calling "memcpy". [Note: The source code implementation of the function has been overridden by a builtin model.] 465 memcpy(&params->bl33_ep_info, &bl_mem_params->ep_info, 466 sizeof(entry_point_info_t)); 467 break; 468 } 469 470 return 0; /plat/renesas/rzg/bl2_plat_setup.c: 407 in bl2_plat_handle_post_image_load() 401 ret = rzg_get_dest_addr_from_cert(TRUSTED_OS_FW_CONTENT_CERT_ID, 402 &dest); 403 if (ret == 0U) { 404 bl_mem_params->image_info.image_base = dest; 405 } 406 >>> CID 378360: (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "&bl_mem_params->ep_info" when calling "memcpy". [Note: The source code implementation of the function has been overridden by a builtin model.] 407 memcpy(&params->bl32_ep_info, &bl_mem_params->ep_info, 408 sizeof(entry_point_info_t)); 409 break; 410 case BL33_IMAGE_ID: 411 memcpy(&params->bl33_ep_info, &bl_mem_params->ep_info, 412 sizeof(entry_point_info_t)); /plat/st/stm32mp1/bl2_plat_setup.c: 472 in bl2_plat_handle_post_image_load() 466 pager_mem_params->image_info.image_base = config_info->config_addr; 467 pager_mem_params->image_info.image_max_size = 468 config_info->config_max_size; 469 470 /* Init base and size for pager if exist */ 471 paged_mem_params = get_bl_mem_params_node(BL32_EXTRA2_IMAGE_ID); >>> CID 378360: (NULL_RETURNS) >>> Dereferencing "paged_mem_params", which is known to be "NULL". 472 paged_mem_params->image_info.image_base = STM32MP_DDR_BASE + 473 (dt_get_ddr_size() - STM32MP_DDR_S_SIZE - 474 STM32MP_DDR_SHMEM_SIZE); 475 paged_mem_params->image_info.image_max_size = STM32MP_DDR_S_SIZE; 476 break; 477 /plat/renesas/rcar/bl2_plat_setup.c: 448 in bl2_plat_handle_post_image_load() 442 case BL32_IMAGE_ID: 443 ret = rcar_get_dest_addr_from_cert(TRUSTED_OS_FW_CONTENT_CERT_ID, 444 &dest); 445 if (!ret) 446 bl_mem_params->image_info.image_base = dest; 447 >>> CID 378360: (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "&bl_mem_params->ep_info" when calling "memcpy". [Note: The source code implementation of the function has been overridden by a builtin model.] 448 memcpy(&params->bl32_ep_info, &bl_mem_params->ep_info, 449 sizeof(entry_point_info_t)); 450 break; 451 case BL33_IMAGE_ID: 452 #if RCAR_GEN3_BL33_GZIP == 1 453 if ((mmio_read_32(BL33_COMP_BASE) & 0xffff) == 0x8b1f) { /plat/renesas/rcar/bl2_plat_setup.c: 440 in bl2_plat_handle_post_image_load() 434 435 switch (image_id) { 436 case BL31_IMAGE_ID: 437 ret = rcar_get_dest_addr_from_cert(SOC_FW_CONTENT_CERT_ID, 438 &dest); 439 if (!ret) >>> CID 378360: (NULL_RETURNS) >>> Dereferencing "bl_mem_params", which is known to be "NULL". 440 bl_mem_params->image_info.image_base = dest; 441 break; 442 case BL32_IMAGE_ID: 443 ret = rcar_get_dest_addr_from_cert(TRUSTED_OS_FW_CONTENT_CERT_ID, 444 &dest); 445 if (!ret) /plat/renesas/rzg/bl2_plat_setup.c: 397 in bl2_plat_handle_post_image_load() 391 392 switch (image_id) { 393 case BL31_IMAGE_ID: 394 ret = rzg_get_dest_addr_from_cert(SOC_FW_CONTENT_CERT_ID, 395 &dest); 396 if (ret == 0U) { >>> CID 378360: (NULL_RETURNS) >>> Dereferencing "bl_mem_params", which is known to be "NULL". 397 bl_mem_params->image_info.image_base = dest; 398 } 399 break; 400 case BL32_IMAGE_ID: 401 ret = rzg_get_dest_addr_from_cert(TRUSTED_OS_FW_CONTENT_CERT_ID, 402 &dest); /plat/renesas/rzg/bl2_plat_setup.c: 404 in bl2_plat_handle_post_image_load() 398 } 399 break; 400 case BL32_IMAGE_ID: 401 ret = rzg_get_dest_addr_from_cert(TRUSTED_OS_FW_CONTENT_CERT_ID, 402 &dest); 403 if (ret == 0U) { >>> CID 378360: (NULL_RETURNS) >>> Dereferencing "bl_mem_params", which is known to be "NULL". 404 bl_mem_params->image_info.image_base = dest; 405 } 406 407 memcpy(&params->bl32_ep_info, &bl_mem_params->ep_info, 408 sizeof(entry_point_info_t)); 409 break; /plat/st/stm32mp1/bl2_plat_setup.c: 529 in bl2_plat_handle_post_image_load() 523 bl_mem_params->ep_info.args.arg1 = 0; /* Unused */ 524 bl_mem_params->ep_info.args.arg2 = 0; /* No DT supported */ 525 } else { 526 #if !STM32MP_USE_STM32IMAGE 527 bl_mem_params->ep_info.pc = bl_mem_params->image_info.image_base; 528 tos_fw_mem_params = get_bl_mem_params_node(TOS_FW_CONFIG_ID); >>> CID 378360: (NULL_RETURNS) >>> Dereferencing "tos_fw_mem_params", which is known to be "NULL". 529 bl_mem_params->image_info.image_max_size += 530 tos_fw_mem_params->image_info.image_max_size; 531 #endif /* !STM32MP_USE_STM32IMAGE */ 532 bl_mem_params->ep_info.args.arg0 = 0; 533 } 534 break; ** CID 378359: Null pointer dereferences (NULL_RETURNS) /plat/st/common/bl2_io_storage.c: 413 in bl2_plat_handle_pre_image_load() ________________________________________________________________________________________________________ *** CID 378359: Null pointer dereferences (NULL_RETURNS) /plat/st/common/bl2_io_storage.c: 413 in bl2_plat_handle_pre_image_load() 407 image_block_spec.length = entry->length; 408 #endif 409 gpt_init_done = true; 410 } else { 411 bl_mem_params_node_t *bl_mem_params = get_bl_mem_params_node(image_id); 412 >>> CID 378359: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing "bl_mem_params", which is known to be "NULL". 413 mmc_block_dev_spec.buffer.offset = bl_mem_params->image_info.image_base; 414 mmc_block_dev_spec.buffer.length = bl_mem_params->image_info.image_max_size; 415 } 416 417 break; 418 #endif ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years

1
0
0 0

Trusted Firmware-A v2.7 release activities in May 2022

by Joanna Farley

TF-A Community, This is to notify that we are planning to target the Trusted Firmware-A 2.7 release during the fourth week of May 2021 as part of the regular 6 month cadence. This is a little later than originally targeted due to the number of patches still under review from contributors. The aim is to consolidate all TF-A work since the 2.6 release. As part of this, a release candidate tag will be created and release activities will commence some time during the week ending 20th May 2022 across all TF-A repositories. Any major enhancement patches still open after that date will not be merged until after the release. This release will involve the various repositories making up the broader TF-A project including the TF-A mainline, TF-A Tests, Hafnium, TF-A CI Scripts and TF-A CI Jobs. We will endeavour minimise the disruption on patch merging and complete release activities ASAP after we start. Thanks Joanna

4 years

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 378231: Control flow issues (UNREACHABLE) /plat/intel/soc/common/socfpga_sip_svc.c: 312 in is_out_of_sec_range() ________________________________________________________________________________________________________ *** CID 378231: Control flow issues (UNREACHABLE) /plat/intel/soc/common/socfpga_sip_svc.c: 312 in is_out_of_sec_range() 306 static int is_out_of_sec_range(uint64_t reg_addr) 307 { 308 #if DEBUG 309 return 0; 310 #endif 311 >>> CID 378231: Control flow issues (UNREACHABLE) >>> This code cannot be reached: "switch (reg_addr) { case ...". 312 switch (reg_addr) { 313 case(0xF8011100): /* ECCCTRL1 */ 314 case(0xF8011104): /* ECCCTRL2 */ 315 case(0xF8011110): /* ERRINTEN */ 316 case(0xF8011114): /* ERRINTENS */ 317 case(0xF8011118): /* ERRINTENR */ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years

1
0
0 0

Updated invitation: TF-A Tech Forum @ Thu Apr 21, 2022 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been changed. Title: TF-A Tech Forum Topic: Feature Detection MechanismPresented by : Jayanth ChidanandAgenda:Feature detection mechanism is a diagnostic tool to quickly check and get assured of whether the architectural features enabled by software match with the given hardware implementation at an early stage of booting. It aims at mitigating the runtime-exceptions.I will be covering the implementation work completed so far and the impact ofReferences:TF-A Mailing List PostPatchesDocumentation=================================================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   (changed) When: Thu Apr 21, 2022 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: (Guest list has been hidden at organizer's request) Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

4 years

1
0
0 0

TF-A Tech-Forum Agenda for Thursday 21-Apr-22 at 4pm BST

by Joanna Farley

Topic: Feature Detection Mechanism Presented by : Jayanth Chidanand Agenda: Feature detection mechanism is a diagnostic tool to quickly check and get assured of whether the architectural features enabled by software match with the given hardware implementation at an early stage of booting. It aims at mitigating the runtime-exceptions. I will be covering the implementation work completed so far and the impact of References: TF-A Mailing List Post<https://lists.trustedfirmware.org/archives/search?mlist=tf-a%40lists.truste…> Patches<https://review.trustedfirmware.org/q/topic:%22jc%252Fdetect_feat%22+(status…> Documentation<https://trustedfirmware-a.readthedocs.io/en/latest/search.html?q=FEATURE_DE…> ================================================= 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://www.trustedfirmware.org/meetings/tf-a-…> 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://zoom.us/j/9159704974&sa=D&source=calen…> 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://zoom.us/u/ad27hc6t7h&sa=D&source=calen…>

4 years

1
0
0 0

Updated invitation: TF-A Tech Forum @ Thu Apr 21, 2022 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been changed. Title: TF-A Tech Forum Topic: Feature Detection MechanismPresented by : Jayanth ChidanandAgenda:Feature detection mechanism is a diagnostic tool to quickly check and get assured of whether the architectural features enabled by software match with the given hardware implementation at an early stage of booting. It aims at mitigating the runtime-exceptions.I will be covering the implementation work completed so far and the impact ofReferences:TF-A Mailing List PostPatchesDocumentation=================================================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   (changed) When: Thu Apr 21, 2022 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher - creator * marek.bykowski(a)gmail.com * okash.khawaja(a)gmail.com * tf-a(a)lists.trustedfirmware.org Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

4 years

1
0
0 0

Status of MTE for bl31

by Okash Khawaja

Hi, I wanted to check the status of MTE support for bl31 itself. It seems like the support was added [1] for clang and armclang but I couldn't find the memory attribute to map pages as tag checked [2]. Is there something I missed? Thanks, Okash [1] https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/… [2] https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/…

4 years

3
7
0 0

MTE support at S-EL1

by Jens Wiklander

Hi, I've started to experiment with MTE in OP-TEE at S-EL1. I've compiled TF-A with CTX_INCLUDE_MTE_REGS and I'm testing this on QEMU. Before trying to use MTE in OP-TEE I check id_aa64pfr1_el1 and skip MTE initializations if unavailable. This works as long as TF-A always is compiled with CTX_INCLUDE_MTE_REGS if MTE is available. If TF-A is compiled without CTX_INCLUDE_MTE_REGS OP-TEE will be trapped into EL3 when trying to access one of the MTE registers. I suppose this is because SCR_EL3.ATA is 0. Is there a way for OP-TEE to tell if the MTE registers are safe to access? Thanks, Jens

4 years

2
2
0 0

TF-a would not handle PSCI_CPU_ON_AARCH64 if forwarded by a hypervisor

by Mushahid Hussain

Hi, I'm working on a hobby project: AARCH64 Hypervisor on Raspberry Pi 4b. I have a problem with trapping a psci smc. I'll explain everything and what steps I have followed. Right now, I'm implementing SMC trapping. I can successfully forward almost all SMCs except for PSCI_CPU_ON_AARCH64. Linux makes these SMCs to bring up secondary CPUs during booting. Here's what I'm trying to do: - trap the PSCI_CPU_ON_AARCH64 SMC, - preserve the entry_point address in global variable - replace the entrypoint with my entrypoint and make the smc to tf-a(or simply forward it.) - when secondary cpus come online at the given address, where I set their stack point and then eret the original address. Secondary cpus won't come online at the given address. Even if I don't change any arguments of CPU_ON smc and forward it as it is, the secondary cpus still won't come online. However, without trapping enabled(HCR_EL2.TSC=0), everything works fine. I tried to debug inside Trusted Firmware. I know that overall path for secondary CPU hotplug in is: CPU released from reset -> (ROM and possibly some other bootloader) -> bl31/aarch64/bl31_entrypoint.S:bl31_warm_entrypoint() -> lib/psci/psci_common.c:psci_warmboot_entrypoint() -> lib/psci/psci_on.c:psci_cpu_on_finish() -> rpi3_pwr_domain_on_finish() I printed at all these points in Trusted Firmware with and without trapping enabled. Here's what I found: Nothing gets printed anywhere in that path if trapping is enabled. However, without trapping enabled, I can print anywhere even in bl31_entrypoint.S:bl31_warm_entrypoint(). What could be the problem? Here's my code: https://github.com/SikkiLadho/Leo/blob/4f272eff39934058a7f989c91aad82eab810… -- Mushahid Hussain

4 years, 1 month

1
0
0 0

Cortex-X1 support

by Okash Khawaja

Hello, Are there any immediate plans to add support for Cortex-X1 in TF-A? If not then I'll be happy to submit CL for it. For start, it will cover a subset of errata workarounds. Then people can add more as needed. Let me know what you think. Thanks, Okash

4 years, 1 month

2
2
0 0

TF-A Tech Forum Agenda this week

by Joanna Farley

Session this week will be: * CCA Attestation and Measured boot * Presented by Tamas Ban * As a follow up to TF-A mailing list posting https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https://zoom.us/j/9159704974&sa=D&source=calen…> Meeting ID: 915 970 4974

4 years, 1 month

1
0
0 0

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

by joanna.farley＠arm.com

This event has been changed with this note: "Agenda for this week: Session this week will be: CCA Attestation and Measured boot Presented by Tamas Ban As a follow up to TF-A mailing list posting https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…" Title: TF-A Tech Forum Session this week will be:CCA Attestation and Measured bootPresented by Tamas BanAs a follow up to TF-A mailing list posting https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… 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   (changed) When: Thu Apr 7, 2022 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher - creator * marek.bykowski(a)gmail.com * okash.khawaja(a)gmail.com * tf-a(a)lists.trustedfirmware.org Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

4 years, 1 month

1
0
0 0

[Feedback required] Feature detection mechanism

by Manish Pandey2

Hello All, We are sending this note, to notify you of all the implementation details related to the Architectural Features Detection Mechanism. Summary: This is a diagnostic tool, which is targeted to mitigate the runtime exceptions due to incorrect feature enablement. This is currently marked as experimental and disabled by default, but our target is to make it mandatory over the time. All the platform owners are expected to read the details(and review the patch) and give it a try by enabling this mechanism and share your thoughts/feedback or any questions to @Jayanth Dodderi Chidanand<mailto:JAYANTHDODDERI.CHIDANAND@arm.com> or me. Patches under Review: https://review.trustedfirmware.org/q/topic:jc/detect_feat Details: 1. What is Feature Detection Mechanism? * Feature Detection is a procedure/mechanism aimed at identifying the features which are enabled ( by software) and not detected/supported in the hardware. * It could be considered as a diagnostic tool to quickly check and get assured which features are not supported by the hardware at an early stage of booting. 2. Why do we need it? Currently, most of the feature-specific register's context management, save and restore routines are conditionally controlled with the ARM_ARCH_AT_LEAST macro, which is primarily causing exceptions under various scenarios like: * For a given version of the architecture, the optional and mandatory features control the access to various registers. If the given version of implementation does not support both, unconditional access to such registers leads to undefined behaviour. * Accessing registers without verifying their actual presence for the given implementation. In general, the problem is broader than just this specific case. We should not rely on ARM_ARCH_AT_LEAST macro to associate with an architecture extension but rather supply the individual ENABLE_FEAT_xxx option for each feature. Again, having individual build flags, won't resolve this completely. There is still room for error as users may unknowingly enable the flags. So, the build flags still need to be validated before performing any action guarded by them. This mechanism helps in resolving this issue completely. It assists in detecting the features which are not present in the platform but are enabled by software unknowingly. It prevents the runtime exception, due to the consequences already mentioned. 3. How have we designed and implemented it? We are introducing a tri-state approach for each feature build flag. From now on, the build flags take three values/states ( 0,1 or 2), and they imply as follows: The 3 states are: * ENABLE_FEAT_xxx = 0: The feature is disabled statically at compile time. * ENABLE_FEAT_xxx = 1: The feature is enabled and must be present in hardware. There will be hard panic if the feature is not present at cold boot. * ENABLE_FEAT_xxx = 2: The feature is enabled and detected at runtime Based on the value defined for each feature flag, they get detected either at boot-time or at runtime, respectively. For simplicity, let's take FEAT_HCX which is available in arch version 8.7. We provide a build option for enabling this feature, say "ENABLE_FEAT_HCX". * ENABLE_FEAT_HCX=0; The feature is disabled statically at compile time. * ENABLE_FEAT_HCX=1; The feature is enabled and must be present in hardware. There will be hard panic if the feature is not present at cold boot. i.e., we detect, whether the HCX feature is present in the PE, by reading its ID register and if not, panic will be called. Thereby at an early boot phase, we stop and report that FEAT_HCX is not supported by PE. * ENABLE_FEAT_HCX=2; The feature is enabled but dynamically enabled at runtime depending on hardware capability. Here, a feature detection check will happen during runtime. 4. What is the status of this implementation? Is it completely implemented and tested? We have divided the entire implementation into two phases. In phase-1 FEAT_STATES { 0, 1} are handled and FEAT_STATE{2} will be handled ahead. Currently, we are in phase-1 delivery, wherein we are introducing a procedure, which will read through all the enabled feature build flags, and if they are defined to state1, ENABLE_FEAT_XXX=1 the respective feature will be detected. 5. Which all features are considered here? TF-A supports most arm architectural features from v8.0 and upwards. Some are mandatory and some are optional features as per the Arm ARM docs. So, both ( Mandatory and optional features from v8.0) are detected under this mechanism. 6. Does this mechanism modify or impact any existing implementation related to any of the architectural features supported in TF-A? * Yes. * Ideally, TF-A enables the architectural features which are mandatory by default from a particular arch version and upwards ( as per Arm-ARM docs ) and disables the optional features by default and allows the platforms to make the decision on enabling the optional feature based on their requirements. * This pattern is followed for most of the features. However, there are some cases wherein optional features are enabled by default within TF-A ( Eg; FEAT_SPE, FEAT_SVE ), which shouldn't have been handled this way. * With the feature detection mechanism in place, as stated earlier the procedure runs through all the enabled features(optional and mandatory) and identifies them. * Now, FEAT_SPE and FEAT_SVE are optional features, which are enabled by default and when detected will not be identified by the PE, if it doesn't support it and panics during booting. * So, since we have enabled these optional features within the TF-A build system, it would panic and stop booting. * If we upstream this mechanism, all the partner's platforms will be impacted involuntarily. This problem will not be seen in other cases like: * Mandatory Feature: Let's say FEAT_FGT which is mandatory from the 8.6 version. So, if a platform is based on v8.6 it will implement this, and this feature will be detected. So no issue here. If the platform is based on v8.5, this FEAT_FGT is not enabled by the TF-A. It gets enabled from 8.6. So here, in this case, the feature is disabled so nothing to worry about. * Optional Feature: Let's say FEAT_NV2 which is an optional feature from arch version 8.4. is supported by TF-A. Since it is an optional one as per Arm ARM, TF-A implements and disables it by default and allows the platforms to decide and enable them as per their requirements. So here, if the platform enables it, it implies they are sure this feature is implemented. If not, this mechanism will help them by detecting it, so that they disable it in future. In general, this would not break the boot flow in all scenarios. But if the optional feature is enabled by TF-A itself, will stop the boot flow in most of scenarios. So, to avoid breaking change, we have decided to overlook such optional features for now and update our partners and get their feedback. Based on that, in future, we will disable these optional features which were enabled by default and will send another email to enable it explicitly according to their requirements. 7. What should the platforms be aware of, with the upstreaming of this mechanism? * Currently, we are introducing this entire implementation as an experimental mechanism, wherein we provide an explicit build flag (FEATURE_DETECTION) to enable the feature detection mechanism itself. We urge the platforms to enable this mechanism, test it and get used to its behaviour before it gets mandated. * So, for now, it wouldn't cause any issue. But our plan is to make sure this mechanism runs by default, as we want to mitigate the runtime Exceptions. As part of the 2.7 release, we are targeting to upstream this implementation and later, have some time window, wherein our partners get used to it and provide feedback as well. 8. Will there be any breakdown during runtime, with respect to any of the platforms? Yes. It's explained in detail above. 9. What is the long-term plan with this mechanism? When will this be completely implemented and tested end to end? We target it to be implemented full-fledged by EoY 2022, but it depends on the feedback received from our partners and get this done. Thanks

4 years, 1 month

1
0
0 0

ENABLE_PIE with clang

by Okash Khawaja

Hi, It seems like setting ENABLE_PIE=1 and compiling with clang/LLVM results in linker errors. E.g. compiling ti/k3 which has ENABLE_PIE=1, with clang and lld version 14.0.1 results in linker errors like "ld.lld: error: can't create dynamic relocation R_AARCH64_ABS64 against local symbol in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output". Is this expected? If not, are there any plans to fix this? Thanks, Okash

4 years, 1 month

2
2
0 0

CCA Attestation and Measured boot

by Tamas Ban

Hi, In Arm CCA the Security Model strongly recommends implementing the CCA HES functionality to ensure the system security properties. A way to achieve this is to add a trusted subsystem to the system, which behaves like a secure enclave. In ARM reference design this trusted subsystem is called to Runtime Security Subsystem (RSS). RSS can execute a firmware component that implements the functional requirements of the HES. But its firmware is not restricted to be only the HES, other tenants are also allowed. The goal of the CCA HES is to provide fundamental services to the AP to ensure its security properties. These fundamental services include secure boot, measured boot and attestation, etc. You can find more information about the role of CCA HES and about its functional requirements in the Arm CCA Security Model [1]. In ARM reference design the CCA HES is going to be executed by RSS. CCA HES is based on TF-M. In this patch series [2] the AP side support of the CCA HES functionalities is going to be introduced: - Communication over an MHU channel between the AP and RSS. - Communication abstracted by the PSA API. So, AP can leverage standard PSA calls to invoke these services on the RSS. - CCA HES provides a measured boot backend. Measurements are taken during AP boot can be stored by RSS and retrieved as part of the CCA Platform Attestation token. - CCA Platform Attestation token can be requested from RSS. Currently, there is no publicly available FVP platform to test these patches, but it will be available later this year. Some limited testing is available on the AEM FVP. Here the RSS based measured boot backend is enabled and mocked version of the measured boot and attestation APIs are available. Due to the lack of RSS in the FVP, the APIs do not communicate to RSS, instead just print the measurements to the console and return to a hard-coded attestation token. [1] https://developer.arm.com/documentation/DEN0096/latest [2] https://review.trustedfirmware.org/q/topic:%2522rss/mboot-attest%2522 Best regards, Tamas Ban

4 years, 1 month

1
0
0 0

Mbed TLS GitHub migration

by dave.rodgman＠arm.com

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

4 years, 1 month

1
0
1 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. 2 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 376885: Integer handling issues (NEGATIVE_RETURNS) ________________________________________________________________________________________________________ *** CID 376885: Integer handling issues (NEGATIVE_RETURNS) /drivers/st/clk/clk-stm32-core.c: 343 in _clk_stm32_set_parent() 337 if (parents->id_parents[sel] == (uint16_t)clkp) { 338 bool clk_was_enabled = _clk_stm32_is_enabled(priv, clk); 339 int err = 0; 340 341 /* Enable the parents (for glitch free mux) */ 342 _clk_stm32_enable(priv, clkp); >>> CID 376885: Integer handling issues (NEGATIVE_RETURNS) >>> "old_parent" is passed to a parameter that cannot be negative. 343 _clk_stm32_enable(priv, old_parent); 344 345 err = clk_mux_set_parent(priv, pid, sel); 346 347 _clk_stm32_disable(priv, old_parent); 348 ** CID 376884: Error handling issues (CHECKED_RETURN) /drivers/nxp/ddr/phy-gen2/phy.c: 2219 in load_fw() ________________________________________________________________________________________________________ *** CID 376884: Error handling issues (CHECKED_RETURN) /drivers/nxp/ddr/phy-gen2/phy.c: 2219 in load_fw() 2213 ERROR("Unsupported DIMM type\n"); 2214 return -EINVAL; 2215 } 2216 2217 size = PHY_GEN2_MAX_IMAGE_SIZE; 2218 image_buf = (uintptr_t)phy_gen2_fw_img_buf; >>> CID 376884: Error handling issues (CHECKED_RETURN) >>> Calling "mmap_add_dynamic_region" without checking return value (as is done elsewhere 14 out of 16 times). 2219 mmap_add_dynamic_region(phy_gen2_fw_img_buf, 2220 phy_gen2_fw_img_buf, 2221 PHY_GEN2_MAX_IMAGE_SIZE, 2222 MT_MEMORY | MT_RW | MT_SECURE); 2223 ret = img_loadr(imem_id, &image_buf, &size); 2224 if (ret != 0) { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 1 month

1
0
1 0

Canceled event: TF-A Tech Forum @ Thu Mar 24, 2022 9am - 10am (MST) (tf-a@lists.trustedfirmware.org)

by don.harbin＠linaro.org

This event has been canceled. Title: TF-A Tech Forum 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   When: Thu Mar 24, 2022 9am – 10am Mountain Standard Time - Phoenix Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher - creator * marek.bykowski(a)gmail.com * okash.khawaja(a)gmail.com * tf-a(a)lists.trustedfirmware.org * don.harbin(a)linaro.org Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

4 years, 1 month

1
0
0 0

TF-A Tech Forum

by Joanna Farley

Not sure if the cancellation has gone out but just confirming this Tech Forum is cancelled. Thanks Joanna From: linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com When: 16:00 - 17:00 24 March 2022 Subject: TF-A Tech Forum You have been invited to the following event. TF-A Tech Forum When Thu Mar 24, 2022 4pm – 5pm United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher - creator • marek.bykowski(a)gmail.com • okash.khawaja(a)gmail.com • tf-a(a)lists.trustedfirmware.org more details »<https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…> 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…> Going (tf-a(a)lists.trustedfirmware.org)? Yes<https://calendar.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tM…> - Maybe<https://calendar.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tM…> - No<https://calendar.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tM…> more options »<https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…> Invitation from Google Calendar<https://calendar.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More<https://support.google.com/calendar/answer/37135#forwarding>.

4 years, 1 month

1
0
0 0

TF-A Tech Forum @ Thu Mar 24, 2022 4pm - 5pm (GMT) CANCELLED

by Joanna Farley

Just confirming that the TF-A Tech forum this week is cancelled due to no subject/topic. Thanks Joanna

4 years, 1 month

1
0
0 0

Invitation: TF-A Tech Forum @ Thu Mar 24, 2022 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

You have been invited to the following event. Title: TF-A Tech Forum 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   When: Thu Mar 24, 2022 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher - creator * marek.bykowski(a)gmail.com * okash.khawaja(a)gmail.com * tf-a(a)lists.trustedfirmware.org Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

4 years, 1 month

1
0
0 0

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

by joanna.farley＠arm.com

This event has been canceled. Title: TF-A Tech Forum 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   When: Thu Mar 24, 2022 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher - creator * 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 courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

4 years, 1 month

1
0
0 0

TrustedFirmware Code of Conduct

by Don Harbin

Hi All, Please find the link to the TrustedFirmware Community Code of Conduct here: https://developer.trustedfirmware.org/w/collaboration/community_guidelines/… Trusted Firmware has a very diverse and global developer community. It is important that we adhere to the code of conduct in all our interactions. For some of you all this may be new and for others just a gentle reminder. In either case, if you have any questions, please feel free to reach out to me directly. And thanks to you all for your contributions to the TrustedFirmware community! Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

4 years, 1 month

1
0
0 0

TF-A Technical Forum Session Agenda for Today

by Joanna Farley

I understand some people may not have seen the calendar invite for today’s Tech Forum session. It is in the archives but formatting has been lost so just confirming the agenda in plain email to the list. Joanna Agenda for Session on 10th March 2022 * Introduction to Arm DRTM specification and its support in TF-A * Stuart Yoder/Lucian Pau-Trifu will go through basic of Arm's DRTM specification, beta specification publicly released https://developer.arm.com/documentation/den0113/latest%C2%A0Manish * Pandey/Manish Badarkhe will go through implementation details and planned delivery in TF-A codebase. Details: * Dynamic Root of Trust for Measurement (DRTM) for Armv8-A is based on concepts from the TCG D-RTM Architecture. DRTM begins a new chain of trust by measuring and executing a protected payload which is in contrast to Static RTM(measured boot) where measurements are done at boot time. * Implementation of DRTM services in BL31 and various platform hooks required. Also, talk about initial support on FVP platform and limitations. 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://www.trustedfirmware.org/meetings/tf-a-…> 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://zoom.us/j/9159704974&sa=D&source=calen…> 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://zoom.us/u/ad27hc6t7h&sa=D&source=calen…>

4 years, 2 months

1
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. 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 376627: (OVERRUN) /plat/xilinx/zynqmp/pm_service/pm_svc_main.c: 276 in pm_smc_handler() /plat/xilinx/zynqmp/pm_service/pm_svc_main.c: 553 in pm_smc_handler() ________________________________________________________________________________________________________ *** CID 376627: (OVERRUN) /plat/xilinx/zynqmp/pm_service/pm_svc_main.c: 276 in pm_smc_handler() 270 SMC_RET1(handle, SMC_UNK); 271 272 pm_arg[0] = (uint32_t)x1; 273 pm_arg[1] = (uint32_t)(x1 >> 32); 274 pm_arg[2] = (uint32_t)x2; 275 pm_arg[3] = (uint32_t)(x2 >> 32); >>> CID 376627: (OVERRUN) >>> Overrunning array "pm_arg" of 4 4-byte elements at element index 4 (byte offset 19) using index "4". 276 pm_arg[4] = (uint32_t)x3; 277 278 api_id = smc_fid & FUNCID_NUM_MASK; 279 280 switch (api_id) { 281 /* PM API Functions */ /plat/xilinx/zynqmp/pm_service/pm_svc_main.c: 553 in pm_smc_handler() 547 SMC_RET2(handle, (uint64_t)ret | ((uint64_t)version << 32), 548 (uint64_t)bit_mask[0] | ((uint64_t)bit_mask[1] << 32)); 549 } 550 551 default: 552 /* Send request to the PMU */ >>> CID 376627: (OVERRUN) >>> Overrunning array "pm_arg" of 4 4-byte elements at element index 4 (byte offset 19) using index "4". 553 PM_PACK_PAYLOAD6(payload, api_id, pm_arg[0], pm_arg[1], 554 pm_arg[2], pm_arg[3], pm_arg[4]); 555 ret = pm_ipi_send_sync(primary_proc, payload, result, 556 PAYLOAD_ARG_CNT); 557 SMC_RET2(handle, (uint64_t)ret | ((uint64_t)result[0] << 32), 558 (uint64_t)result[1] | ((uint64_t)result[2] << 32)); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 2 months

1
0
0 0

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

by joanna.farley＠arm.com

This event has been changed. Title: TF-A Tech Forum Agenda for TF-A Tech Forum on 10th March 2022Introduction to Arm DRTM specification and its support in TF-AStuart Yoder/Lucian Pau-Trifu will go through basic of Arm's DRTM specification, beta specification publicly released https://developer.arm.com/documentation/den0113/latest M… Pandey/Manish Badarkhe will go through implementation details and planned delivery in TF-A codebase. Details:Dynamic Root of Trust for Measurement (DRTM) for Armv8-A is based on concepts from the TCG D-RTM Architecture. DRTM begins a new chain of trust by measuring and executing a protected payload which is in contrast to Static RTM(measured boot) where measurements are done at boot time.Implementation of DRTM services in BL31 and various platform hooks required. Also, talk about initial support on FVP platform and limitations.=========================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   (changed) When: Thu Mar 10, 2022 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher - creator * marek.bykowski(a)gmail.com * okash.khawaja(a)gmail.com * tf-a(a)lists.trustedfirmware.org Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

4 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. 12 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 4 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 12 of 12 defect(s) ** CID 376586: Memory - illegal accesses (OVERRUN) /lib/psci/psci_stat.c: 207 in psci_get_stat() ________________________________________________________________________________________________________ *** CID 376586: Memory - illegal accesses (OVERRUN) /lib/psci/psci_stat.c: 207 in psci_get_stat() 201 if (pwrlvl == PSCI_INVALID_PWR_LVL) { 202 ERROR("Invalid target power level for PSCI statistics operation\n"); 203 panic(); 204 } 205 206 /* Get the index into the stats array */ >>> CID 376586: Memory - illegal accesses (OVERRUN) >>> Overrunning array "state_info.pwr_domain_state" of 2 bytes at byte offset 3 using index "pwrlvl" (which evaluates to 3). 207 local_state = state_info.pwr_domain_state[pwrlvl]; 208 stat_idx = get_stat_idx(local_state, pwrlvl); 209 210 if (pwrlvl > PSCI_CPU_PWR_LVL) { 211 /* Get the power domain index */ 212 parent_idx = SPECULATION_SAFE_VALUE(psci_cpu_pd_nodes[target_idx].parent_node); ** CID 376585: (OVERRUN) /lib/extensions/amu/aarch64/amu.c: 495 in amu_context_save() /lib/extensions/amu/aarch32/amu.c: 337 in amu_context_save() ________________________________________________________________________________________________________ *** CID 376585: (OVERRUN) /lib/extensions/amu/aarch64/amu.c: 495 in amu_context_save() 489 * Save the counters to the local context. 490 */ 491 492 isb(); /* Ensure counters have been stopped */ 493 494 for (i = 0U; i < amcgcr_el0_cg0nc; i++) { >>> CID 376585: (OVERRUN) >>> Overrunning array "ctx->group0_cnts" of 16 8-byte elements at element index 254 (byte offset 2039) using index "i" (which evaluates to 254). 495 ctx->group0_cnts[i] = amu_group0_cnt_read(i); 496 } 497 498 #if ENABLE_AMU_AUXILIARY_COUNTERS 499 for (i = 0U; i < amcgcr_el0_cg1nc; i++) { 500 ctx->group1_cnts[i] = amu_group1_cnt_read(i); /lib/extensions/amu/aarch32/amu.c: 337 in amu_context_save() 331 * Save the counters to the local context. 332 */ 333 334 isb(); /* Ensure counters have been stopped */ 335 336 for (i = 0U; i < amcgcr_cg0nc; i++) { >>> CID 376585: (OVERRUN) >>> Overrunning array "ctx->group0_cnts" of 16 8-byte elements at element index 254 (byte offset 2039) using index "i" (which evaluates to 254). 337 ctx->group0_cnts[i] = amu_group0_cnt_read(i); 338 } 339 340 #if ENABLE_AMU_AUXILIARY_COUNTERS 341 for (i = 0U; i < amcgcr_cg1nc; i++) { 342 ctx->group1_cnts[i] = amu_group1_cnt_read(i); ** CID 376584: (OVERRUN) /lib/extensions/amu/aarch64/amu.c: 585 in amu_context_restore() /lib/extensions/amu/aarch32/amu.c: 396 in amu_context_restore() ________________________________________________________________________________________________________ *** CID 376584: (OVERRUN) /lib/extensions/amu/aarch64/amu.c: 585 in amu_context_restore() 579 580 /* 581 * Restore the counter values from the local context. 582 */ 583 584 for (i = 0U; i < amcgcr_el0_cg0nc; i++) { >>> CID 376584: (OVERRUN) >>> Overrunning array "ctx->group0_cnts" of 16 8-byte elements at element index 254 (byte offset 2039) using index "i" (which evaluates to 254). 585 amu_group0_cnt_write(i, ctx->group0_cnts[i]); 586 } 587 588 #if ENABLE_AMU_AUXILIARY_COUNTERS 589 for (i = 0U; i < amcgcr_el0_cg1nc; i++) { 590 amu_group1_cnt_write(i, ctx->group1_cnts[i]); /lib/extensions/amu/aarch32/amu.c: 396 in amu_context_restore() 390 391 /* 392 * Restore the counter values from the local context. 393 */ 394 395 for (i = 0U; i < amcgcr_cg0nc; i++) { >>> CID 376584: (OVERRUN) >>> Overrunning array "ctx->group0_cnts" of 16 8-byte elements at element index 254 (byte offset 2039) using index "i" (which evaluates to 254). 396 amu_group0_cnt_write(i, ctx->group0_cnts[i]); 397 } 398 399 #if ENABLE_AMU_AUXILIARY_COUNTERS 400 for (i = 0U; i < amcgcr_cg1nc; i++) { 401 amu_group1_cnt_write(i, ctx->group1_cnts[i]); ** CID 376583: (OVERRUN) /plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c: 309 in ddr3_get_parameter() /plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c: 298 in ddr3_get_parameter() ________________________________________________________________________________________________________ *** CID 376583: (OVERRUN) /plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c: 309 in ddr3_get_parameter() 303 tmp = ((DDR3_TWTR * nmhz + (nmhz >> 1) + 999) / 1000); 304 pdram_timing->twtr = max(4, tmp); 305 pdram_timing->trtw = DDR3_TRTW; 306 pdram_timing->tras_max = 9 * pdram_timing->trefi; 307 pdram_timing->tras_min = ((DDR3_TRAS * nmhz + (nmhz >> 1) + 999) 308 / 1000); >>> CID 376583: (OVERRUN) >>> Overrunning array "ddr3_trc_tfaw" of 22 2-byte elements at element index 31 (byte offset 63) using index "ddr_speed_bin" (which evaluates to 31). 309 pdram_timing->tfaw = 310 (((ddr3_trc_tfaw[ddr_speed_bin] & 0x0ff) * nmhz + 999) 311 / 1000); 312 /* tRFC, 90ns(512Mb),110ns(1Gb),160ns(2Gb),300ns(4Gb),350ns(8Gb) */ 313 if (ddr_capability_per_die <= 0x4000000) 314 tmp = DDR3_TRFC_512MBIT; /plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c: 298 in ddr3_get_parameter() 292 else 293 pdram_timing->mr[0] = DDR3_BL8 294 | DDR3_CL(pdram_timing->cl) 295 | DDR3_WR(tmp); 296 tmp = ((DDR3_TRTP * nmhz + (nmhz >> 1) + 999) / 1000); 297 pdram_timing->trtp = max(4, tmp); >>> CID 376583: (OVERRUN) >>> Overrunning array "ddr3_trc_tfaw" of 22 2-byte elements at element index 31 (byte offset 63) using index "ddr_speed_bin" (which evaluates to 31). 298 pdram_timing->trc = 299 (((ddr3_trc_tfaw[ddr_speed_bin] >> 8) * nmhz + 999) / 1000); 300 tmp = ((DDR3_TRRD * nmhz + 999) / 1000); 301 pdram_timing->trrd = max(4, tmp); 302 pdram_timing->tccd = DDR3_TCCD; 303 tmp = ((DDR3_TWTR * nmhz + (nmhz >> 1) + 999) / 1000); ** CID 376582: (UNINIT) ________________________________________________________________________________________________________ *** CID 376582: (UNINIT) /drivers/st/clk/stm32mp1_clk.c: 1928 in stm32mp1_clk_init() 1922 if ((mmio_read_32(rcc_base + RCC_MP_RSTSCLRR) & 1923 RCC_MP_RSTSCLRR_MPUP0RSTF) != 0) { 1924 pll3_preserve = stm32mp1_check_pll_conf(_PLL3, 1925 clksrc[CLKSRC_PLL3], 1926 pllcfg[_PLL3], 1927 plloff[_PLL3]); >>> CID 376582: (UNINIT) >>> Using uninitialized value "*pllcfg[_PLL4]" when calling "stm32mp1_check_pll_conf". 1928 pll4_preserve = stm32mp1_check_pll_conf(_PLL4, 1929 clksrc[CLKSRC_PLL4], 1930 pllcfg[_PLL4], 1931 plloff[_PLL4]); 1932 } 1933 /* Don't initialize PLL4, when used by BOOTROM */ /drivers/st/clk/stm32mp1_clk.c: 1924 in stm32mp1_clk_init() 1918 if (ret != 0) { 1919 return ret; 1920 } 1921 1922 if ((mmio_read_32(rcc_base + RCC_MP_RSTSCLRR) & 1923 RCC_MP_RSTSCLRR_MPUP0RSTF) != 0) { >>> CID 376582: (UNINIT) >>> Using uninitialized value "*pllcfg[_PLL3]" when calling "stm32mp1_check_pll_conf". 1924 pll3_preserve = stm32mp1_check_pll_conf(_PLL3, 1925 clksrc[CLKSRC_PLL3], 1926 pllcfg[_PLL3], 1927 plloff[_PLL3]); 1928 pll4_preserve = stm32mp1_check_pll_conf(_PLL4, 1929 clksrc[CLKSRC_PLL4], ** CID 376581: Memory - illegal accesses (OVERRUN) /plat/brcm/common/brcm_io_storage.c: 389 in plat_get_image_source() ________________________________________________________________________________________________________ *** CID 376581: Memory - illegal accesses (OVERRUN) /plat/brcm/common/brcm_io_storage.c: 389 in plat_get_image_source() 383 boot_source = boot_source_get(); 384 if (image_id == FIP_IMAGE_ID) 385 policy = &boot_source_policies[boot_source]; 386 else 387 policy = &policies[image_id]; 388 >>> CID 376581: Memory - illegal accesses (OVERRUN) >>> Overrunning array of 48 bytes at byte offset 168 by dereferencing pointer "policy". 389 result = policy->check(policy->image_spec); 390 if (result == 0) { 391 *image_spec = policy->image_spec; 392 *dev_handle = *(policy->dev_handle); 393 394 if (image_id == TRUSTED_BOOT_FW_CERT_ID) { ** CID 376580: Memory - illegal accesses (OVERRUN) /drivers/nxp/crypto/caam/src/caam.c: 245 in run_descriptor_jr() ________________________________________________________________________________________________________ *** CID 376580: Memory - illegal accesses (OVERRUN) /drivers/nxp/crypto/caam/src/caam.c: 245 in run_descriptor_jr() 239 int i = 0, ret = 0; 240 uint32_t *desc_addr = jobdesc->desc; 241 uint32_t desc_len = desc_length(jobdesc->desc); 242 uint32_t desc_word; 243 244 for (i = 0; i < desc_len; i++) { >>> CID 376580: Memory - illegal accesses (OVERRUN) >>> Overrunning array of 64 4-byte elements at element index 126 (byte offset 507) by dereferencing pointer "desc_addr + i". 245 desc_word = desc_addr[i]; 246 VERBOSE("%x\n", desc_word); 247 sec_out32((uint32_t *)&desc_addr[i], desc_word); 248 } 249 dsb(); 250 ** CID 376579: (OVERRUN) /plat/xilinx/zynqmp/pm_service/pm_client.c: 220 in pm_client_set_wakeup_sources() /plat/xilinx/zynqmp/pm_service/pm_client.c: 217 in pm_client_set_wakeup_sources() /plat/xilinx/versal/pm_service/pm_client.c: 149 in pm_client_set_wakeup_sources() /plat/xilinx/versal/pm_service/pm_client.c: 156 in pm_client_set_wakeup_sources() ________________________________________________________________________________________________________ *** CID 376579: (OVERRUN) /plat/xilinx/zynqmp/pm_service/pm_client.c: 220 in pm_client_set_wakeup_sources() 214 node = irq_to_pm_node(irq); 215 reg &= ~lowest_set; 216 217 if ((node != NODE_UNKNOWN) && 218 (!pm_wakeup_nodes_set[node])) { 219 ret = pm_set_wakeup_source(NODE_APU, node, 1); >>> CID 376579: (OVERRUN) >>> Overrunning array "pm_wakeup_nodes_set" of 78 bytes at byte offset 127 using index "node" (which evaluates to 127). 220 pm_wakeup_nodes_set[node] = !ret; 221 } 222 } 223 } 224 } 225 /plat/xilinx/zynqmp/pm_service/pm_client.c: 217 in pm_client_set_wakeup_sources() /plat/xilinx/versal/pm_service/pm_client.c: 149 in pm_client_set_wakeup_sources() 143 break; 144 } 145 146 node_idx = irq_to_pm_node_idx(irq); 147 reg &= ~lowest_set; 148 >>> CID 376579: (OVERRUN) >>> Overrunning array "pm_wakeup_nodes_set" of 84 bytes at byte offset 127 using index "node_idx" (which evaluates to 127). 149 if ((node_idx != XPM_NODEIDX_DEV_MIN) && 150 (pm_wakeup_nodes_set[node_idx] == 0U)) { 151 /* Get device ID from node index */ 152 device_id = PERIPH_DEVID(node_idx); 153 ret = pm_set_wakeup_source(node_id, 154 device_id, 1, /plat/xilinx/versal/pm_service/pm_client.c: 156 in pm_client_set_wakeup_sources() 150 (pm_wakeup_nodes_set[node_idx] == 0U)) { 151 /* Get device ID from node index */ 152 device_id = PERIPH_DEVID(node_idx); 153 ret = pm_set_wakeup_source(node_id, 154 device_id, 1, 155 SECURE_FLAG); >>> CID 376579: (OVERRUN) >>> Overrunning array "pm_wakeup_nodes_set" of 84 bytes at byte offset 127 using index "node_idx" (which evaluates to 127). 156 pm_wakeup_nodes_set[node_idx] = (uint8_t)(!ret); 157 } 158 } 159 } 160 } 161 ** CID 376578: Uninitialized variables (UNINIT) /plat/xilinx/zynqmp/pm_service/pm_svc_main.c: 533 in pm_smc_handler() ________________________________________________________________________________________________________ *** CID 376578: Uninitialized variables (UNINIT) /plat/xilinx/zynqmp/pm_service/pm_svc_main.c: 533 in pm_smc_handler() 527 528 case PM_CLOCK_GETRATE: 529 { 530 uint64_t value; 531 532 ret = pm_clock_getrate(pm_arg[0], &value); >>> CID 376578: Uninitialized variables (UNINIT) >>> Using uninitialized value "value". 533 SMC_RET2(handle, (uint64_t)ret | 534 (((uint64_t)value & 0xFFFFFFFFU) << 32U), 535 (value >> 32U) & 0xFFFFFFFFU); 536 537 } 538 ** CID 376577: (OVERRUN) /plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c: 236 in ddr3_get_parameter() /plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c: 235 in ddr3_get_parameter() ________________________________________________________________________________________________________ *** CID 376577: (OVERRUN) /plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c: 236 in ddr3_get_parameter() 230 /* when dll bypss cl = cwl = 6 */ 231 if (nmhz < 300) { 232 pdram_timing->cl = 6; 233 pdram_timing->cwl = 6; 234 } else { 235 pdram_timing->cl = (ddr3_cl_cwl[ddr_speed_bin][tmp] >> 4) & 0xf; >>> CID 376577: (OVERRUN) >>> Overrunning array "ddr3_cl_cwl" of 22 7-byte elements at element index 31 (byte offset 223) using index "ddr_speed_bin" (which evaluates to 31). 236 pdram_timing->cwl = ddr3_cl_cwl[ddr_speed_bin][tmp] & 0xf; 237 } 238 239 switch (timing_config->dramds) { 240 case 40: 241 tmp = DDR3_DS_40; /plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c: 235 in ddr3_get_parameter() 229 230 /* when dll bypss cl = cwl = 6 */ 231 if (nmhz < 300) { 232 pdram_timing->cl = 6; 233 pdram_timing->cwl = 6; 234 } else { >>> CID 376577: (OVERRUN) >>> Overrunning array "ddr3_cl_cwl" of 22 7-byte elements at element index 31 (byte offset 223) using index "ddr_speed_bin" (which evaluates to 31). 235 pdram_timing->cl = (ddr3_cl_cwl[ddr_speed_bin][tmp] >> 4) & 0xf; 236 pdram_timing->cwl = ddr3_cl_cwl[ddr_speed_bin][tmp] & 0xf; 237 } 238 239 switch (timing_config->dramds) { 240 case 40: ** CID 376576: Uninitialized variables (UNINIT) /plat/mediatek/mt8195/plat_sip_calls.c: 48 in mediatek_plat_sip_handler() ________________________________________________________________________________________________________ *** CID 376576: Uninitialized variables (UNINIT) /plat/mediatek/mt8195/plat_sip_calls.c: 48 in mediatek_plat_sip_handler() 42 ret = dfd_smc_dispatcher(x1, x2, x3, x4); 43 SMC_RET1(handle, ret); 44 break; 45 case MTK_SIP_APUSYS_CONTROL_AARCH32: 46 case MTK_SIP_APUSYS_CONTROL_AARCH64: 47 ret = apusys_kernel_ctrl(x1, x2, x3, x4, &ret_val); >>> CID 376576: Uninitialized variables (UNINIT) >>> Using uninitialized value "ret_val". 48 SMC_RET2(handle, ret, ret_val); 49 break; 50 default: 51 ERROR("%s: unhandled SMC (0x%x)\n", __func__, smc_fid); 52 break; 53 } 54 55 SMC_RET1(handle, SMC_UNK); ** CID 375635: Integer handling issues (BAD_SHIFT) /lib/zlib/inflate.c: 263 in inflatePrime() ________________________________________________________________________________________________________ *** CID 375635: Integer handling issues (BAD_SHIFT) /lib/zlib/inflate.c: 263 in inflatePrime() 257 state->hold = 0; 258 state->bits = 0; 259 return Z_OK; 260 } 261 if (bits > 16 || state->bits + (uInt)bits > 32) return Z_STREAM_ERROR; 262 value &= (1L << bits) - 1; >>> CID 375635: Integer handling issues (BAD_SHIFT) >>> In expression "(unsigned int)value << state->bits", left shifting by more than 31 bits has undefined behavior. The shift amount, "state->bits", is as much as 32. 263 state->hold += (unsigned)value << state->bits; 264 state->bits += (uInt)bits; 265 return Z_OK; 266 } 267 268 /* ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 2 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-A