Hello,
In the file lib/xlat_tables/xlat_tables_common.c and other associated files, there are instances where if...else if constructs lack an else statement, resulting in violations during the Coverity MISRA-C analysis for the ZynqMP platform.
Addressing this issue added empty else statement to resolve the issue but it is related to core translational table logic function. Is it possible to address this issue? Please provide your suggestions.
Regards,
Nithin G
Hi folks,
If you don’t use any of the JavaScript-based tooling from the TF-A repository then you can safely ignore this.
I’ve just updated TF-A’s Node.js dependencies, including the minimum version of Node.js required to use the JavaScript-based hooks and tooling from the repository (previously v16, now v20). If you use these and you find that they have started throwing errors, make sure that you are rebased on the latest version of the integration branch, and then run:
npm ci
If you need to commit changes while the tools are erroring, you can commit with the `-n` flag to skip the commit hooks:
git commit -n <usual commit flags…>
Please let me know if you run into any issues.
Cheers,
Chris
Hi Olivier Deprez,
One more question, the SPM_MM code will not be removed from the main repository, right?
________________________________
Hi Olivier Deprez,
We use the SPM_MM framework mainly for read/write control of security variables. We do not want to modify the original application code at this time.
At the same time we want to add support for the new SPMD framework based code.
________________________________
Hi Baopeng,
By "code based on the SPM_MM framework" I assume you refer to a secure service running in a S-EL0 partition based on the MM protocol? If you can share this information, what kind of service is this implementing? RAS handling, secure variables, TPM back end, other? What kind of interface is needed to access the service? asynchronous with interrupts? synchronous with SMC from normal world? Another question is why do you need to collocate the SPMD if the MM implementation is already achieving the scenarios you need?
Ideally you'd want to migrate this service to run on top of:
* the EL3 FF-A SPMC https://trustedfirmware-a.readthedocs.io/en/latest/components/el3-spmc.html * or if the HW/chipset implements it, the S-EL2 FF-A SPMC https://hafnium.readthedocs.io/en/latest/secure-partition-manager/index.html...<https://hafnium.readthedocs.io/en/latest/secure-partition-manager/index.htm…>
Knowing the kind of S-EL0 service would help narrowing the effort for a migration.
FF-A (https://developer.arm.com/documentation/den0077/latest/) is a modern evolution of MM (https://developer.arm.com/documentation/den0060/latest) and any functionality achieved by the MM protocol can be handled by FF-A. For example the MM_COMMUNICATE interface can be easily swapped by the FFA_MSG_SEND_DIRECT_REQ interface.
Regards, Olivier.
________________________________ From: baopeng (A) via TF-A tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org Sent: 21 February 2024 07:10 To: tf-a(a)lists.trustedfirmware.org tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org Subject: [TF-A] Re: Request for help
Hi Olivier Deprez,
We have developed code based on the SPM_MM framework and do not want to reconstruct the code. However, we want to adapt the code to the SPMD framework.
What should we do?
________________________________
Hi Baopeng,
SPM_MM is the legacy implementation for a secure partition manager relying on the MM protocol. This implementation gets deprecated in favor of FF-A based implementations (what you refer to as SPMD + SPMC). Both implementations aren't compatible and it is discouraged to attempt co-locating both. It may be more palatable and future proof to transition all your SW stack to be compliant to FF-A standard.
We may help you better if you tell a bit more about the reason for mixing both implementations in the same build.
Regards, Olivier.
________________________________ From: baopeng (A) baopeng1@huawei.commailto:baopeng1@huawei.com Sent: 20 February 2024 02:19 To: tf-a-owner(a)lists.trustedfirmware.org tf-a-owner@lists.trustedfirmware.orgmailto:tf-a-owner@lists.trustedfirmware.org Subject: Request for help
Dear Sir/ Madam,
we need to support the simultaneous loading of SPMD and SPM_MM due to project reasons.
However, we notice that the makefile of SPM_MM of ATF does not support the simultaneous loading of SPMD and SPM_MM by default.
I would like to ask what is the main reason for making the current restrictions?
This event has been updated
Changed: description
TF-A Tech Forum
Every 2 weeks from 9am to 10am on Thursday
Mountain Standard Time - Phoenix
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/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://linaro-org.zoom.us/my/trustedfirmware?pwd=VktXcm5MNUUyVVM4R0k3ZUtvdU84QT09 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-freeMeeting ID: 915 970 4974Find your
local number: https://zoom.us/u/ad27hc6t7h
Guests
tf-a(a)lists.trustedfirmware.org
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.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
This event has been updated
TF-A Tech Forum
Every 2 weeks from 8am to 9am on Thursday
Mountain Standard Time - Phoenix
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
tf-a(a)lists.trustedfirmware.org
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.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
Hi all,
Please use this link for the Tech Forum
https://armltd.zoom.us/j/97580924908?pwd=VkVXL2pxemJJYVhieUovRmF4QTU3UT09&f…
Bipin
-----Original Appointment-----
From: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com>
Sent: Thursday, July 16, 2020 11:22 AM
To: Trusted Firmware Public Meetings; Bipin Ravi; John Powell; tf-a(a)lists.trustedfirmware.org
Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org)
When: Thursday, February 22, 2024 4:00 PM-5:00 PM Europe/London.
Where:
Forwarding as it seems you guys still have the old one in your calendars. You have to accept this one and delete the old one.
Don't blame me blame Linaro as its their invite and they said they sent it to everybody on the TF-A ML....
Will send you the link to the zoom recording once it comes through to me as it takes a few days to get the webpages up dated.
Joanna
From: linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com<mailto:linaro.org_havjv2figrh5egaiurb229pd8c@group.calendar.google.com>
When: 16:00 - 17:00 18 June 2020
Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>)
You have been invited to the following event.
TF-A Tech Forum
When
Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time
Calendar
tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>
Who
*
Bill Fletcher- creator
*
tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>
more details ><https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…>
We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.
Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…>
Trusted Firmware is inviting you to a scheduled Zoom meeting.
Join Zoom Meeting
https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…>
Meeting ID: 915 970 4974
One tap mobile
+16465588656,,9159704974# US (New York)
+16699009128,,9159704974# US (San Jose)
Dial by your location
+1 646 558 8656 US (New York)
+1 669 900 9128 US (San Jose)
877 853 5247 US Toll-free
888 788 0099 US Toll-free
Meeting ID: 915 970 4974
Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…>
Going (tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options ><https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…>
Invitation from Google Calendar<https://www.google.com/calendar/>
You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> because you are an attendee of this event.
To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.
Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>.
________________________________
From: Trusted Firmware Public Meetings
Sent: Sunday, June 14, 2020 5:21:25 PM (UTC) Coordinated Universal Time
To: Trusted Firmware Public Meetings; tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>
Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>)
When: Occurs on Thursday every other week from 4:00 PM to 5:00 PM effective 6/18/2020. Europe/London
Where:
You have been invited to the following event.
TF-A Tech Forum
When
Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time
Calendar
tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>
Who
*
Bill Fletcher- creator
*
tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>
more details ><https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…>
We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.
Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…>
Trusted Firmware is inviting you to a scheduled Zoom meeting.
Join Zoom Meeting
https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…>
Meeting ID: 915 970 4974
One tap mobile
+16465588656,,9159704974# US (New York)
+16699009128,,9159704974# US (San Jose)
Dial by your location
+1 646 558 8656 US (New York)
+1 669 900 9128 US (San Jose)
877 853 5247 US Toll-free
888 788 0099 US Toll-free
Meeting ID: 915 970 4974
Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…>
Going (tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options ><https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…>
Invitation from Google Calendar<https://www.google.com/calendar/>
You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> because you are an attendee of this event.
To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.
Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>.
Hi, In the TF-A Tech Forum today Feb, 22nd 4.00pm BST, Harrison Mutai and
Manish Pandey will present the Firmware hand-off framework: The
presentation will address the firmware handoff framework’s objectives, key
concepts, progress on FVP platform support, and plans for wider adoption
across other firmware components and Arm platforms. Regards, Olivier.
TF-A Tech Forum
Thursday Feb 22, 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
tf-a(a)lists.trustedfirmware.org
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
Hi Olivier Deprez,
We have developed code based on the SPM_MM framework and do not want to reconstruct the code. However, we want to adapt the code to the SPMD framework.
What should we do?
________________________________
Hi Baopeng,
SPM_MM is the legacy implementation for a secure partition manager relying on the MM protocol. This implementation gets deprecated in favor of FF-A based implementations (what you refer to as SPMD + SPMC). Both implementations aren't compatible and it is discouraged to attempt co-locating both. It may be more palatable and future proof to transition all your SW stack to be compliant to FF-A standard.
We may help you better if you tell a bit more about the reason for mixing both implementations in the same build.
Regards, Olivier.
________________________________ From: baopeng (A) baopeng1(a)huawei.com<mailto:baopeng1@huawei.com> Sent: 20 February 2024 02:19 To: tf-a-owner(a)lists.trustedfirmware.org tf-a-owner(a)lists.trustedfirmware.org<mailto:tf-a-owner@lists.trustedfirmware.org> Subject: Request for help
Dear Sir/ Madam,
we need to support the simultaneous loading of SPMD and SPM_MM due to project reasons.
However, we notice that the makefile of SPM_MM of ATF does not support the simultaneous loading of SPMD and SPM_MM by default.
I would like to ask what is the main reason for making the current restrictions?
Hello,
I'm trying to understand the purpose of ENABLE_PIE build flag.
IIUC, it makes the BL* executables position-independent. But I could not find
any ASLR or some other addresses randomization support. Therefore, could you
please clarify, what is the point of building position-independent parts,
if (most of the time?) they will be loaded at the fixed addresses?
Thank you.
Hi Baopeng,
SPM_MM is the legacy implementation for a secure partition manager relying on the MM protocol.
This implementation gets deprecated in favor of FF-A based implementations (what you refer to as SPMD + SPMC).
Both implementations aren't compatible and it is discouraged to attempt co-locating both.
It may be more palatable and future proof to transition all your SW stack to be compliant to FF-A standard.
We may help you better if you tell a bit more about the reason for mixing both implementations in the same build.
Regards,
Olivier.
________________________________
From: baopeng (A) <baopeng1(a)huawei.com>
Sent: 20 February 2024 02:19
To: tf-a-owner(a)lists.trustedfirmware.org <tf-a-owner(a)lists.trustedfirmware.org>
Subject: Request for help
Dear Sir/ Madam,
we need to support the simultaneous loading of SPMD and SPM_MM due to project reasons.
However, we notice that the makefile of SPM_MM of ATF does not support the simultaneous loading of SPMD and SPM_MM by default.
I would like to ask what is the main reason for making the current restrictions?
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
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