February 2022 - TF-M - lists.trustedfirmware.org

Re: [TF-M] Supporting encryption with ITS

by Sherry Zhang

Hi George, The ITS without encryption is not a compromised RoT. In the PSA Secure Storage API spec, the PSA Internal Trust Storage aims at providing a place for devices to store their most intimate secrets. Also “””””””””””””””””””” 1. The storage underlying the PSA Internal Trusted Storage Service MUST be protected from read and modification by attackers with physical access to the device. 2. The storage underlying the PSA Internal Trusted Storage Service MUST be protected from direct read or write access from software partitions outside of the PSA Root of Trust (PRoT). “””””””””””””””””””” So, for internal trusted storage service, it requires the underlying storage itself should provide being read or write protection. The storage area should be a “trusted” area. Does the storage area on your device meet this requirement? Is the memory physically isolated? If not, I wonder why not uses the Protected Storage service instead? For the design of adding encryption in ITS, in the PS partition, the `iv` and the encrypted object data are stored with the object file while the tag of each object is stored with the object table file. So, if encrypt the PS object in the ITS file system, how the PS partition get the `tag` of each object? After a rough thought, I think probably a standalone encryption for ITS is more reasonable. As this is a relatively “big topic”, would you like to hold a discussion on the TF-M Tech forum if it is not limited by confidential information? The next Tech forum will be hold on this Thursday 3:00 PM UTC time. Regards, Sherry Zhang From: Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>> Sent: Friday, September 24, 2021 8:52 PM To: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Supporting encryption with ITS Hello Sherry, Thank you for your input! 1. Our threat model is more concerned about attacks which can happen very early in the boot process, I think. A completely compromised RoT is not in our threat model. 2. I see that, ITS is supposed to store small objects. The storage overhead of adding encryption will be probably bigger than 20 bytes I think but the intention is to have this only as a configuration, not as the default option. 3. Agreed, a HAL API should be used for this. Do you have any opinion on the design of it? Do you think that it adds value to do try to use a common design for the object handling of both PS and ITS or is it better to have it as a standalone thing for the ITS. Regards, George ________________________________ From: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>> Sent: Friday, September 24, 2021 11:58 AM To: Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: [TF-M] Supporting encryption with ITS Hi George, Some comments from my side: 1. Internal trusted storage is part of the Root of Trust domain. If ITS storage device is attacked, then the code flash where the PSA Rot SP locates may also be attacked. Does the thread model of your system require the encryption in ITS? 2. The ITS service is intended to be used to interface to a small piece of storage. Encryption would increase the context for each ITS file. For example, similarly to PS object context, the `IV` which is used in encryption as well as the generated `tag` should be added into each file context. They total together can be about more than 20 bytes. 3. If the encryption is mandatory/ necessary required by the thread model of your system, as discussed, the PSA crypto service should not be called to avoid the circular. I think a HAL API for encryption may be created in ITS for platform implementation defined encryption/decryption. Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vasilakis, Georgios via TF-M Sent: Thursday, September 23, 2021 10:47 PM To: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>; Fabian Schmidt <fabian.schmidt(a)nxp.com<mailto:fabian.schmidt@nxp.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Supporting encryption with ITS Hey Gyorgy, These are very valuable comments! I am aware of the circular dependency issue because the PSA apis are using the ITS as a storage backend. This, as you said, can be circumvented by using a software crypto library or an implementation specific API. So, for the encryption a flexible API can be used which can allow externals to use their own function calls. Regarding the key storage, this is what I had in mind as well, using derived keys from the HUK. So that we don't need to store anything but the crypto metadata. Adding another layer of storage will raise more issues, I think. ________________________________ From: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>> Sent: Thursday, September 23, 2021 4:30 PM To: Fabian Schmidt <fabian.schmidt(a)nxp.com<mailto:fabian.schmidt@nxp.com>>; Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: [TF-M] Supporting encryption with ITS Hi, AFAIK the main reason for ITS not using encryption is the problem of circular dependency. ITS is used by crypto SP for key storage, so how will crypto fetch the key from ITS to decrypt ITS? You could use a software crypto implementation (another mbed-tls instance) in ITS, but where would you safely store the keys? If you have a two layer ITS, one for only storing the keys for the second instance, and a second, encrypted one, then you end up with something like ITS and PS. You may not need a full blown on-chip FLASH device for ITS. If you have a HUK available, you can derive the same SP specific keys from that at each boot, and store these in RAM backed ITS. You won’t be able to store other keys in ITS in a persistent way of course, but for that you can use PS. Well, something along these lines. Perhaps the TF-M team could help better if you could share some details on why your customer would need encrypted ITS. (A PSA for Cortex-A (TS) maintainer chiming in to a “not his business” discussion here 😉 ) /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Fabian Schmidt via TF-M Sent: September 23, 2021 15:51 To: Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Supporting encryption with ITS Hi George, I’m wondering if that would add value. To my understanding, ITS was never designed to be encrypted because of the way it’s supposed to be set up. (It’s Internal Trusted Storage.) I believe best practice is to place it in a “trusted” location, one that is ideally only accessible from Secure world, and also ideally on-die. If you then restrict outside access to the internal flash (JTAG, flash programmer ports,…), you’re pretty golden, in that no unauthorized party should be able to read from or write to the ITS.* Let me know if I misunderstand anything about ITS or TrustZone, but that’s my view. Maybe I’m painting an idealized picture. Greetings, Fabian Schmidt * at least short of a sophisticated physical attack or finding some loophole in TrustZone… From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vasilakis, Georgios via TF-M Sent: Donnerstag, 23. September 2021 15:28 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [EXT] [TF-M] Supporting encryption with ITS Caution: EXT Email Hey all, Lately the requirement for an encrypted ITS solution is being asked from our customers and I would like to have a discussion here on how we can design this in a reasonable way. The first thought that came to my mind was to add the functionality to the ITS flash-fs layer. This layer contains file metadata in the its_file_meta_t structure and it should be possible to expand this to include additional crypto metadata (conditionally). This seems to be the less invasive change to me, even though it will introduce some increased memory usage since supporting encryption will mean that we cannot read the data in chunks anymore, we will have to use static buffers. At the same time, I looked at the PS partition since I knew that it has support for encryption. I believe that some core concepts of both solutions have similarities even though the code is quite different. For example, a file in ITS is similar to an object in PS and the (linear) list of file metadata in ITS is similar to the concept of the object table in PS. So, I think that it should be possible to design some generic-enough APIs that we can use for both the ITS and PS. Even though this will require some major refactoring in both partitions, it will decrease the code of these services which will probably decrease maintenance later. What are your thoughts on this? Regards, George

