|
| 1 | +.. SPDX-License-Identifier: GPL-2.0 |
| 2 | +
|
| 3 | +================================= |
| 4 | +TS-TEE (Trusted Services project) |
| 5 | +================================= |
| 6 | + |
| 7 | +This driver provides access to secure services implemented by Trusted Services. |
| 8 | + |
| 9 | +Trusted Services [1] is a TrustedFirmware.org project that provides a framework |
| 10 | +for developing and deploying device Root of Trust services in FF-A [2] S-EL0 |
| 11 | +Secure Partitions. The project hosts the reference implementation of the Arm |
| 12 | +Platform Security Architecture [3] for Arm A-profile devices. |
| 13 | + |
| 14 | +The FF-A Secure Partitions (SP) are accessible through the FF-A driver [4] which |
| 15 | +provides the low level communication for this driver. On top of that the Trusted |
| 16 | +Services RPC protocol is used [5]. To use the driver from user space a reference |
| 17 | +implementation is provided at [6], which is part of the Trusted Services client |
| 18 | +library called libts [7]. |
| 19 | + |
| 20 | +All Trusted Services (TS) SPs have the same FF-A UUID; it identifies the TS RPC |
| 21 | +protocol. A TS SP can host one or more services (e.g. PSA Crypto, PSA ITS, etc). |
| 22 | +A service is identified by its service UUID; the same type of service cannot be |
| 23 | +present twice in the same SP. During SP boot each service in the SP is assigned |
| 24 | +an "interface ID". This is just a short ID to simplify message addressing. |
| 25 | + |
| 26 | +The generic TEE design is to share memory at once with the Trusted OS, which can |
| 27 | +then be reused to communicate with multiple applications running on the Trusted |
| 28 | +OS. However, in case of FF-A, memory sharing works on an endpoint level, i.e. |
| 29 | +memory is shared with a specific SP. User space has to be able to separately |
| 30 | +share memory with each SP based on its endpoint ID; therefore a separate TEE |
| 31 | +device is registered for each discovered TS SP. Opening the SP corresponds to |
| 32 | +opening the TEE device and creating a TEE context. A TS SP hosts one or more |
| 33 | +services. Opening a service corresponds to opening a session in the given |
| 34 | +tee_context. |
| 35 | + |
| 36 | +Overview of a system with Trusted Services components:: |
| 37 | + |
| 38 | + User space Kernel space Secure world |
| 39 | + ~~~~~~~~~~ ~~~~~~~~~~~~ ~~~~~~~~~~~~ |
| 40 | + +--------+ +-------------+ |
| 41 | + | Client | | Trusted | |
| 42 | + +--------+ | Services SP | |
| 43 | + /\ +-------------+ |
| 44 | + || /\ |
| 45 | + || || |
| 46 | + || || |
| 47 | + \/ \/ |
| 48 | + +-------+ +----------+--------+ +-------------+ |
| 49 | + | libts | | TEE | TS-TEE | | FF-A SPMC | |
| 50 | + | | | subsys | driver | | + SPMD | |
| 51 | + +-------+----------------+----+-----+--------+-----------+-------------+ |
| 52 | + | Generic TEE API | | FF-A | TS RPC protocol | |
| 53 | + | IOCTL (TEE_IOC_*) | | driver | over FF-A | |
| 54 | + +-----------------------------+ +--------+-------------------------+ |
| 55 | + |
| 56 | +References |
| 57 | +========== |
| 58 | + |
| 59 | +[1] https://www.trustedfirmware.org/projects/trusted-services/ |
| 60 | + |
| 61 | +[2] https://developer.arm.com/documentation/den0077/ |
| 62 | + |
| 63 | +[3] https://www.arm.com/architecture/security-features/platform-security |
| 64 | + |
| 65 | +[4] drivers/firmware/arm_ffa/ |
| 66 | + |
| 67 | +[5] https://trusted-services.readthedocs.io/en/v1.0.0/developer/service-access-protocols.html#abi |
| 68 | + |
| 69 | +[6] https://git.trustedfirmware.org/TS/trusted-services.git/tree/components/rpc/ts_rpc/caller/linux/ts_rpc_caller_linux.c?h=v1.0.0 |
| 70 | + |
| 71 | +[7] https://git.trustedfirmware.org/TS/trusted-services.git/tree/deployments/libts/arm-linux/CMakeLists.txt?h=v1.0.0 |
0 commit comments