Hi, if I set PS_ENCRYPTION=OFF
set(PS_ENCRYPTION OFF CACHE BOOL "Enable encryption for Protected Storage partition")
I see this compile error:
In file included from /home/brian/gits/spe/source/third_party/tfm/secure_fw/partitions/internal_trusted_storage/tfm_internal_trusted_storage.c:32:
/home/brian/gits/spe/source/third_party/tfm/secure_fw/partitions/internal_trusted_storage/../protected_storage/ps_object_defs.h:48:31: error: 'PS_TAG_LEN_BYTES' undeclared here (not in a function)
48 | #define PS_TAG_IV_LEN_MAX ((PS_TAG_LEN_BYTES > PS_IV_LEN_BYTES) ? \
| ^~~~~~~~~~~~~~~~
/home/brian/gits/spe/source/third_party/tfm/secure_fw/partitions/internal_trusted_storage/../protected_storage/ps_object_defs.h:60:20: note: in expansion of macro 'PS_TAG_IV_LEN_MAX'
60 | uint8_t tag_iv[PS_TAG_IV_LEN_MAX];
| ^~~~~~~~~~~~~~~~~
/home/brian/gits/spe/source/third_party/tfm/secure_fw/partitions/internal_trusted_storage/../protected_storage/ps_object_defs.h:48:50: error: 'PS_IV_LEN_BYTES' undeclared here (not in a function)
48 | #define PS_TAG_IV_LEN_MAX ((PS_TAG_LEN_BYTES > PS_IV_LEN_BYTES) ? \
| ^~~~~~~~~~~~~~~
/home/brian/gits/spe/source/third_party/tfm/secure_fw/partitions/internal_trusted_storage/../protected_storage/ps_object_defs.h:60:20: note: in expansion of macro 'PS_TAG_IV_LEN_MAX'
60 | uint8_t tag_iv[PS_TAG_IV_LEN_MAX];
| ^~~~~~~~~~~~~~~~~
make[7]: *** [secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/build.make:90: secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/tfm_internal_trusted_storage.o] Error 1
I think the correct fix is to add the following highlighted code to ps_object_defs.h. Patch is attached.
/*!
* \struct ps_object_t
*
* \brief The object to be written to the file system below. Made up of the
* object header and the object data.
*/
struct ps_object_t {
struct ps_obj_header_t header; /*!< Object header */
uint8_t data[PS_MAX_OBJECT_DATA_SIZE]; /*!< Object data */
#ifdef PS_ENCRYPTION
uint8_t tag_iv[PS_TAG_IV_LEN_MAX];
#endif
};
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
Hi,
Is it possible to call psa_call() with NULL outvecs with TF-M v2.0? I am using IPC model. This worked for me with TF-M v1.8 but now I see get a NULL pointer dereference with TF-M v2.0 when psa_reply() is called. Specifically, it happens inside update_caller_outvec_len().
It seems msg.out_size[i] is non-zero (due to a previous psa_call which had 3 outvecs). handle->caller_outvec[i].len causes a NULL pointer deference.
void update_caller_outvec_len(struct connection_t *handle)
{
uint32_t i;
for (i = 0; i < PSA_MAX_IOVEC; i++) {
if (handle->msg.out_size[i] == 0) {
continue;
}
SPM_ASSERT(handle->caller_outvec[i].base == handle->outvec_base[i]);
handle->caller_outvec[i].len = handle->outvec_written[i];
}
}
spm_associate_call_params() does not clear msg.out_size[] so the previous contents remain.
One potential fix is to add the highlighted code below to clear out_size[].
[cid:image001.png@01DA27A5.8860E6F0]
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
12500 TI Blvd, MS F-4000
Dallas, TX 75243
214-479-4076
Hi all,
I noticed that partition log subsystem uses stdio_output_string through following chain of calls tfm_hal_output_sp_log => SVC TFM_SVC_OUTPUT_UNPRIV_STRING => tfm_hal_output_spm_log => stdio_output_string. SVC handler doesn't validate arguments, so it's allows APP RoT partitions to access PSA RoT memory via partition log subsystem.
It seems that tfm_hal_memory_check must be called on SVC handler to validate permissions.
Best Regards,
Roman.
Hi, I'm seeing references in the documentation for preload.cmake and several files with that name in TF-M v2.0.0. But looking at the code it seems like preload.cmake was replaced with cpuarch.cmake. Am I missing something? Where should be put fixed platform-specific definitions which are not related to CPU architecture?
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
Hi all
It seems to me like following check
# FWU_DEVICE_CONFIG_FILE exists and is a file
if(NOT EXISTS ${FWU_DEVICE_CONFIG_FILE})
message(FATAL_ERROR "FWU_DEVICE_CONFIG_FILE:${FWU_DEVICE_CONFIG_FILE} does not exist.")
elseif(IS_DIRECTORY ${FWU_DEVICE_CONFIG_FILE})
message(FATAL_ERROR "FWU_DEVICE_CONFIG_FILE:${FWU_DEVICE_CONFIG_FILE} is a folder while a file is expected.")
endif()
in secure_fw/partitions/firmware_update/CMakeLists.txt is redundant as FWU_DEVICE_CONFIG_FILE may be generated, thus not present when cmake performs EXISTS check (note that by default FWU_DEVICE_CONFIG_FILE is generated so I dont see point in limiting user from using generated file)
So i propose to remove this check.
Regards,
Bohdan Hunko
Cypress Semiconductor Ukraine
Engineer
CSUKR CSS ICW SW FW
Mobile: +38099 50 19 714
Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>
Hello,
I am happy to announce the new release of TF-M v2.0.0<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tag/?h=TF-Mv2.0…>.
The major version update indicates the important changes in the way TF-M builds.
New major features are:
* TF-M secure build process and non-secure build process are split.
* Refer to TF-M Build Instruction to build SPE image.
* Refer to Building Tests to build non-secure tests.
* Update new Mailbox agent API.
* Decouple the specific application Mailbox from SPM, make it an application in Secure Partition.
* Unify the interfaces between partitions and SPM, and reduces the interaction interface between them.
* Multi-core support in the Secure Function (SFN) model.
* Optimize SPM critical section implementation to reduce time cost in isolation level 2&3.
* Use local variables for connection handles instead of dynamic allocation.
* P256-M component is enabled on the TF-M side in profile medium.
* MCUboot upgrade to v2.0.0.
* Mbed TLS upgrade to v3.5.0.
* TF-M PSA client API performance profiling is tracked in SQUAD and the profiling tool is updated.
* TF-M integrates Read the Docs.
Please check the release notes<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/25143/12/doc…> for more information.
The release branch changes will be ported to the main branch shortly.
Many thanks to everyone for contributing, reviewing and supporting this milestone.
Anton
The Laird Connectivity platform board BL5340 DVK no longer compiles in the main branch of TF-M after the split build feature was merged.
The BL5340 DVK is a module that contains the nRF5340 SoC, because of this the platform is re-using the Nordic platform support files.
This cross-reference is causing us, the maintainers of Nordic a lot of problems as making changes to the Nordic platform code can break the Laird Connectivity platform.
We don't have this board either to run any tests and confirm any changes.
Laird Connectivity has not contributed to the platform support for more than a year.
Nordics strategy for maintaining support for TF-M is to have the base DK supported in TF-M for testing purposes, and then provide support for all other boards in our SDK through our board support configuration system.
Removing the platform from TF-M will still mean that the BL5340 DVK board is supported in the nRF Connect SDK.
To support the board in the Zephyr Project the following PR is needed: https://github.com/zephyrproject-rtos/zephyr/pull/65823
Joakim Andersson
Nordic Semiconductor
hello.
I have ported corestone1000 plaform to tfm and am trying to use mhu to send and receive messages between secure enclave (SPE)core and host core(NSPE). (I want to use it for future encryption requests).
Looking at the rss platform and corstone-1000 tfm code, the function for initializing and registering the mhu seems to be tfm_inter_core_comm_init.
But I can't find the part that calls tfm_inter_core_comm_init.
Can anyone tell me the procedure and a simple example of sending and receiving messages using MHU in a TFM environment? I've been looking through the TFM documentation, but I can't find it yet.
Below is the tfm_inter_core_comm_init function to register the rpc of the spe in rss.
I was wondering where the function below is called and used.
int32_t tfm_inter_core_comm_init(void)
{ int
int32_t ret;
/* Register RPC callbacks */
ret = tfm_rpc_register_ops(&rpc_ops);
if (ret != TFM_RPC_SUCCESS) {
return ret;
}
/* Platform specific initialization */
ret = tfm_multi_core_hal_init();
if (ret != TFM_PLAT_ERR_SUCCESS) {
tfm_rpc_unregister_ops();
return ret;
}
} return TFM_RPC_SUCCESS;
}
You are a newbie to TFM and are looking for help.
Hello,
I have recently trying to flash the B-U585I-IOT02A board by running the 3
scripts generated in the build folder, as I usually do with the STM32L552
board. However, I encountered some unexpected errors as I noticed that the
secure and non-secure images were being written to external flash address
spaces. I quickly noticed that this was happening because the
"flash_layout.h" file defines the variable "EXTERNAL_FLASH". Additionally,
the "image_macros_to_preprocess_bl2.c" set the image as encrypted by
default with "RE_IMAGE_ENCRYPTED= 0X01", causing the "TFM_UPDATE.sh" script
to write to the secondary slots.
I found it quite strange because tf-m presented an off-the-shelf solution
for the other board while for this board it assumes the use of an external
flash.
Nevertheless, I tried to work around these limitations by commenting the
EXTERNAL_FLASH variable and assigning the "RE_IMAGE_ENCRYPTED= 0X00"
similarly to the stm32l552. This led to the images being written to the
primary slots defined in the flash layout, however, in runtime I
encountered an error that states "Unable to find bootable image".
Therefore, my question is: Do I need to make further adjustments, or is it
possible that there's a configuration issue that is not compatible with the
board?
Best regards,
João Bento