Trusted Firmware-m Isolation Level 2

Updated 1,266 Days AgoPublic

Actions

Trusted Firmware-M Isolation level 2

This document analyzes the requirements of isolation level 2 in IPC mode and describes the design proposal.

Terms and abbreviations

This document uses the following terms and abbreviations.

Introduction

PSA Firmware Framework defines three levels of isolation. The following table provides a summary of the three supported isolation levels:

The IPC model is implemented to follow PSA Firmware Framework v1.0. The interaction between clients and services happens via the IPC
mechanism. The IPC model supports isolation level 1. To get align with PSA Firmware Framework, the other two isolation levels need to be supported. This document describes the design of isolation level 2.

Requirements

The requirements of isolation level 2 in PSA Firmware Framework specification is:

• The SPM must ensure that no runtime state, data or devices that are part of the PSA Root of Trust can be read or written by firmware or hardware in the Application Root of Trust.
• The SPM can allow the firmware and hardware in the PSA RoT Services to read/write runtime state, data or hardware in other Secure Partitions. However, enforcing isolation is recommended because it mitigates the risk of defects in secure firmware that could disclose secrets or accept untrusted inputs.

Design Details

This chapter describes the design details of isolation level 2. Includes background, proposal and implementation.

Background

The existing TF-M implementation with isolation is:

• IPC mode is implemented with isolation level 1.
• Library mode is implemented with isolation level 1 and a prototype isolation level 3.

Isolation level 1

IPC mode isolation level 1 uses the same isolation settings of library mode. There are no MPU region activated in isolation level 1, default memory map is applied in this case. The following table describes the memory layout of isolation level 1 TF-M:

Isolation level 3

Isolation level 3 is a prototype and showcases the isolation between
partitions. There are 8 MPU regions are enabled for the following purposes:

The region 0,1,2 and 3 are enabled while booting with a fixed setting. The accessible memory regions of running partition are set into region 4,5,6 and 7 while running partition to be switched into. The following table describes the secure firmware memory layout in isolation level 3 and related to MPU regions:

Sections not listed in the table (privileged code and data like SPM and Core) follow default memory map setting. The default memory map is set as privileged accessing as default. Library mode uses direct call between caller and callee, so there are areas for the partition shared code and data (Region1,2,3 and 7). These areas are unnecessary for IPC mode because IPC mode applies SVCalls instead of putting shared code and
data in region 1,2,3 and 7.

Configuration switches and scheduler

One configuration switch for isolation is available with two values: 'TFM_LVL=1' and 'TFM_LVL=3'. 'TFM_LVL=1' works under IPC mode and
library mode. While 'TFM_LVL=3' works for library mode only.

The IPC scheduler works in isolation level 1. The scheduler does not update partition related status since Secure Partitions in isolation level 1 could access all TF-M memory, no extra setting needs to be changed during the running partition switching.

Proposal

Linker script sections re-arrangement

As isolation level 2 requires, the App RoT partitions and PSA RoT partitions have different accessing levels. The PSA RoT partitions are put under a privileged level, which is the same privileged level as SPM. MPU is necessary in this case since the default memory map put all memory in the same privileged level. MPU has a limited number of regions, App RoT partition data need to be put together to avoid different memory sections get interleaved. Interleaving costs more regions to be enabled, which is a waste of MPU regions. There are suggestions of isolating RO data and RW data in the PSA Firmware Framework specification, these two parts of App RoT partitions can be put in two different locations.
Summarized points of isolation level 2 are:

• The RO data of all App RoT partitions need to be put together.
• The RW data of all App RoT partitions need to be put together.

RW data area here contains read-write data and zero-initialized data. The stack for each partition is covered in RW data area.

The following table describes the changed section arrangement of isolation level 2:

PSA Firmware Framework APIs are implemented as SVCalls in IPC mode. All the service providing APIs are packaged into calling of PSA Firmware Framework APIs. Besides PSA FF APIs, there are shared code and its related read-only data for Secure Partition calling, for example, thread exiting interface. A dedicated MPU region needs to be prepared for these codes. The requirement for this region are:

• This code must be thread-safe and reentrant.
• This code must be read-only.

The updated MPU regions with status are listed in the following table:

After the combination of the two updated tables, the following tables describe the arrangement for isolation level 2:

And updated MPU regions:

NOTE:

• In the first implementation, one MPU region for peripheral is supported as default. Typically there should be more MPU regions are available for peripheral usage if a Secure Partition needs more un-continuous peripheral registers. The un-continuous peripheral number larger than available free region number needs an advanced implementation which needs further design.

Configuration switch and scheduler

A new value of TFM_LVL is going to be added for isolation level 2. And the scheduler needs to set related settings based on Secure Partition information.

Implementation

This chapter describes the implementation of the proposed points.

Section relocation

The linker script for GNUARM and the scatter file for ARMCLANG need to be changed to put AppRoT partition components together. Since PSA RoT partitions have the same privileged level with SPM, PSA RoT partitions could be placed freely.

GNUARM

The linker script for GNUARM is put at:

TFM_ROOT/platform/ext/target/<platform_name>/gcc/<platform_name>.ld

This linker script is generated from a template, and the template is put
at:

TFM_ROOT/platform/ext/target/<platform_name>/gcc/<platform_name>.ld.template

The related sections in GNUARM are:

