TF-A January 2026

tf-a@lists.trustedfirmware.org

9 participants
12 discussions

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 501137: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /common/runtime_svc.c: 261 in handler_sync_exception() _____________________________________________________________________________________________ *** CID 501137: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /common/runtime_svc.c: 261 in handler_sync_exception() 255 /* advance the PC to continue after the instruction */ 256 write_ctx_reg(state, CTX_ELR_EL3, read_ctx_reg(state, CTX_ELR_EL3) + 4); 257 } /* otherwise return to the trapping instruction (repeating it) */ 258 return; 259 /* If FFH Support then try to handle lower EL EA exceptions. */ 260 } else if ((exc_class == EC_IABORT_LOWER_EL || exc_class == EC_DABORT_LOWER_EL) >>> CID 501137: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "state->ctx_regs[0U /* 0U >> 3U */] | (8UL /* 1UL << 3 */)" is always 1/true regardless of the values of its operand. This occurs as the logical second operand of "&&". 261 && (read_ctx_reg(state, CTX_SCR_EL3) | SCR_EA_BIT)) { 262 #if FFH_SUPPORT 263 /* 264 * Check for Uncontainable error type. If so, route to the 265 * platform fatal error handler rather than the generic EA one. 266 */ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://scan.coverity.com/projects/arm-software-arm-trusted-firmware?tab=ov…

2 weeks, 2 days

Re: Questions about Chain-of-Trust and RSE Connectivity

by Olivier Deprez

+ TF-A list ________________________________ From: Olivier Deprez Sent: 05 January 2026 15:11 To: Taehoon Kim <gth1919(a)adtek.co.kr> Cc: Raef Coles <Raef.Coles(a)arm.com>; Jackson Cooper-Driver <Jackson.Cooper-Driver(a)arm.com>; Nishant Sharma <Nishant.Sharma(a)arm.com>; Rohit Mathew <Rohit.Mathew(a)arm.com>; Manish Pandey2 <Manish.Pandey2(a)arm.com>; Manish Badarkhe <Manish.Badarkhe(a)arm.com> Subject: Questions about Chain-of-Trust and RSE Connectivity Hi Taehoon Kim, We seem to experience an issue with the mailing list where messages are not properly dispatched. I reproduced your initial email sent Dec 18th 2025 below and Cced relevant folks just in case. Regards, Olivier. ____________________________________________________________ Hello, I'm firmware developer for RD-V3-R1 chipset. I have developed our firmware based on Neoverse Reference Platform RD-INFRA-2025.07.03, but I have also kept an eye on the code to ensure we remain in step with the latest release. While inquiring on the TF-M forum to update the TF-M code, I also developed a query regarding the TF-A section. Re: Several Questions related to RSE Provisioning - TF-M - lists.trustedfirmware.org<https://lists.trustedfirmware.org/archives/list/tf-m@lists.trustedfirmware.…> This link includes that RSE API codes are removed in the SotA TF-A codes. I check this in the TF-A commit. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/46314 I was already aware that this API was not used outside of test code. However, I would like to know the reason why that code was removed, beyond the simple fact that it was not being used. Is it possible that Chain-of-Trust is established in whole firmware stack from RSE ROM to AP BL33 bootloader, without RSE assist? If possible, what does TF-A rely upon as the basis for trust in establishing the Root of Trust? Our team believed that CoT was established on the premise of the RSE API, and was therefore designing to ensure the trustworthiness of the entire firmware using that code. However, we recognise that to use the latest version of the code, we must abandon that belief and design in a different manner. Before the new version of RD-INFRA is released, we intend to resolve this internally as a team. Should you feel the scope of the question extends beyond what is typically addressed in the forum, please do not hesitate to let us know. Thank you for reading this mail. Best Regard, Taehoon Kim

2 weeks, 2 days

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-A January 2026