| Julian Hall | e76ade8 | 2020-11-25 03:07:21 +0100 | [diff] [blame] | 1 | Architecture Overview |
| 2 | ===================== |
| 3 | |
| 4 | The Trusted Services project provides a framework for developing applications that can be built and deployed in |
| 5 | different secure processing environments and on different hardware platforms. The structure and conventions adopted |
| 6 | are designed to maximize opportunities for component reuse. The project adopts a portability model based on the |
| 7 | *ports and adapters* architectural pattern, which promotes loose coupling between an application |
| 8 | and its environment. The model allows applications to be deployed in a diverse range of environments from full |
| 9 | featured trusted OSs, such as OP-TEE, to bare metal secure partitions. |
| 10 | |
| 11 | For a more in-depth description of how the ports and adapters pattern is applied, see: |
| 12 | :ref:`Portability Model` |
| 13 | |
| 14 | Service Model |
| 15 | ------------- |
| 16 | |
| 17 | Trusted services conform to a client/server model where service specific operations are invoked using an RPC mechanism. |
| 18 | The realization of the RPC layer and any underlying messaging layer may vary between deployments but the service layer |
| 19 | should be identical for every deployment of a particular service. The following diagram illustrates the common layered |
| 20 | model and where standardization on layer interfaces and protocols will be aimed for. |
| 21 | |
| 22 | .. image:: image/TrustedServicesLayers.svg |
| 23 | |
| 24 | The layered service model is reflected in the project source tree where software components are organized by layer and role. |
| 25 | Because components that perform the same role are inter-changeable, there is much flexibility to meet the needs of |
| 26 | different deployments. For example: |
| 27 | |
| 28 | - An instance of the secure storage service could be accessed by different types of client, each presenting |
| 29 | different upper edge APIs to suite the needs of different applications. Some different secure storage clients |
| 30 | could be: |
| 31 | |
| 32 | - A filesystem driver that presents a filesystem mount for user-space access to stored objects. |
| 33 | - A client that presents the PSA Protected Storage API. |
| 34 | |
| 35 | - Different types of secure storage provider are possible, each accessed using a common protocol. Some different |
| 36 | secure storage providers could be: |
| 37 | |
| 38 | - A secure storage provider that uses an external RPMB serial flash device for storage. |
| 39 | - A secure storage provider that encrypts objects before passing them to a normal world agent to access |
| 40 | file-backed storage. |
| 41 | |
| 42 | - Different RPC layers may be used to access services deployed in different secure processing environments. |
| 43 | |
| 44 | Service Deployments |
| 45 | ------------------- |
| 46 | |
| 47 | The ability to deploy trusted services over a range of secure processing environments allows a consistent view of |
| 48 | services to be presented to clients, independent of the back-end implementation. For a particular service deployment, a |
| 49 | concrete set of build-time and run-time dependencies and configurations must be defined. Representing each deployment |
| 50 | in the project structure allows multiple deployments to be supported, each reusing a subset of shared components. |
| 51 | The following diagram illustrates the dependencies and configurations that must be defined for a fully specified |
| 52 | deployment. |
| 53 | |
| 54 | .. uml:: uml/ServiceDeployment.puml |
| 55 | |
| 56 | Currently supported deployments are listed here: |
| 57 | :ref:`Deployments` |
| 58 | |
| 59 | Service Access Protocols |
| 60 | ------------------------ |
| 61 | |
| 62 | As mentioned in the section on layering, trusted services are accessed by clients via an RPC layer. Independent of the |
| 63 | mechanics of the RPC layer, a service access protocol is defined by: |
| 64 | |
| 65 | - A supported set of operations, each qualified by an opcode. |
| 66 | - A set of request and response message parameter definitions, one for each operation. |
| 67 | |
| 68 | The main documentation page for service access protocols is here: :ref:`Service Access Protocols`. |
| 69 | |
| 70 | The trusted service framework can accommodate the use of arbitrary serializations for message parameters. So far, |
| 71 | message protocols using Google Protocol Buffers and packed C structures have been defined. |
| 72 | |
| 73 | .. image:: image/ServiceAccessProto.svg |
| 74 | |
| 75 | -------------- |
| 76 | |
| 77 | *Copyright (c) 2020-2021, Arm Limited and Contributors. All rights reserved.* |
| 78 | |
| 79 | SPDX-License-Identifier: BSD-3-Clause |