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.

[gdl]

Hey
thanks for your reply

Regarding RelWithDebInfo:
I commented-out "CONFIG_DEBUG=y" and instead tried adding one of the following lines (each tested separately) to my prj.conf:
CONFIG_relwithdebinfo =y
relwithdebinfo =y
CONFIG_RelWithDebInfo =y
CONFIG_REL_WITH_DEB_INFO =y

The full prj.conf then reads:

#
# Copyright (c) 2021 Nordic Semiconductor ASA
#
# SPDX-License-Identifier: Apache-2.0
#

CONFIG_BUILD_WITH_TFM=y
CONFIG_TFM_PROFILE_TYPE_NOT_SET=y
CONFIG_TFM_CONNECTION_BASED_SERVICE_API=y
CONFIG_TFM_PARTITION_CRYPTO=n
#CONFIG_DEBUG=Y
CONFIG_relwithdebinfo=y

CONFIG_TFM_SECURE_UART=y
CONFIG_TFM_SECURE_UART1=y

However they each led to the same undefined symbol error, so i couldn't build the program (while setting CONFIG_DEBUG=y works):

/home/usern/vscodeprojects/tfm_secure_partition_modified/prj.conf:12: warning: attempt to assign the value 'y' to the undefined symbol relwithdebinfo

error: Aborting due to Kconfig warnings

/home/usern/vscodeprojects/tfm_secure_partition_modified/prj.conf:12: warning: attempt to assign the value 'y' to the undefined symbol relwithdebinfo

error: Aborting due to Kconfig warnings

/home/usern/vscodeprojects/tfm_secure_partition_modified/prj.conf:12: warning: attempt to assign the value 'y' to the undefined symbol RelWithDebInfo

error: Aborting due to Kconfig warnings

/home/usern/vscodeprojects/tfm_secure_partition_modified/prj.conf:12: warning: attempt to assign the value 'y' to the undefined symbol REL_WITH_DEB_INFO

error: Aborting due to Kconfig warnings

        $<$<OR:$<CONFIG:Debug>,$<CONFIG:relwithdebinfo>>:ENABLE_HEAP>

How/With which command do i activate RelWithDebInfo?
Do i need to pass it differently?

Regarding the heap:

Sigurd Hellesvik said:

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.

Ok thanks a lot.
Is there still a limit on the heap size?

And how do i increase the sram-size? Just by setting a higher number in this line in the same file you linked or is something more needed?

#define SPU_SRAM_REGION_SIZE    (0x00002000)

There is also no direct "equivalent" folder for my device (nrf9161), inside the directory
(/home/usern/ncs/modules/tee/tf-m/trusted-firmware-m/platform/ext/target/nordic_nrf/common/) only the following folders exist:
-core
-nrf91
-nrf5340
-nrf9120
-nrf9160

Should i just edit the region_defs file within core and snrf91(/home/usern/ncs/modules/tee/tf-m/trusted-firmware-m/platform/ext/target/nordic_nrf/common/nrf91/partition/region_defs.h)?

[Sigurd Hellesvik]

gdl said:

How/With which command do i activate RelWithDebInfo?
Do i need to pass it differently?

I have not used this before, but.
When I look it up, it looks like it is passed with cmake and not Kconfig.
For example https://github.com/Z3Prover/z3/issues/990:
"cmake -G Ninja -DCMAKE_BUILD_TYPE=RelWithDebInfo .."

gdl said:

And how do i increase the sram-size? Just by setting a higher number in this line in the same file you linked or is something more needed?

Yep, I think so.
The default sram partitioning looks like this, so I guess you will have enough here that you dont need to increase that.

  sram_primary (0x40000 - 256kB): 
+--------------------------------------------------+
+---0x20000000: mcuboot_sram (0x8000 - 32kB)-------+
+---0x20000000: sram_secure (0x8000 - 32kB)--------+
| 0x20000000: tfm_sram (0x8000 - 32kB)             |
+---0x20008000: sram_nonsecure (0x38000 - 224kB)---+
+---0x20008000: nrf_modem_lib_sram (0x4568 - 17kB)-+
| 0x20008000: nrf_modem_lib_ctrl (0x4e8 - 1kB)     |
| 0x200084e8: nrf_modem_lib_tx (0x2080 - 8kB)      |
| 0x2000a568: nrf_modem_lib_rx (0x2000 - 8kB)      |
+--------------------------------------------------+
| 0x2000c568: sram_primary (0x33a98 - 206kB)       |
+--------------------------------------------------+

gdl said:

There is also no direct "equivalent" folder for my device (nrf9161), inside the directory
(/home/usern/ncs/modules/tee/tf-m/trusted-firmware-m/platform/ext/target/nordic_nrf/common/) only the following folders exist:
-core
-nrf91
-nrf5340
-nrf9120
-nrf9160

Good point.
Can i suggest that you temporarily put #warning "AAAAAAAAAAA" inside each of the SRAM defines in those files to see which one is being used with the 9161?

[gdl]

Sigurd Hellesvik said:

Yep, I think so.
The default sram partitioning looks like this, so I guess you will have enough here that you dont need to increase that.

Great Many thanks.

Sigurd Hellesvik said:

I have not used this before, but.
When I look it up, it looks like it is passed with cmake and not Kconfig.
For example https://github.com/Z3Prover/z3/issues/990:
"cmake -G Ninja -DCMAKE_BUILD_TYPE=RelWithDebInfo .."

I will look into it further. I seem to get an error when using it with the default size-optimized building, but the speed-optimized one probably works.

Sigurd Hellesvik said:

Can i suggest that you temporarily put #warning "AAAAAAAAAAA" inside each of the SRAM defines in those files to see which one is being used with the 9161?

It doesn't seem to use one of the two partition_defs.h inside the common-directory as nothing seems to be displayed when pressing build

/home/usern/ncs/modules/tee/tf-m/trusted-firmware-m/platform/ext/target/nordic_nrf/common/nrf91/partition/region_defs.h

/home/usern/ncs/modules/tee/tf-m/trusted-firmware-m/platform/ext/target/nordic_nrf/common/nrf5340/partition/region_defs.h

It does print out the #warning "AAAAAAAAAAA" when changing the following file, so maybe thats the right

one /home/usern/ncs/nrf/modules/trusted-firmware-m/tfm_boards/partition/region_defs.h