Learn about RISC-V Trusted Execution Environment in one article: Keystone

Regarding ARM TrustZone articles, I have published several superficial articles to learn from you.

Today I will give you an overview of the RISC-V Trusted Execution Environment (TEE): Risc-V Keystone.

Perface

Keystone is an open source framework designed to build custom Trusted Execution Environments (TEEs).

It provides a highly programmable trusted layer underneath the untrusted operating system and is implemented using the basic components of RISC-V.

Keystone is designed to pave the way for low-cost use case customization by decoupling isolation mechanisms from resource management, virtualization and trust boundary decisions.

Compared with existing TEE solutions, Keystone is more flexible and customizable. It can independently explore gaps/trade-offs in existing designs, rapidly prototype new functional requirements, shorter repair cycles, adapt to threat models and use-specific deploy.

Keystone is also designed with security in mind, leveraging hardware primitives to provide built-in support for TEE guarantees such as secure boot, memory isolation and authentication.

Let’s take a look below!

Why do you need Keystone?

Keystone is an open source framework that allows you to build your own Trusted Execution Environment (TEE) like building blocks. TEE is where your code and data can be protected from insecure computer environments. TEEs have developed rapidly in the past decade, and many CPU vendors have launched their own TEEs.

But each supplier's TEE has its own limitations, just like you can't change the shape of building blocks at will. When you choose a cloud service provider or software developer, they may be locked into the limitations of their own TEE, which may not match your actual application needs.

Keystone is like a new building block box with various components that can be used to build TEE. You can choose which components to use based on your own needs and build a TEE that meets your needs. This gives you more flexibility to protect your code and data, whether on cloud servers, mobile phones, ISPs, IoT devices, sensors or hardware tokens.

Keystone is also designed with security in mind. It has a security monitor (SM) and runtime (RT) components. SM uses hardware primitives to provide security guarantees such as secure boot, memory isolation, and authentication. RT provides functional modules in the enclave, such as system call interface, standard libc support, virtual memory management and self-paging. This way, any enclave-specific functionality can be implemented cleanly by RT, while SM enforces the security of the hardware.

Overall, Keystone is a more flexible and secure open source framework that allows you to build custom TEEs to protect your code and data.

Introduction to Keystone

A Keystone-enabled system consists of multiple components with different permission models.

Trusted Hardware is a CPU package built by a trusted vendor and must contain a standard Keystone-compatible RISC-V kernel and root of trust. Hardware may also include optional features such as cache partitioning, memory encryption, cryptographically secure random sources, etc. Security Monitor requires platform-specific plug-ins to support optional functionality.

Security Monitor (SM) is M-mode software with a small TCB. SM provides an interface to manage the life cycle of an enclave and take advantage of platform-specific features. SM enforces most of Keystone's security guarantees because it manages the isolation boundary between the enclave and the untrusted operating system.

An Enclave is an environment isolated from untrusted operating systems and other enclaves. Each enclave has a private physical memory region that can only be accessed by the enclave and the SM. Each enclave consists of a user-level enclave application eapp and a supervisor-level runtime.

An Enclave Application (eapp) is a user-level application that executes in an enclave. You can build a custom eapp from scratch, or just run an existing RISC-V executable in Keystone.

The runtime is S-mode software, which implements system calls, trap handling, virtual memory management and other functions.

Keystone Features

Keystone isan open source project that builds customizable Trusted Execution Environments (TEEs) based on RISC-V, suitable for various platforms and use cases.

Our goal is to build a secure and trustworthy open source secure hardware enclave that can be applied to a variety of applications and devices.

Keystone is an open source TEE framework based on Risc-V. In any Risc-V processor, only needs very minor modifications to the hardware to meet the Keystone platform framework The following is a brief introduction to the features that Risc-V CPU needs to support when using Keystone.

Instruction set compatibility

Keystone requires all three permission modes (M/S/U) to support dynamic user-level isolation in Linux machines.
rv64gc-lp64d (Sv39 virtual addressing mode)
rv32gc-ilp32d (Sv32 virtual addressing mode)

Keystone requires all three permission modes (M/S/U) to support dynamic user-level isolation in Linux machines. This means that Keystone can support three different permission levels, namely machine level (M), system level (S) and user level (U). These three permission levels can be used to create and manage different types of isolation and security environments.

Keystone also supportstwo different virtual addressing modes, Sv39 and Sv32. These modes are part of the virtual memory system in the RISC-V architecture and are used to manage code and data in virtual memory. Sv39 is a 64-bit mode that enables 32-bit applications to run on 64-bit systems. And Sv32 is a 32-bit mode that supports running 32-bit applications on a 32-bit system.

