- TF-A - lists.trustedfirmware.org

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…

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

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

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

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

4 years, 3 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

4 years, 3 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 >

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

4 years, 3 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

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

4 years, 3 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

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

4 years, 4 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…

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

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

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

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

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

4 years, 4 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…

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

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

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

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

4 years, 5 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

4 years, 5 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

4 years, 5 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

4 years, 5 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

4 years, 5 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 |

4 years, 5 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

4 years, 5 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

4 years, 5 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

4 years, 5 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

4 years, 5 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.

4 years, 5 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…

4 years, 5 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

4 years, 6 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…

4 years, 6 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

4 years, 6 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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, 8 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, 8 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, 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. 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, 8 months

1
0
0 0

[MPAM] Removing initialization of MPAM EL2 registers when EL2 is used

by Zelalem Aweke

Hi all, The small patch below [1] removes initialization of MPAM EL2 registers when EL2 is used, with the assumption that if an EL2 software exists it should perform the necessary initializations. Please take a look at the patch and let me know if this change affects any downstream projects. Thanks! Zelalem [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/13805/7

4 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. 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 376573: Control flow issues (NO_EFFECT) /plat/intel/soc/common/socfpga_sip_svc.c: 142 in intel_fpga_config_completed_write() ________________________________________________________________________________________________________ *** CID 376573: Control flow issues (NO_EFFECT) /plat/intel/soc/common/socfpga_sip_svc.c: 142 in intel_fpga_config_completed_write() 136 137 while (*count < 3) { 138 139 status = mailbox_read_response(job_id, 140 resp, &resp_len); 141 >>> CID 376573: Control flow issues (NO_EFFECT) >>> This less-than-zero comparison of an unsigned value is never true. "resp_len < 0U". 142 if (resp_len < 0) 143 break; 144 145 max_blocks++; 146 147 if (mark_last_buffer_xfer_completed( ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 8 months

1
0
0 0

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

by joanna.farley＠arm.com

This event has been canceled with this note: "No topic to be presented this week. Cancelling meeting." 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 Feb 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, 8 months

1
0
0 0

Re: please fix incomplete distclean Makefile target

by Nicolas Boulenguez

Hello. This threads originates in a trivial fix for the 'clean' Makefile target. All contributions, even cosmetic and/or from the outside world, must follow the same formal process. Apparently, the process fails for external contributors. The discussion is visible there: https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… At this moment, there were more people involved in the discussion than letters affected by the patch, so I was invited to switch to a private mail exchange. I was asked to describe the error messages, did so, and was forgotten ever since. Almost a year has passed, the patch is neither refused nor applied. The connection error still prevents some/all external contributions. The only effect of my request so far is that I have been obliged to create accounts on github and your gerrit instance. Is there hope for a more satisfying conclusion?

4 years, 9 months

2
1
0 0

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

by joanna.farley＠arm.com

This event has been canceled with this note: "No topics prepared for this 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 Feb 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 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, 9 months

1
0
0 0

Is there any development roadmap(plan) for the Arm CCA features?

by Sangwan Kwon

Hi, I checked that TF-A supports FEAT_RME since v2.6. (https://trustedfirmware-a.readthedocs.io/en/latest/change-log.html) And those are developed on rme_prototype branch. ( https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/log/?h=topics/r… ) But it is not updated since last year (September, 2021). I was wondering if there is a development plan or active branch about Arm CCA features (like RME RMM). BRs, Sangwan Kwon

4 years, 9 months

2
1
0 0

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

by Beom Heyn Kim

Hi, With RME enabled FVP_Base_RevC_2xAEMvA, we are trying to have TF-A's BL31 successfully exit EL3 and jump to a normal world boot firmware (edk2 UEFI boot loader) instead of tftf.bin. Yet, it fails with the following log messages (showing the last 3): INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x88000000 INFO: SPSR = 0x3c9 We could boot and run RMM and tftf.bin successfully following the instructions on the TF-A documentation page ( https://trustedfirmware-a.readthedocs.io/en/latest/components/realm-managem…). While keeping build and run commands same, we tried to just replace the tftf.bin with FVP_AARCH64_EFI.fd, the build artifact of the edk2-platform for ARM ( https://github.com/tianocore/edk2-platforms/tree/master/Platform/ARM) We checked both tftf.bin and FVP_AARCH64_EFI.fd cases result in the same entry point address 0x88000000. Yet, the latter stops after exiting EL3 as aforementioned, unlike tftf.bin which successfully proceeds to run some tests afterwards. Also, we found that FVP_AARCH64_EFI.fd can boot successfully with the same fast model but without RME enabled. What is the possible reason for this symptom and the necessary tweaks we should do to address this issue? What should we look for to get some clue? Cheers,

4 years, 9 months

2
1
0 0

Re: How secondary core(s) move from TF-A into Kernel space using PSCI - 4 x A55 ?

by Manish Pandey2

Hi Yusuf, I hope you have gone through https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/porting-… 1. Distinguishing between a cold boot and a warm boot. 2. In the case of a cold boot and the CPU being a secondary CPU, ensuring that the CPU is placed in a platform-specific state until the primary CPU performs the necessary steps to remove it from this state. 3. In the case of a warm boot, ensuring that the CPU jumps to a platform- specific address in the BL31 image in the same processor mode as it was when released from reset. Secondary cores are kept in TF-A holding pen until primary core makes a request to start secondary core(from OS through PSCI CPU_ON). On receiving this call primary breaks the condition which held secondary. For example, investigate a5ds platform's plat_secondary_cold_boot_setup() & a5ds_pwr_domain_on(). Platform also provides warm_boot_entrypoint (most platform uses bl31_warm_entrypoint) from where secondary starts execution. Primary core is responsible for platform initialization using platform helper functions mentioned https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/porting-… (make sure your platform has implemented all the mandatory hooks). Hope this helps thanks Manish ________________________________ From: Mohd Yusuf Abdul Hamid via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 07 February 2022 02:32 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] How secondary core(s) move from TF-A into Kernel space using PSCI - 4 x A55 ? Hi, I have been stuck at this problem for more than a week. Hopefully good folks here can help clarify a few things. Platform 4x Cortex A55 single cluster. What I got working: 1. I can boot single core kernel to shell using TFA bl31 Baremetal (bare minimum startup + platform specific SOC enablement, EL3) -> TFA bl31 -> Kernel 2. I added PSCI in DT and can see the hook trigger service and hotplug secondary core in. Secondary core woke up: 1. Bare minimum startup (skip SOC specific enablement) -> TFA bl31 -> go thru 'plat_secondary_cold_boot_setup' path, using 'RESET_TO_BL31:=1' Now, I am not sure how from there, the secondary core would jump to: a. If jump to kernel's 'secondary_holding_pen' it looks like it would drop from EL3 -> EL1 and wait (however at this point Core0 is already in cpu_idle) and won't continue a.1 For this case, I am also not sure why I hit "instruction abort" in core1 - from what I read MMU hasnt been set up, which is true. I also wonder at what point MMU is set up for this path in the secondary core? b. If jump to 'secondary_entry' I believe the core is still in EL3 at this point and I will get an exception at 'set_cpu_boot_mode_flag' c. If someone can summarize what are the minimum requirements for the secondary core to get set up before jumping to 'secondary_holding_pen'/'secondary_entry' whichever is applicable. Any pointers would be much appreciated. ps: I have access to Trace32. Mohd Yusuf Abdul Hamid

4 years, 9 months

2
1
0 0

What Doc / NDA doc do I need when I want to add a new platfrom in TF-A / OPTEE? (i.e., RK3566 )

by 起飞的老杨

Hello, Everyone, If I want to add a new platform support in TF-A for RK3566 as an example, what Documentation do I need to read. Using RK3399 as a contrast ( because most of RK3399 doc is opened in internet ), we already know this SoC is supported in OPTEE and TF-A. And I can get RK3399 Docs:* TRM V1.3 Part 1*, T*RM V1.3 Part2*, *TRM V1.4 Part 1*, *Datasheet V2.1*. I can see in *TRM chapter 16 System Security, *there are some descriptions about system security, and references to other system registers, like *SGRF, *etc, but it still seems to me insufficiently ( No SGRF description ) to finish a full support platform implementation in TF-A. Some people said I need to sign an NDA with Rockchip to get Security related part docs. But when I reach to Rockchip, they said all docs are opened already, No NDA options. When I talked to one partner/distributor of Rockchip, only security related doc is also some doc I can find on internet. So I am curious and confused, can I, as a third party developer, develop a new platform implementation for TF-A / OPTEE ( specially for Rockchip Platform )? Thanks

4 years, 9 months

2
2
0 0

How secondary core(s) move from TF-A into Kernel space using PSCI - 4 x A55 ?

by Mohd Yusuf Abdul Hamid

Hi, I have been stuck at this problem for more than a week. Hopefully good folks here can help clarify a few things. Platform 4x Cortex A55 single cluster. What I got working: 1. I can boot single core kernel to shell using TFA bl31 Baremetal (bare minimum startup + platform specific SOC enablement, EL3) -> TFA bl31 -> Kernel 2. I added PSCI in DT and can see the hook trigger service and hotplug secondary core in. Secondary core woke up: 1. Bare minimum startup (skip SOC specific enablement) -> TFA bl31 -> go thru 'plat_secondary_cold_boot_setup' path, using 'RESET_TO_BL31:=1' Now, I am not sure how from there, the secondary core would jump to: a. If jump to kernel's 'secondary_holding_pen' it looks like it would drop from EL3 -> EL1 and wait (however at this point Core0 is already in cpu_idle) and won't continue a.1 For this case, I am also not sure why I hit "instruction abort" in core1 - from what I read MMU hasnt been set up, which is true. I also wonder at what point MMU is set up for this path in the secondary core? b. If jump to 'secondary_entry' I believe the core is still in EL3 at this point and I will get an exception at 'set_cpu_boot_mode_flag' c. If someone can summarize what are the minimum requirements for the secondary core to get set up before jumping to 'secondary_holding_pen'/'secondary_entry' whichever is applicable. Any pointers would be much appreciated. ps: I have access to Trace32. Mohd Yusuf Abdul Hamid

4 years, 9 months

1
0
0 0

Re: GIC-600 errata 1717652: missed wake requests

by Bipin Ravi

Hi Okash, In TF-A project, we haven't supported errata patches for system IP's like GIC-600 until now. We typically support Cat B errata patches for Arm CPU implementations that are made public. Additionally we also support DSU errata patches for the TF-A supported CPUs as applicable. But we are more than happy to support any code reviews required for the implementation of the below said errata. Thanks, Bipin -----Original Message----- From: tf-a-request(a)lists.trustedfirmware.org <tf-a-request(a)lists.trustedfirmware.org> Sent: Thursday, January 27, 2022 6:00 PM To: tf-a(a)lists.trustedfirmware.org Subject: TF-A Digest, Vol 37, Issue 16 1. GIC-600 errata 1717652: missed wake requests (Okash Khawaja) ---------------------------------------------------------------------- Message: 1 Date: Thu, 27 Jan 2022 13:36:32 +0000 From: Okash Khawaja <okash(a)google.com> Subject: [TF-A] GIC-600 errata 1717652: missed wake requests To: tf-a(a)lists.trustedfirmware.org Message-ID: <CAGjWKv6TTLVvF7GfsmY76QFjSzcSX8DqPuPukJQAOH-AqAvuLg(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Hi, It seems like TF-A's GIC600 driver currently doesn't have support for the Cat B errata 1717652 "Wake_request may not be delivered if multiple cores are woken by PPIs at the same time". Are there plans to support this? Thanks, Okash ------------------------------ Subject: Digest Footer TF-A mailing list -- tf-a(a)lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave(a)lists.trustedfirmware.org ------------------------------ End of TF-A Digest, Vol 37, Issue 16 ************************************

4 years, 9 months

2
1
1 0

GIC-600 errata 1717652: missed wake requests

by Okash Khawaja

Hi, It seems like TF-A's GIC600 driver currently doesn't have support for the Cat B errata 1717652 "Wake_request may not be delivered if multiple cores are woken by PPIs at the same time". Are there plans to support this? Thanks, Okash

4 years, 9 months

1
0
0 0

Updated invitation: TF-A Tech Forum @ Thu Jan 27, 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 Session on 27th January 2020Introduction of Arm CCA Context ManagementSession Presented by: Manish Pandey, Soby Mathew and Zelalem AwekeDetails: With the introduction of Arm CCA, the context management library needs to manage the context for one more world (realm world). Since the current context management library has evolved over time, some of design principles need sharpening / re-defining to make it easier to manage and make it less error-prone when managing the 3 worlds. The proposal lists down the design principles and discusses about introduction of new CPU Context for the root world (EL3). The refactor will increase the overall robustness of EL3 firmware as it will enforce a design pattern in software plus have a more predictable sysreg state during execution at EL3.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 Jan 27, 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, 9 months

1
0
1 0

TF-A Technical Forum Session Agenda this week

by Joanna Farley

Agenda for Session on 27th January 2020 * Introduction of Arm CCA Context Management * Session Presented by: Manish Pandey, Soby Mathew and Zelalem Aweke * Details: With the introduction of Arm CCA, the context management library needs to manage the context for one more world (realm world). Since the current context management library has evolved over time, some of design principles need sharpening / re-defining to make it easier to manage and make it less error-prone when managing the 3 worlds. The proposal lists down the design principles and discusses about introduction of new CPU Context for the root world (EL3). The refactor will increase the overall robustness of EL3 firmware as it will enforce a design pattern in software plus have a more predictable sysreg state during execution at EL3. 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, 9 months

1
0
0 0

Updated invitation: TF-A Tech Forum @ Thu Jan 27, 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 Session on 27th January 2020introduction of Arm CCA Context ManagementSession Presented by: Manish Pandy, Soby Mathew and Zelalem AwekeDetails: With the introduction of Arm CCA, the context management library needs to manage the context for one more world (realm world). Since the current context management library has evolved over time, some of design principles need sharpening / re-defining to make it easier to manage and make it less error-prone when managing the 3 worlds. The proposal lists down the design principles and discusses about introduction of new CPU Context for the root world (EL3). The refactor will increase the overall robustness of EL3 firmware as it will enforce a design pattern in software plus have a more predictable sysreg state during execution at EL3.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 Jan 27, 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, 9 months

1
0
0 0

RFC for context management refactoring in TF-A

by Soby Mathew

Hello Everyone, We have a proposal to refactor the Context management framework in TF-A and an RFC is pushed for review here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/13651 . The abstract of the RFC is given below: With the introduction of Arm CCA, the context management library needs to manage the context for one more world (realm world). Since the current context management library has evolved over time, some of design principles need sharpening / re-defining to make it easier to manage and make it less error-prone when managing the 3 worlds. The proposal lists down the design principles and discusses about introduction of new CPU Context for the root world (EL3). The refactor will increase the overall robustness of EL3 firmware as it will enforce a design pattern in software plus have a more predictable sysreg state during execution at EL3. The plus point here is that many of the design principles are already adhered to in one way or other in the current the implementation so much of the work can be done in an incremental fashion without much disruption. Along with @Zelalem Aweke<mailto:Zelalem.Aweke@arm.com> and @Manish Pandey2<mailto:Manish.Pandey2@arm.com>, we hope to discuss the this RFC and how this translates to code changes in TF-A during the Tech Forum this week. Best Regards Soby Mathew

4 years, 9 months

1
0
0 0

About arm_validate_ns_entrypoint in arm_pm.c

by Ming Huang

Hi, arm_validate_ns_entrypoint() in plat/arm/common/arm_pm.c check ARM_NS_DRAM1_BASE and ARM_NS_DRAM2_BASE only, for some platform there are include more than two non-secure dram areas. It will bring dependencies between TF-A and physical memory space which can get from uefi atfer memory initialization, if arm_validate_ns_entrypoint() include the entire physical memory space. In my mind, the kernel should guarantee the validity of entry point. So why this check is need? Thanks, Ming

4 years, 9 months

3
3
0 0

imx8mm-evk does not boot kernel 5.16 with mainline TF-A

by Fabio Estevam

Hi, I am running U-Boot 2022.01 on imx8mm-evk. If I build the NXP vendor-based TF-A (imx_5.4.47_2.2.0) I am able to boot kernel 5.16 just fine. However, if I use the upstream TF-A (v2.5 or v2.6), the kernel fails to boot most of the attempts. Peng, Jacky, Could you please try booting kernel 5.16 + U-Boot 2022.01 built with TF-A v2.6? What is missing in upstream TF-A to be able to boot kernel 5.16? Thanks, Fabio Estevam

4 years, 10 months

2
1
0 0

fw update & anti-rollback versioning

by Etienne CARRIERE

Dear all, (and may the new year be happy to you and your beloved) In the course of evaluating the FW update flows for systems with FIP images, we identified the following requirements: Req1: The FIP image, or the components in the FIP, must have a version field. Each version field will be compared against the anti-rollback counter of the platform that the FIP or its component is bound to. Req2: We must be able to increment the FIP version field (though a FIP image FW update) without affecting the anti-rollback counter value. The anti-rollback counter should be incremented only for security updates upon explicit request. Req3: The version field should be present even if the FIP does not contain image certificates. Currently the FIP carries a version field in the different certificates, the anti-rollback counters are updated every time the root certificate value increased. This is not flexible enough and does not allow trial/acceptance of updates. Can we open a discussion on how to enhance the version/anti-rollback counter update in TF-A? Best regards, Etienne Carriere ST Restricted

4 years, 10 months

4
6
0 0

TF-A (inc Hafnium) Tech Forum this week

by Joanna Farley

Hi Everyone, Welcome to 2022! To start off this year’s Tech Forum’s we will use the session this week to follow up on two ongoing email list discussion subjects: * Hafnium Build and Tooling Options. * Discussion led by Olivier Deprez. * Covering recent changes to the Hafnium project that has neem announced on the Hafnium mailing list https://lists.trustedfirmware.org/archives/list/hafnium@lists.trustedfirmwa…<https://www.google.com/url?q=https%3A%2F%2Flists.trustedfirmware.org%2Farch…> * Firmware Update and Anti-Rollback Versioning * Discussion led by Manish Badarkhe and Manish Pandey2 * An opportunity to discuss the recent email thread on this topic on the TF-A mailing list. https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…<https://www.google.com/url?q=https%3A%2F%2Flists.trustedfirmware.org%2Farch…> If you don’t have the invite which just been updated the meeting details are: TF-A Tech Forum Thursday, January 13⋅4:00 – 5:00pm GMT 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…> Thanks all Joanna

4 years, 10 months

1
0
0 0

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

by joanna.farley＠arm.com

This event has been changed. Title: TF-A Tech Forum The Tech Forum this week will cover two discussion subjects:Hafnium Build and Tooling Options.  Discussion led by Olivier Deprez.Covering recent changes to the Hafnium project that has neem announced on the Hafnium mailing list https://lists.trustedfirmware.org/archives/list/hafnium@lists.trustedfirmwa… Update and Anti-Rollback VersioningDiscussion led by Manish Badarkhe and Manish Pandey2An opportunity to discuss the recent email thread on this topic on the TF-A mailing list. 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 Jan 13, 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, 10 months

1
0
0 0

MISRA C compliance spreadsheet access permission

by Lim, Jit Loon

Hi TF-A committee, We are trying to access to the MISRA C spreadsheet mentioned over here. [cid:image001.jpg@01D806BE.A535F7C0] https://developer.trustedfirmware.org/file/download/lamajxif3w7c4mpjeoo5/PH… However, we are facing issue to open the spreadsheet and we are getting "Invalid Authorization". [cid:image002.jpg@01D806BE.A535F7C0] After we click on the "Continue", the website show Restricted File and we have no access permission. [cid:image003.jpg@01D806BE.A535F7C0] Thus, we would like to get your help to assist us on how to obtain the spreadsheet. Hope to hear from you soon. Thanks Best Regards JL Lim (Benjamin)

4 years, 10 months

2
2
0 0

A problem about assert failed in TF-A

by Chenxu Wang

Hi all, I am running FVP with 2CPUs, Cactus SP (SEL1), Hafnium (SEL2) and KVM VHE. Sometimes I send the "FFA_MSG_SEND_DIRECT_REQ" smc call from KVM (I fill 0x8400006f in x0, then VMID and SP ID in x1, let x2 as 0). It says assert failed, like this: ASSERT: lib/el3_runtime/aarch64/context_mgmt.c:651 BACKTRACE: START: assert 0: EL3: 0x4005cac 1: EL3: 0x400323c 2: EL3: 0x400620c 3: EL3: 0x400e180 4: EL3: 0x4005a94 BACKTRACE: END: assert After I check the bl31.dump, I notice that: when services/std_svc/spmd/spmd_main.c sends the FFA call (from NS to S) via "spmd_smc_forward(smc_fid, secure_origin,x1, x2, x3, x4, handle)", it will go to cm_el1_sysregs_context_restore(secure_state_out) and cm_el2_sysregs_context_restore(secure_state_out), then it will assert the cm_get_context(). it gets the NULL context, so assert failed. Before the problem appeared, I have modified many codes on a dirty TF-A v2.4 (commit hash is 0aa70f4c4c023ca58dea2d093d3c08c69b652113), Hafnium and TF-A-TESTS. I also mail with Hafnium MailList, they consider it can be a problem in EL3. Such assert is NOT ALWAYS failed. I mean, maybe when I run FVP and send "smc" now, it is failed. But when I shut down, run FVP, and send the same instruction with the same parameter again, it is OK. I want to know, what is the possible reasons for suddenly losing the secure context. Can you give me some advice on debugging? e.g., where should I check? Need I provide more info? Sincerely, Wang

4 years, 10 months

3
4
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 374565: Error handling issues (CHECKED_RETURN) /drivers/st/mmc/stm32_sdmmc2.c: 176 in stm32_sdmmc2_init() ________________________________________________________________________________________________________ *** CID 374565: Error handling issues (CHECKED_RETURN) /drivers/st/mmc/stm32_sdmmc2.c: 176 in stm32_sdmmc2_init() 170 171 mmio_write_32(base + SDMMC_POWER, 172 SDMMC_POWER_PWRCTRL_PWR_CYCLE | sdmmc2_params.dirpol); 173 mdelay(POWER_CYCLE_DELAY); 174 175 if (sdmmc2_params.vmmc_regu != NULL) { >>> CID 374565: Error handling issues (CHECKED_RETURN) >>> Calling "regulator_enable" without checking return value (as is done elsewhere 6 out of 7 times). 176 regulator_enable(sdmmc2_params.vmmc_regu); 177 } 178 179 mdelay(VCC_POWER_ON_DELAY); 180 181 mmio_write_32(base + SDMMC_POWER, sdmmc2_params.dirpol); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 10 months

1
0
0 0

How to change the address of region "RAM" in BL31?

by Chenxu Wang

Hi all, I want to add some big data structures in BL31 (e.g., create a large uint32_t array). Also, I reserve a secure memory space (assume it is 0xa000_0000 - 0xb000_0000) by configuring TZASC. Now, the BL31 says build/fvp/debug/bl31/bl31.elf section `.bss' will not fit in region `RAM' aarch64-none-elf-ld: BL31 image has exceeded its limit. aarch64-none-elf-ld: region `RAM' overflowed by 458752 bytes It looks like that the previous RAM cannot hold my big data structures. If I want to add my reserved region into RAM (so I may allocate these data into the reserved region), what should I do? Sincerely, Wang

4 years, 10 months

2
1
0 0

Re: [TF-A] [TF-M] Tip on cloning TF-M on OS X Monterey

by Gyorgy Szing

Hi, Please allow me to add some more details. Also posting to the TF-A list, as all tf.org repositories are affected. The root cause of this issue is OpenSSH dropping support for SHA-1 RSA signatures with the 8.8 release, and thus any OS (or git client) coming with a recent version is affected. I.e. the newest git for windows is affected too, and so are “top notch” Linux distributions like Arch. For details see the “Potentially-incompatible changes” chapter here: https://www.openssh.com/releasenotes.html As the above page states “Incompatibility is more likely when connecting to older SSH implementations…”, and thus a server-side update would eliminate the problem. Till that happens the page above list multiple client-side workarounds. (It is possible to amend the ssh config in a way that fixes all repositories.) /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: December 15, 2021 13:06 To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Tip on cloning TF-M on OS X Monterey I recently switched to a new MBP that ships with OS X Monterey, and on both 12.0 and 12.1 (released this week) git clone seems to be broken when you're using HTTP rather than SSH: digital envelope routines:CRYPTO_internal:bad key length In order to clone TF-M, I had to make the following changes. 1. Add these details to $HOME/.ssh/config (microbuilder being my github username, associated with my TF-M account): Host trustedfirmware.org<http://trustedfirmware.org> User microbuilder Hostname review.trustedfirmware.org<http://review.trustedfirmware.org> Port 29418 IdentityFile ~/.ssh/id_rsa IdentitiesOnly yes 2. Then try to clone with: $ git clone trustedfirmware.org:/TF-M/trusted-firmware-m.git This fails, however, since it tries to clone tf-m-tests.git, so: 3. Edit lib/ext/tf-m-tests/fetch_repo.cmake, changing: FetchContent_Declare(tfm_test_repo GIT_REPOSITORY trustedfirmware.org:TF-M/tf-m-tests.git # GIT_REPOSITORY https://git.trustedfirmware.org/TF-M/tf-m-tests.git GIT_TAG ${TFM_TEST_REPO_VERSION} GIT_PROGRESS TRUE ) This let me at least clone TF-M until the issues with HTTP-based cloning are fixed. Hope this is useful to someone else working on OS X natively. Kevin

4 years, 11 months

1
0
0 0

FCONF warning for TOS_FW_CONFIG

by Yann Gautier

Hi, On STM32MP1, we'd like BL2 to be agnostic of what BL32 is in the FIP. It can be either OP-TEE or TF-A SP_min. But on STM32MP1, SP_min needs a device tree file (TOS_FW_CONFIG_ID), whereas OP-TEE doesn't use this separate DT image. As TOS_FW_CONFIG_ID is in list of images to be loaded by BL2, we then have a warning message in case OP-TEE is used: WARNING: FCONF: Invalid config id 26 I'd like to silence this warning with this kind of patch: diff --git a/lib/fconf/fconf_dyn_cfg_getter.c b/lib/fconf/fconf_dyn_cfg_getter.c index 25dd7f9eda..f7e9834c3b 100644 --- a/lib/fconf/fconf_dyn_cfg_getter.c +++ b/lib/fconf/fconf_dyn_cfg_getter.c @@ -51,7 +51,11 @@ struct dyn_cfg_dtb_info_t *dyn_cfg_dtb_info_getter(unsigned int config_id) } } - WARN("FCONF: Invalid config id %u\n", config_id); + if (config_id == TOS_FW_CONFIG_ID) { + VERBOSE("FCONF: No TOS_FW_CONFIG image\n"); + } else { + WARN("FCONF: Invalid config id %u\n", config_id); + } return NULL; } I can change the VERBOSE message to INFO. Do you think it is OK if I push the patch? Thanks, Yann

4 years, 11 months

2
6
0 0

Cancelling Tech-Forums 16th and 30th December 2021

by Joanna Farley

I’m not sure if the cancellations have been sent from the trustedfirmware.org calendar system so confirming that they are cancelled to the list. Next scheduled Tech Forum is 13th January 2022. Joanna

4 years, 11 months

1
0
0 0

How to load some images in BL31?

by Chenxu Wang

Hi all, I want to load a specific image in BL31. But when I call load_auth_image(). It says "in function `load_image': trusted-firmware-a/common/bl_common.c:87: undefined reference to `plat_get_image_source'" Also, the io_read, io_size and etc. are undefined reference. I find other BL files (bl1, bl2) will call the load_auth_image() in their main functions or sub-functions. If I want to implement it on BL31, what should I do? Should I modify the Makefile? Sincerely, Wang

4 years, 11 months

2
1
0 0

Re: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a@lists.trustedfirmware.org)

by Joanna Farley

Hi Everyone, this is the TF-A Tech Forum meeting agenda for this week. Thanks Joanna Subject: ‘Measured Boot Driver - refactor and Critical Data measurement design’ Presented by: Manish Badarkhe 1. A brief overview of Measured Boot driver refactoring done in TF-A Bootloader 2. Discuss a few gaps observed in the Measured Boot driver and patches up-streamed for it 3. Discuss the list of critical data observed in TF-A firmware and its measurement design From: linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com When: 16:00 - 17:00 2 December 2021 Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org) Regular bi weekly Trustedfirmware.org TF-A TechForum. I host this and its where we go to our community and present/discuss things live in public. Past sessions listed here https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ Mailing list here if you want to subscribe. https://lists.trustedfirmware.org/mailman/listinfo/tf-a Project page here: https://www.trustedfirmware.org/projects/tf-a/ Abhishek never attended any of these. Cancelled if there is no topic to present. From: linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com When: 16:00 - 17:00 18 June 2020 Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org) You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> 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)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.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://www.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 organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>. ________________________________ From: Trusted Firmware Public Meetings Sent: Sunday, June 14, 2020 5:21:25 PM (UTC) Coordinated Universal Time To: Trusted Firmware Public Meetings; tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org) When: Occurs on Thursday every other week from 4:00 PM to 5:00 PM effective 6/18/2020. Europe/London Where: You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> 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)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.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://www.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 organiser and be added to the guest list, 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, 11 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-A