- TF-A - lists.trustedfirmware.org

Canceled event with note: TF-A Tech Forum @ Thu Jan 25, 2024 5pm - 6pm (GMT+1) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled with a note: "Hi, No topic proposed, cancelling. Thanks, Olivier. " TF-A Tech Forum Thursday Jan 25, 2024 ⋅ 5pm – 6pm Central European Time - Paris 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

1
0
0 0

Should strscpy() be preferred over strlcpy()?

by Sandrine Bailleux

Hi, Right now, TF-A coding guidelines advocate the use of strlcpy() over strcpy()/strncpy() (see the banned libc functions [1]) for the following reasons: - strlcpy() always null-terminates the destination string, even if it gets truncated. This is safer and less error-prone than leaving it unterminated like strncpy() does in this case. - With strlcpy(), it is possible to detect whether the string was truncated. This is useful in some use cases. - strlcpy() writes a single null-terminating byte into the destination string, whereas strncpy() wastes time writing multiple null-terminating bytes until it fills the destination string. Thus, strlcpy() is more efficient in the case where the source string is shorter than the destination one. There exists another string copy variant: strscpy(). Just like strlcpy(), it is not part of the C standard but most libc implementations provide it. strscpy() has the following advantages over strlcpy(): - strscpy() only reads the specified number of bytes from the source string, whereas strlcpy() reads all of its bytes until it finds a null-terminating byte (this is because it needs to return this information). This opens up a potential security risk if the source string is untrusted and controlled by an attacker, as we might end up reading a lot of memory if proper safeguards are not put in place on the source string prior to calling strlcpy(). Also it causes a performance penalty for reading "useless" bytes from the source string. - Checking for truncation is easier and less error-prone with strscpy() : strscpy() returns an error code (-E2BIG) in case of truncation, whereas strlcpy() requires comparing the return value with the destination string size. For these reasons, it seems to me we should prefer strscpy() over strlcpy() in TF-A code base. Any thoughts? Note that the Linux kernel coding style already goes in that direction. The coding style verification script (checkpatch.pl), which TF-A reuses, will print the following warning message if strlcpy() is used: WARNING: Prefer strscpy over strlcpy - see: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmk… This got flagged by the OpenCI into some TF-A code review already [2]. If we decide that strlcpy() is fine for TF-A codebase in the end, we'll at least need to find a way to silence this checkpatch.pl warning. AFAICS there is already a switch to this effect so it should just be a matter of adding '--ignore STRLCPY' inside .checkpatch.conf file. Best regards, Sandrine [1] https://trustedfirmware-a.readthedocs.io/en/latest/process/coding-guideline…) [2] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/25551

2 years

1
0
0 0

Declaration uses a different parameter type than the function Definition.

by Nithin G

Hello, In the file /plat/xilinx/zynqmp/aarch64/zynqmp_common.c, there is a function named plat_get_syscnt_freq2 with its definition. Simultaneously, the declaration of this function is included in include/plat/common/platform.h with the name plat_get_syscnt_freq2 and a different parameter type, leading to a violation when running the Coverity MISRA-C analysis for the Zynqmp platform. Declaration uses a different parameter type than the function Definition. Addressing this issue by introducing a typedef for plat_get_syscnt_freq2 in platform.h and specifying its type as uint32_t resolves the violation. However, it introduces a challenge for other platforms, as this modification necessitates similar changes across various platforms, causing violations in those areas due to the adjusted typedef. Is it possible to fix with the typedef? Please suggest. Regards, Nithin

2 years

3
5
0 0

A project should not contain unused tag declarations.

by Nithin G

Hello, In the file /bl31/interrupt_mgmt.c and /include/drivers/arm/gicv2.h and other files getting misra_c_2012_rule_2_4_violation: Type has tag "intr_type_desc" but that tag is never used. during the Coverity MISRA-C analysis. typedef struct intr_type_desc { interrupt_type_handler_t handler; u_register_t scr_el3[2]; uint32_t flags; } intr_type_desc_t; Resolution: Removed the intr_type_desc variable as it declared it's typedef intr_type_desc_t. typedef struct { interrupt_type_handler_t handler; u_register_t scr_el3[2]; uint32_t flags; } intr_type_desc_t; Is It possible to remove the intr_type_desc variable since it is typedef. Please suggest? Regards, Nithin

2 years

