TFM / CubeMX integration

[bear2023R]

HI,

we are interested in a guide to  a clear workflow of integrating CubeMX-generated code for U5 into TFM-based application.

In particular:
1. We have trustzone-enabled CubeMX-generated app with Azure RTOS and TouchGFX. The IDE and compiler are IAR. We want to be able to easily debug and re-build it, as needed, without any much security involved and, even most important, without manipulations with flash loaders and signed binaries every time a single line of code gets changed. 

2. Once we are happy with stable code behaviour, then we want to "wrap" it in TFM, by letting the latter to create signed binaries and the loader, as per TFM example for U5 from STM. If any intermittent step((s) required to achieve so: adjusting addressees, locations, etc - we are OK to create custom pre/post builds ourselves. But we'd like to know what exactly steps are needed.

So the questions are:

a). Is there any help/guide/examples or any other support can be expected from STM for that matter?
(Yes, we read through manuals, ANs, and even through Secure workshop). None of those letting you the above task be achieved in a feasible way). If not - can they be provided?

b). Can the gap between widely used CubeMX ecosystem and TFM framework be closed in a painless way with step-by-step guide from STM?
At minimum, a clear explanations on what memory areas TFM loader locks, which access rights assigns, and can they be then coexisting with CubeMX assigned, - may help a lot. What parts of HAL  initialization and at which points shall be shared between both and what exactly way? And so forth. Ideally, a simple trust-zone enabled "Hello world" app, running with and without TFM would be extremely helpful and be an answer to all the above.
I.e. something similar to non-trustzone example for SBSFU and L476 in Secure Workshop sessions.

c). What are the TFM dependencies on TFM bootloader? Can be TFM PAS services called without being preloaded first in heavily secured, time-consuming and hard-to-debug way by a bootloader - i.e. from "standalone" application, as described in (1)  and (2) above? For instance, this "tfm_core_get_boot_data" fails if secure app is attempted running standalone, without a bootloader.

===============================================

Last , but not least: are there any plans to close finally a long-time reported simple yet very annoying bug in CubeMX when the latter doesn't allow to generate correct TouchGFX code for Azure RTOS in TrustZone-enabled projects? It forces time consuming workarounds after each code re-generation. The Azure RTOS option is still grayed out in CubeMX 6.12.1 after more than  4 CubeMX releases since the bug was reported.

Many thanks in advance.

[Jocelyn RICARD]

Hello @bear2023R 

Regarding the first points, could you please tell what do you expect from TFM ?

I mean, do you want to use TFM services related to secure storage and cryptography or you just want a secure boot?

About your last point, I'm not sure what limitation your are talking about.

I tried a simple project with TZ enabled on U585, enabled ThreadX and then enabled TouchGFX. But I'm not usually using TouchGFX so I can miss something for sure. Could you please describe the issue or give a link?

Thank you

Best regards

Jocelyn

[bear2023R]

HI Jocelyn

thank you very much for asking.

We'd expect:

1. We have TrustZone-enabled Secure+NonSecure application, with ThreadX and TouchGFX, using CubeMX as hardware configurator.

We need to port in to to TFM for the following reasons, in order of importance:

1) Secure boot and firmware OTA
2) We need to support secure functionality  (authentification, authorization, session security etc.) while connecting to the cloud storage (custom server). Surely, it can be done with libraries, yet as long as here is already TFM - ideally it would be some of its services.

So, it is important to have:

CubeMX,and TouchGFX (its Graphical Designed) generated code, running under ThreadX, to be compatible  and relatively painlessly glued with TFM framework. TouchGFX mentioned just because it is also using autocode generation for GUI screens, assets and screen transitions, so we'd expect that code be properly wrapped by TFM app - all folder tree etc. ideally shall be compatible or requiring a minimal work.

Any guide in that regard will be highly appreciated!
Ideally a sample project:  simplest possible blinking LED, running ThreadX in non-secure app and secure part, demonstrating TFM initialisation and its run-time stage.

