- TF-A - lists.trustedfirmware.org

Platform issues with mitigations of powerdown errata

by Boyan Karatotev

Hello everyone, There is a type of errata on a few CPUs where if they initiate a power down request which gets denied then attempting to power down again can fail in a deadlock. In essence, after the PE's power down sequence which ends on a WFI, but before actual power down, there exists a small window where an external event can interrupt the power down and cause the PE to continue after the WFI. Attempting to power down again after that can result in a deadlock. Affected CPUs are the Neoverse N2, Makalu ELP (Cortex X3), and Cortex A710. The SDEN [1] suggests to set the chicken bit CPUACTLR2_EL1[36] before the power down sequence and to clear it after coming out of the WFI (on anything other than RESET). The mitigations [2] set the bit in the `core_pwr_dwn` of each CPU but never clear it. This is because in the generic TF-A code path the WFI ends up being called in an infinite loop with the only way to come out of it being RESET. Most platforms with custom `pwr_domain_pwr_down_wfi` end up in the same loop or unrelated hardware reset mechanisms that avoid the errata. However, a few platforms could continue running as normal without going through a hardware reset which would require special treatment. The four problematic platforms are: * amlogic gxl and g12a: they fake a reset by manually calling the reset entrypoint on their primary CPUs only. This will leave the chicken bit set after reset. * socionext uniphier: same as amlogic but on all CPUs. * nxp (common code): I hope I understand what the platform is trying to do but there are 2 paths that raise an eyebrow: `_psci_sys_pwrdn_wfi` which has a single non-looped wfi (which could return as above) and `_psci_cpu_off_wfi` which seems to accept waking up as normal behaviour. The former path is a simple fix but the latter is the same case as amlogic and socionext. Due to its complexity I have not proposed any modification on either path. Finally, nvidia tegra and renesas (common code) have acceptable behaviour as far as the errata are concerned, however, they end up in the wfi loop only after a panic sequence. Although not problematic, this stands out. For all six platforms above there are a few options on how to proceed, the preferred one being to bring them in line with what everyone else does. Alternatively, ignoring the errata would be ok if these platforms never intend to use these CPUs. It must be noted, however, that it appears to be a family of errata, and these may not be all CPUs affected. [1]: the wording is identical for all 3 cores. For Neoverse N2: https://developer.arm.com/documentation/SDEN1982442/latest/ [2]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/17157/1 Regards, Boyan

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

2 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

2 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

2 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

2 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.

2 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

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

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

2 years, 8 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…

2 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

2 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)

2 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

2 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

2 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

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

2 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

2 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

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

2 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

2 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

2 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

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

2 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

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

2 years, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A