3
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. 1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 414009: (RETURN_LOCAL) /services/std_svc/spm/el3_spmc/spmc_main.c: 1530 in spmc_ffa_console_log() /services/std_svc/spm/el3_spmc/spmc_main.c: 1530 in spmc_ffa_console_log() ________________________________________________________________________________________________________ *** CID 414009: (RETURN_LOCAL) /services/std_svc/spm/el3_spmc/spmc_main.c: 1530 in spmc_ffa_console_log() 1524 } 1525 1526 if ((chars_count == 0) || (chars_count > chars_max)) { 1527 return spmc_ffa_error_return(handle, FFA_ERROR_INVALID_PARAMETER); 1528 } 1529 >>> CID 414009: (RETURN_LOCAL) >>> Using "chars", which points to an out-of-scope variable "registers". 1530 for (size_t i = 0; (i < chars_count) && (chars[i] != '\0'); i++) { 1531 putchar(chars[i]); 1532 } 1533 1534 SMC_RET1(handle, FFA_SUCCESS_SMC32); 1535 } /services/std_svc/spm/el3_spmc/spmc_main.c: 1530 in spmc_ffa_console_log() 1524 } 1525 1526 if ((chars_count == 0) || (chars_count > chars_max)) { 1527 return spmc_ffa_error_return(handle, FFA_ERROR_INVALID_PARAMETER); 1528 } 1529 >>> CID 414009: (RETURN_LOCAL) >>> Using "chars", which points to an out-of-scope variable "registers". 1530 for (size_t i = 0; (i < chars_count) && (chars[i] != '\0'); i++) { 1531 putchar(chars[i]); 1532 } 1533 1534 SMC_RET1(handle, FFA_SUCCESS_SMC32); 1535 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

2 years

1
0
0 0

PSCI patches fail TF-A-tests on 2 platform configs

by Yann Gautier

Hi, Patrick has sent 2 correction patches for PSCI stack in OSI mode there: https://review.trustedfirmware.org/q/topic:%22fix_psci_osi%22 But when running CI+2, there are 2 platforms for which 2 PSCI OSI tests are failing: fvp-ext-pstate-ea-el3|fvp-default|fvp-tftf-fip.tftf-cortexa57x4a53x4-debug fvp-ext-pstate-ea-el3|fvp-default|fvp-tftf-fip.tftf-aemv8a-debug I'm not familiar with those test configs, but when checking lava logs, I see those traces for failing tests: 2024-01-11T14:21:59 > Executing 'CPU suspend to powerdown at level 1 in OSI mode' 2024-01-11T14:21:59 INFO: Booting 2024-01-11T14:21:59 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:21:59 INFO: Booting 2024-01-11T14:21:59 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:21:59 INFO: Booting 2024-01-11T14:21:59 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:21:59 INFO: Booting 2024-01-11T14:21:59 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:21:59 INFO: Booting 2024-01-11T14:21:59 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:21:59 INFO: Booting 2024-01-11T14:21:59 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:21:59 INFO: Booting 2024-01-11T14:21:59 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:21:59 INFO: Going into suspend state 2024-01-11T14:22:00 INFO: Going into suspend state 2024-01-11T14:22:00 INFO: Going into suspend state 2024-01-11T14:22:00 INFO: Going into suspend state 2024-01-11T14:22:00 INFO: Going into suspend state 2024-01-11T14:22:00 INFO: Going into suspend state 2024-01-11T14:22:00 INFO: Going into suspend state 2024-01-11T14:22:00 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Going into suspend state 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 TEST COMPLETE Failed 2024-01-11T14:22:03 Wrong value: expected 0, got -3 2024-01-11T14:22:03 > Executing 'CPU suspend to powerdown at level 2 in OSI mode' 2024-01-11T14:22:03 INFO: Booting 2024-01-11T14:22:03 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:22:03 INFO: Booting 2024-01-11T14:22:03 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:22:03 INFO: Booting 2024-01-11T14:22:03 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:22:03 INFO: Booting 2024-01-11T14:22:03 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:22:03 INFO: Booting 2024-01-11T14:22:03 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:22:03 INFO: Booting 2024-01-11T14:22:03 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:22:03 INFO: Booting 2024-01-11T14:22:03 INFO: Registered IRQ handler 0x8801b274 for IRQ #7 2024-01-11T14:22:03 INFO: Going into suspend state 2024-01-11T14:22:03 INFO: Going into suspend state 2024-01-11T14:22:03 INFO: Going into suspend state 2024-01-11T14:22:03 INFO: Going into suspend state 2024-01-11T14:22:03 INFO: Going into suspend state 2024-01-11T14:22:03 INFO: Going into suspend state 2024-01-11T14:22:03 INFO: Going into suspend state 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Going into suspend state 2024-01-11T14:22:03 INFO: Saving system context 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7 2024-01-11T14:22:03 INFO: Powering off 2024-01-11T14:22:03 INFO: Restoring system context 2024-01-11T14:22:03 INFO: Resumed from suspend state 2024-01-11T14:22:03 TEST COMPLETE Failed 2024-01-11T14:22:03 Wrong value: expected 0, got -3 The "Resumed from suspend state" message interleaved with "Going into suspend state" seem strange, but I cannot say what could be wrong there. Maybe there is something wrong with the TF-A patches? Or the platforms tests or configs need to be updated? If you have any clue that would be very helpful! Thanks, Yann