Three software privileges

RISC-V has three software privilege levels (in order of increasing functionality):

User mode (U-mode),

Supervisor mode (S-mode)

Machine mode (M-mode).

The processor can only operate in one of these privileged modes at a time.

Permission levels define what running software can do during its execution. Common usage of each permission level is as follows:

U-mode: user process
S-mode: kernel (including kernel modules and device drivers), hypervisor
M-mode: bootloader, firmware

Some embedded devices may be M-mode only or M/U-mode only.

M-mode is the most privileged mode and controls all physical resources and interrupts. M mode is similar to microcode in Complex Instruction Set Computer (CISC) ISAs such as x86 in that it is uninterruptible and uninterrupted by lower modes.

Keystone uses M-mode to run the Security Monitor (SM), the system's Trusted Computing Base (TCB).

Yes,M-mode is the most privileged mode and can control all physical resources and interrupts. It is similar to microcode in Complex Instruction Set Computer (CISC) ISAs such as x86 in that it is uninterruptible and uninterrupted by lower modes. In the RISC-V architecture, M-mode is a privileged mode that can perform critical tasks such as memory management, exception handling, and system calls. It has full control over all physical resources and can interrupt other lower mode operations. In contrast, S-mode and U-mode have system-level and user-level permissions respectively, and M-mode must be entered through a specific system call.

memory protection

First, RISC-V is an open source instruction set architecture (ISA) that provides a flexible way to define and extend the instruction set. The RISC-V Priv 1.10 standard introduces the Physical Memory Protection (PMP) feature, a powerful primitive that allows access to physical memory to be controlled from lower privileges (U-/S mode) in M mode.

PMP is implemented through a set of control and status registers (CSR). These registers can be configured to allow or deny access to specific areas of physical memory.

In U mode, only those physical memory areas configured by PMP to allow access can be accessed.
In S mode, all non-denied physical memory areas can be accessed.
However, the state of the PMP register can be configured and changed only in M mode.

Each PMP entry can be defined by one or more PMP CSRs. Each CSR has a specific bit pattern that indicates the size and extent of the physical memory area that the CSR controls.

For example, a PMP entry might be defined by two CSRs, one indicating the starting address of the physical memory region and another indicating the size.

Keystone is an open source framework for building custom Trusted Execution Environments (TEEs). It uses RISC-V as its basic instruction set and introduces security monitor (SM) and runtime (RT) components. Keystone requires PMP to implement enclave memory isolation.

In Keystone**, SM is responsible for performing security monitoring functions, which uses PMP to enforce memory access control**. Each enclave has its own isolated area of physical memory that can only be accessed by that enclave.

RT provides functional modules within each enclave, such as system call interface, standard libc support, virtual memory management and self-paging. RT requests access to external resources, such as shared memory or host resources, by communicating with SM.

In this way, Keystone is able to provide a highly isolated and secure execution environment.

Each enclave has its own virtual memory space and can only access physical memory areas authorized by the SM. This design ensures data security and integrity when performing sensitive tasks.

Interrupts and Exceptions

By default, M mode is the first recipient of any interrupt or exception (i.e., a trap) in the system, which means that M mode has full authority over CPU scheduling and configuration. However, M Mode can delegate this control to S Mode as needed.

M mode can use mieCSR to disable or enable each interrupt. mieCSR is a control and status register that can be configured to indicate which interrupts are enabled or disabled.

M mode can also delegate traps to S mode by setting the bits of the trap delegation register (i.e. mideleg and medeleg). Trap delegates can skip M-mode handlers so that S-mode can quickly handle frequent traps, such as page faults, system calls (environment calls), etc.

In this way, collaboration between M-mode and S-mode optimizes system performance. Frequent interrupts or exceptions can be quickly handled by S mode, while M mode can focus on more important tasks, such as CPU scheduling and configuration. This decentralized approach allows the system to be optimally configured based on specific application requirements.

virtual address translation

In RISC-V, virtual address translation is performed by the Memory Management Unit (MMU), a process that consists of two hardware components: the page table walker (PTW) and the translation lookaside buffer (TLB).

Virtual address translation uses multi-level page tables. The number of pages in the page table and the page size depend on the addressing mode. The CSR (Control and Status Register) determines which addressing mode the MMU should use and which physical page contains the root page table used to start the page table walk.

In the Keystone enclave, memory access protection is implemented through PMP (Physical Memory Protection). Enclaves have their own protected page tables, which the operating system cannot modify.

PMP restricts access to physical memory through the Control and Status Register (CSR). Each enclave has its own isolated area of physical memory that can only be accessed by that enclave.

