1Architecture Overview
2=====================
3
4The Trusted Services project provides a framework for developing applications that can be built and deployed in
5different secure processing environments and on different hardware platforms.  The structure and conventions adopted
6are 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
8and its environment.  The model allows applications to be deployed in a diverse range of environments from full
9featured trusted OSs, such as OP-TEE, to bare metal secure partitions.
10
11For a more in-depth description of how the ports and adapters pattern is applied, see:
12:ref:`Service Deployment Model`
13
14Service Model
15-------------
16
17Trusted services conform to a client/server model where service specific operations are invoked using an RPC mechanism.
18The realization of the RPC layer and any underlying messaging layer may vary between deployments but the service layer
19should be identical for every deployment of a particular service.  The following diagram illustrates the common layered
20model and where standardization on layer interfaces and protocols will be aimed for.
21
22.. image:: image/TrustedServicesLayers.svg
23
24The layered service model is reflected in the project source tree where software components are organized by layer and role.
25Because components that perform the same role are inter-changeable, there is much flexibility to meet the needs of
26different 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
44Service Deployments
45-------------------
46
47The ability to deploy trusted services over a range of secure processing environments allows a consistent view of
48services to be presented to clients, independent of the back-end implementation.  For a particular service deployment, a
49concrete set of build-time and run-time dependencies and configurations must be defined.  Representing each deployment
50in the project structure allows multiple deployments to be supported, each reusing a subset of shared components.
51The following diagram illustrates the dependencies and configurations that must be defined for a fully specified
52deployment.
53
54.. uml:: uml/ServiceDeployment.puml
55
56Currently supported deployments are listed here:
57:ref:`Deployments`
58
59Service Access Protocols
60------------------------
61
62As mentioned in the section on layering, trusted services are accessed by clients via an RPC layer.  Independent of the
63mechanics 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
68The main documentation page for service access protocols is here: :ref:`Service Access Protocols`.
69
70The trusted service framework can accommodate the use of arbitrary serializations for message parameters.  So far,
71message 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-2022, Arm Limited and Contributors. All rights reserved.*
78
79SPDX-License-Identifier: BSD-3-Clause
80