| Julian Hall | 5e3626f | 2022-04-07 14:05:08 +0100 | [diff] [blame^] | 1 | Secure Partitions |
| 2 | ================= |
| 3 | Secure partition (SP) deployments are concerned with building SP images that can |
| 4 | be loaded and run under a secure partition manager such as Hafnium or OP-TEE. |
| 5 | SP images will usually include service provider components that expose a |
| 6 | service interface that may be reached using FF-A messages. A set of SP images |
| 7 | will be loaded and verified by device firmware to provide the required services. |
| 8 | |
| 9 | The following SP deployments are currently supported: |
| 10 | |
| 11 | crypto |
| 12 | ------ |
| 13 | An instance of the crypto service provider is built into an SP image to |
| 14 | perform cryptographic operations on behalf of clients running in different |
| 15 | partitions. Backend crypto operations are implemented by the crypto library |
| 16 | component of MbedTLS. This deployment provides the cryptographic facilities |
| 17 | needed for PSA certification. For more information, see: |
| 18 | :ref:`Crypto Service Description`. |
| 19 | |
| 20 | .. list-table:: |
| 21 | :widths: 1 2 |
| 22 | :header-rows: 0 |
| 23 | |
| 24 | * - Supported Environments |
| 25 | - * *opteesp* (runs as an S-EL0 SP under OP-TEE) |
| 26 | * - External Dependencies |
| 27 | - * | TRNG (platform specific) |
| 28 | * | Secure storage SP |
| 29 | |
| 30 | attestation |
| 31 | ----------- |
| 32 | An instance of the attestation service provider is built into an SP image |
| 33 | to support remote attestation use-cases. The service provider obtains a |
| 34 | trusted view of the boot state of device firmware from the TPM event log |
| 35 | collected by the boot loader. This deployment provides the initial attestation |
| 36 | facility needed for PSA certification. For more information, see: |
| 37 | :ref:`Attestation Service Description`. |
| 38 | |
| 39 | .. list-table:: |
| 40 | :widths: 1 2 |
| 41 | :header-rows: 0 |
| 42 | |
| 43 | * - Supported Environments |
| 44 | - * *opteesp* (runs as an S-EL0 SP under OP-TEE) |
| 45 | * - External Dependencies |
| 46 | - * | TPM Event Log (via SP boot parameter) |
| 47 | * | Crypto SP |
| 48 | |
| 49 | internal-trusted-storage & protected-storage |
| 50 | -------------------------------------------- |
| 51 | Two secure storage SP deployments are provided to allow different classes |
| 52 | of storage to coexist on a device. Both deployments build an instance of |
| 53 | the secure storage service provider with a storage backend. To allow |
| 54 | different security trade-offs to be made and to support different hardware, |
| 55 | a system integrator may configure which storage backend to use. Secure storage |
| 56 | is a requirement for PSA certification. For more information, see: |
| 57 | :ref:`Secure Storage Service Description`. |
| 58 | |
| 59 | .. list-table:: |
| 60 | :widths: 1 2 |
| 61 | :header-rows: 0 |
| 62 | |
| 63 | * - Supported Environments |
| 64 | - * *opteesp* (runs as an S-EL0 SP under OP-TEE) |
| 65 | * - External Dependencies |
| 66 | - * Depends on configured storage backend |
| 67 | |
| 68 | se-proxy |
| 69 | -------- |
| 70 | The se-proxy SP provides access to services hosted by a secure enclave (hence |
| 71 | 'se'). A secure enclave consists of a separate MCU, connected to the host via |
| 72 | a secure communications channel. To protect access to the communication channel, |
| 73 | the se-proxy SP is assigned exclusive access to the communication peripheral via |
| 74 | device or memory regions defined in the SP manifest. The deployment integrates |
| 75 | multiple service providers into the SP image. After performing access control, |
| 76 | service requests are forwarded to the secure enclave. |
| 77 | |
| 78 | The se-proxy deployment includes proxies for the following services: |
| 79 | |
| 80 | - Crypto |
| 81 | - Attestation |
| 82 | - Internal Trusted Storage |
| 83 | - Protected Storage |
| 84 | |
| 85 | .. list-table:: |
| 86 | :widths: 1 2 |
| 87 | :header-rows: 0 |
| 88 | |
| 89 | * - Supported Environments |
| 90 | - * *opteesp* (runs as an S-EL0 SP under OP-TEE) |
| 91 | * - External Dependencies |
| 92 | - * SE communication peripheral (platform specific) |
| 93 | |
| 94 | smm-gateway |
| 95 | ----------- |
| 96 | An instance of the smm-variable service provider is built into the smm-gateway SP |
| 97 | image to provide secure world backing for UEFI SMM services. The smm-gateway SP |
| 98 | provides a lightweight alternative to StMM. For more information, see: |
| 99 | :ref:`UEFI SMM Services`. |
| 100 | |
| 101 | .. list-table:: |
| 102 | :widths: 1 2 |
| 103 | :header-rows: 0 |
| 104 | |
| 105 | * - Supported Environments |
| 106 | - * *opteesp* (runs as an S-EL0 SP under OP-TEE) |
| 107 | * - External Dependencies |
| 108 | - * | Secure storage service instance (e.g. hosted by protected-storage SP) |
| 109 | * | Crypto service instance (e.g. hosted crypto SP) |
| 110 | |
| 111 | env-test |
| 112 | -------- |
| 113 | An instance of the test runner service provider is built into an SP image to |
| 114 | allow test cases to be run from within the SP isolated environment. The SP |
| 115 | image also includes environment and platform specific test cases to allow |
| 116 | access to FF-A services and platform hardware to be tested. The test runner |
| 117 | service provider is intended to be used in conjunction with a client that |
| 118 | coordinates which tests to run and collects test results. |
| 119 | |
| 120 | .. list-table:: |
| 121 | :widths: 1 2 |
| 122 | :header-rows: 0 |
| 123 | |
| 124 | * - Supported Environments |
| 125 | - * *opteesp* (runs as an S-EL0 SP under OP-TEE) |
| 126 | * - External Dependencies |
| 127 | - * Any hardware accessed by test cases (platform specific) |
| 128 | |
| 129 | -------------- |
| 130 | |
| 131 | *Copyright (c) 2022, Arm Limited and Contributors. All rights reserved.* |
| 132 | |
| 133 | SPDX-License-Identifier: BSD-3-Clause |