Hi,
Looking at the big picture, the secure side is owning the memory map, so it seems to be inevitable to communicate this information to the non-secure world. There are many ways to do this, ranging from capturing the info in documentation to providing configuration to high-level memory layout definition tools. The build system could support multiple options, but the first implementation shall focus on portability. Having a set of header files, which (as the tf-m build system already shows) make the needed information available for both the C program, the linker and the build system, seems to be a good fit to me. It might not be the most user friendly, but is highly accessible.
What those header files actually do contain is a different question. Sor security reasons it may be a good idea to remove all information not needed by the NS world. Luckily CMake has the needed features to solve this issue.
And when we are at the topic, we need to provide a solution for defining available peripherals to as the secure vs non-secure peripheral availability is also controlled by the secure-side.
There seems to be room for a tool independent of tf-m to help standardizing the format this information can be captured in, to help portability of this information and to enhance user-experience. Unfortunately CMSIS-Zone (as per this page https://arm-software.github.io/CMSIS_5/Zone/html/zTInstall.html ) is an IDE extension and thus it is hardly applicable in a command-line focused build environment. /George
From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Robert Rostohar via TF-M Sent: 03 February 2020 08:15 To: TF-M@lists.trustedfirmware.org Subject: Re: [TF-M] Exporting flash_layout.h and region_defs.h
Hi,
I don’t believe this is the right approach.
TF-M currently includes a non-secure side application (integration test) which is built together with the secure side. This is also reflected in “flash_layout.h” and “region_defs.h” which mixes defines for the secure and non-secure side.
While this might be convenient within TF-M current build setup for the platforms that are supported, it causes issues in real applications and when trying to make this scalable across a large number of platforms. We have seen those issues already while working on providing TF-M as a CMSIS-Pack.
There should be a clean separation of files between the secure and non-secure side.
The mentioned header files should not be imposed to the non-secure side.
Typically non-secure software will have a device specific linker script which will only need to know limited information from the memory layout (non-secure code and data location). Also the secure side might be prebuilt and the non-secure side developed and built separately.
One possible solution is to use a CMSIS-Zone to partition the memory layout on a global level and then splitting it to sub-systems for secure and non-secure and exporting only relevant information for each side. This approach will be used also with TF-M CMSIS-Pack which should be available soon.
Best regards, Robert
From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Devaraj Ranganna via TF-M Sent: Friday 31 January 2020 17:09 To: TF-M@lists.trustedfirmware.orgmailto:TF-M@lists.trustedfirmware.org Subject: [TF-M] Exporting flash_layout.h and region_defs.h
Hi,
The headers `flash_layout.h` and `region_defs.h` as the name suggests defines layout of flash and how different regions are organised in flash and ram respectively. These headers define the location of Bootloader if any, secure and non-secure firmware in flash and these defines are used in the linker scripts. As far as I can tell, these headers will be used by NS RTOS without any modifications, I can confirm that, this is the case in Mbed OS.
Since these headers are usually imported into NS RTOS without any modifications, I propose that we export these headers as part of the build.
Thanks, Dev IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi Gyorgy,
Yes, the memory map needs to be communicated to non-secure world and the existing headers are not the best way.
CMSIS-Zone is one possible tool that could help here and make it user friendly. It provides memory partitioning and also assignment of peripherals to secure or non-secure world.
It is a standalone utility that can be used also from command-line.
Best regards, Robert
From: Gyorgy Szing Gyorgy.Szing@arm.com Sent: Monday 3 February 2020 09:05 To: Robert Rostohar Robert.Rostohar@arm.com; tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: RE: Exporting flash_layout.h and region_defs.h
Hi,
Looking at the big picture, the secure side is owning the memory map, so it seems to be inevitable to communicate this information to the non-secure world. There are many ways to do this, ranging from capturing the info in documentation to providing configuration to high-level memory layout definition tools. The build system could support multiple options, but the first implementation shall focus on portability. Having a set of header files, which (as the tf-m build system already shows) make the needed information available for both the C program, the linker and the build system, seems to be a good fit to me. It might not be the most user friendly, but is highly accessible.
What those header files actually do contain is a different question. Sor security reasons it may be a good idea to remove all information not needed by the NS world. Luckily CMake has the needed features to solve this issue.
And when we are at the topic, we need to provide a solution for defining available peripherals to as the secure vs non-secure peripheral availability is also controlled by the secure-side.
There seems to be room for a tool independent of tf-m to help standardizing the format this information can be captured in, to help portability of this information and to enhance user-experience. Unfortunately CMSIS-Zone (as per this page https://arm-software.github.io/CMSIS_5/Zone/html/zTInstall.html ) is an IDE extension and thus it is hardly applicable in a command-line focused build environment. /George
From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Robert Rostohar via TF-M Sent: 03 February 2020 08:15 To: TF-M@lists.trustedfirmware.orgmailto:TF-M@lists.trustedfirmware.org Subject: Re: [TF-M] Exporting flash_layout.h and region_defs.h
Hi,
I don’t believe this is the right approach.
TF-M currently includes a non-secure side application (integration test) which is built together with the secure side. This is also reflected in “flash_layout.h” and “region_defs.h” which mixes defines for the secure and non-secure side.
While this might be convenient within TF-M current build setup for the platforms that are supported, it causes issues in real applications and when trying to make this scalable across a large number of platforms. We have seen those issues already while working on providing TF-M as a CMSIS-Pack.
There should be a clean separation of files between the secure and non-secure side.
The mentioned header files should not be imposed to the non-secure side.
Typically non-secure software will have a device specific linker script which will only need to know limited information from the memory layout (non-secure code and data location). Also the secure side might be prebuilt and the non-secure side developed and built separately.
One possible solution is to use a CMSIS-Zone to partition the memory layout on a global level and then splitting it to sub-systems for secure and non-secure and exporting only relevant information for each side. This approach will be used also with TF-M CMSIS-Pack which should be available soon.
Best regards, Robert
From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Devaraj Ranganna via TF-M Sent: Friday 31 January 2020 17:09 To: TF-M@lists.trustedfirmware.orgmailto:TF-M@lists.trustedfirmware.org Subject: [TF-M] Exporting flash_layout.h and region_defs.h
Hi,
The headers `flash_layout.h` and `region_defs.h` as the name suggests defines layout of flash and how different regions are organised in flash and ram respectively. These headers define the location of Bootloader if any, secure and non-secure firmware in flash and these defines are used in the linker scripts. As far as I can tell, these headers will be used by NS RTOS without any modifications, I can confirm that, this is the case in Mbed OS.
Since these headers are usually imported into NS RTOS without any modifications, I propose that we export these headers as part of the build.
Thanks, Dev IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi Robert,
“It is a standalone utility that can be used also from command-line. “
The homepage says this is the command to run it “headless”: eclipsec.exe -noSplash -consoleLog –launcher.suppressErrors -application com.arm.cmsis.zone.ui.headlessgen -azone FILENME.azone -ftl FTL_DIR -ftl_gen FTL_GEN_DIR
For me this means you still need Eclipse to be installed on your PC to run it and thus this is still and IDE extension just it has support being run headless.
There might be ways to run it without Eclipse, but this does not seem to be officially supported. This means there is expected to be sparse information on how-to-do this, no, or limited support. There is a risk in using this tool to generate extra work (need to work out what environment it needs, need to document it, need to test it to ensure proper operation, need to support issues with the environment, etc…).
This is not really helping us for now, hopefully this changes in the future.
/George
From: Robert Rostohar Robert.Rostohar@arm.com Sent: 03 February 2020 09:27 To: Gyorgy Szing Gyorgy.Szing@arm.com; tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: RE: Exporting flash_layout.h and region_defs.h
Hi Gyorgy,
Yes, the memory map needs to be communicated to non-secure world and the existing headers are not the best way.
CMSIS-Zone is one possible tool that could help here and make it user friendly. It provides memory partitioning and also assignment of peripherals to secure or non-secure world.
It is a standalone utility that can be used also from command-line.
Best regards, Robert
From: Gyorgy Szing <Gyorgy.Szing@arm.commailto:Gyorgy.Szing@arm.com> Sent: Monday 3 February 2020 09:05 To: Robert Rostohar <Robert.Rostohar@arm.commailto:Robert.Rostohar@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto:nd@arm.com> Subject: RE: Exporting flash_layout.h and region_defs.h
Hi,
Looking at the big picture, the secure side is owning the memory map, so it seems to be inevitable to communicate this information to the non-secure world. There are many ways to do this, ranging from capturing the info in documentation to providing configuration to high-level memory layout definition tools. The build system could support multiple options, but the first implementation shall focus on portability. Having a set of header files, which (as the tf-m build system already shows) make the needed information available for both the C program, the linker and the build system, seems to be a good fit to me. It might not be the most user friendly, but is highly accessible.
What those header files actually do contain is a different question. Sor security reasons it may be a good idea to remove all information not needed by the NS world. Luckily CMake has the needed features to solve this issue.
And when we are at the topic, we need to provide a solution for defining available peripherals to as the secure vs non-secure peripheral availability is also controlled by the secure-side.
There seems to be room for a tool independent of tf-m to help standardizing the format this information can be captured in, to help portability of this information and to enhance user-experience. Unfortunately CMSIS-Zone (as per this page https://arm-software.github.io/CMSIS_5/Zone/html/zTInstall.html ) is an IDE extension and thus it is hardly applicable in a command-line focused build environment. /George
From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Robert Rostohar via TF-M Sent: 03 February 2020 08:15 To: TF-M@lists.trustedfirmware.orgmailto:TF-M@lists.trustedfirmware.org Subject: Re: [TF-M] Exporting flash_layout.h and region_defs.h
Hi,
I don’t believe this is the right approach.
TF-M currently includes a non-secure side application (integration test) which is built together with the secure side. This is also reflected in “flash_layout.h” and “region_defs.h” which mixes defines for the secure and non-secure side.
While this might be convenient within TF-M current build setup for the platforms that are supported, it causes issues in real applications and when trying to make this scalable across a large number of platforms. We have seen those issues already while working on providing TF-M as a CMSIS-Pack.
There should be a clean separation of files between the secure and non-secure side.
The mentioned header files should not be imposed to the non-secure side.
Typically non-secure software will have a device specific linker script which will only need to know limited information from the memory layout (non-secure code and data location). Also the secure side might be prebuilt and the non-secure side developed and built separately.
One possible solution is to use a CMSIS-Zone to partition the memory layout on a global level and then splitting it to sub-systems for secure and non-secure and exporting only relevant information for each side. This approach will be used also with TF-M CMSIS-Pack which should be available soon.
Best regards, Robert
From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Devaraj Ranganna via TF-M Sent: Friday 31 January 2020 17:09 To: TF-M@lists.trustedfirmware.orgmailto:TF-M@lists.trustedfirmware.org Subject: [TF-M] Exporting flash_layout.h and region_defs.h
Hi,
The headers `flash_layout.h` and `region_defs.h` as the name suggests defines layout of flash and how different regions are organised in flash and ram respectively. These headers define the location of Bootloader if any, secure and non-secure firmware in flash and these defines are used in the linker scripts. As far as I can tell, these headers will be used by NS RTOS without any modifications, I can confirm that, this is the case in Mbed OS.
Since these headers are usually imported into NS RTOS without any modifications, I propose that we export these headers as part of the build.
Thanks, Dev IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
tf-m@lists.trustedfirmware.org
-
Gyorgy Szing -
Robert Rostohar