Hi,
I saw that PSA_FRAMEWORK_HAS_MM_IOVEC is not permitted for Isolation level 2-3 and transient copies of the input and output data into a 5KB scratch buffer are always made when making a PSA call.
This makes sense as FF-Mv1.1 states:
“In a system using isolation level 3, a Secure Partitions is not permitted to access another Secure
Partition’s Private data. MM-IOVEC can provide a mechanism for one Secure Partition to access the
other’s Private data.”
But I think the requirements for isolation level 3 could be fulfilled by:
If SP detects a Secure caller, it could make a transient copy of I/O data.
If SP detects a Non-Secure caller, it could use MMIOVECs or a similar method to access NS memory directly to avoid overhead and limitations of copying the I/O data.
Is this logical/ correct?
With this approach, an attacker may tamper NS input data while the RoT service is processing those data but rules of isolation level 3 are maintained.
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
Now sure where exactly this belongs, but I already posted question abut the Musca S1 earlier, and this seems relevant. ARM support essentially seem to tell me that they cannot support GDB and they are not certain of DAPLink, and recommend ULINKPLUS debugger with ARM IDE. So wanted to get a sense from anyone who has attempted to use this.
In the following I describe the steps to obtain a base line, then provide description in what way GDB / DAPLink seems to misbehave.
To get a base line:
~~~~~~~~~~~~~
- I build 'samples/hello_world' app using Zephyr 'v3.4.0'. Copy the 'build/zephyr/zephyr.hex' file to '/media/user/MUSCA_S1' directory when the board is USB. Connect a terminal emulator to the UART exposed by USB DAPLink, e.g. 'picocom -b 115200 -y n /dev/ttyACM0'. I can see on the console the followinbg
*** Booting Zephyr OS build zephyr-v3.4.0 ***
Hello World! musca_s1
If I press the reset button, the app restarts as well. This is as expected. I note that this is entirely running as in secure mode, that it does not use TF-M.
- Next I start 'pyocd-gdbserver'. Then start a GDB session using the 'zephyr.elf' file, 'target remote localhost:3333' to connect it to the gdbserver. It connects ok. So I put a breakpoint at "main", do a 'monitor reset halt', and then continue. The breakpoint at 'main' is hit, I can obtain the backtrace to see it is correct as expected.
So my setup seems good.
Next I attempt to test a non-secure app with TF-M.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Build the app using Zephyr build env 'west build -b v2m_musca_s1_ns samples/tfm_integration/tfm_psa_test/ -DCONFIG_TFM_PSA_TEST_CRYPTO=y'. Copy 'build/zephyr/tfm_merged.hex' to '/media/user/MUSCA_S1'. Connect a terminal emulator, picocom, to the console, and hit the PBON (power on) button. I see the following output as expected on the console:
Musca-S1 Dual Firmware Version 1.9
[WRN] This device was provisioned with dummy keys. This device is NOT SECURE
[Sec Thread] Secure image initializing!
Booting TF-M 79a6115d3
[INF][Crypto] Initialising HW accelerator... complete.
*** Booting Zephyr OS build zephyr-v3.4.0 ***
***** PSA Architecture Test Suite - Version 1.4 *****
Running.. Crypto Suite
******************************************
TEST: 201 | DESCRIPTION: Testing crypto key management APIs | UT: psa_crypto_init
[Info] Executing tests from non-secure
This is as expected.
However, if I press the reset button the board does not appear to reset - this is unexpected. Has anyone seen a different behavior? Is the specific board that I have is misbehaving?
- Now I start PyOCD GDB server, start GDB and successfully connect it to the GDB server. The target is halted where it was executing, e.g.
Remote debugging using localhost:3333
CC_HalWaitInterruptRND (data=data@entry=1024)
at /home/zephyr/zephyrproject/modules/tee/tf-m/trusted-firmware-m/lib/ext/cryptocell-312-runtime/host/src/hal/cc3x/cc_hal.c:107
107 irr = CC_HAL_READ_REGISTER(CC_REG_OFFSET(HOST_RGF, HOST_IRR));
(gdb)
This is as expected.
- Next I put a breakpoint at 'sprt_main', then issue a 'monitor reset halt', then issue a 'continue',
The breakpoint is is NOT hit. I see a blue LED blink at perhaps 4 times per second.
This is unexpected. Has anyone seen this behave correctly? Do I have a board that is misbehaving?
Hello.
The ARM MPS2/MPS3 have Cortex M33 two processor configuration. I am building TF-M under the Zephyr OS setup. From the build it appears that the secure (TF-M) and non-secure (Zephyr OS and app) are bound and executed on separate CPUs. Assuming that two CPUs are used, in the build, is there a way to force using same one CPU for TF-M and Zephyr/app, while disabling the second CPU?
Thanks.
Problem: ARoT app is too large, that the image build fails.
Error:
/home/gramshan/zephyr-sdk-0.16.1/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: bin/tfm_s.axf section `.ER_UNPRIV_CODE' will not fit in region `FLASH'
/home/gramshan/zephyr-sdk-0.16.1/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: region `FLASH' overflowed by 114956 bytes
Memory region Used Size Region Size %age Used
FLASH: 572684 B 447 KB 125.11%
RAM: 54556 B 1 MB 5.20%
To overcome this issue, I changed the flash_layout header file (https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/master/platfo…) such that the secure side size is (FLASH_S_PARTITION_SIZE) 700+KB from the 512KB default for the MPS2 AN521 app, and correspondingly update the non-secure side FLASH_NS_PARTITION_SIZEto be 300KB. This builds the tfm_merged.hex file, But fails it to boot the app.
So, I do not use your ARoT, but just built as non-secure app - the 'hello_world' Zephyr app that prints a one line hello_world on the console, but using the modified partition layout. This too fails to boot, in that the "hello world" is not printed. I debugged this to find that it is BL2 that is failing.
I see that the Panic occurs during the image swapping operation, this is because the image to be filled in the primary slot is identified as invalid and the secure boot stops. The TF-M thinks some firmware upgrade is happening, the integrity check fails and panics, thus inducing a Fault Injection Hardening defense.
Now I am stuck with this issue and I do not know how to proceed further, any help on how to change the flash partition sizes in a clean manner would be appreciated.
Hi
There seem to be scheduling bug we have found in SPM.
This bug is related to handling of interrupts that arrives during SVC call and assert signed for partition.
Steps to reproduce:
1. Call psa_wait() from partition (e.g. mailbox partition)
2. During execution of SVC handler generate Interrupt that asserts signal of that partition (e.g. mailbox partition signal ) (adding long delay in SVC handler or adding breakpoint in SVC handler helps to easier reproduce this )
3. Following sequence happens:
* Mailbox IRQ has lower priority than SVC thus SVC is not preempted.
* SVC sees that mailbox partition is blocked (as it is waiting for signal and no signals are pending)
* SVC triggers pendSV
i. Mailbox IRQ and pendSV are both pending
* Mailbox IRQ has higher priority than pendSV thus Mailbox IRQ is executed
* Mailbox IRQ calls spm_handle_interrupt
i. Signal is asserted thus spm_handle_interrupt in thrd_next calls query_state_cb which returns THRD_STATE_RET_VAL_AVAIL and thus tfm_arch_set_context_ret_code is called
ii. tfm_arch_set_context_ret_code sets return code using OLD value of partition PSP (as it was never updated, as it is updated in PendSV)
* Mailbox IRQ return, pendsv is started and it runs mailbox partition
i. Mailbox partition has 0 as signal because return value was written to wrong location is stack
Patch I have attached to the mail solves this problem for us BUT it seems more like a workaround than a proper fix(
Anyways it would be nice to have this problem review by SPM experts and have proper fix (maybe we have other places with same problem...)
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,
I’d like to give you a heads-up that build split feature branch will be merged back to main branch very soon this week.
Trusted-firmware-m build split branch: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/?h=feature…
Tf-m-tests build split branch: https://git.trustedfirmware.org/TF-M/tf-m-tests.git/tree/?h=feature-build-s…
Build split feature improves how NS side integrate with TF-M SPE and therefore build commands are changed for building regression tests and PSA arch tests.
Could you please refer to https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/23898 for updated commands/configuration to integrate NS side and port platforms after build split?
If anything is broken after build split, please let us know. It would be also appreciated if you could contribute to build split. 😊
Any feedback or comment is welcome.
Best regards,
Hu Ziji
I have a few questions regarding RSS and Secure Enclave to see what's required and considered for SoC design to leverage RSS and why we nee to use RSS & TF-M
1. What is the difference between RSS and Secure Enclave?
- Is RSS the same as Secure Enclave?
- Or is it referring to any subsystem providing runtime crypto service regardless of whether it's a Secure Enclave or not?
Question below is assuming RSS is a Secure Enclave......
2. What enables TF-M to operate as a Secure Enclave?
- To operate as a Secure Enclave, HW support is mandatory?
a) If so, we must use a Secure Enclave IP such as cryptoisland(CI-300P-C)?
b) Or can we construct a Secure Enclave with some other IPs(LCM, KMU, CryptoCell) metioned RSS doc? (by using TF-M without secure enclave IP)
It feels vague whether this can be called a Secure Enclave...
https://tf-m-user-guide.trustedfirmware.org/platform/arm/rss/rss_key_manage…
- If HW support is not mandatory, I wonder how TF-M can operate as a Secure Enclave.
- The article below seems to say that TF-M can provide Secure Enclave functionality without HW support. or I may misunderstand.
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.2.0/tfm/technical_re…
Hi,
Reading through https://tf-m-user-guide.trustedfirmware.org/integration_guide/non-secure_cl… I'm wondering why so much of the work is done in the secure world. Ultimately, the secure world relies on the non-secure world to tell it the client_id, directly or indirectly. Is there a good reason for the NCSE part to reside in the secure world, rather than the non-secure?
Particularly as the document states that the non-secure RTOS may have a built-in "Secure Context Manager", there may well be redundancy between that and NCSE that could be eliminated if the NCSE was in the NSPE. And the less code there is in the secure world, the less scope for vulnerabilities.
If client_ids themselves were passed from the NS to the S world, it would probably be very easy to use that same interface on the NS core in a dual core system, too.
Chris
Hi,
Seems like following code
$<$<BOOL:TFM_PARTITION_PLATFORM>:${CMAKE_CURRENT_SOURCE_DIR}/services/src/tfm_platform_system.c>
In platform/ext/target/arm/corstone1000/CMakeLists.txt is wrong because it uses TFM_PARTITION_PLATFORM but should use ${ TFM_PARTITION_PLATFORM }
If so then maybe platform maintainers can fix this.
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>
Is 11.2-2022.02 the recommended compiler version?
I saw TF-M v1.8 states:
" GNU Arm compiler version *10-2020-q4-major* has an issue in CMSE
support. The bug is reported in `here <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99157>`__.
Select other GNU Arm compiler versions instead.
GNU Arm compiler version greater and equal than *11.3.Rel1* has a linker issue in syscall.
Select other GNU Arm compiler versions instead.
"
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.