Jamie Fox | 519cc4b | 2022-06-07 12:07:28 +0100 | [diff] [blame] | 1 | Runtime Security Subsystem (RSS) |
| 2 | ================================ |
| 3 | |
| 4 | Introduction |
| 5 | ------------ |
| 6 | |
| 7 | Runtime Security Subsystem (RSS) is an Arm subsystem that provides a reference |
| 8 | implementation of the HES Host in the |
| 9 | `Arm Confidential Compute Architecture (CCA) <https://www.arm.com/architecture/security-features/arm-confidential-compute-architecture>`_. |
| 10 | It is designed to be integrated into A-profile compute subsystems that implement |
| 11 | Arm CCA, where it serves as the Root of Trust. |
| 12 | |
| 13 | RSS initially boots from immutable code (BL1_1) in its internal ROM, before |
| 14 | jumping to BL1_2, which is provisioned and hash-locked in RSS OTP. The updatable |
| 15 | MCUBoot BL2 boot stage is loaded from host system flash into RSS SRAM, where it |
| 16 | is authenticated. BL2 loads and authenticates the TF-M runtime into RSS SRAM |
| 17 | from host flash. BL2 is also responsible for loading initial boot code into |
| 18 | other subsystems within the host. |
| 19 | |
David Vincze | 8c95d2a | 2022-01-19 10:11:58 +0100 | [diff] [blame] | 20 | The RSS platform port supports the TF-M Crypto, TF-M Initial Attestation, |
| 21 | Measured Boot and TF-M Platform services along with the corresponding |
| 22 | regression tests. It supports the IPC model in multi-core topology with |
| 23 | Isolation Level 1 and 2. |
Jamie Fox | 519cc4b | 2022-06-07 12:07:28 +0100 | [diff] [blame] | 24 | |
| 25 | Building TF-M |
| 26 | ------------- |
| 27 | |
Anton Komlev | 0dbe8f1 | 2022-06-17 16:48:12 +0100 | [diff] [blame] | 28 | Follow the instructions in :doc:`Build instructions </building/tfm_build_instruction>`. |
Jamie Fox | 519cc4b | 2022-06-07 12:07:28 +0100 | [diff] [blame] | 29 | Build TF-M with platform name: `arm/rss` |
| 30 | |
| 31 | ``-DTFM_PLATFORM=arm/rss`` |
| 32 | |
| 33 | Signing host images |
| 34 | ------------------- |
| 35 | |
| 36 | RSS BL2 can load boot images into other subsystems within the host system. It |
| 37 | expects images to be signed, with the signatures attached to the images in the |
| 38 | MCUBoot metadata format. |
| 39 | |
| 40 | The `imgtool Python package <https://pypi.org/project/imgtool/>`_ can be used to |
| 41 | sign images in the required format. To sign a host image using the development |
| 42 | key distributed with TF-M, use the following command:: |
| 43 | |
| 44 | imgtool sign \ |
| 45 | -k <TF-M base directory>/bl2/ext/mcuboot/root-RSA-3072.pem \ |
| 46 | --public-key-format full \ |
| 47 | --max-align 8 \ |
| 48 | --align 1 \ |
| 49 | -v "0.0.1" \ |
| 50 | -s 1 \ |
| 51 | -H 0x1000 \ |
| 52 | --pad-header \ |
| 53 | -S 0x80000 \ |
| 54 | --pad \ |
| 55 | --boot-record "HOST" \ |
| 56 | -L <load address> \ |
| 57 | <binary infile> \ |
| 58 | <signed binary outfile> |
| 59 | |
Jamie Fox | a1e8602 | 2022-07-12 17:58:02 +0100 | [diff] [blame] | 60 | The ``load address`` is the logical address in the RSS memory map to which BL2 |
| 61 | will load the image. RSS FW expects the first host image to be loaded to address |
| 62 | ``0x70000000`` (the beginning of the RSS ATU host access region), and each |
| 63 | subsequent host image to be loaded at an offset of ``0x100000`` from the |
| 64 | previous image. The RSS ATU should be configured to map these logical addresses |
| 65 | to the physical addresses in the host system that the images need to be loaded |
| 66 | to. |
Jamie Fox | 519cc4b | 2022-06-07 12:07:28 +0100 | [diff] [blame] | 67 | |
| 68 | For more information on the ``imgtool`` parameters, see the MCUBoot |
| 69 | `imgtool documentation <https://docs.mcuboot.com/imgtool.html>`_. |
| 70 | |
| 71 | .. warning:: |
| 72 | |
| 73 | The TF-M development key must never be used in production. To generate a |
| 74 | production key, follow the imgtool documentation. |
| 75 | |
| 76 | Running the code |
| 77 | ---------------- |
| 78 | |
| 79 | To run the built images, they need to be concatenated into binaries that can be |
| 80 | placed in ROM and flash. To do this, navigate to the TF-M build directory and |
| 81 | run the following ``srec_cat`` commands:: |
| 82 | |
| 83 | srec_cat \ |
| 84 | bl1_1.bin -Binary -offset 0x0 \ |
| 85 | bl1_provisioning_bundle.bin -Binary -offset 0xE000 \ |
| 86 | -o rom.bin -Binary |
| 87 | |
| 88 | srec_cat \ |
| 89 | bl2_signed.bin -Binary -offset 0x0 \ |
| 90 | bl2_signed.bin -Binary -offset 0x20000 \ |
| 91 | tfm_s_ns_signed.bin -Binary -offset 0x40000 \ |
| 92 | tfm_s_ns_signed.bin -Binary -offset 0x140000 \ |
| 93 | <Host AP BL1 image> -Binary -offset 0x240000 \ |
| 94 | <SCP BL1 image> -Binary -offset 0x2C0000 \ |
| 95 | <Host AP BL1 image> -Binary -offset 0x340000 \ |
| 96 | <SCP BL1 image> -Binary -offset 0x3C0000 \ |
| 97 | -o flash.bin -Binary |
| 98 | |
| 99 | For development purposes, the OTP image is included as a provisioning bundle in |
| 100 | the ROM image and provisioned into OTP by BL1_1. The flash image should include |
| 101 | the signed host images from the previous section. For each boot image, there is |
| 102 | a primary and secondary image; if these are different then BL2 will load the one |
| 103 | with the higher version number. |
| 104 | |
| 105 | The ROM binary should be placed in RSS ROM at ``0x11000000`` and the flash |
| 106 | binary should be placed at ``0x31000000``. |
| 107 | |
| 108 | -------------- |
| 109 | |
| 110 | *Copyright (c) 2022, Arm Limited. All rights reserved.* |