SPRADK2 November   2024 F29H850TU , F29H859TU-Q1

 

  1.   1
  2.   Abstract
  3.   Trademarks
  4. 1Introduction
  5. 2Supplemental Online Information
  6. 3SSU Overview
  7. 4Key Concept Definitions
  8. 5Safety and Security Goals
  9. 6System Design
  10. 7Configuring the SSU
    1. 7.1 Flash SECCFG Region
    2. 7.2 SSU Development Life Cycle
    3. 7.3 Using the SysConfig Tool
      1. 7.3.1 Enabling System Security Configuration
      2. 7.3.2 Configuring Application Modules
      3. 7.3.3 Configuring Special Modules
        1. 7.3.3.1 LINK2 Configuration
        2. 7.3.3.2 LINK1 Configuration
        3. 7.3.3.3 Adding Shared Memory
      4. 7.3.4 Defining Sandboxes
  11. 8Summary
  12. 9References

6 System Design

The first step in configuring the SSU for an application is to determine the required system partitioning. The SSU provides three levels of hierarchy for partitioning the application subsystem:

  1. ZONEs: Each ZONE determines debug access for all C29 CPUs on the chip. ZONEs are designed to enable multiple code owners or entities to develop and maintain different partitions of an application residing on the same chip. For instance, if a certain aspect of the embedded application is owned and maintained by a third-party vendor, then the system can be divided into two ZONEs:
    1. ZONE1: Primary user ZONE, owned by the primary system developer;
    2. ZONE2: Secondary user ZONE, owned by the third-party developer.

    This partitioning enables the third-party developer to develop, debug and maintain an application function on the same chip without requiring access to the primary user’s code and data assets. Furthermore, each user ZONE provides two levels of debug authorization:

    1. Partial debug – CPU debug commands such as halt, step, and breakpoints allowed, but no memory access
    2. Full debug – Access to memory locations is provided as permitted for all LINKs contained within the ZONE.

    As an example, a secondary user such as a third-party developer can debug an application module in ZONE2, and also be given partial debug access to ZONE1, so that the secondary user can effectively debug the application in context without having access to the primary user’s assets.

    Each device has 3 user ZONEs available: ZONE1, ZONE2, and ZONE3. ZONE1 is the primary user ZONE; ZONE2 and ZONE3 are secondary user ZONEs.

  2. Sandboxes (STACKs): Sandboxes provide security and safety isolation within a CPU. Each Sandbox is associated with a STACK in the SSU. Each sandbox has a dedicated physical stack pointer in the CPU that is inaccessible by other sandboxes, and a dedicated stack memory AP region with read/write permissions restricted to only code belonging to that sandbox. Special C29 CPU gate instructions are required when crossing from one STACK to another. These instructions must be inserted by the compiler at the entry and exit of each function, and at function calls or branches. These mechanisms provide security protection against malware attacks that attempt to redirect code execution or manipulate the stack.
    • A Sandbox consists of an SSU STACK and everything associated with the STACK, including the stack memory AP region. Each STACK belongs to one ZONE, but a ZONE can contain multiple STACKs. For each CPU, there are three predefined STACKs:
    • STACK0: This STACK is reserved for TI internal use and cannot be configured by the user.
    • STACK1: This STACK is primarily used for bootloaders, but can optionally be associated with other user application code. STACK1 is always associated with ZONE1, and contains only one LINK (LINK1).
    • STACK2: This is the primary user STACK. STACK2 is always associated with ZONE1. STACK2 always contains LINK2, but can also contain other LINKs.
  3. Application Modules (LINKs): An application module is a basic partition of a system application. Each module consists of a single SSU LINK, one or more code memory AP regions containing the code of the LINKs, all data memory AP regions associated with the LINK, and all peripherals and interrupts associated with the Module. Typically, the code AP regions contain .text and other linker output sections containing code, and the data AP regions contain .bss, .const, and other linker output sections containing data and variables.
    • Each LINK enables SSU memory protections, providing safety protection from other LINKs in the CPU. Every AP region defines access permissions for each LINK. These permissions are enforced in real time for every instruction that performs a memory access, depending on the LINK ID instruction. Functions that require safety isolation from each other can be placed in separate Modules. If security isolation is required, then these Modules are placed in separate sandboxes; if not, the Modules can be placed in the same sandbox.
    • For each CPU, there are three predefined LINKs
      1. LINK0: This LINK is reserved for TI internal use and cannot be configured by the user.
      2. LINK1: This LINK is primarily used for bootloaders, but can optionally be associated with other user application code. CPU1.LINK1 has some special fixed permissions that enable access to certain system configuration registers, in addition to AP-defined protections.
      3. LINK2: This is the primary user LINK. CPU1.LINK2 is the system security root LINK (SROOT), and has special fixed permissions that enable access to system configuration registers and override controls. This LINK typically executes privileged host functions at the RTOS level.
Example of Software Partitioning With SSU Figure 6-1 Example of Software Partitioning With SSU

Figure 6-1 shows an example of SSU system partitioning on a single-CPU, single-ZONE system. In this system, the RTOS runs in STACK2.LINK2, and is responsible for initializing system configuration, setting up peripherals and interrupts, and starting the main execution loop. There are two control functions, Control Loop1 and Control Loop 2. Each of these control functions is placed in a separate Application Module (LINK), and both Application Modules are placed in the same Sandbox. In this system, safety isolation is required between the two control functions, but security isolation is not required between the two. A fourth Module hosts communications code, such as UART or CAN-FD code. Because data coming from an external interface can potentially pose a security threat to other functions in the system, this Module is placed in a separate Sandbox. Finally, a fifth Module contains common code functions which are shared between all the other Modules in the system. The LINK associated with this module is defined as the Access Protection Inheritance LINK (APILINK) for other LINKs. The Common Code Module is also placed in a separate sandbox to maintain security isolation from the rest of the system (while maintaining inherited permissions).

SysConfig includes full support for multicore applications. The built-in memory allocator tool automatically manages memory regions associated with application modules across multiple CPUs, and also manages the allocation of peripherals across the entire device. The SysConfig tool also includes a Shared Memory feature that enables the definition of memory regions that can be shared between modules on the same CPU or multiple CPUs.