2 years, 6 months

6
16
0 0

Documentation improvements

by Anton Komlev

Hello, The project documentation will never be ideal and we are continuing improving it. Let me ask you for reply to this email with the pain points you have experienced or suggestions for improvements to be considered in this phase. Your direct contribution with docs articles will be much appreciated too. For example: TF-M debugging technics and experience would be very helpful. Thank you in advance, Anton

2 years, 7 months

3
3
0 0

Technical Forum call - March 3

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, March 3, 7:00-8:00 UTC (Asian time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

3 years

2
2
0 0

TF-M covertly results and configs to align our coverity environment to TF-M project CI

by Kostiantyn.Tkachov＠infineon.com

Hi colleagues! Could we get a list of MISRA/CERT-C violations that were found by tf-m Coverity CI, as example from https://ci.trustedfirmware.org/job/tf-m-coverity/lastSuccessfulBuild/ Also (if it possible), could you provide Coverity configs to help align this tool setup on our side to CI and to check all changes before any pool requests? Best regards, Kostiantyn Tkachov Cypress Semiconductor Ukraine Firmware Security

3 years

2
1
0 0

Problem compiling Trusted Firmware M in Linux for PSOC64

by AntonioJavier.CabreraGutierrez＠infineon.com

Hello, I am writing to you asking help because we are having problems when I try to compile the Trusted Firmware M from source code. I downloaded the code from the official repository: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git I moved to the last TAG: TF-Mv1.5.0 I am following this tutorial for PSOC64 platform https://tf-m-user-guide.trustedfirmware.org/platform/ext/target/cypress/pso… When I execute the first cmake command indicating the platform and the toolchain everything works well: cmake -DTFM_PLATFORM=cypress/psoc64 -DTFM_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake .. The problems appears when I build the code using the second cmake command: cmake --build cmake_build -- -j I got this output [cid:image003.jpg@01D82A77.95B43640] /home/admin/Escritorio/trusted-firmware-m/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.c: In function 't_cose_crypto_pub_key_verify': /home/admin/Escritorio/trusted-firmware-m/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.c:145:5: error: conversion to non-scalar type requested 145 | verification_key_psa = (psa_key_handle_t)verification_key.k.key_handle; | ^~~~~~~~~~~~~~~~~~~~ /home/admin/Escritorio/trusted-firmware-m/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.c: In function 't_cose_crypto_pub_key_sign': /home/admin/Escritorio/trusted-firmware-m/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.c:194:5: error: conversion to non-scalar type requested 194 | signing_key_psa = (psa_key_handle_t)signing_key.k.key_handle; | ^~~~~~~~~~~~~~~ /home/admin/Escritorio/trusted-firmware-m/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.c: In function 't_cose_crypto_sig_size': /home/admin/Escritorio/trusted-firmware-m/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.c:245:5: error: conversion to non-scalar type requested 245 | signing_key_psa = (psa_key_handle_t)signing_key.k.key_handle; | ^~~~~~~~~~~~~~~ secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/build.make:425: recipe for target 'secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/__/__/__/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.o' failed make[2]: *** [secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/__/__/__/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.o] Error 1 make[2]: *** Waiting for unfinished jobs.... CMakeFiles/Makefile2:1347: recipe for target 'secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/all' failed make[1]: *** [secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/all] Error 2 Makefile:135: recipe for target 'all' failed make: *** [all] Error 2 There are the version of the software that are using: arm-none-eabi-gcc (GNU Arm Embedded Toolchain 10.3-2021.10) 10.3.1 20210824 (release) cmake version 3.23.0-rc2 It seems strange to me that there are compilation errors in the source code, that's why I am writing this mail, in case there is a bug in the code. Best regards. Antonio Javier Cabrera Gutierrez Infineon Technologies AG PhD Candidate R&D Engineer IFAG BEX RDE RDF ISS Office: +49 89 234 36403 Mobile: +49 151 181 34322 AntonioJavier.CabreraGutierrez(a)infineon.com<mailto:AntonioJavier.CabreraGutierrez@infineon.com> Am Campeon 1-15 85579 Neubiberg Germany www.infineon.com<http://www.infineon.com> Discoveries<http://www.infineon.com/discoveries> Facebook<http://www.facebook.com/infineon> Twitter<http://www.twitter.com/Infineon> LinkedIn<http://www.linkedin.com/company/infineon-technologies> Part of your life. Part of tomorrow. Infineon Technologies AG Chairman of the Supervisory Board: Dr. Wolfgang Eder Management Board: Dr. Reinhard Ploss (CEO), Dr. Helmut Gassel, Jochen Hanebeck, Dr. Sven Schneider Registered Office: Neubiberg Commercial Register: München HRB 126492 This e-mail and any attachments are confidential. They are intended solely for the attention and use of the named addressee(s). If you are not the named addressee(s) you must not use, disclose, retain or reproduce all or any part of the information contained in this e-mail or any attachments. Any unauthorized use or disclosure may be unlawful. If you have received this e-mail by mistake, please inform the sender immediately and delete it and all copies from your system and destroy any hard copies of it.

3 years

3
2
0 0

Locking of PRIS bit in AIRCR register

by JAYLES Romain

Hi all, We are currently testing the tfm-m implementation on a STMicroelectronic chip: stm32u5 board. This stm32u5 has a special register: SYSCFG_CSLOCKR (see https://www.st.com/resource/en/reference_manual/rm0456-stm32u575585-armbase…). This register allows to lock the PRIS bit of the AIRCR register from further modification. The issue here is that, in the ST implementation, thanks to this SYSCFG_CSLOCKR, the PRIS bit of the AIRCR is locked at boot (Reset_Handler in file startup_stm32u5xx_s.c). Resulting in the function tfm_arch_set_secure_exception_priorities() not being able to set the PRIS bit of the AIRCR. This situation lead to big issues at runtime as interrupt priority of NSPE are able to pre-empt interrupt of SPE. Disabling the locking of PRIS bit solve our problem but currently we don't see a clean way to integrate chip specific security features (something like callback/tfm_hal_ ) after the function tfm_arch_set_secure_exception_priorities() has been called. What would be the best way to fix the current issue which could also arise on other platform ? Regards, Romain

3 years

3
4
0 0

Please review a new design proposal guideline

by David Hu

Hi all, As part of the documentation improvements, a new design proposal guideline [1] is proposed to replace and simplify the current process. The basic idea is to encourage developers to share their design via mailing list and tech forum, without a well-formatted design document. If developers prefer a document for a new feature, please provide an integration guide/user manual instead. Please check the details in the patch below. [1] https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/14104 The rendered html version: https://ci-builds.trustedfirmware.org/static-files/KTOoRMhB4VsgNQFkdMgWZcZG… Best regards, Hu Ziji

3 years, 1 month

1
0
0 0

Issues with psa_wait() when waiting for interrupts and IPC function calls.

by Martin Gunnarsson

Hello, I am trying to write an Application RoT for a research project I am a part of. I have run into an issue that I have been unable to solve independently. My problem is the unexpected behavior of psa_wait() when using signal masks. I have two signals, TFM_TIMER1_IRQ_SIGNAL and TFM_SECURE_FUNCTION_SIGNAL. The TIMER1_IRQ signal is triggered by an FLIH interrupt handler that returns TFM_FLIH_SIGNAL. The interrupt is triggered every 1 second by TIMER1. The TFM_SECURE_FUNCTION_SIGNAL is triggered by a periodic function call from the NSPE (a Zephyr thread) and is called every 10 seconds. Observed result: If PSA_WAIT_ANY is used as a signal mask, the TIMER0_IRQ_SIGNAL will only be received when TFM_SECURE_FUNCTION_SIGNAL is received, ergo, every 10 s. Thus any stage 2 handling of an interrupt would be missed. If TFM_TIMER1_IRQ_SIGNAL is used as a signal mask, the signal will be received every 1 s as expected. The TFM_SECURE_FUNCTION_SIGNAL will never be received, as can be expected in the NSPEtoo. I have tried a "hybrid approach" where I call psa_wait(TFM_TIMER1_IRQ_SIGNAL, PSA_BLOCK) /* handle signals .... */ and then psa_wait(TFM_SECURE_FUNCTION_SIGNAL, PSA_POLL). The stage 2 IRS is called, and the secure function is also called. But not with the regularity that I would like. Am I missing something obvious? I have read the Secure Interrupt Integration Guide and carefully studied the SLIH and FLIH test services for the TF-M regression tests. Have I forgotten to reset a signal somewhere? Does the interrupt not preempt the NSPE? I would be immensely grateful for any or all responses. If you need more information, please let me know. Best wishes, Martin Gunnarsson PhD Student RISE Research Institutes of Sweden & Lund University Complete code of my Application RoT: #include <stdbool.h> #include <stdint.h> #include <stddef.h> #include "tfm_api.h" #include "tfm_secure_api.h" #include "psa/service.h" #include "tfm_sp_log.h" #include "psa_manifest/pid.h" #include "psa_manifest/tfm_secure_partition.h" #include <hal/nrf_gpio.h> #include <hal/nrf_timer.h> #include <helpers/nrfx_reset_reason.h> #include <nrf_board.h> #include <region_defs.h> #define TIMER_RELOAD_VALUE (1*1024*1024) static volatile uint32_t interrupt_ctr = 0; static volatile uint32_t function_ctr = 0; static void timer_init(NRF_TIMER_Type * TIMER) { nrf_timer_mode_set(TIMER, NRF_TIMER_MODE_TIMER); nrf_timer_bit_width_set(TIMER, NRF_TIMER_BIT_WIDTH_32); nrf_timer_frequency_set(TIMER, NRF_TIMER_FREQ_1MHz); nrf_timer_cc_set(TIMER, NRF_TIMER_CC_CHANNEL0, TIMER_RELOAD_VALUE); /* Clear the timer once event is generated. */ nrf_timer_shorts_enable(TIMER, NRF_TIMER_SHORT_COMPARE0_CLEAR_MASK); } static void timer_stop(NRF_TIMER_Type * TIMER) { nrf_timer_task_trigger(TIMER, NRF_TIMER_TASK_STOP); nrf_timer_int_disable(TIMER, NRF_TIMER_INT_COMPARE0_MASK); nrf_timer_event_clear(TIMER, NRF_TIMER_EVENT_COMPARE0); } static void timer_start(NRF_TIMER_Type * TIMER) { timer_stop(TIMER); nrf_timer_task_trigger(TIMER, NRF_TIMER_TASK_CLEAR); nrf_timer_int_enable(TIMER, NRF_TIMER_INT_COMPARE0_MASK); nrf_timer_task_trigger(TIMER, NRF_TIMER_TASK_START); } static void timer_event_clear(NRF_TIMER_Type *TIMER) { nrf_timer_event_clear(TIMER, NRF_TIMER_EVENT_COMPARE0); } void tfm_secure_controller_secure_timer_start(void) { timer_init(NRF_TIMER1); timer_start(NRF_TIMER1); } void tfm_secure_controller_secure_timer_clear_intr(void) { timer_event_clear(NRF_TIMER1); } psa_flih_result_t tfm_timer1_irq_flih(void) { tfm_secure_controller_secure_timer_clear_intr(); interrupt_ctr++; return PSA_FLIH_SIGNAL; } static psa_status_t tfm_sp_secure_function_ipc(psa_msg_t *msg) { function_ctr++; LOG_INFFMT("Secure function called %u times, interrupt ctr: %u\n", function_ctr, interrupt_ctr ); return PSA_SUCCESS; } void tfm_sp_secure_function(psa_msg_t *msg) { psa_status_t status; status = tfm_sp_secure_function_ipc(msg); psa_reply(msg->handle, status); } void tfm_sp_entry(void) { LOG_INFFMT("Secure Partition: Init\n"); tfm_secure_controller_secure_timer_start(); psa_irq_enable(TFM_TIMER1_IRQ_SIGNAL); psa_signal_t signals = 0; uint32_t ctr = 0; while (1) { signals = psa_wait(TFM_TIMER1_IRQ_SIGNAL, PSA_BLOCK); if ( (signals & TFM_TIMER1_IRQ_SIGNAL) == TFM_TIMER1_IRQ_SIGNAL) { ctr++; LOG_INFFMT("FLIH stage 2 %u\n", interrupt_ctr); psa_reset_signal(TFM_TIMER1_IRQ_SIGNAL); } if ( ctr % 10 == 0 ) { signals = psa_wait(PSA_WAIT_ANY, PSA_POLL); if ( (signals & TFM_SECURE_FUNCTION_SIGNAL) == TFM_SECURE_FUNCTION_SIGNAL) { psa_msg_t msg; psa_get(signals, &msg); tfm_sp_secure_function(&msg); } } } }

3 years, 1 month

2
8
0 0

New API tfm_hal_system_halt()

by Bøe, Sebastian

Hi, in the effort to ease debugging by supporting a choice between halting and rebooting we are introducing a new HAL API: void tfm_hal_system_halt(void) which by default (weak) does: __disable_irq(); while(1) { __WFE(); } CPUs cannot halt. But they can sleep until they are awoken in a loop, which is pretty close. tfm_hal_system_halt() is, when configured so, used by tfm_core_panic() which is why we disable irqs to stop all threads of execution, not just the thread that is executing. Currently it is proposed that tfm_core_panic() halts when TFM_HALT_ON_CORE_PANIC is ON and otherwise reboots. TFM_HALT_ON_CORE_PANIC is default ON if and only if Debug mode is enabled. Any feedback to these changes are welcome, and if any platform needs to halt in a different manner then a contribution would be welcome as well. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/13839

3 years, 1 month

1
0
0 0

TF-M regression test refinements

by Jianliang Shen

Hi, all I'd like to share two new refinements in TF-M test repo to you. l The struct variable test_result_t has been removed from the definition of struct variable test_t. It is unnecessary to set an initial value of test result for each case. With this change, the binary size will be reduced. Please see [test patch]<https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/13822/4> for more details. l The flag TEST_SKIPPED has been added into enum variable test_status_t, works with TEST_PASSED and TEST_FAILED. TEST_SKIPPED indicates that the test case is skipped in runtime when the test environment is unavailable. Please ee [test patch]<https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/13826/5> for more details. Hope these two changes can help your work in the future. Please let me know if anything can be improved. Thanks! Best Regards Jianliang Shen

3 years, 1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M February 2022