The operating system cannot modify the enclave's page tables, so there is no way to attack it by changing the page tables. This design provides a highly isolated and secure execution environment, ensuring data security and integrity when performing sensitive tasks.

Keystone workflow

This image shows the distribution of development work, which can be mainly divided into enclave developers and platform developers.

Steps ❶❷❸ are performed by the platform provider, and Security Monitor that meets the Keystone architecture needs to be deployed on the device;
Enclave developers use the Keystone SDK to develop enclaves. Developers build eapp, host, and runtime binaries and (optionally) package them into a single file (❹);
Then deploy on the device through ❺, ❻ and ❼;
❽It is the process of remote certification.

As a component strongly related to the platform, SM is provided by platform developers, while enclave developers are responsible for the development of Host APP, Eapp, and Runtime.

Platform Developer Jobs:
- Platform developers need to develop and deploy Security Monitor that meets the Keystone architecture. This component is responsible for monitoring and managing memory access permissions to ensure that only authorized code and data can access physical memory.
- Platform developers also need to configure and manage page tables (Page Tables), which are data structures used by the operating system to manage the mapping between virtual memory and physical memory. Platform developers need to set up the correct page tables to ensure that virtual addresses can be correctly mapped to physical addresses.
Jobs of Enclave Developers:
- Enclave developers use the Keystone SDK to develop enclave applications. This SDK provides a set of APIs and tools for building isolated and secure execution environments.
- Enclave developers first need to create an eApp, which is a collection of code and data for the enclave application. An eapp can be any type of program, such as a simple application, an operating system, or a security-critical application.
- Enclave developers also need to develop and configure the runtime environment. The runtime environment provides various services required to execute eapp, such as memory management, process scheduling, input and output, etc.
- Enclave developers can use the tools provided by the Keystone SDK to package the eApp and runtime environment into an executable binary. This binary can run on the device and execute in isolation from other enclave applications.
Deployment process:
- Enclave developers deploy executable binaries to devices. Deployment methods can vary based on device type and operating system, such as via USB transfer, network upload, or installation directly on the device.
- Once deployed on the device, the enclave application is loaded into memory and begins execution. Each enclave application has its own isolated area of physical memory and can only access its own memory space and not that of other applications.
Remote certification process:
- In some cases, it may be necessary to verify the integrity and security of the enclave application. At this time, you can use the Remote Attestation process provided by Keystone. This process allows third-party organizations or users to verify that enclave applications comply with Keystone's security standards.
- The remote attestation process typically involves collecting information such as the metadata, runtime state, and memory contents of the enclave application and submitting this information to a verification authority for verification. Verification authorities can use the tools and analysis algorithms provided by Keystone SDK to verify the integrity and security of this information. If the verification passes, the enclave application can be considered authentic.

Keystone life cycle

Creation stage:

Apply for memory: Before creating an enclave, you need to apply for a contiguous memory from the system. This memory is called enclave private memory (EPM). EPM is private memory for an enclave application and can only be accessed by that enclave.
Load binary files: After applying for EPM, you need to load the binary files of the enclave into EPM. This binary includes the enclave's page table (PT), runtime (RT), and eapp. These components are required for the enclave application to run.
Create enclave: After loading the binary, create the enclave by calling SM (Security Monitor). SM uses PMP (Physical Memory Protection) entries to isolate and protect the created EPM memory. PMP entries define which areas of physical memory are protected and which cores can access these areas.
Checksum measurement: After the enclave is created, SM will perform checksum measurement on the enclave. This process is mainly to verify whether the initial state of the enclave is as expected and to ensure that there is no malicious code injection or other security issues.

Execution phase:

Run and Continue: At this stage, the Host can control a core running enclave. To achieve this control, the SM will grant this core PMP access to the EPM. The core then starts executing the enclave application.
Stop and exit: Running an enclave can be exited or stopped at any time. When stopped or exited, SM will switch the core's PMP permissions to ensure that the core no longer has permission to access the EPM, thereby maintaining isolation from the outside world through PMP.

Destruction phase:

Destruction: The Host can destroy an enclave at any time. When an enclave is destroyed, SM releases the related PMP entries and reclaims the free memory occupied by the EPM. This way, the system can reuse this memory to create new enclaves.

VS TrustZone

The key core word of TrustZone is isolation, this word. Every module adds a filter and a safe or non-safe flag. This is really a clever design.

So what are the advantages of Risc-V's keystone solution over TrustZone?

Mainly reflected in the following aspects:

Memory Protection: Keystone uses the PMP (Physical Memory Protection) mechanism to isolate and protect the physical memory of each enclave, ensuring that one enclave cannot access the memory space of other enclaves. This protection mechanism prevents malicious code injection and data leakage, improving security. Although TrustZone also provides memory isolation functions, it cannot provide comprehensive physical memory protection like Keystone.
Enclave isolation: Keystone supports the creation of multiple mutually isolated enclaves (Zone). Each enclave has its own runtime environment, applications and data, and each other is not affected. This isolation mechanism can prevent problems in one enclave from affecting other enclaves, improving the reliability of the system. Although TrustZone also provides isolation functions, there are potential security risks in sharing data and programs between each isolation zone (Secure World).
Flexibility and scalability: Keystone's architecture is more flexible and scalable. It supports the dynamic creation and destruction of virtual machines in enclaves, supports the deployment of multiple operating systems and applications, and can meet the needs of different scenarios. TrustZone's virtualization support is relatively weak and its scalability is limited.
Performance optimization: By deploying different runtime environments and applications in different enclaves, Keystone can better utilize system resources, reduce unnecessary overhead, and improve performance. The runtime environment of TrustZone is fixed and cannot be optimized.

Overall, Risc-V's keystone solution has advantages over TrustZone in terms of memory protection, enclave isolation, flexibility and scalability, and performance optimization. However, it should be noted that these advantages are not absolute, and the specific choice of which solution needs to be weighed based on actual application scenarios and needs.

Some challenges and limitations faced by Keystone solutions

The flexibility of the solution will inevitably increase the workload of developers, because memory management and life cycle management need to be performed in SM at the same time, which corresponds to an increase in the amount of code, so the risk becomes greater.

How to ensure the reliability of the code?
For these key parts of the code, methods such as formal verification or static code analysis can be used to check the correctness of the code.

Second, you can adopt safe programming practices to avoid common security vulnerabilities. Finally, unauthorized access can be prevented by implementing access control on the SM, allowing only authorized entities to access the code.

Problems with limited PMP segment configuration and continuous memory requirements

Regarding the issues of limited PMP segment configuration and continuous memory requirements, this may indeed pose challenges to system deployment. This may require proper planning and optimization by system designers during implementation.
For example, system memory can be pre-partitioned and some areas reserved specifically for enclave creation. At the same time, situations where contiguous memory is required can be solved through pre-allocation or dynamic memory management technology.

Attackers achieve the purpose of DDOS attacks by creating unlimited enclaves

In Keystone, the creation and destruction of enclaves require the authorization of SM, and SM will track the status and resource usage of each enclave.

The design of Keystone itself does not provide a mechanism to prevent DDOS attacks. However, this risk of attack can be mitigated through other security mechanisms.

Resource limits: Prevent a single enclave or multiple enclaves from over-consuming resources by setting resource limits (such as memory, CPU, etc.) at the system level or enclave level. This limits the extent to which potential DDOS attackers can exploit the enclave's resources.

Access control: Limit communication and interaction between enclaves through strict access control mechanisms. This prevents malicious enclaves from flooding other enclaves or system resources with large amounts of requests or data flow.

Monitoring and detection: By monitoring the resource usage of the system in real time, abnormal traffic or behavior can be discovered in a timely manner. Once a potential DDOS attack is discovered, corresponding defensive measures can be taken, such as current limiting, isolation or terminating the operation of the malicious enclave.

implementation complexity

The Keystone solution requires the implementation and management of multiple enclaves and corresponding runtime environments, which requires complex memory management and life cycle management mechanisms. At the same time, ensuring isolation and security between all enclaves requires implementing sophisticated access control and authentication mechanisms.

limited resources

Although the Keystone solution can effectively isolate and protect enclaves, each enclave still requires an independent runtime environment and memory space. This can result in limited resource allocation, especially when memory and processor resources are limited.

Performance overhead

The implementation and management of Keystone solutions require certain performance overhead. For example, when creating and destroying enclaves, operations such as memory allocation and recycling, permission verification, and security monitoring are required. These overheads may affect the overall performance of the system.

so on

keyStone

If you want to learn about keystone, simply following the following process may be helpful to you:

Learn about Riscv

About chip architecture, interrupts and exceptions, and memory management

Learn about operating systems

process, process, driver

Theory: keystone

【Keystone: An Open Framework for Architecting
Trusted Execution Environments】

【Keystone-Enclave-An-Open-Source-Secure-Enclave-for-RISC-V】

Practice: Read the official guidance document [the best guidance book]

【Keystone-Getting-Started】

The emergence of a new technology must be to solve some pain points, but it will also bring some new pain points. I think this is why many projects require technical experts to make technology selections and achieve the stability and balance of a system through the combination of different technologies.

I hope it will be helpful to the friend who asked the question at 2023-10-31 10:16.