PSA Firmware Framework specification also suggests isolating Read-only part with other parts of a Secure Partition if possible. The section
'.text' plus '.rodata' are regarded as 'Read-only' part in GNUARM case.

ARMCLANG

For ARMCLANG, the scatter file is put at:

TFM_ROOT/platform/ext/target/<platform_name>/armclang/<platform_name>.sct

TF-M does not use a template for ARMCLANG scatter file.

The related sections in ARMCLANG are:

The RO part is regarded as 'Read-only' in PSA Firmware Framework specification. The RO sections of App RoT partitions are put together. RW sections of App RoT partitions are put together, too. No requirements tell that these two groups (RO and RW) can be neighboured.

Conclusion

Summarized items list below:

• Change template for GNUARM to support grouping App RoT partitions in the linker script.

• Change scatter file for ARMCLANG to support grouping App RoT partitions.

• Template tool support for ARMCLANG (optional).

MPU configuration

The MPU needs to be default initialized for isolation level 2. To re-use the design of isolation level 3, set the region 4,5 and 6 with the App
Rot partitions group information.

The memory type needs to be set correctly to provide better memory performance.

Summarized items:

• Apply MPU configuration.

• Correct set memory type in MPU configuration.

Configuration switches

There is a configuration switch for isolation: 'TFM_LVL=1' and 'TFM_LVL=3'. A new configuration switch needs to be added for isolation level 2: 'TFM_LVL=2'. The dependency checking rules need to be available to permit isolation level 2 in IPC mode only.

Scheduler

Partition status

The scheduler in isolation level 1 is put freely because scheduler does not need to change Secure Partition information. This behavior is not
aligned with PSA Firmware Framework. The scheduler should get Secure Partition type by calling Secure Partition Manager APIs and do necessary environment setup before switches into the running partition.

Secure Partition has three types of status (From Firmware Framework specification):

• Running
• Blocked
• Ready

While scheduler supports 4 exiting status:

• Creating
• Running
• Blocked
• Detach

There must be an alignment between these statuses. The status value is not defined as a detailed code in PSA Firmware Framework, SPM could take the values defined in thread sources directly:

The existing scheduler design is straight, which does not distinguish
the run-able and running status.

Partition priority

The priority set in Secure Partition manifest are:

• HIGH
• NORMAL
• LOW

The scheduler set the priority of a thread as an integer value within
the range 0 ~ 255. The relationship between Secure Partition priority
and thread priority could be hard mapped:

Scheduling policy

In isolation level 2, the privileged bit needs to be set correctly for
partition. The steps need to be done for scheduler are:

1. Get next partition to be run
2. Check if next partition is PSA RoT partition
3. Clear/Set CONTROL.nPRIV if the next partition is privileged/non-privileged
4. Call scheduler API to switch partitions

Regions clean-up

Below MPU regions are not used for IPC mode:

There are some existing un-privileged code been included in IPC mode but never get called at current, change the makefile to move these files out of IPC mode:

• tfm_spm_services.o
• dummy_crypto_keys.o
• dummy_nv_counters.o
• dummy_boot_seed.o
• dummy_device_id.o
• platform_retarget_dev.o
• SFN
• armlib

NOTE:

• The clean-up needs to be done step by step in case breaks existing runtime behaviour. In very start implementation, these files may still be seen in project files but not linked since no one references them.

Functions to be re-design

printf

Log functions call 'printf' in toolchain lib to output debug messages. This function needs to access privileged data such as UART driver to output data. Calling this function in the un-privileged App RoT partitions can cause a memory accessing violation.

The printf and Log functions need to be re-design. The printf itself need to be implemented in privileged mode. And an interface for calling this needs to be provided.

There is an implementation in library isolation level 3 already. This implementation needs to be moved into IPC mode.

Tests

This chapter describes the tests to be created to validate the isolation
level 2 implementation.

Test design

Two specified Secure Partitions are created for these test cases. One Secure Partition contains App RoT services, and the other one contains
PSA RoT services. They provided services to show internal memories to the caller, and caller access it. Two types of memory are defined inside of each partition: Read-only (RO) memory and Read-write (RW) memory.

For the memory accessing test inside Secure Partition such as access internal read-only data, it could be done directly with accessing give memory.

For the accessing happen between partitions, one SID is provided for these tests. The following table describes the services partition provided:

The client partition provides memory inside itself to the service partition by requesting dedicated services, and the service partition accesses the provided memory.

The access sequence for both services:

1. Convert start address of memory into "uint8_t *"
2. Increase each byte of provided memory with 1.

Test cases

This chapter describes detail test steps and the expected result.

1. A PSA RoT service can access App RoT secure partition read-write memory

Expected result:
PSA RoT service change memory content to specified value and App RoT service confirms the change.

2. An App RoT service cannot access PSA RoT secure partition memory

2.1 Check by software memory check function

Expected result:
The obtained memory address is not in the accessible memory region for App RoT service. Software memory check fails and gets panic.

Note: This case should be the last test case and disabled as default since it would block other tests.

2.2 Check by MPU

Expected result:
App RoT service tries to change memory content and gets panic.

Note: This case should be the last test case and disabled as default since it would block other tests.

3. A PSA RoT service cannot write App RoT secure partition read-only memory

Expected result:
PSA RoT service tries to change memory content and gets panic.

Note:
This case is disabled as default since it would block other tests. Enable it manually.

Reference Document

Copyright (c) 2019, Arm Limited. All rights reserved.