Open source confidential computing platform: Penglai-OpenHarmony

Speaker | Du Dong

Review and compilation | Liao Tao

Typesetting and proofreading | Li Pingping

Guest introduction

Du Dong is an assistant researcher at Shanghai Jiao Tong University. Member of CCF, China Computer Federation, and member of ACM. His research interests include operating systems and architecture, serverless computing, and system security. Published/accepted many academic papers in famous international conferences and journals including ASPLOS, ISCA, OSDI, SOSP, ACM SoCC, TOCS, etc.

Content source

The First Open Atomic Open Source Foundation OpenHarmony Technology Summit - Security and Confidential Computing Sub-forum

video review

Video link:

Summit Review Issue 13 | Open Source Confidential Computing Platform: Penglai-OpenHarmony (Du Dong)_bilibili_bilibili

True text content

OpenHarmony empowers the Internet of Everything, and there is a need for security capabilities covering end to cloud. Penglai-OpenHarmony is an open source confidential computing platform that provides a trusted execution environment for OpenHarmony and empowers OpenHarmony security capabilities. So, what security enhancement work has Penglai-OpenHarmony done mainly, and what are the key technologies? Du Dong, an assistant researcher at Shanghai Jiao Tong University, a CCF member of the China Computer Federation, and an ACM member, brought some sharing to everyone at the first OpenHarmony Technology Summit.

01 ►Security challenges of Internet of Everything computing

When entering the new scenario of the Internet of Everything, what security risks and challenges exist, and what solutions are there?

Relying on the software itself to provide system security capabilities is one solution. However, it currently seems difficult to rely on technologies such as formal verification and type safety languages ​​to enhance system security. In the Internet of Everything scenario, the diversity of developers' backgrounds and abilities has doubled, and each of them relies on the development software itself to have different abilities to deal with security risks. Even if it can be achieved, more auxiliary tools may be needed to cooperate with developers to complete it.

Through the cooperation of software and hardware, relying on the security features provided by the hardware to strengthen the system, providing a trusted execution environment (TEE) is another feasible system security hardening solution. The trusted execution environment can effectively enhance the security capabilities of edge devices, such as memory isolation, I/O isolation, etc. Representative systems that rely on this solution for security hardening include Intel SGX, ARM TrustZone, and RISC-V Penglai or Keystone. At present, multiple security feature extensions and complete executable environment solutions have been released. Why do we need to customize a Penglai-OpenHarmony? Because the Internet of Everything scenario that OpenHarmony faces has different challenges and risks, they mainly include the following three aspects:

First, the Internet of Everything will lead to the need to face a complex hardware environment. In a heterogeneous hardware environment, it is very complicated to support the security features and requirements of OpenHarmony through a system. For example, there may be very small low-profile devices on the terminal side without page tables and memory isolation, but it is difficult for TEE to run in this configuration; for another example, in the scenario of higher-profile mobile phones, how can we make small devices without many basics Collaboration between a security-capable environment and a security-capable environment is also a big challenge.

Second, there are differences in software stacks. For cloud scenarios, the software is mainly based on the Linux kernel and virtual machine monitor, and components such as security OS can be introduced when necessary. For edge and IoT, the software stack is relatively simple, and the entire software may be built based on RTOS (such as OpenHarmony small kernel). stack. Therefore, how to make the two collaborate is a problem caused by software heterogeneity.

Third, the issue of localization of operating systems. For example, OpenHarmony has made some achievements in system security. How to ensure that its security capabilities are independently controllable? This is also a risk and challenge that needs to be considered.

Penglai-OpenHarmony can effectively solve the above problems. The picture below is the logo of Penglai-OpenHarmony. Discuss an interesting topic: Why is the new system named Penglai? Penglai is a fairy island in ancient Chinese mythology, which is surrounded by a black Styx River. We hope to provide a trusted execution environment that is isolated from the outside world. Things inside cannot come out and things outside cannot enter. On the one hand, it can ensure the security of internal confidential data, on the other hand, it can also prevent internal insecure factors from causing damage to the outside due to its special status.

02 ►Penglai -OpenHarmony

In the Penglai-OpenHarmony project, the Penglai trusted execution environment was developed and a universal solution was provided. The four main tasks currently being done are: (1) Propose a universal TEE architecture and interface for OpenHarmony, clarify the definition of the architecture and interface, and ensure that all subsequent TEEs can meet a certain abstraction or a certain core interface and be included in the OpenHarmony system Medium; (2) Based on the instruction set of RISC-V v1.10, Penglai security hardware extension was developed; (3) Develop the software layer of firmware layer (M-mode) Monitor and TEE SDK; (4) Provide MMU platform and There is no support for the two systems of the MMU platform.

2.1 ►► RISC-V Ecosystem

In the RISC-V ecosystem, developers can customize the design of hardware according to their own needs without worrying about copyright risks. If the characteristics of the hardware are good enough, they can also be incorporated into the official instruction set of RISC-V. As of 2022, RISC-V processor shipments will reach 10 billion, and Semico Research predicts that by 2025, RISC-V processor shipments will reach 80 billion, building a strong influence and ecosystem.

