Hi All,
Please note build option CTX_INCLUDE_MTE_REGS is now replaced with ENABLE_FEAT_MTE[1]
To avoid breaking any builds for timebeing CTX_INCLUDE_MTE_REGS usage will indirectly
enable ENABLE_FEAT_MTE but will produce a build warning.
Kindly request anyone using CTX_INCLUDE_MTE_REGS to replace with ENABLE_FEAT_MTE
As option CTX_INCLUDE_MTE_REGS backward support will be removed after next release
and going forward usage of CTX_INCLUDE_MTE_REGS will not be handled within build.
--
Thanks,
Govindraj R
[1]: https://review.trustedfirmware.org/q/topic:%22gr/refac_mte%22
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
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
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
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
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
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 |