blob: 6cf7e1bc2ac804670406034cf598427620a0fc2f [file] [log] [blame]
Jamie Fox519cc4b2022-06-07 12:07:28 +01001Runtime Security Subsystem (RSS)
2================================
3
4Introduction
5------------
6
7Runtime Security Subsystem (RSS) is an Arm subsystem that provides a reference
8implementation of the HES Host in the
9`Arm Confidential Compute Architecture (CCA) <https://www.arm.com/architecture/security-features/arm-confidential-compute-architecture>`_.
10It is designed to be integrated into A-profile compute subsystems that implement
11Arm CCA, where it serves as the Root of Trust.
12
13RSS initially boots from immutable code (BL1_1) in its internal ROM, before
14jumping to BL1_2, which is provisioned and hash-locked in RSS OTP. The updatable
15MCUBoot BL2 boot stage is loaded from host system flash into RSS SRAM, where it
16is authenticated. BL2 loads and authenticates the TF-M runtime into RSS SRAM
17from host flash. BL2 is also responsible for loading initial boot code into
18other subsystems within the host.
19
David Vincze8c95d2a2022-01-19 10:11:58 +010020The RSS platform port supports the TF-M Crypto, TF-M Initial Attestation,
21Measured Boot and TF-M Platform services along with the corresponding
22regression tests. It supports the IPC model in multi-core topology with
23Isolation Level 1 and 2.
Jamie Fox519cc4b2022-06-07 12:07:28 +010024
25Building TF-M
26-------------
27
Anton Komlev0dbe8f12022-06-17 16:48:12 +010028Follow the instructions in :doc:`Build instructions </building/tfm_build_instruction>`.
Jamie Fox519cc4b2022-06-07 12:07:28 +010029Build TF-M with platform name: `arm/rss`
30
31``-DTFM_PLATFORM=arm/rss``
32
33Signing host images
34-------------------
35
36RSS BL2 can load boot images into other subsystems within the host system. It
37expects images to be signed, with the signatures attached to the images in the
38MCUBoot metadata format.
39
40The `imgtool Python package <https://pypi.org/project/imgtool/>`_ can be used to
41sign images in the required format. To sign a host image using the development
42key 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 Foxa1e86022022-07-12 17:58:02 +010060The ``load address`` is the logical address in the RSS memory map to which BL2
61will 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
63subsequent host image to be loaded at an offset of ``0x100000`` from the
64previous image. The RSS ATU should be configured to map these logical addresses
65to the physical addresses in the host system that the images need to be loaded
66to.
Jamie Fox519cc4b2022-06-07 12:07:28 +010067
68For 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
76Running the code
77----------------
78
79To run the built images, they need to be concatenated into binaries that can be
80placed in ROM and flash. To do this, navigate to the TF-M build directory and
81run 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
99For development purposes, the OTP image is included as a provisioning bundle in
100the ROM image and provisioned into OTP by BL1_1. The flash image should include
101the signed host images from the previous section. For each boot image, there is
102a primary and secondary image; if these are different then BL2 will load the one
103with the higher version number.
104
105The ROM binary should be placed in RSS ROM at ``0x11000000`` and the flash
106binary should be placed at ``0x31000000``.
107
108--------------
109
110*Copyright (c) 2022, Arm Limited. All rights reserved.*