IN addition, we'd like to be able to debug/rebuild application freely, as if there is no loader (TFM) at all, - and only when it is necessary to flash according to TFM-expected flash-layout. Using whatever scripts, for instance, or dedicated project configuration. It is relatively easy(?) to achieve, however, ideally that also shall be a part of integrated CubeMX/TFM solution, as long as STM provide both.

We are using IAR.

Right now we have these results:

1. SBSFU from U5 FW 1.6 can be compiled, example works fine. Relatively easy to port all the above. However, there no support for any secure services and doesn't claim certifications campriable to TFM. We are a medical company and need all those approvals..
Debugging is difficult.

2. TFM example from U5 FW 1.6 - compiles, example works fine. Very different initialization to what CubeMX produces though, not clear on ThreadX, so the porting looks a very time-consuming task.
Debugging is very difficult.

3. Example from "x-cube-azure-v2-3-0 " doesn't even compile so far. HUndreds of errors, wrong paths, duplicate declarations , missing files and lack of compatibility with latest U5 FW 1.6 (seems like). So trying it with limited success (lesseer errors) on 1.3 yet still no joy. HOwever it has CubeMX generated code (seems like) a..nd ThreadX OS. So seems like might be a help if it compiles....

=================================================

As per last point:

CubeMX+TrustZone+ThreadX+TouchGFX issue is here:

https://community.st.com/t5/stm32-mcus-touchgfx-and-gui/new-cubemx-6-11-1-still-dowsn-t-fix-touchgfx-for-threadx/td-p/673181

And there is still no fix since March.

Best regards and many thanks in advance.

[Jocelyn RICARD · Accepted solution]

Hello @bear2023R ,

thank you for this detailed explanation.

First, there is no absolute need to create a TrustZone project in CubeMX in your context. Reason is that you will not reuse the secure part as it will be the TFM.

So, this limitation related to TouchGFX shouldn't impact you.

You can develop your secure application independently as long as you don't need to use the services provided by TFM.

Then, you will need to do this integration with TFM environment.

I did this quite long time ago on STM32CubeIDE. I'm not sure everything is still necessary. I give you these inputs as a kind of guide lines but may not be fully accurate

From my notes here are the important points:

1) Create CubeMX project without enabling TrustZone

2) System clock configuration : if you want to set your clocking configuration in non secure you will probably need to switch first to MSI and then use standard SystemClock_Config.

3) If you use ICache, you will need to first disable it because it is enabled by TFM.

4) system_stm32u5xx.c modifications: Remove the code after FPU activation that is clocking part. VTOR setting.  The VTOR value will be set in another location

5) Linker related changes. Use provided configuration of non secure example: linker file, prebuild and postbuild and adapt the paths to the path of your application. Here this is quite dependent on IAR so may require some adaptations. You need to understand that linker file is parsed in prebuild to generate a .icf.i that you need to use as actual linker file

6) Vector table. CubeMX generates a startup_stm32u5*.s containing the vector table and reset handler. In TFM context you use startup_stm32u5xx.c copied from example. I'm not 100% sure this is mandatory to use .c file instead of .s but it is how it is done in the example. Also, easier to modify :)

7) When using ThreadX you need to edit tx_initialize_low_level.S file to change the vector table name. In my notes I had to replace  g_pfnVectors by __Vectors but may be not the good name now.

Also, when regenerating CubeMX this will be overwritten. The solution I found was to add a script launched as prebuild that performs this variable replacement.

In any case using TFM is very complex if you want to debug in secure part. For this I can just provide possible tips if you have issues. Normally, when using PSA api the best is to start from an example and adapt it.

I hope this will help

Best regards

Jocelyn

[bear2023R]

HI Jocelyn and thanks for your suggestions: we'll definitely try them!

However, from what we see: it might be easier indeed to use SBSFU with something like Mbed Crypto (for any additional secure services) than deal with TFM as it is implemented...

