January 2024 - TF-A - lists.trustedfirmware.org

Need a mechanism to easily define platform-independent SMC FIDs

by Julius Werner

Hi, I would like to restart a discussion that we already had a few years ago on a thread called "SMC to intentionally trigger a panic in TF-A" (https://lists.trustedfirmware.org/archives/search?mlist=tf-a%40lists.truste…) but that petered out without any real resolution (and resulted in me ultimately not implementing the feature I was hoping to add). Basically, we are repeatedly stumbling over the problem that we have a use case for some platform-independent SMC API that we want to implement in TF-A, but don't have an appropriate SMC FID range to put it. My request from a few years ago was about implementing a call to intentionally trigger a panic in TF-A for test-automation purposes. Today we came up with a use case where a Trusted OS wants to query BL31 about the location of a shared log buffer: https://review.trustedfirmware.org/20478 . Currently, the available SMC ranges are Arm, CPU, SiP, OEM, Standard, Hypervisor, TA and TOS. The SiP, OEM and TOS ranges are all specific to a single silicon vendor, OEM or trusted OS implementation, so they are not good targets to implement APIs that would make sense to be shared among multiple of these. In theory, the Standard range would probably be the right target to implement calls that are independently useful for multiple platforms / OSes... but as far as I understand, adding a new call to that range requires petitioning Arm to update the SMC calling convention itself, which is a ridiculously high bar to implement a small utility API. In practice, the only choice we have for implementing these kinds of calls is to let every OEM, SiP or TOS assign its own (different) FID for it and then write separate SMC handlers for each in TF-A that all end up calling the same underlying function... which creates a lot of unnecessary code duplication and identifier soup (especially in the case of SMCs for the non-secure OS which would then be implemented by a platform-independent Linux driver that needs a big mapping table to decide which FID to use on which platform for the same API). I think it would be very useful if there was another range of easily allocatable FIDs that developers could just add to with a simple TF-A CL without having to go through a huge specification update process. There are still 41 OENs unused in the Arm SMCCC, and I don't think any new ones were added in the 10 years that the specification existed... so we are really not going to run out of them any time soon. If we could get even one of those OENs for this purpose, we would have 64K FIDs to use up for our small, simple platform-independent API needs, which should last us a long while. We could maybe call it the "Secure Monitor range" and say the FIDs are specific to a certain implementation of Secure Monitor (e.g. TF-A). Then there could just be a header file in the TF-A sources that serves as the authoritative FID assignment table for TF-A, and anyone with a sufficiently useful idea (subject to TF-A maintainer review) for a platform-independent API like this could add it there by just uploading a patch. I recently argued for a similar "simple tag allocation" concept on https://github.com/FirmwareHandoff/firmware_handoff and it found support there, so I hope I'll be able to convince you that it would be useful for SMC FIDs as well?

2 days, 17 hours

3
3
0 0

Firmware-A v2.10 release code freeze notification

by Olivier Deprez

Hi All, The next release of the Firmware-A bundle of projects tagged v2.10 has an expected code freeze date of Nov, 7th 2023. Refer to the Release Cadence section from TF-A documentation (https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/about…). Closing out the release takes around 6-10 working days after the code freeze. Preparations tasks for v2.10 release should start in coming month. We want to ensure that planned feature patches for the release are submitted in good time for the review process to conclude. As a kind recommendation and a matter of sharing CI resources, please launch CI jobs with care e.g.: -For simple platform, docs changes, or one liners, use Allow-CI+1 label (no need for a full Allow-CI+2 run). -For large patch stacks use Allow-CI+2 at top of the patch stack (and if required few individual Allow+CI+1 in the middle of the patch stack). -Carefully analyze results and fix the change if required, before launching new jobs on the same change. -If after issuing a Allow-CI+1 or Allow-CI+2 label a Build start notice is not added as a gerrit comment on the patch right away please be patient as under heavy load CI jobs can be queued and in extreme conditions it can be over an hour before the Build start notice is issued. Issuing another Allow-CI+1 or Allow-CI+2 label will just result in an additional job being queued. Thanks & Regards, Olivier.

1 week, 2 days

1
2
0 0

All if...else if constructs shall be terminated with an else statement.

by Nithin G

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

1 month, 3 weeks

4
12
0 0

Handling of normal world interrupts with BL31 PSCI handler

by caleb.ethridge＠analog.com

Hello, If normal world interrupts are received while invoking TF-A's PSCI reset handler, we have observed that the reset can be aborted. In TF-A's PSCI reset handler, a call out to OP-TEE is made before performing the platform-specific reset: https://github.com/ARM-software/arm-trusted-firmware/blob/master/lib/psci/p… https://github.com/ARM-software/arm-trusted-firmware/blob/master/services/s… When OP-TEE is entered, it is possible to receive foreign (normal world) interrupts, which invokes the procedure described here: https://optee.readthedocs.io/en/3.16.0/architecture/core.html#deliver-non-s… When the SMC call is aborted as described above, this results in the reboot failing. Linux does not retry the PSCI reset (https://github.com/torvalds/linux/blob/master/drivers/firmware/psci/psci.c#…). This makes sense because it is not expecting the SMC call to fail (it expected to make an uninterruptable SMC call into the secure monitor, not a call into OP-TEE). If OP-TEE itself is setup to handle PSCI reset calls, it also handles them in (uninterruptable) SMC context: https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/sm/psci.c#L140 https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/sm/sm_a32.S#L96 Based on this, we see two possible solutions: a) Masking the non-secure interrupts in BL31 while we are doing a reset b) Removing the call to OPTEE in the reset handler so that we never leave the SMC context Which option do you suggest? Or are we missing an important detail here? Thanks, Caleb

2 months, 3 weeks

6
11
0 0

All if...else if constructs shall be terminated with an else statement.

by Nithin G

Hello, In the file /lib/el3_runtime/aarch64/context_mgmt.c. getting misra_c_2012_rule_15_7_violation: No non-empty terminating "else" statement. during the Coverity MISRA-C analysis. void cm_prepare_el3_exit(uint32_t security_state) { u_register_t sctlr_elx, scr_el3, mdcr_el2; if (security_state == NON_SECURE) { scr_el3 = read_ctx_reg(get_el3state_ctx(ctx), CTX_SCR_EL3); misra_c_2012_rule_15_7_violation: No non-empty terminating "else" statement. if ((scr_el3 & SCR_HCE_BIT) != 0U) { ... ... ... write_sctlr_el2(sctlr_elx); } else if (el_implemented(2) != EL_IMPL_NONE) { el2_unused = true; ... ... ... write_cnthp_ctl_el2(CNTHP_CTL_RESET_VAL & ~(CNTHP_CTL_ENABLE_BIT)); } manage_extensions_nonsecure(el2_unused, ctx); } cm_el1_sysregs_context_restore(security_state); cm_set_next_eret_context(security_state); } Resolution: added empty else statement to resolve the issue. diff --git a/lib/el3_runtime/aarch64/context_mgmt.c b/lib/el3_runtime/aarch64/context_mgmt.c index 8e6bfc5..8996746 100644 --- a/lib/el3_runtime/aarch64/context_mgmt.c +++ b/lib/el3_runtime/aarch64/context_mgmt.c @@ -789,6 +789,8 @@ void cm_prepare_el3_exit(uint32_t security_state) */ write_cnthp_ctl_el2(CNTHP_CTL_RESET_VAL & ~(CNTHP_CTL_ENABLE_BIT)); + } else { + /* To fix the MISRA 15.7 warning - Added an empty else statement */ } manage_extensions_nonsecure(el2_unused, ctx); } -- Is it possible to add an empty else statement in this code? Please suggest. Regards, Nithin G