The sharp increase in RISC-V equipment has gradually formed the end-edge scenario of the Internet of Everything. Calista Redmond, CEO of RISC-V, predicts that by 2030, there will be 50 billion Internet and IoT devices that require security and customized processor support. Sufficient Multiple security features ensure that devices around you can meet computing and processor needs.

2.2 ►►Universal TEE architecture and interface for OpenHarmony

The common TEE architecture and interfaces for OpenHarmony are currently in draft status. As shown in the figure below, the architecture itself has nothing to do with RISC-V and does not involve specific architecture and features. We believe that the future OpenHarmony general TEE architecture and interface may include 4 layers: the bottom layer is the required hardware features, and the upper layer is the secure firmware; the trusted execution environment operating system is on the upper layer of the secure firmware; the top layer is the user application layer.

2.3 ►►Penglai -OpenHarmony: TEE system architecture under the RISC-V instruction set

The overall architecture of Penglai-OpenHarmony is shown in the figure below. Penglai-OpenHarmony is based on the OpenHarmony TEE reference architecture defined above; it innovates in hardware and proposes fine-grained lightweight isolation for heterogeneous scenarios of the Internet of Everything, and its security features are configurable and optional; in software It has also made innovations to meet the needs of multiple isolation, supporting secure OS and lightweight security applications; in addition, Penglai-OpenHarmony also supports OpenHarmony standard, small, lightweight and other configurations.

2.4 ►►Hardware heterogeneous response cases

In a scenario with heterogeneous hardware, how to achieve memory isolation? RISC-V divides the entire software and hardware into four layers: hardware layer, machine state, privileged state and user state. Among them, the hardware layer RISC-V supports different features and extensions; the machine state is the firmware layer, which has higher permissions than the privileged state, and is usually responsible for loading the operating system or implementing security features; the privileged state runs the operating system kernel and supports MMU and no -MMU platform; user mode runs various applications. The basic capabilities of the Trusted Execution Environment require memory isolation between the kernel and applications. The cloud edge scenario can be implemented through the memory management module (MMU)/page table, but IoT and edge RISC-V devices may not have an MMU. Between the kernel and applications Lack of isolation.

How to solve it? As shown in the figure below, a temporary solution is to run the kernel in the machine state. There is a set of hardware mechanism PMP in the machine state, and the kernel and user state can be isolated through PMP control. For example, when Linux does not have an MMU, it implements coarse-grained isolation through the PMP isolation mechanism of the RISC-V machine state. But then a problem arises. There will be machine-state contention between the machine-state firmware and the operating system. The problem is fundamentally caused by the different hardware conditions of edge devices. Such problems and risks often exist for small hardware.

In Penglai-OpenHarmony, a new RISC-V hardware extension is proposed: sPMP. sPMP is a lightweight memory isolation mechanism, which has the advantages of low hardware resource overhead and good memory access performance. What is the difference between having sPMP and not having sPMP? When there is no sPMP, the machine state has memory isolation, but there is no isolation between the user state and the OS state, making it difficult to run multiple APPs on it. With sPMP, the operating system can achieve isolation by relying on the sPMP register . Mechanical defects have been corrected.

2.5 ►►Software heterogeneous solutions

In software heterogeneous scenarios, isolation domains rely on the physical memory isolation mechanism of security hardware, such as the RISC-V segment isolation mechanism. The problem is that the isolation domain is strongly related to the hardware, such as PMP, and the final overall isolation number is positively correlated with the number of PMPs. The segment isolation mechanism itself is limited (no more than 16), and the 4 sets of PMP registers can only be divided into up to 4 domains now, as shown in the figure.

So how does a Trusted Execution Environment provide scalable isolation domains? In cloud scenarios, software can be used to isolate more isolation domains, but this is not applicable at the edge due to insufficient memory resources. To address this problem, Penglai-OpenHarmony provides a sliding window isolation domain design, which enables a group of PMPs to (logically) protect multiple isolation domains and slide the actual protection scope during context switching. As shown in the figure, when isolation domain-1 is executed, PMP-2 can shrink the isolation domain to the range of isolation domain-1; conversely, when isolation domain-2 is executed, PMP-2 can also shrink the isolation domain. to the range of isolation domain-2. In this way, it can be ensured that when each isolation domain is executed, its memory protection range is accurate.

03 ►Summary _

In general, the Penglai-OpenHarmony project provides a security cornerstone for OpenHarmony under the RISC-V architecture, supporting OpenHarmony's multi-scenario security requirements for the Internet of Everything. Welcome everyone to continue to pay attention to the Penglai-OpenHarmony project, and we also look forward to more developers joining in to jointly empower OpenHarmony's secure base.

Guess you like

Origin blog.csdn.net/OpenHarmony_dev/article/details/132731841