F29H850TU: How to use SECURE_GROUP on output sections ?

Part Number: F29H850TU

Hello,

When the System Security is added in SysCfg, the linker script is generated by the tool and SECURE_GROUP is used in MEMORY.

This does not fulfill our needs because we don't want to fix the size of all the areas associated with the SECURE_GROUPs.

Instead, we use MEMORY only to specify the memory areas dedicated to the application and then we use the output sections to create the different areas (ex: CODE_QM, CODE_ASIL_C, CODE_SHARED). This way, we don't need to specify a size for each, their size will be adapted automatically based on the evolution of the software.

Then, using labels before and after each output section (or each group of output sections eventually), we are able to configure the ranges once and for all (as long as the list of output sections is not modified).

In the documentation of the clang for the F29, it is indicated that SECURE_GROUP can be used on output sections but now how and I found in the online documentation that the support of SECURE_GROUP on output sections is deprecated and could be removed in the future which would be problematic for us.

image.png

So

1/ Will this support be removed in the future ? If yes, why ? And is there a possibility to avoid this ?

2/ How can we use SECURE_GROUP with the output sections ? Is there a way to see what the linker understood (I searched for the name of the SECURE_GROUPs in the map file but did not find anything) ?

Thank you

  • Hi Ronan,

    Security being applied at the output section level was deprecated because it did not fit the level of abstraction on which security acts.

    Output sections represent software. Data and code which comprise the application.

    Memory regions represent hardware. Distinct pieces of real device memory into which output sections are placed before being loaded and executed on the device.

    Security subsystems are hardware features. Syscfg splits physical memory regions available on the device and assigns each to a secure region of code/memory. Because of this, we identified that output sections were not the correct abstraction, and moved the specification up to the memory regions.

    There are currently no plans to remove output section specification, but this deprecation warning exists to cover the possibility of future features which may not apply to the output section specification.

  • Hello James,

    Thank you for your answer.

    In fact, the goal of security (and FFI in safety) is to handle the access rights to resources which can be peripherals or memory areas.

    It has nothing to do with a physical memory. For example, we could allow a process to access to a part of LDA2 (for example) and another process to the other part of LDA2. Security (and FFI for safety) will still be guaranteed even though we split the physical memory in 2 parts.

    Also having dynamic frontiers (from one build to another) for the different areas with different access rights does not compromise the security or the FFI for the safety.

    What we do for the memory is that we create partitions, each partition having a specific set of rights and the size and location of these partitions is automatically adapted to their content thanks to their definition at the output sections level. Then, the memory protection is also automatically adapted to these partitions thanks to labels added in the linker script, providing the start and end of all the partitions and then used to configure the ranges.

    With this solution, security and FFI for safety are covered with the flexibility to automatically adapt the ranges to the content of the different partitions.

    And for that, we need the SECURE_GROUP at the output section level, and we need this to still exist in the future versions of the compiler.

  • Hello  ,

    Could you please give some feedback to the customer? They want to keep their current approach of the security, and seeing that the support of SECURE_GROUP on output sections is deprecated and could be removed in the future is a real concern for them.


    Best regards,
    François.