| .. |
| # Copyright (c) 2022-2023, Arm Limited. |
| # |
| # SPDX-License-Identifier: MIT |
| |
| ###################### |
| Software architecture |
| ###################### |
| |
| |
| ***************** |
| Arm Corstone-1000 |
| ***************** |
| |
| Arm Corstone-1000 is a reference solution for IoT devices. It is part of |
| Total Solution for IoT which consists of hardware and software reference |
| implementation. |
| |
| Corstone-1000 software plus hardware reference solution is PSA Level-2 ready |
| certified (`PSA L2 Ready`_) as well as System Ready IR certified(`SRIR cert`_). |
| More information on the Corstone-1000 subsystem product and design can be |
| found at: |
| `Arm corstone1000 Software`_ and `Arm corstone1000 Technical Overview`_. |
| |
| This readme explicitly focuses on the software part of the solution and |
| provides internal details on the software components. The reference |
| software package of the platform can be retrieved following instructions |
| present in the user-guide document. |
| |
| *************** |
| Design Overview |
| *************** |
| |
| The software architecture of Corstone-1000 platform is a reference |
| implementation of Platform Security Architecture (`PSA`_) which provides |
| framework to build secure IoT devices. |
| |
| The base system architecture of the platform is created from three |
| different types of systems: Secure Enclave, Host and External System. |
| Each subsystem provides different functionality to overall SoC. |
| |
| |
| .. image:: images/CorstoneSubsystems.png |
| :width: 720 |
| :alt: CorstoneSubsystems |
| |
| |
| The Secure Enclave System, provides PSA Root of Trust (RoT) and |
| cryptographic functions. It is based on an Cortex-M0+ processor, |
| CC312 Cryptographic Accelerator and peripherals, such as watchdog and |
| secure flash. Software running on the Secure Enclave is isolated via |
| hardware for enhanced security. Communication with the Secure Encalve |
| is achieved using Message Handling Units (MHUs) and shared memory. |
| On system power on, the Secure Enclave boots first. Its software |
| comprises of a ROM code (TF-M BL1), Mcuboot BL2, and |
| TrustedFirmware-M(`TF-M`_) as runtime software. The software design on |
| Secure Enclave follows Firmware Framework for M class |
| processor (`FF-M`_) specification. |
| |
| The Host System is based on ARM Cotex-A35 processor with standardized |
| peripherals to allow for the booting of a Linux OS. The Cortex-A35 has |
| the TrustZone technology that allows secure and non-secure security |
| states in the processor. The software design in the Host System follows |
| Firmware Framework for A class procseeor (`FF-A`_) specification. |
| The boot process follows Trusted Boot Base Requirement (`TBBR`_). |
| The Host Subsystem is taken out of reset by the Secure Enclave system |
| during its final stages of the initialization. The Host subsystem runs |
| FF-A Secure Partitions(based on `Trusted Services`_) and OPTEE-OS |
| (`OPTEE-OS`_) in the secure world, and U-Boot(`U-Boot repo`_) and |
| linux (`linux repo`_) in the non-secure world. The communication between |
| non-secure and the secure world is performed via FF-A messages. |
| |
| An external system is intended to implement use-case specific |
| functionality. The system is based on Cortex-M3 and run RTX RTOS. |
| Communication between the external system and Host (Cortex-A35) is performed |
| using MHU as transport mechanism and rpmsg messaging system (the external system |
| support in Linux is disabled in this release. More info about this change can be found in the |
| release-notes). |
| |
| Overall, the Corstone-1000 architecture is designed to cover a range |
| of Power, Performance, and Area (PPA) applications, and enable extension |
| for use-case specific applications, for example, sensors, cloud |
| connectivitiy, and edge computing. |
| |
| ***************** |
| Secure Boot Chain |
| ***************** |
| |
| For the security of a device, it is essential that only authorized |
| software should run on the device. The Corstone-1000 boot uses a |
| Secure Boot Chain process where an already authenticated image verifies |
| and loads the following software in the chain. For the boot chain |
| process to work, the start of the chain should be trusted, forming the |
| Root of Trust (RoT) of the device. The RoT of the device is immutable in |
| nature and encoded into the device by the device owner before it |
| is deployed into the field. In Corstone-1000, the BL1 image of the secure |
| enclave and content of the CC312 OTP (One Time Programmable) memory |
| forms the RoT. The BL1 image exists in ROM (Read Only Memory). |
| |
| .. image:: images/SecureBootChain.png |
| :width: 870 |
| :alt: SecureBootChain |
| |
| It is a lengthy chain to boot the software on Corstone-1000. On power on, |
| the secure enclave starts executing BL1 code from the ROM which is the RoT |
| of the device. Authentication of an image involves the steps listed below: |
| |
| - Load image from flash to dynamic RAM. |
| - The public key present in the image header is validated by comparing with the hash. |
| Depending on the image, the hash of the public key is either stored in the OTP or part |
| of the software which is being already verified in the previous stages. |
| - The image is validated using the public key. |
| |
| In the secure enclave, BL1 authenticates the BL2 and passes the execution |
| control. BL2 authenticates the initial boot loader of the host (Host TF-A BL2) |
| and TF-M. The execution control is now passed to TF-M. TF-M being the run |
| time executable of secure enclave which initializes itself and, at the end, |
| brings the host CPU out of rest. The host follows the boot standard defined |
| in the `TBBR`_ to authenticate the secure and non-secure software. |
| |
| *************** |
| Secure Services |
| *************** |
| |
| Corstone-1000 is unique in providing a secure environment to run a secure |
| workload. The platform has TrustZone technology in the Host subsystem but |
| it also has hardware isolated secure enclave environment to run such secure |
| workloads. In Corstone-1000, known Secure Services such as Crypto, Protected |
| Storage, Internal Trusted Storage and Attestation are available via PSA |
| Functional APIs in TF-M. There is no difference for a user communicating to |
| these services which are running on a secure enclave instead of the |
| secure world of the host subsystem. The below diagram presents the data |
| flow path for such calls. |
| |
| |
| .. image:: images/SecureServices.png |
| :width: 930 |
| :alt: SecureServices |
| |
| |
| The SE Proxy SP (Secure Enclave Proxy Secure Partition) is a proxy partition |
| managed by OPTEE which forwards such calls to the secure enclave. The |
| solution relies on OpenAMP which uses shared memory and MHU interrupts as |
| a doorbell for communication between two cores. Corstone-1000 implements |
| isolation level 2. Cortex-M0+ MPU (Memory Protection Unit) is used to implement |
| isolation level 2. |
| |
| For a user to define its own secure service, both the options of the host |
| secure world or secure encalve are available. It's a trade-off between |
| lower latency vs higher security. Services running on a secure enclave are |
| secure by real hardware isolation but have a higher latency path. In the |
| second scenario, the services running on the secure world of the host |
| subsystem have lower latency but virtual hardware isolation created by |
| TrustZone technology. |
| |
| |
| ********************** |
| Secure Firmware Update |
| ********************** |
| |
| Apart from always booting the authorized images, it is also essential that |
| the device only accepts the authorized (signed) images in the firmware update |
| process. Corstone-1000 supports OTA (Over the Air) firmware updates and |
| follows Platform Security Firmware Update specification (`FWU`_). |
| |
| As standardized into `FWU`_, the external flash is divided into two |
| banks of which one bank has currently running images and the other bank is |
| used for staging new images. There are four updatable units, i.e. Secure |
| Enclave's BL2 and TF-M, and Host's FIP (Firmware Image Package) and Kernel |
| Image (the initramfs bundle). The new images are accepted in the form of a UEFI capsule. |
| |
| |
| .. image:: images/ExternalFlash.png |
| :width: 690 |
| :alt: ExternalFlash |
| |
| When Firmware update is triggered, u-boot verifies the capsule by checking the |
| capsule signature, version number and size. Then it signals the Secure Enclave |
| that can start writing UEFI capsule into the flash. Once this operation finishes |
| ,Secure Enclave resets the entire system. |
| The Metadata Block in the flash has the below firmware update state machine. |
| TF-M runs an OTA service that is responsible for accepting and updating the |
| images in the flash. The communication between the UEFI Capsule update |
| subsystem and the OTA service follows the same data path explained above. |
| The OTA service writes the new images to the passive bank after successful |
| capsule verification. It changes the state of the system to trial state and |
| triggers the reset. Boot loaders in Secure Enclave and Host read the Metadata |
| block to get the information on the boot bank. In the successful trial stage, |
| the acknowledgment from the host moves the state of the system from trial to |
| regular. Any failure in the trial stage or system hangs leads to a system |
| reset. This is made sure by the use of watchdog hardware. The Secure Enclave's |
| BL1 has the logic to identify multiple resets and eventually switch back to the |
| previous good bank. The ability to revert to the previous bank is crucial to |
| guarantee the availability of the device. |
| |
| |
| .. image:: images/SecureFirmwareUpdate.png |
| :width: 430 |
| :alt: SecureFirmwareUpdate |
| |
| |
| |
| ****************************** |
| UEFI Runtime Support in U-Boot |
| ****************************** |
| |
| Implementation of UEFI boottime and runtime APIs require variable storage. |
| In Corstone-1000, these UEFI variables are stored in the Protected Storage |
| service. The below diagram presents the data flow to store UEFI variables. |
| The U-Boot implementation of the UEFI subsystem uses the U-Boot FF-A driver to |
| communicate with the SMM Service in the secure world. The backend of the |
| SMM service uses the proxy PS from the SE Proxy SP. From there on, the PS |
| calls are forwarded to the secure enclave as explained above. |
| |
| |
| .. image:: images/UEFISupport.png |
| :width: 590 |
| :alt: UEFISupport |
| |
| |
| *************** |
| References |
| *************** |
| `ARM corstone1000 Search`_ |
| |
| `Arm security features`_ |
| |
| -------------- |
| |
| *Copyright (c) 2022-2023, Arm Limited. All rights reserved.* |
| |
| .. _Arm corstone1000 Technical Overview: https://developer.arm.com/documentation/102360/0000 |
| .. _Arm corstone1000 Software: https://developer.arm.com/Tools%20and%20Software/Corstone-1000%20Software |
| .. _Arm corstone1000 Search: https://developer.arm.com/search#q=corstone-1000 |
| .. _Arm security features: https://www.arm.com/architecture/security-features/platform-security |
| .. _linux repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ |
| .. _FF-A: https://developer.arm.com/documentation/den0077/latest |
| .. _FF-M: https://developer.arm.com/architectures/Firmware%20Framework%20for%20M-Profile |
| .. _FWU: https://developer.arm.com/documentation/den0118/a/ |
| .. _OPTEE-OS: https://github.com/OP-TEE/optee_os |
| .. _PSA: https://www.psacertified.org/ |
| .. _PSA L2 Ready: https://www.psacertified.org/products/corstone-1000/ |
| .. _SRIR cert: https://armkeil.blob.core.windows.net/developer/Files/pdf/certificate-list/arm-systemready-ir-certification-arm-corstone-1000.pdf |
| .. _TBBR: https://developer.arm.com/documentation/den0006/latest |
| .. _TF-M: https://www.trustedfirmware.org/projects/tf-m/ |
| .. _Trusted Services: https://www.trustedfirmware.org/projects/trusted-services/ |
| .. _U-Boot repo: https://github.com/u-boot/u-boot.git |