2 months, 3 weeks

2
1
0 0

Fw: Trusted Firmware-A LTS v2.8.15 Release Announcement

by Yann GAUTIER - foss

Hello, Trusted Firmware-A LTS version 2.8.15 is now available. This release contains the following patches. 7185d051b fix(docs): add few missed links for Security Advisories [1] 10d738975 docs(security): security advisory for CVE-2023-49100 [2] fc08e1bc4 fix(cpus): workaround for Cortex X3 erratum 2743088 [3] 70bd2640b fix(cpus): workaround for Cortex-X3 erratum 2302506 [4] eadc24b6b fix(cpus): workaround for Cortex-X3 erratum 2266875 [5] 560f14075 fix(cpus): workaround for Cortex-A78C erratum 2683027 [6] bdb731568 docs(changelog): changelog for lts-v2.8.15 release [7] [1] https://review.trustedfirmware.org/q/I9cab72b70a518273cbb1a291142f452198427… [2] https://review.trustedfirmware.org/q/I13fa93a65e5017dae6c837e88cd80bda72d4c… [3] https://review.trustedfirmware.org/q/I2c8577e3ca0781af8b1c3912e577d3bd77f92… [4] https://review.trustedfirmware.org/q/I048b830867915b88afa36582c6da05734a56d… [5] https://review.trustedfirmware.org/q/I9c610777e222f57f520d223bb03fc5ad05af1… [6] https://review.trustedfirmware.org/q/I2bf9e675f48b62b4cd203100f7df40f4846aa… [7] https://review.trustedfirmware.org/q/Ibb920e90a6f44a858b9f4709dbeb22e22ab86… Thanks, TF-A LTS team

3 months

1
0
0 0

New ticketing system

by Sandrine Bailleux

Hi all, As you might have heard, developer.trustedfirmware.org is getting deprecated. TF-A project used to make (little) use of its issues tracker at [1]. In replacement, we suggest switching to the issues tracker associated with TF-A Github mirror at [2]. Similarly, for TF-A Tests and TF-A CI scripts repositories, we've now got Github mirrors for these projects as well and associated issues trackers at [3] and [4], which we'd like to start using. If you've opened tickets on developer.trustedfirmware.org in the past, could you please migrate them to Github? We might review the tickets list at some point and migrate remaining ones but your help would be much appreciated! TF-A and TF-A tests documentation are in the process of being updated (see [5] and [6]) to refer to the new ticketing system. Best regards, Sandrine [1] https://developer.trustedfirmware.org/project/board/1/ [2] https://github.com/TrustedFirmware-A/trusted-firmware-a/issues [3] https://github.com/TrustedFirmware-A/tf-a-tests/issues [4] https://github.com/TrustedFirmware-A/tf-a-ci-scripts/issues [5] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/26168 [6] https://review.trustedfirmware.org/c/TF-A/tf-a-tests/+/26169

3 months

1
0
0 0

Deprecating CTX_INCLUDE_MTE_REGS build option.

by Govindraj Raja

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

3 months

1
0
0 0

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

3 months

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

3 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

TF-A January 2024