Hi everyone,
Some time ago patch for split build<https://review.trustedfirmware.org/q/topic:%2522split-build%2522> of SPE, NSPE, BL2 was announced.
I am interested on when this patch is planned to be merged?
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,
The branch release/1.7.x<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/log/?h=release/…> has been created indicating the start of the release process and features freeze.
RC1 tag will follow after successful run of the basic tests.
Let me remind that the code is not frozen, and development can be continued on the main branch.
Thanks,
Anton
Hi,
when I updated from CMake 3.24.0 to the new (two weeks old) CMake 3.25.0 I am no longer
able to build TF-M with -DTEST_PSA_API=CRYPTO.
(Downgrading CMake fixes the issue)
Is there an interoperability issue with the latest CMake release and the TF-M build system?
Reproduced with
TF-Mv1.7.0-RC1
TF-Mv1.6.0
Steps to reproduce:
1. install CMake 3.25.0.
1. cd trusted-firmware-m
1. rm -rf cmake_build && cmake -G Ninja -S . -B cmake_build -DTEST_PSA_API=CRYPTO -DTFM_PLATFORM=nordic_nrf/nrf5340dk_nrf5340_cpuapp -DTFM_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Debug && ninja -C cmake_build
Only reproduces with TEST_PSA_API and CMake 3.25.0. Builds fine with 3.24.0 or non-PSA API builds.
error:
file INSTALL cannot find
"/home/sebo/ncs/modules/tee/tf-m/trusted-firmware-m/cmake_build/tf-m-tests/app/psa_api_tests/src/psa_generate_database-build/target_database.h":
No such file or directory.
Hello,
I'm trying to build the Trusted Firmware M on Win10 x64 for NXP LPC55S69 using the IAR compiler, but I get the following error:
[ 76%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/platform/ext/target/nxp/lpcxpresso55s69/Device/Source/startup_lpcxpresso55s69.o
extern uint32_t __INITIAL_SP;
^
"C:\Work\TF-M\trusted-firmware-m\platform\ext\target\nxp\lpcxpresso55s69\Device\Source\startup_lpcxpresso55s69.c",29 Error[Pe007]:
unrecognized token
extern uint32_t __INITIAL_SP;
^
"C:\Work\TF-M\trusted-firmware-m\platform\ext\target\nxp\lpcxpresso55s69\Device\Source\startup_lpcxpresso55s69.c",29 Error[Pe065]:
expected a ";"
extern uint32_t __INITIAL_SP;
^
"C:\Work\TF-M\trusted-firmware-m\platform\ext\target\nxp\lpcxpresso55s69\Device\Source\startup_lpcxpresso55s69.c",29 Error[Pe007]:
unrecognized token
extern uint32_t __STACK_LIMIT;
^
"C:\Work\TF-M\trusted-firmware-m\platform\ext\target\nxp\lpcxpresso55s69\Device\Source\startup_lpcxpresso55s69.c",30 Error[Pe007]:
unrecognized token
extern uint32_t __STACK_LIMIT;
^
"C:\Work\TF-M\trusted-firmware-m\platform\ext\target\nxp\lpcxpresso55s69\Device\Source\startup_lpcxpresso55s69.c",30 Error[Pe065]:
expected a ";"
extern uint32_t __STACK_LIMIT;
^
"C:\Work\TF-M\trusted-firmware-m\platform\ext\target\nxp\lpcxpresso55s69\Device\Source\startup_lpcxpresso55s69.c",30 Error[Pe007]:
unrecognized token
(VECTOR_TABLE_Type)(&__INITIAL_SP), /* Initial Stack Pointer */
In the attachment, you can find the full build log and also the CMake build file generation log.
Some details about my setup:
Win10 Enterprise x64. Version 20H2
IAR ANSI C/C++ Compiler V8.50.9.278/W32 for ARM
GNU Make 3.81
git version 2.36.0.windows.1
CMake 3.24.2
Python 3.10.5
I followed the steps from the Getting started guide here<https://tf-m-user-guide.trustedfirmware.org/getting_started/index.html> than the steps to build the framework for LPC55S69 here<https://tf-m-user-guide.trustedfirmware.org/platform/nxp/lpcxpresso55s69/RE…>.
Do you have any idea what I'm missing?
In case you need any further information let me please know.
Thanks in advance.
Kind regards,
Ildikó Pocsai
Hello,
I see that in coming 1.7.0 the file secure_fw/spm/ns_client_ext/tfm_ns_ctx.h contains a comment
/* Supported maximum context for NS. Only support single context for now. */
#define TFM_NS_CONTEXT_MAX 1
Does it mean that several simultaneous NSC call is not supported ?
Best regards
ST Restricted
Dear developers,
I have a question about interrupt SLIH scheduling in IPC model.
Assume that there are two secure partitions P1 and P2, and P1 has higher priority than P2.
P1 calls psa_call(), so SPM blocks P1 and wakes up P2 to execute P2's service handler.
Now P2 is running. Suddenly P1's interrupt occuerred, and P1's SLIH signal is asserted for more processing.
A shedule request is also triggered.
Since P1 has higher priority than P2, will P2 be preemted by P1 to execute P1's SLIH immediately?
If the answer is yes, the psa_call() chain will be corrupted, right?
Thanks in advance.
Alvin Chang
Hi,
Partition is described through configuration in YAML files (manifests). This configuration includes following properties (see Adding Secure Partition - Add manifest<https://tf-m-user-guide.trustedfirmware.org/integration_guide/services/tfm_…>):
* Name, type, priority, model, ...
* List of services provided by partition
* MMIO regions
* List of IRQs
* Dependencies
Each platform should provide implementation of HAL which is specific to standard partitions like Crypto, ITS, etc. It's mandatory to provide proper isolation of memory/peripheral that are used by platform specific code that provides HAL implementation or add a custom dependency for standard partition.
Currently platform can use following approaches to resolve the problem of extending YAML of standard TF-M partition:
* Create a platform specific copy of partition YAML, see https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15639 as an example of such approach.
* Modify standard partition by introducing optional fields, see https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/17718.
These both solution are not flexible enough. It requires to modify platform independent code or maintain own copy of partition YAML file with needed changes.
I think it make sense to integrate partition YAML extension tool in TF-M. Platform/application should be able to provide manifest-extension file(s). Such manifest-extension file may provide additional properties which should be joined with properties provided by standard partition manifest files.
For example to solve problem for https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15639 ARM RSS platform may provide following manifest-extension file with structure like this:
{
"extensions": [
{
"name": "TFM_SP_INITIAL_ATTESTATION",
"dependencies": [
"TFM_MEASURED_BOOT"
]
}
]
}
Tool which parses manifests should add a new dependency on "TFM_MEASURED_BOOT" to list of dependencies for "TFM_SP_INITIAL_ATTESTATION" partition.
Please, share your opinion on this topic.
Best regards,
Roman.
Hello!
Seemingly, there is an issue with file deletion in ITS. I would think it is not
possible to delete the last object in a data block (so that the data
block becomes empty).
It's easiest to reproduce with using large objects (because then the number of
involved objects is small), but would also happen with multiple
smaller objects:
With the following flash configuration:
ITS_MAX_ASSET_SIZE=0x1000
TFM_HAL_ITS_SECTORS_PER_BLOCK=1
TFM_HAL_ITS_FLASH_AREA_SIZE=0x20000
TFM_HAL_ITS_PROGRAM_UNIT=0x100
ITS_FLASH_NAND_BUF_SIZE=1*0x1000
In a sequence of writing and deleting an object like:
const uint8_t big_file[ITS_MAX_ASSET_SIZE] = {0};
status = psa_its_set(uid, sizeof(big_file), big_file, flags);
status = psa_its_remove(uid);
deleting the file fails with the status of PSA_ERROR_GENERIC_ERROR.
What I think happens is:
Due to the size of the file, it does not fit in the metadata block, and is put a
second (data only) block. The object is written there as expected.
When the data block is deleted later, an attempt is being made to compact it
with its_flash_fs_dblock_compact_block(). However, there is no data to keep
before the object to be deleted and also no data to keep after it, this block
will become empty, so no call to its_flash_fs_block_to_block_move() happens,
which causes no call to fs_ctx->ops->write() happens. Now the flash driver in
my case is a buffering its_flash_nand.c. In the write() call it would associate
a buffer for the physical sector to write. But since there is no write() call
the subsequent fs_ctx->ops->flush() fails as it has no buffer to flush out.
I believe no compaction of the block should even be attempted - it is known
that the block will be empty beforehand. Perhaps similar to
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/17578, this is
yet another reason to skip compacting of the block?
It would be very much appreciated if one of the experts could confirm this
suspicious behavior or point out a mistake I am making.
Thank you very much, best regards
Stefan Krug
