Can you use the heap in custom secure partitions in TFM?

[gdl]

11 months ago in an answer a nordic member wrote (in regards to an error that I now also had and could solve using CONFIG_DEBUG=y):

Øivind said:

I looked a bit more into it, and in order to use malloc heap must be enabled, and it is by default disabled in TF-M. In TF-M the heap is hardcoded to a small size of 0x200 and is only meant for debug builds.

CONFIG_DEBUG=y enables the heap and will likely remove the error, but I suggest managing the memory in some other way instead.

Is this still current?

Especially is the heap still limited to 0x200/512bytes?
Like in the manifest-file we can set the "heap_size" attribute similar to the "stack_size" attribute, but values above 512byte aren't realized?
If it has changed in the meantime, is there a current heap-size-limit and if yes what is it?
(I use SDK 2.6.1 with the nRF9161. The project extensively uses the heap/malloc therefore the question.)

Regards

[Sigurd Hellesvik]

Hi,

Im will ask

Regards,
Sigurd Hellesvik

[gdl]

OK thanks

[Sigurd Hellesvik]

The answer is that this is still a bit complicated.
I can explain to you what you would have to do to use the heap.

Could you explain a bit what you need the heap for in TF-M, so I can better guide you?

Alternatively: Maybe it is easier to avoid using the heap in TF-M and solve your issue in another way instead. Worth thinking about.

[gdl]

It's a C programm running in its own secure partition that stores some data permanently on the heap (corresponding roughly to what objects and their members are in object-oriented langs) and also uses the heap to generate data and return it to the caller. The external user in the non-secure world can call roughly a dozen functions the programm offers to the outside through an interface. The individual data can be relatively large, e.g. several hundred bytes or in more rare cases >1000 bytes. The entire heap is ofc larger than that.

Would setting the "heap_size"-attribute in the manifest change the heap-size itself?

(Rewriting the application itself (instead of the secure partition configuration) would be complicated as it's already finished and to be used in various different tasks (not just on a microcontroller), however would be interested in it anyway if that's the suggested solution.)

Edit: And currently the programm only compiles with "CONFIG_DEBUG=y" in the prj.conf (as described in starting post). Does setting "CONFIG_DEBUG=y" impact performance or cause security issues?

[Sigurd Hellesvik]

So far this is what I got:

Here is how the HEAP is enabled:

https://github.com/nrfconnect/sdk-trusted-firmware-m/blob/0fa3c2a105a9c737643594bed2fef6dca11049f7/platform/CMakeLists.txt#L352

So you must use either DEBUG or relwithdebinfo (release build with dwarf debug info enabled) to get the C heap.

gdl said:

And currently the programm only compiles with "CONFIG_DEBUG=y" in the prj.conf (as described in starting post). Does setting "CONFIG_DEBUG=y" impact performance or cause security issues?

We do not have full insight into CONFIG_DEBUG, or how it will change in the future, so unfortunally I am unable to promise anything in regards to this question now.

Since debug configuration is not generally intended for releases, it could have some impacts, unfortunately.
The one thing I know for sure will be impacted is that the program will take more space.

I suggest that you try RelWithDebInfo and see if that works, as it seems to be a middle ground between release and debug builds.

For heap size, you should be able to increase it here, or equivalent for different boards.
Just make sure to size up the partitioning of sram as well when doing that.