diff options
Diffstat (limited to 'docs/technical_references/secure_enclave_solution.rst')
-rw-r--r-- | docs/technical_references/secure_enclave_solution.rst | 122 |
1 files changed, 122 insertions, 0 deletions
diff --git a/docs/technical_references/secure_enclave_solution.rst b/docs/technical_references/secure_enclave_solution.rst new file mode 100644 index 0000000000..ce665ac229 --- /dev/null +++ b/docs/technical_references/secure_enclave_solution.rst @@ -0,0 +1,122 @@ +############################################## +Secure Enclave solution for Trusted Firmware-M +############################################## + +:Author: Mark Horvath +:Organization: Arm Limited +:Contact: Mark Horvath <mark.horvath@arm.com> +:Status: Draft + +******** +Abstract +******** + +This document summarizes the design goals and one possible implementation +of the TF-M Secure Enclave solution. + +************ +Introduction +************ + +If a separate subsystem can provide the PSA Root of Trust (RoT) in a system +then an additional physical separation exists between the most trusted and +other domains. In such a system at least two subsystems are present, a Secure +Enclave (SE) whose only task is to provide PSA RoT and an application core +where any other application specific functionality can be placed. The latter +core (or cores) are referred as *Host* in this document. + +The current design assumes that Host is a v8-m core with security extension. + +************ +Requirements +************ + +- Secure Enclave shall implement secure boot-flow (start-up first at reset and + validate its own and the Host image or images before release Host from reset) +- Secure Enclave shall provide the PSA RoT services +- Host shall provide not just the non-secure context but the Application RoT as + well +- It shall be transparent to the (secure or non-secure) applications running on + host whether the RoT services are provided by the same subsystem or by a + Secure Enclave. + +.. Note:: + + In comparison, in a Dual Core system the whole secure context is placed on a + separate subsystem, while a Secure Enclave only implements the PSA RoT + security domain. + +*************** +Proposed design +*************** + +As the clients and the services are running on different cores only the IPC +model can be used on both Secure Enclave and Host. + +Secure Enclave +============== + +To provide the required functionality it is enough to run the current PSA RoT +secure partitions on the Secure Enclave, so no need for non-secure context +there. (It is enough if the Secure Enclave's architecture is v6-m, v7-m or v8-m +without the security extension.) + +Secure Enclave can treat all clients running on Host as non-secure (even the +services running on Host's secure side). This means that fom Secure Enclave's +point of view all Host images, Host's RAM and shared memory between Host and +Secure Enclave if present are treated as non-secure. (Just like in the Dual CPU +solution.) But the clients need to be distinguished, otherwise some +functionalities are not working, for example: +- Protected Storage partition shall run on Host, but the PS area is handled by +Internal Trusted Storage partition (running on Secure Enclave). ITS partition +decides whether it should work on PS or ITS assets by checking the client ID. +- If a secure partition on host creates a crypto key, no other client shall be +able to destroy it. + +Communication +============= + +To communicate between Host and Secure Enclave, the existing mailbox solution +can be reused as it is. + +Host +==== + +On Host the current TF-M software architecture can be placed to provide +non-secure context and Application RoT domain. + +One solution to forward a PSA RoT IPC message from a client running on Host to +the Secure Enclave is to add a proxy partition to the secure side. This PSA +Proxy partition can provide all the RoT services to the system by forwarding +the messages over the mailbox solution. + +If the new partition's manifest contains all the PSA RoT service IDs SPM will +deliver all IPC messages there. Then the messages just must be blindly copied +into the mailbox. PSA proxy can use the non-secure interface of the mailbox, +but it is placed on the secure side of Host. (From SE's point of view this is +in fact the non-secure side of the mailbox as whole Host is treated as +non-secure.) + +It is important to verify IOVECs before forwarding them to SE, otherwise a +malicous actor could use SE to access a memory area otherwise unaccessable. If +PSA proxy uses the current secure partition interface then this is ensured by +Host's SPM. + +SE treats all clients of Host as non-secure, so all PSA messages shall have a +negative client ID when pushed into SE's SPM. This is given for the clients on +the non-secure side of Host, but the secure side clients of Host have positive +client IDs. The straightforward solution is to translate the positive client +IDs into a predefined negative range in PSA proxy, and push the translated +values into the mailbox. Of course this range shall be reserved for this use +only and no clients on non-secure side of Host shall have client ID from this +range. + +To avoid blocking Host when a message is sent PSA Proxy shall handle the +service requests in non-blocking mode. And to maximize bandwidth PSA Proxy +shall be able to push new messages into the mailbox, while others still not +answered. To achieve these the mailbox interrupts needs to be handled in the +PSA Proxy partition. + +-------------- + +*Copyright (c) 2020, Arm Limited. All rights reserved.* |