- TF-A - lists.trustedfirmware.org

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

by Chenxu Wang

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

2 years, 9 months

2
2
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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

2 years, 9 months

1
0
0 0

TF-A RME support

by Shameerali Kolothum Thodi

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

2 years, 9 months

3
6
0 0

TF-A CI often fail due to missing rebase

by Julius Werner

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

2 years, 9 months

4
6
0 0

A problem about TZASC in Armv9

by Chenxu Wang

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

2 years, 9 months

3
7
0 0

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

by joanna.farley＠arm.com

This event has been canceled with a note: "Cancelling this week. I have no topics ready for presenting also many folks are out on summer holidays. " TF-A Tech Forum Thursday Aug 11, 2022 ⋅ 4pm – 5pm United Kingdom Time We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 10 months

1
0
0 0

TF-A TechForum 19th May Cancelled

by Bipin Ravi

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

2 years, 10 months

1
1
0 0

Re: Question about disable MMU in BL1

by 邬金平

Hi, I have tried this before, there is a problem. on Armv8, when MMU disabled, the default attribute of memory is device, and device memory access has alignment requirements. For example, accessing address (0x1) will result in fault. Ben via TF-A <tf-a(a)lists.trustedfirmware.org> 于2022年7月19日周二 17:02写道： > Hello, > > To decrease feature in BL1, I plan to disable MMU in BL1 stage. > Are there any potential issues besides performance issues? > > BRs > > ------------------------------ > Ben(a)tsingmicro.com > -- > TF-A mailing list -- tf-a(a)lists.trustedfirmware.org > To unsubscribe send an email to tf-a-leave(a)lists.trustedfirmware.org >

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

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

2 years, 10 months

1
0
0 0

Question about maximum TF-A BL31 memory usage

by Peng Fan

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

2 years, 10 months

2
1
0 0

Rebooting LTS discussion

by Okash Khawaja

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

2 years, 10 months

4
11
0 0

Question about FVP's dts

by Chenxu Wang

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

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

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

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

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

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

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

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

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

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

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

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

2 years, 11 months

1
0
0 0

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

by joanna.farley＠arm.com

TF-A Tech Forum Thursday Jun 16, 2022 ⋅ 4pm – 5pm United Kingdom Time We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Reply for tf-a(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 11 months

1
0
0 0

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

by joanna.farley＠arm.com

This event has been canceled. TF-A Tech Forum Thursday Jun 16, 2022 ⋅ 4pm – 5pm United Kingdom Time We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 11 months

1
0
0 0

Measured boot and external TPM modules

by Ramon Fried

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

3 years

4
9
0 0

Trusted Firmware version 2.7 is now available

by Daniel Boulby

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

3 years

1
0
0 0

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

by Ahmad Fatoum

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

3 years

1
0
0 0

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

by joanna.farley＠arm.com

This event has been canceled with this note: "Public holiday in the UK so cancelling with week." Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu Jun 2, 2022 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher - creator * marek.bykowski(a)gmail.com * okash.khawaja(a)gmail.com * tf-a(a)lists.trustedfirmware.org Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years

1
0
0 0

Floating point math

by Bartus, Dan

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

3 years

4
9
0 0

arm-trustedfirmware whether has unit test

by 郭浙伟(本记)

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

3 years

2
1
0 0

ChangeLog-v2.7

by Jayanth Dodderi Chidanand

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

3 years

2
1
0 0

Add neoverse-n1 support to QEMU SBSA

by Itaru Kitayama

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

3 years

2
8
1 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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

3 years

1
0
0 0

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

by JY Ho (何駿彥)

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

3 years

3
3
1 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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

3 years

1
0
0 0

imx8mn and HAB

by Heiko Thiery

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

3 years

3
5
0 0

Issue about passing arguments between the BL1 and BL2 in Arch32

by 邬金平

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

3 years

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

3 years

2
1
0 0

About SVE issue

by Ming Huang

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

3 years, 1 month

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

3 years, 1 month

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

3 years, 1 month

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

3 years, 1 month

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…

3 years, 1 month

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

3 years, 1 month

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…

3 years, 1 month

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

3 years, 1 month

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

3 years, 1 month

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

3 years, 1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A