2 years

2
1
0 0

Cache Maintenance For SiP buffers

by Ahmad Fatoum

Hi, I was looking at imx_hab_handler, which forwards calls into the BootROM on i.MX SoCs in response to secure monitor calls. The BootROM call (and thus the SiP call) accepts two pointers as arguments, where it writes data. The plat/imx/imx8m/imx8m*/imx8m*_bl31_setup.c files map the RAM as MT_MEMORY | MT_RW, which would mean that not only is it writable from TF-A side, but it's also mapped cacheable. I see no explicit cache maintenance in the i.MX SiP code for these two pointer arguments and haven't been successful to find where in TF-A core code if at all, complete D-Cache is flushed on SMC exit. Therefore I ask: - Don't shared non-secure memory buffers between EL3 and lower EL require explicit cache maintenance? - Did I miss the place where this cache maintenance is done? - How did it work so far? barebox does explicit flushing before HAB SiP, invalidation after. U-Boot doesn't do cache maintenance. Both apparently work... 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 |

2 years

3
11
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 413966: Uninitialized variables (UNINIT) /plat/qemu/qemu_sbsa/sbsa_sip_svc.c: 113 in read_cpuinfo_from_dt() ________________________________________________________________________________________________________ *** CID 413966: Uninitialized variables (UNINIT) /plat/qemu/qemu_sbsa/sbsa_sip_svc.c: 113 in read_cpuinfo_from_dt() 107 108 if (fdt_getprop(dtb, node, "numa-node-id", NULL)) { 109 fdt_read_uint32(dtb, node, "numa-node-id", &nodeid); 110 } 111 112 dynamic_platform_info.cpu[cpu].nodeid = nodeid; >>> CID 413966: Uninitialized variables (UNINIT) >>> Using uninitialized value "mpidr". 113 dynamic_platform_info.cpu[cpu].mpidr = mpidr; 114 115 INFO("CPU %d: node-id: %d, mpidr: %ld\n", cpu, nodeid, mpidr); 116 117 cpu++; 118 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

2 years

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Jan 11, 2024 5pm - 6pm (CET) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled with a note: "Hi, Cancelling as no topic proposed. Thanks & Regards, Olivier. " TF-A Tech Forum Thursday Jan 11, 2024 ⋅ 5pm – 6pm Central European Time - Paris 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

1
0
0 0

Violations MISRA_15.1 and 15.5 when running the Coverity MISRA-C analysis.

by Nithin G

1. misra_c_2012_rule_15_1_violation: Using "goto" statement. In the file common/bl_common.c and other related files, getting misra_c_2012_rule_15_1_violation: Using "goto" statement. during the Coverity MISRA-C analysis. if (...) { goto exit; } exit: some operation Resolution: goto statement is replaced with exit_func() and new variable is introduced to store the return value of exit_func(). exit_func() some operation int ret; if (...) { ret = return value of exit func() } return ret; Is it possible to fix MISRA 15.1 like this in open source? Please suggest. 2. misra_c_2012_rule_15_5_violation: This return statement is not the final statement in the compound statement that forms the body of the function. In the file common/bl_common.c, lib/xlat_tables/aarch64/xlat_tables.c and other related files, getting misra_c_2012_rule_15_5_violation: This return statement is not the final statement in the compound statement that forms the body of the function. during the Coverity MISRA-C analysis. if (...) { return <something> } if (...) { return <something> } return; Resolution: Taken new variable and assign the return result to new variable and calling only one return statement in end of the function. int result; if (...) { result = <something> } else { if (...) { result = <something> } } return result; Is it possible to fix MISRA 15.5 like this in open source? Please suggest. Thanks & Regards, Nithin G

2 years, 1 month

2
3
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-A