For instance, in case we'd like to extend some secure functionality by moving some MCU peripheral(s) into secure domain and manipulating there with it - it is not that trivial (if possible at all), having the secure part under full control of TFM, isn't it? The plans like these were a major reason to have TZ-enabled project at first stage, even though, as you correctly noticed, it is not strictly required to deal with TouchGFX. In fact, not required at all :)))

And last poi9nt: even though there are obviously workarounds for CubeMX is not being able to generate correct ThreadX code for TouchGFX when TZ enabled - it is still a confirmed bug in CubeMX. A very simple bug, as it works corretly with TZ disabled - so all the code-generation fucntionality is there, and secure poject is not affected by that part at all. So the matter is really in enabling TthreadX in drop down list in CubeMX and calling a correct EXISTING functionality. It is big surprise, not to say "disappointment", it was not fixed until now for so many CubeMX releases.

Thanks again and best regards!

[Jocelyn RICARD]

Hello @bear2023R ,

TFM allows the implementation of user defined partitions to add features on secure side. This is totally feasible, but requires a good experience in programming and is time consuming. Also, you have be comfortable with debugging in secure/non secure environment. 

If you go SBSFU only and you want to implement cryptographic operation, you will probably need to implement a kind of key storage on secure side, the equivalent of TFM's ITS. Also, if you go SBSFU route, you will need to manage secure + non secure project, where there is still this TouchGFX limitation.

Regarding this last point, I understand your frustration. Moreover, I had a look in internal database and couldn't find the related ticket... I will double check that tomorrow. As a general advise, if you want something fixed and at least have a follow-up please use online support. 

Best regards

Jocelyn

[bear2023R]

Thanks Jocelyn

very nice explanation presented in a nice way, too. And thanks for looking after that CumebMX/TOuchGFX issue, and for suggestions on online support use, - I thought that ST's confirmation of "confirming bug and passing information to ... " in here would be sufficient. Sorry.

Back to SBSFU: indeed, even though we do have programming experience and we are OK with secure/nonsecure debugging, - using SBSFU in pair with any Crypto lib looks like a faster and cleaner path right at the moment, as our programming experience in particular crypto area is not as great as, obviously, TFM handling requires :)

With U5, though, I guess we have also such a great HW feature as SAES, which may help implementing quite secure way of storing/deriving keys, isn't it? From U5 manual, as well as your own explanation here , and ST training here , and from few other sources - it seems like it may be a good help in key handling for any added to SBSFU secure services.
Unless we are completely off the ground with our "understanding" and the main use case for SAES has nothing to do with what we are thinking about, as its exclusively targeting a firmware protection in OEM :)

Best regards and many thanks again!

[Jocelyn RICARD]

Hello @bear2023R ,

Regarding TouchGFX I could finally find the internal ticket. There was actually a misunderstanding between ThreadX with TrustZone enabled and ThreadX in secure side and was rejected. I pushed it back providing details. I'm waiting for confirmation about it.

Regarding TFM usage, this is not that complex if you stay at PSA API level. You have many examples available. 

What is complex is the TFM integration, the possible requirement to update mbedCrypto, the addition of a partition on secure side, the change in memory mapping.

So, when you develop your own secure application you have control on everything.

About the secure storage, yes SAES with usage of DHUK for key wrapping is the definitive way to go.

It provides very high level of protection of the encrypted data.

Best regards

Jocelyn

[bear2023R]

Thanks Jocelyn so much.

Indeed, we tried your suggestions and it looks now not as scary as before - the TFM integration. Pretty straight forward, the  matter is in replacing few files. Thanks a lot!.

And thank you very much for looking after that TouchGFX stuff, - not like a real  showstopper but it would be very-very useful if it would be finally fixed!

If we need any additional tips on TFM integration - I hope we can ask you for some extra help, if you don't mind  :)

Thanks!

[Jocelyn RICARD]

Hi @bear2023R ,

thank you for your feedback.

OK let's do like this

Best regards

Jocelyn