• State Verified Answer
  • Replies 2 replies
  • Subscribers 65 subscribers
  • Views 163 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 328057
Options

Can one run a custom c-application in the Arm TrustZone (especially using VSCode)?

gdl

Hi, here in the documentation (https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/config_and_build/board_support/processing_environments.html) for the latest nRF Connect SDK it says:
"The application is built as a non-secure image and Trusted Firmware-M (TF-M) is built as the secure image. The build system merges both images to form a combined image that will be used for programming or updating the device.
TF-M enables hardware-supported separation of firmware. It also implements Platform Security Architecture (PSA) API, which provides security features for the system, including roots of trust for protecting secrets, platform state, and cryptographic keys. The API coordinates the communication with the components in NSPE."
So this currently sounds to me like the secure image is Trusted Firmware-M and is not written by the user (can be interacted with through an API only), or?

However I have code of two applications written in c, one of which should run in the secure world while the other runs in the non-secure world and calls functions of the application running in the secure world. (I use an Nordic Semi nRF9161.)

Is it als possible/supported to run custom code/a custom application in the secure world (= inside TrustZone)?

And I use Visual Studio Code with the nRF Connect extension etc and can run a simple single application on the board. However how can you configure the VS-Code nrf-Connect-extension to use some files for the secure application and some files for the non-secure application (if that's possible)?

Thanks for any help

Parents
  • +1

    Hi,

    There is nothing from a hardware perspective that dictates that you must use TF-M. You can in theory also run another secure image, like we did early on in the SDK before introducing TF-M. However, TF-M is the only thing we support now, ant it is heavily integrated in the SDK. So I would strongly advice that you stick with TF-M.

    That said, you can expand TF-M yourself. Both with pure software servicds, and services that integrade with specific hardware. This is demonstrated by the TF-M secure peripheral partition sample.

    The VS code extension supports multi image builds and also debugging multi image builds. You can experiment with this using SDK examples to see how it works, but in generall it is quite seemless and behaves as you would expect.

Reply
  • +1

    Hi,

    There is nothing from a hardware perspective that dictates that you must use TF-M. You can in theory also run another secure image, like we did early on in the SDK before introducing TF-M. However, TF-M is the only thing we support now, ant it is heavily integrated in the SDK. So I would strongly advice that you stick with TF-M.

    That said, you can expand TF-M yourself. Both with pure software servicds, and services that integrade with specific hardware. This is demonstrated by the TF-M secure peripheral partition sample.

    The VS code extension supports multi image builds and also debugging multi image builds. You can experiment with this using SDK examples to see how it works, but in generall it is quite seemless and behaves as you would expect.

Children
Related