This event has been canceled with a note:
"Hi, Cancelling as no topic planned. Regards, Olivier."
TF-A Tech Forum
Thursday Feb 8, 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,
I am using hypervisors to allow execution of EL3 code directly and had to deal with MMIO caused by instructions that have post-indexing parameters.
Xen community had to deal with this in 2022: https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg113335.html
This does not cause any trouble and have implemented ways to deal with this expeditiously.
Yet, I wonder if it is desirable to from a synchronisation perspective?
Cheers
FF
Compiling TFA 2.10 for PLAT=a80x0_mcbin
The following line
https://elixir.bootlin.com/arm-trusted-firmware/v2.10.0/source/drivers/marv…
Is compiled as:
win_reg = mmio_read_32(AMB_WIN_CR_OFFSET(win_id));
4026d9c: f9470260 ldr x0, [x19, #3584]
4026da0: 9100e002 add x2, x0, #0x38
4026da4: b9400001 ldr w1, [x0]
win_reg &= ~WIN_ENABLE_BIT;
4026da8: 121f7821 and w1, w1, #0xfffffffe
*(volatile uint32_t*)addr = value;
// post-indexing
4026dac: b8008401 str w1, [x0], #8
#gcc --version
gcc (Ubuntu 10.3.0-1ubuntu1) 10.3.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
#objdump --version
GNU objdump (GNU Binutils for Ubuntu) 2.36.1
Copyright (C) 2021 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.
#I can’t get access to latests compiler and binutils versions to overcome
# « ../.. array subscript 0 is outside array bounds of ‘volatile void[0] »
# « ../.. has a LOAD segment with RWX permissions »
# so I don’t know if this behaviour is changed when using this latests toolchain
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