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
Hello,
This is an announcement of TF-M v1.6.1 hotfix preparation. The reason for the hot fix is the recently found incorrect stack sealing in Library model.
The library mode is deprecated already but is available in v1.6.0 and the intention is to leave it in the best shape to our knowledge.
Security analysis shows no vulnerability was brought by this defect, so it is not a security fix.
The plan is to issue the fix by Nov 17.
TF-M release cadence and process is here: https://tf-m-user-guide.trustedfirmware.org/releases/release_process.htmlte…
Thanks,
Anton
Hello!
While playing around with TF-M I have stumbled upon unexpected behavior:
In a sequence of ITS api calls like:
a.) psa_its_set(TEST_UID_1, sizeof(write_data_1), write_data_1, PSA_STORAGE_FLAG_NONE);
b.) psa_its_set(TEST_UID_2, 0, NULL, PSA_STORAGE_FLAG_NONE);
c.) psa_its_remove(TEST_UID_1);
d.) psa_its_set(TEST_UID_2, sizeof(write_data_2), write_data_2, PSA_STORAGE_FLAG_NONE);
e.) psa_its_get(TEST_UID_2, 0, sizeof(read_data_2), read_data_2, &read_data_length);
with
#define TEST_UID_1 2U
#define TEST_UID_2 3U
const uint8_t write_data_1[] = "ONE";
const uint8_t write_data_2[] = "TWO";
It seems that step e) does not return the data written in step d).
I believe I have root-caused it to an issue in its_flash_delete_idx() (see below), but since
this is a rather straightforward API call sequence, I wonder whether this is not rather an issue
in my environment and would be glad if someone could confirm it or point me to
a direction of a potential different cause?
I am using TF-M version 1.6, a nor flash with (erase) block size 0x1000 bytes and a program unit
size (page size) of 0x100 bytes.
Thank you, best regards
Stefan Krug
More analysis details:
After step c) there will be the following relevant metadata blocks in the filesystem:
1.) unused metadata block (used to have the metadata of TEST_UID_1)
2.) metadata block of TEST_UID_2
During step d) the update of TEST_UID_2 is done in two steps - first step is to
write metadata + content of TEST_UID_2. After this step, the metadata blocks look like:
1.) NEW metadata block of TEST_UID_2
2.) old metadata block of TEST_UID_2 (indicating TEST_UID_2 to be erased)
The second step is to delete the outdated file, and compact/defragment the data
in the file system. This is done in its_flash_fs_delete_idx().
its_flash_fs_delete_idx will collect the amount of data bytes to preserve.
There are two parts of data to be preserved, a chunk of data before the deleted
file (of size del_file_data_idx) and a chunk of data after the deleted file.
Calculation of del_file_data_idx is done by taking the start offset of the
to-be-deleted file. In this particular situation the start of the old
TEST_UID_2 is the same as the start of the new TEST_UID_2. The subsequent
its_flash_fs_dblock_compact_block will only keep data up to del_file_data_idx -
in this case it will NOT keep the data of the new TEST_UID_2 - this data is
lost.
Hi all,
TFM Library model has been deprecated, thus AUDIT logging partition has been deleted, but I still see a reference to that partition in
config/check_config.cmake lines 102-103:
#Audit log is not supported in IPC model, disable it by default
tfm_invalid_config(TFM_PARTITION_AUDIT_LOG)
Looks like this should be removed or comment fixed.
An I missing something or this is a mistake that should be fixed?
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>
Hi all,
I have a few questions regarding an521 platform protection settings for Level 3 isolation.
In platform/ext/target/arm/mps2/an521/tfm_hal_isolation.c there is an const static struct mpu_armv8m_region_cfg_t region_cfg[] - for L3 it specifies to protect:
* Code (from Image$$PT_RO_START$$Base to Image$$PT_RO_END$$Base) to be accessible in both PRIV and UNPRIV states.
* PSA RoT partitions data in RAM (from Image$$PT_PRIV_RWZI_START$$Base to Image$$PT_PRIV_RWZI_END$$Base)to be accessible only in UNPRIV state.
* TFM_SP_META_PTR to be accessible in both PRIV and UNPRIV states.
Also in this file mpu_armv8m_enable() function call specifies PRIVILEGED_DEFAULT_ENABLE for MPU.
I have following question to this configuration
* Does this configuration mean that in L3 PSA RoT code is not isolated from APP RoT (APP RoT can read/execute PSA RoT domain code)?
* How SPM data (TFM_BSS and TFM_DATA sections from scatter file) is protected? I cant see it being protected by MPU.
* Is it skipped because PRIVILEGED_DEFAULT_ENABLE is set which means that SPM will be able to access this data and this allows to save one MPU region?
* If so then why MPU region is used for PSA RoT partitions data?
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>
Hi all,
I have tried building Extra S and NS tests from tf-m-extras repo for PSoC64 and the result I got is that device prints message that extra S test started and reboots.
Here is the command line I used:
cmake -S . -B build_psoc64 -G "Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DTFM_LVL=2 -DEXTRA_S_TEST_SUITES_PATHS=< tf-m-extras path>/examples/extra_test_suites_example/extra_s -DEXTRA_NS_TEST_SUITES_PATHS=<tf-m-extras path>/examples/extra_test_suites_example/extra_ns
I have also tries building with following command line (same as before but -DTEST_S=ON and -DTEST_NS=ON added):
cmake -S . -B build_psoc64 -G "Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DTFM_LVL=2 -DEXTRA_S_TEST_SUITES_PATHS=< tf-m-extras path>/examples/extra_test_suites_example/extra_s -DEXTRA_NS_TEST_SUITES_PATHS=<tf-m-extras path>/examples/extra_test_suites_example/extra_ns -DTEST_S=ON -DTEST_NS=ON
The result is the same - message about starting Extra S test suite is printed and then device reboots.
Could someone please test it on other platform and let me know whether Extra S and NS tests works there.
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>