A method and apparatus for providing a trusted execution environment based on a trusted zone architecture

Abstract

The embodiments of the present specification provide a method and device for providing a trusted execution environment based on a trusted zone architecture. The trusted zone architecture comprises a secure world and a non-secure world; wherein the non-secure world runs a host operating system (OS) and the secure world runs a secure monitor, and the secure monitor comprises a memory protector and a sandbox manager. The method comprises: in response to a sandbox creation request, the host OS allocates a first memory segment for a first sandbox. Then, the memory protector performs a first update on a first page table used by a CPU core running the host OS, so that the updated first page table does not contain a mapping to the first memory segment. The memory protector further creates a second page table and sets it as a page table used by a CPU core running the first sandbox; wherein the second page table only contains a mapping to the first memory segment. The sandbox manager starts the first sandbox and runs a target application deployed by a third party therein, to provide a trusted execution environment for the target application.

Description

TECHNICAL FIELD

[0001] One or more embodiments of the present specification relate to a trusted zone technology, and in particular to a method, device and equipment for providing a trusted execution environment in a trusted zone architecture. BACKGROUND

[0002] With the rapid development and popularization of information technology, today's society has entered the era of big data, and data information in the network space is growing explosively every day. Measures need to be taken to strengthen data protection and privacy protection to promote the benign circulation and open sharing of data. In order to ensure the flowability and security of data at the same time, the concept of trusted execution environment is proposed. Trusted execution environment (TEE) builds a secure area in the central processing unit (CPU) through hardware-based encryption or isolation, protects the confidentiality and integrity of programs and data therein, and prevents the execution process of programs from being disturbed and destroyed by malicious software or attackers. It can provide a secure computing environment to protect sensitive data from being leaked or tampered with, and can also effectively prevent hacker attacks and malicious software intrusion. Trusted execution environment can provide hardware-level security protection to make data processing more secure and reliable.

[0003] At present, the widely used commercial trusted execution environment solutions mainly include Intel's Software Guard Extensions (SGX) and ARM's TrustZone, as well as AMD's Secure Encrypted Virtualization (SEV). These three trusted execution environment technologies have their own unique isolation technologies and security features, and have been applied to various scenarios. Among them, ARM TrustZone, i.e. trusted zone technology, is mainly applied to the field of mobile devices and embedded systems. Most of the smartphones and tablet computers on the market use ARM architecture processors, and ARM architecture processors have also been widely used in the fields of smart home, smart wear, industrial automation, etc.

[0004] While TrustZone provides applications with a trusted execution environment that helps improve security, as well as some basic security services, most applications cannot actually leverage TrustZone's security features because it imposes many limitations on third-party application developers. TrustZone is designed for vendors, not third-party application developers. If application developers want to put their sensitive code into TrustZone, they must work with the vendor. Furthermore, developers need sufficient prior knowledge and significant development effort; otherwise, vulnerabilities can be created, compromising the security of the isolated environment.

[0005] The rapid development of applications has reshaped the security landscape's demand for Trusted Execution Environments (TEEs). Research trends in TEEs are gradually shifting from previously vendor-controlled, closed TEEs to open TEEs, which can host trusted applications from multiple sources with independent tasks. In 2019, ARM proposed the Confidential Computing Architecture (CCA) to address this issue by providing developers with an isolated Realm. However, CCA requires complex virtualization technologies to isolate the Realm, resulting in significant performance and memory overhead, thus limiting its availability in resource-constrained mobile and embedded devices. Furthermore, CCA has not yet been widely deployed in the real world; immature specifications and compatibility issues between new and old hardware and software mean that widespread adoption may take several years. Therefore, there is an urgent need for more efficient and lightweight solutions to meet the security needs of third-party developers for mobile and embedded devices. Summary of the Invention

[0006] This specification describes one or more embodiments of a method and apparatus for providing a trusted execution environment based on a trusted zone architecture, which can efficiently and flexibly provide a trusted execution environment for third-party applications based on an existing trusted zone architecture.

[0007] According to the first aspect, a method for providing a trusted execution environment based on a trusted zone architecture is provided, wherein the trusted zone architecture includes a secure world and a non-secure world; wherein a host operating system (OS) runs in the non-secure world, and a security monitor runs in the secure world, the security monitor including a memory protector and a sandbox manager, and the method includes:

[0008] In response to the sandbox creation request, the host OS allocates a first memory segment for the first sandbox;

[0009] The memory protector performs a first update to a first page table used by a CPU core running the host OS, such that the updated first page table does not contain a mapping to the first memory segment;

[0010] The memory protector creates a second page table and sets it as the page table used by a CPU core running the first sandbox; wherein the second page table only contains a mapping to the first memory segment;

[0011] The sandbox manager starts the first sandbox, runs a target application deployed therein by a third party, and provides a trusted execution environment for the target application.

[0012] According to a second aspect, there is provided an apparatus for providing a trusted execution environment based on a trusted zone architecture, the trusted zone architecture comprising a secure world and an unsecure world; the apparatus comprising a host operating system (OS) running in the unsecure world, a secure monitor running in the secure world, the secure monitor comprising a memory protector and a sandbox manager, wherein:

[0013] The host OS is configured to allocate a first memory segment for a first sandbox in response to a sandbox creation request;

[0014] The memory protector is configured to perform a first update to a first page table used by a CPU core running the host OS, such that the updated first page table does not contain a mapping to the first memory segment;

[0015] The memory protector is further configured to create a second page table and set it as the page table used by a CPU core running the first sandbox; wherein the second page table only contains a mapping to the first memory segment;

[0016] The sandbox manager is configured to start the first sandbox, run a target application deployed therein by a third party, and provide a trusted execution environment for the target application.

[0017] According to a third aspect, there is provided a computing device comprising a memory and a plurality of processors, the memory storing executable code, the processors being configured to execute the executable code to implement the method of the first aspect.

[0018] In the scheme provided by the embodiments of the present specification, several sandboxes are created in the normal world for deploying third-party applications. The memory protector in the security monitor provides different memory page table views for different CPU cores running different environments, forcing the sandboxes to execute in isolation from the host operating system. Regarding the use of peripherals, the SMMU manager ensures that the host operating system cannot initiate a DMA attack using the peripherals by transferring the management of the SMMU to the security monitor, and the memory protector ensures exclusive access to the peripherals for different environments through page table settings. In this way, a trusted execution environment is provided for third-party applications in the form of a lightweight sandbox environment. BRIEF DESCRIPTION OF DRAWINGS

[0019] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings needed in the embodiment description. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0020] Figure 1 A structural schematic diagram of a system created based on a trusted zone architecture according to an embodiment is shown.

[0021] Figure 2 A method of providing a trusted execution environment based on a trusted zone architecture according to an embodiment is shown.

[0022] Figure 3 A memory page table view of each CPU core in an embodiment is shown.

[0023] Figure 4 A sandbox life cycle process according to an embodiment is shown. DETAILED DESCRIPTION

[0024] The scheme provided by the present specification will be described below in conjunction with the drawings.

[0025] Currently, although the TrustZone trusted zone technology used by the Armv8 platform can provide manufacturers with the service of embedding trusted applications in advance, it cannot open this service to third-party developers. The Armv9 confidential computing architecture, which provides a trusted execution environment service for developers, still needs time to be implemented.

[0026] In the existing Armv8 trusted execution environment work, in order to provide services for third-party developers, two isolation means are mainly adopted. One is the virtual machine scheme based on virtualization (such as vTZ, Twinvisor, PrivateZone, etc.). Although they provide an effective isolation environment through virtualization technology, the introduction of the virtual machine monitor brings additional workload, and the attack surface of the virtual machine monitor is larger. Once a virtual machine attacks the virtual machine monitor, it can read the entire memory. The second is an isolation scheme based on access control. For example, TrustICE protects the memory of the isolated environment through digital watermarking, but it cannot guarantee the normal operation of the original operating system while the isolated environment is running. Therefore, in general, in the widely used Armv8 trusted zone architecture, it is difficult to provide flexible and lightweight trusted execution environments for third-party applications.

[0027] To solve this problem, the present specification provides a technical concept and its implementation, wherein based on the trusted zone architecture, a lightweight sandbox environment is created in the non-safe world for deploying third-party applications developed by third-party developers. The isolation between sandboxes and between sandboxes and the original operating system is ensured by the security monitor in the safe world. Thus, the sandbox provides a trusted execution environment for third-party applications, ensuring the security of the execution process.

[0028] In order to describe the implementation of the above technical concept, first, the trusted zone architecture and some important components thereof are introduced.

[0029] I. Trusted Zone Technical Architecture

[0030] TrustZone is a security mechanism to implement a Trusted Execution Environment (TEE) on Arm platforms. The TrustZone architecture introduces a Secure World and a Normal World, thus creating isolated environments for code and data with different security requirements. The Normal World is used for the untrusted software stack, while the Secure World runs the trusted applications. Instructions executed by a processor enabled with TrustZone technology can be divided into four exception levels, EL0 to EL3, based on the privilege level, where EL0 represents the application level, EL1 is used for the operating system (OS). EL2 is optional, representing the hypervisor, and EL3 runs the Arm Trusted Firmware (ATF). These four levels can also be used to represent the permission levels of the running environment. In the TrustZone architecture, the CPU security state is divided into a Non-Secure state and a Secure state. From EL0 to EL2, the physical CPU can switch between the two security states, thus executing different tasks in different hardware isolation modes. For example, an untrusted OS can be executed in EL1 of the Non-Secure World, and a trusted OS can be executed in EL1 of the Secure World. EL3 always runs in the Secure World and provides comprehensive security-related services through a Secure Monitor Call (SMC). The Secure Monitor (SM) is trusted software in EL3, which is used to handle all SMC calls and has the permission to configure security-related hardware.

[0031] An important hardware component in the Arm architecture is the TrustZone Address Space Controller (TZASC). The TZASC acts as a filter between the bus master and the memory chip to ensure correct and legal access to the memory. The TZASC divides the memory into secure and non-secure regions, where access to the secure memory region is restricted to the secure state, and access to the non-secure memory region can be performed in any state. Recently, Arm has also introduced an identity-based filtering mechanism in the TZASC. With this mechanism, the TZASC assigns different non-secure access identifiers (NSAIDs) to each peripheral group and divides the memory into different regions. This mechanism requires that each divided region must be contiguous, and the number of regions is limited (a total of 9 regions). The Secure Monitor (SM) can configure variable access permissions for each NSAID.

[0032] II. System Memory Management Unit (SMMU)

[0033] As understood by those skilled in the art, the MMU is a hardware component between the memory and the CPU, and the CPU uses the MMU for memory access. When the host is connected with a peripheral device (referred to as a peripheral), the access control of the peripheral to the memory needs to use the system memory management unit (SMMU).

[0034] The SMMU is a hardware component for managing the direct memory access (DMA) of the peripheral to the host memory. The DMA allows the peripheral to directly transmit data to the host memory without the CPU, thereby improving the system performance. However, the peripheral cannot use the MMU to translate the discrete physical memory region into a continuous virtual memory region, and the peripheral usually needs a continuous physical memory space for the DMA operation. The SMMU provides the peripheral with the required address translation mechanism. When the peripheral initiates a DMA request, the SMMU is responsible for converting the discrete physical memory into a continuous virtual memory. The address translation is usually based on a page table, referred to as an SMMU page table, thereby supporting flexible DMA operation.

[0035] In the SMMUv3, each peripheral is allocated a stream ID, each stream ID corresponds to a stream table entry (STE) in a stream table, and the stream table entry stores the base address of the SMMU page table, so as to realize the memory management of multiple peripherals.

[0036] Based on the above introduction of the trusted zone architecture and related components, the implementation of the technical concept in the specification is described.

[0037] Figure 1 A structural schematic diagram of a system created based on the trusted zone architecture according to an embodiment is shown. In the specification, it is assumed that the system runs on a platform supporting the Arm TrustZone trusted zone architecture, and all exception levels work normally and do not occur overstep access. As shown in Figure 1 In the normal world, the host end runs, including the host operating system (OS) and the normal application running thereon. According to the concept in the embodiment of the specification, in order to provide a trusted execution environment for third-party applications, the scheme of the embodiment creates a plurality of sandbox environments in the normal world. The created sandbox is a confidential computing environment, which can protect the application (for example, the application deployed by the third party) running therein and can exclusively access the peripheral device when needed. In one implementation, the scheme of the embodiment can generate a plurality of parallel sandboxes, which are completely isolated from the host operating system and the application in the normal world.

[0038] In the embodiment scheme of the specification, it is assumed that all components of the secure world are completely trusted, and the host end is untrusted.

[0039] To create and manage the sandbox environment described above, the scheme of embodiments adds several additional software components in the original secure monitor of the TrustZone without any hardware modification. Specifically, the added software components include a memory protector, an SMMU manager, and a sandbox manager.

[0040] The memory protector is used to provide isolated memory access for the sandbox. Specifically, in the scheme of embodiments, the sandbox is forced to execute in isolation from the original environment (i.e. the host operating system and applications) by providing different memory page table views for different CPU cores running different environments. The SMMU manager ensures that the host operating system cannot initiate DMA attacks using peripherals by transferring the management of the SMMU to the secure monitor, and ensures exclusive access to peripherals for different environments. The sandbox manager manages the entire life cycle (creation, running, destruction) of the sandbox, and provides an interface through the secure monitor calling SMCs, so that third-party developers can quickly deploy their own sandbox to run applications.

[0041] The following describes a process of providing a trusted execution environment for third-party applications based on the architecture of Figure 1 The following describes a process of providing a trusted execution environment for third-party applications based on the architecture of Figure 2 A method of providing a trusted execution environment based on the TrustZone architecture according to an embodiment is shown. The method is performed based on the TrustZone architecture shown in Figure 1 The TrustZone architecture includes a secure world and a non-secure world, the non-secure world runs a host operating system OS, and the highest privilege level (EL03) of the secure world runs a secure monitor. The method includes the following steps.

[0042] In step S21, in response to a sandbox creation request, the host operating system OS of the non-secure world allocates a first memory segment for a first sandbox.

[0043] In an embodiment, two kernel modules CKM (Creation Kernel Module) and TKM (Termination Kernel Module) can be additionally deployed in the host OS, the CKM is used to create a sandbox, and the TKM is used to end or destroy a sandbox. When a user wants to create a sandbox, the above-mentioned CKM can be called to issue a sandbox creation request, and the creation process of the sandbox is started.

[0044] In response to a sandbox creation request of a user, the host OS (specifically, through the above-mentioned CKM) allocates a memory segment for the newly created sandbox. Since multiple sandboxes can be created in parallel in practice, the newly created sandbox is referred to as a first sandbox, and the memory segment allocated for it is referred to as a first memory segment.

[0045] Then, in step S22, the memory protector running in the secure monitor performs a first update of the first page table used by the CPU core running the host OS, such that the updated first page table does not contain a mapping to the first memory segment.

[0046] And, in step S23, the memory protector creates a second page table and sets it as the page table used by the CPU core running the first sandbox; wherein the second page table contains only a mapping to the first memory segment.

[0047] As can be seen from steps S22 and S23, the memory protector provides different versions of the page table view for the CPU core running the host OS and the CPU core running the first sandbox, such that the different CPU cores perform tasks based on different page tables. It is appreciated by those skilled in the art that the page table is used to provide a mapping from a virtual address to a physical address. In the first page table, the mapping to the first memory segment is removed, which makes the CPU core using the first page table unable to access this memory segment, i.e. the host OS is unable to access this memory segment. In the second page table, only the mapping to the first memory segment is contained. This means that the CPU core using the second page table can only access the first memory segment, i.e. the first sandbox can only access the first memory segment during its running. In this way, by configuring different page table views for different CPU cores, the isolation of memory access is achieved.

[0048] In the above scheme, the management of different page table views is placed in the secure monitor, rather than performing these operations in the virtual machine monitor. This is because the virtual machine monitor brings additional load and has a larger attack surface. By performing the page table management operations through the secure monitor, the virtual machine monitor can be excluded from the trusted base.

[0049] In one embodiment, the above-mentioned first page table and second page table directly record the mapping of virtual addresses to memory physical addresses, i.e. a one-level page table structure is adopted. However, more typically, in most Arm platforms, a two-level page table or two-stage translation mechanism is adopted for memory access control. Specifically, in the two-stage translation mechanism, memory access needs to go through two stages of page table query, i.e. first stage S-1 address translation and second stage S-2 address translation. In the S-1 address translation, the kernel controls a set of translation tables to translate the virtual address to an intermediate physical address IPA (Intermed iate Physica l Address). Then, through a set of page tables controlled by the virtual machine, referred to as the second stage page table S2PT (Stage-2 Page Table), the IPA is translated to the real physical address in turn.

[0050] In the case of adopting two-stage translation, the first page table and the second page table in steps S22 and S23 are both second stage page tables S2PT.

[0051] More specifically, setting the second page table as the page table used by the CPU core running the first sandbox can include setting a specific register of the CPU core running the first sandbox to store the base address of the second page table, so that the CPU core uses the second page table as the page table on which the program instructions are executed. In the case of the second stage page table, the specific register is the VTTBR_EL2 register.

[0052] On the basis of the memory isolation, at step S24, the sandbox manager starts the first sandbox to run the target application deployed by the third party in the first sandbox, and provides a trusted execution environment for the target application. Through the memory isolation provided by the multi-version page table, the host OS cannot access the data running in the first sandbox, and the sandbox and the host OS are isolated. In addition, since each sandbox can only read its own dedicated memory segment, the different sandboxes are also isolated. Thus, a trusted execution environment is provided for the target application.

[0053] According to an embodiment, the running of the first sandbox requires the use of a peripheral device. Under the Armv8 platform architecture, it is assumed that various peripherals have memory-mapped MMIO segments in the host memory. The CPU uses the corresponding peripheral device through the MMIO segment. The peripheral device performs direct memory access DMA to the host memory based on the aforementioned SMMU page table.

[0054] It is assumed that the first sandbox requests to use the first peripheral device. At this time, after creating the second page table, the security monitor (specifically, the memory protector) needs to update it, so that the updated second page table contains the mapping in the memory-mapped MMIO segment corresponding to the first peripheral device. In this way, the first sandbox can interact with the first peripheral device through the MMIO segment and use the first peripheral device. In addition, the security monitor also updates the SMMU page table corresponding to the first peripheral device through the SMMU manager, so that the SMMU page table only contains the mapping of the first memory segment. This ensures that the first peripheral device can only access the memory segment of the first sandbox.

[0055] In one case, before or when the first sandbox requests to use the first peripheral, the first peripheral is originally used by the host OS. At this time, after the host OS finishes the current processing for the first peripheral (e.g. finishes the current interrupt of the first peripheral), the security monitor updates the first page table (i.e. the page table used by the host OS) again through the memory protector, which includes clearing the mapping in the MMIO region of the first peripheral in the first page table. In this way, the host OS cannot continue to access the MMIO region and thus cannot continue to use the first peripheral. The first peripheral is thus "unbound" from the host OS. Then, the use of the first peripheral is transferred to the first sandbox by updating the second page table and the SMMU page table as described above. Through the above process, it is ensured that a peripheral is exclusively used by only one entity (the host OS or a sandbox) at a time. In this way, it is prevented that a peripheral illegally accesses the memory of a sandbox and avoids DMA attacks of a peripheral.

[0056] Figure 3 The memory page table view of each CPU core is shown in one embodiment. In the example of Figure 3 The Arm platform has 4 CPU cores, namely core 0, core 1, core 2 and core 3. At a certain time, the host OS (and normal applications thereon) runs in core 0 and core 1, sandbox 1 runs in core 2, and sandbox 2 runs in core 3. The platform has peripheral 1 and peripheral 2. It is assumed that the host OS uses peripheral 1 and sandbox 1 uses peripheral 2.

[0057] The entire physical memory space can be divided into multiple regions, including:

[0058] SMMIO region, for SMMU memory mapping;

[0059] PMMIO1 region, for memory mapping MMIO of peripheral 1;

[0060] PMMIO2 region, for memory mapping MMIO of peripheral 2;

[0061] NMem region, normal memory region of the normal world;

[0062] AMem1 region, memory region allocated to sandbox 1;

[0063] AMem2 region, memory region allocated to sandbox 2;

[0064] S2PT region, region for storing the second stage page table;

[0065] SMem region, memory region of the secure world.

[0066] Each CPU core accesses memory through the MMU page table. Figure 3The page table view of each CPU core is shown.

[0067] Core 0 and Core 1 run the host OS together, sharing the same page table view, i.e. the page table view shown in the first row, referred to as the first view. In this first view, only PMMIO1 and NMem are accessible, i.e. the CPU core running the host OS can interact with peripheral 1 via PMMIO1 and can run the host OS and normal applications therein based on normal memory segment NMem. Since sandbox 1 uses peripheral 2, the PMMIO2 segment corresponding to peripheral 2 has no mapping information in this first view and is not accessible. AMem1 and AMem2 are allocated to sandbox 1 and sandbox 2 respectively, and these two segments also have no mapping information in this first view and are not accessible. The other segments belong to the segments accessible by the secure world.

[0068] Core 2 runs sandbox 1 and has the second view shown in the second row. In this second view, only the mapping information of PMMIO2 and AMem1 segments is included, and only these two segments are accessible. That is, the CPU core running sandbox 1 can interact with peripheral 2 via PMMIO2 and can run sandbox 1 and applications therein based on the dedicated memory segment AMem1 allocated to sandbox 1. In this second view, the mapping information of other segments is cleared or masked, so that sandbox 1 cannot access other segments.

[0069] Core 3 runs sandbox 2 and has the third view shown in the third row. In this third view, only the mapping information of AMem2 segment is included, i.e. only this segment is accessible. Therefore, the CPU core corresponding to sandbox 2 can only run sandbox 2 and applications therein based on the dedicated memory segment AMem2 allocated to sandbox 2.

[0070] As for the SMMU page table used by the peripherals, peripheral 1 and peripheral 2 also have different page table views. Specifically, peripheral 1 is used by the host OS, so in its SMMU page table view, only the NMem segment corresponding to the host OS is accessible, and other segments (segments of sandbox 1 and sandbox 2) cannot be accessed due to lack of mapping information. Peripheral 2 is used by sandbox 1, so in its SMMU page table view, only the AMem1 segment corresponding to sandbox 1 is accessible, and other segments (segments of the host OS and sandbox 2) cannot be accessed.

[0071] From the perspective of each segment in the memory space, the PMMIO1 segment for peripheral 1 is only accessible by the host OS, the PMMIO2 segment for peripheral 2 is only accessible by sandbox 1, the normal memory segment NMem can be accessed by the host OS and peripheral 1, the AMem1 segment for sandbox 1 can be accessed by sandbox 1 and peripheral 2, and the AMem2 segment for sandbox 2 is only accessible by sandbox 2. Figure 3Different subject access is shown with different clipper head shapes.

[0072] From the above examples, it can be clearly seen that by providing different page table views for different CPU cores, memory isolation can be ensured between different running subjects (including the host OS and each sandbox). By only reflecting the mapping of the peripheral MMIO region in the page table view of a single entity, each peripheral can only be exclusively used by one subject at any time, and by configuring the SMMU page table for different peripherals, attacks on the sandbox through peripheral DMA are avoided.

[0073] It should be noted that although the TZASC can achieve memory partition management for a group of peripherals through the NSAID mechanism, this mechanism has some limitations. On the one hand, each partitioned region must be continuous, and on the other hand, the number of partitioned regions is limited. These limitations and requirements make it difficult for this mechanism to be applied to scenarios where multiple sandboxes and multiple peripherals are managed. Therefore, according to the above embodiment, an SMMU manager is introduced in the security monitor, and the SMMU page table of the peripheral is configured and modified through the SMMU manager. In this way, the use of the peripheral can be flexibly configured for the sandbox environment, and DMA attacks from the peripheral can be avoided.

[0074] The complete life cycle of a sandbox will be described in detail below with reference to a specific example. Figure 4 A sandbox life cycle process according to an embodiment is shown.

[0075] First is the system startup phase. According to the embodiment of the present specification, code for initializing the page table can be added to the startup code of the host operating system OS. In this way, when the system starts, the host OS will initialize its page table (the first page table in Figure 2 Typically, this page table is a second stage page table. Subsequently, in the security monitor, a series of SMMU initialization is performed, which includes initializing the flow table, the command queue, etc. Then, the security monitor configures the SMMU page table for each peripheral through the SMMU manager, i.e., the connected peripherals shown in Figure 4 The above operations are all completed by the host operating system by calling the corresponding SMC interface.

[0076] After the system startup is complete, the user can apply to create a sandbox by calling the kernel module for creating a sandbox, i.e., the aforementioned CKM module. The system enters the phase of creating a sandbox.

[0077] The phase of creating the sandbox specifically involves the following steps. First, the CKM requests the kernel (both belonging to the host OS) to allocate a memory AMem as the memory space of the sandbox and returns the start address of the memory. Then, the CKM loads the relevant data, including the kernel image, the memory file system, the device tree, etc. into the memory space AMem. Then the CKM initiates an SMC call to make the CPU core enter the EL3 level and run the security monitor SM. Then the sandbox manager in the security monitor SM verifies the integrity of the data and creates metadata for the sandbox, which includes the sandbox ID, the physical address space, the size, the context, and the base address of the page table for the sandbox. In addition, the memory protector in the security monitor removes the mapping relationship of the memory segment AMem allocated for the sandbox from the page table (the first page table) used by the host OS. In addition, the memory protector creates a new page table (the second page table) for the sandbox, which only contains the mapping relationship of the memory segment AMem. Figure 2

[0078] In the case where the sandbox uses a peripheral, the memory protector also needs to unbind the peripheral from the host OS and switch to the sandbox. Specifically, the memory protector removes the MMIO region corresponding to the peripheral from the page table used by the host OS, and adds the corresponding mapping in the page table used by the sandbox. In addition, the SMMU manager removes the mapping of the memory segment of the host OS from the SMMU page table of the peripheral, and adds the mapping of the memory segment AMem of the sandbox, so that the peripheral can only access the memory of the sandbox. At this point, the creation of the sandbox is completed, and the system returns to EL1, starts the sandbox kernel, and enters the sandbox running phase.

[0079] According to an embodiment, a customized Linux kernel can be used as the operating system of the sandbox. In this way, the developer can arbitrarily use the device drivers in the Linux ecosystem, which can be integrated as loadable kernel modules (LKMs) during compilation.

[0080] Correspondingly, in the running phase of the sandbox, the above-mentioned customized Linux can be started, and the peripheral drivers used by the sandbox have been compiled together with the Linux as kernel modules, which can make the developer conveniently use all the peripheral drivers in the current Linux ecosystem.

[0081] After the application in the sandbox is completed, it will enter the security monitor again through the SMC interface (specifically, the TKM in the host OS kernel sends an SMC to the security monitor) to enter the phase of ending the sandbox.

[0082] ​At the end / destroy phase of a sandbox, the sandbox manager in the security monitor cleans up the sandbox's memory and cache, destroys its metadata. Then it returns to the kernel module in the host operating system OS, which releases the previously allocated memory, and thus the life cycle of a sandbox ends.

[0083] Recalling the above process, in the solution of the above embodiment, instead of the virtualization way, only a number of light-weighted sandboxes are created in the normal world for deploying third-party applications. By providing different memory page table views for different CPU cores running different environments through the security monitor, the memory isolation between the sandbox and the host operating system, and between the sandboxes is enforced. The SMMU manager ensures that the host operating system cannot initiate DMA attacks through peripherals, and ensures exclusive access of different environments to peripherals, by transferring the management of the SMMU to the security monitor. In this way, a trusted execution environment is provided for third-party applications in the way of light-weighted sandbox environments.

[0084] On the other hand, corresponding to the above method process, the embodiments of the present specification also disclose an apparatus for providing a trusted execution environment based on a trusted zone architecture, the trusted zone architecture comprising a secure world and a non-secure world; the apparatus comprising a host operating system OS running in the non-secure world, a security monitor running in the secure world, the security monitor comprising a memory protector, a sandbox manager, wherein:

[0085] The host OS is configured to allocate a first memory segment for a first sandbox in response to a sandbox creation request;

[0086] The memory protector is configured to perform a first update on a first page table used by a CPU core running the host OS, so that the updated first page table does not contain a mapping to the first memory segment;

[0087] The memory protector is further configured to create a second page table and set it as the page table used by a CPU core running the first sandbox; wherein the second page table only contains a mapping to the first memory segment;

[0088] The sandbox manager is configured to start the first sandbox, run a target application deployed therein by a third party, and provide a trusted execution environment for the target application.

[0089] According to an embodiment, the security monitor further comprises an SMMU manager;

[0090] The memory protector is further configured to update the second page table in response to a first sandbox requesting to use a first peripheral, so that the updated second page table contains a mapping in a memory mapping MMIO segment corresponding to the first peripheral;

[0091] The SMMU manager is configured to update the SMMU page table corresponding to the first peripheral, so that the SMMU page table only contains the mapping of the first memory segment.

[0092] Further, in one embodiment, before or when the first sandbox requests to use the first peripheral, the first peripheral is used by the host OS; accordingly:

[0093] The memory manager is further configured to perform a second update on the first page table, the second update including clearing the mapping in the first page table in the MMIO segment corresponding to the first peripheral;

[0094] The SMMU manager is specifically configured to remove the mapping of the memory segment used by the host OS from the SMMU page table, and add the mapping of the first memory segment.

[0095] The specific execution process of the above device can refer to the description of the foregoing embodiments of the method. Figure 1 and Figure 2 The specific execution process of the above device can refer to the description of the foregoing embodiments of the method.

[0096] According to another aspect, an embodiment of the application also provides a computing device, including a memory and a plurality of processors, the memory stores executable code, and the processors execute the executable code to implement the method described above in conjunction with Figure 2 .

[0097] Those skilled in the art should be aware that the functions described in the above one or more examples can be implemented by hardware, software, firmware or any combination thereof. When implemented by software, these functions can be stored in a computer readable medium or transmitted as one or more instructions or codes on a computer readable medium.

[0098] The above specific embodiments further illustrate the purpose, technical solutions and beneficial effects of the application. It should be understood that the above description is only a specific embodiment of the application and is not intended to limit the protection scope of the application. Any modification, equivalent replacement, improvement, etc. made on the basis of the technical solutions of the application shall be included in the protection scope of the application.

Claims

1. A method of providing a trusted execution environment based on a trusted zone architecture, the trusted zone architecture comprising a secure world and a non-secure world. wherein a non-secure world runs a host operating system OS, and a secure world runs a secure monitor, the secure monitor comprising a memory protector and a sandbox manager, the method comprising: in response to a sandbox creation request, the host OS allocates a first memory segment for a first sandbox; the memory protector performs a first update to a first page table used by a CPU core running the host OS, such that the updated first page table does not contain a mapping to the first memory segment; the memory protector creates a second page table and sets it as the page table used by a CPU core running the first sandbox; wherein the second page table contains only a mapping to the first memory segment; the sandbox manager starts the first sandbox, running a target application deployed by a third party therein, providing a trusted execution environment for the target application.

2. The method of claim 1, wherein, the secure monitor further comprises an SMMU manager; the method further comprises: in response to the first sandbox requesting use of a first peripheral, the memory protector updates the second page table such that the updated second page table contains a mapping in a memory mapped I / O (MMIO) segment corresponding to the first peripheral; the SMMU manager updates an SMMU page table corresponding to the first peripheral such that the SMMU page table contains only a mapping to the first memory segment.

3. The method of claim 2, wherein the first peripheral is used by the host OS before or when the first sandbox requests use of the first peripheral; the method further comprises: the memory protector performs a second update to the first page table, the second update comprising clearing a mapping in the first page table in the MMIO segment corresponding to the first peripheral; the SMMU manager updates the SMMU page table corresponding to the first peripheral, comprising removing a mapping to a memory segment used by the host OS from the SMMU page table and adding a mapping to the first memory segment.

4. The method of claim 1, wherein, the first page table and the second page table are second stage page tables in a two-stage address translation mechanism.

5. The method of claim 1, wherein, the memory protector creates the second page table and sets it as the page table used by a CPU core running the first sandbox, comprising: the memory protector sets a target register in the CPU core running the first sandbox to store a start address of the second page table in memory.

6. The method of claim 1, wherein, before starting the first sandbox, the method further comprises: the sandbox manager initializes metadata of the first sandbox, comprising a sandbox number, a physical address of the first memory segment, and a base address of the second page table.

7. The method of claim 1, wherein, the host OS kernel comprises a create kernel module for creating a sandbox, and the sandbox creation request is issued by invoking the create kernel module.

8. The method of claim 1, wherein, the host OS kernel comprises an end kernel module for ending a sandbox; the method further comprises: in response to completion of execution of the target application, the end kernel module invokes the sandbox manager to clear sandbox data of the first sandbox; the host OS releases the first memory segment.

9. The method of claim 8, wherein, clearing sandbox data of the first sandbox comprises: the sandbox manager clears data in the first memory segment and destroys metadata of the first sandbox.

10. An apparatus for providing a trusted execution environment based on a trusted zone architecture, the trusted zone architecture comprising, a secure world and a non-secure world; the apparatus comprising, A host operating system OS running in a non-secure world, a secure monitor running in a secure world, the secure monitor comprising a memory protector, a sandbox manager, wherein: The host OS is configured to allocate a first memory segment for a first sandbox in response to a sandbox creation request; The memory protector is configured to make a first update to a first page table used by a CPU core running the host OS, such that the updated first page table does not contain a mapping to the first memory segment; The memory protector is further configured to create a second page table and set it as the page table used by a CPU core running the first sandbox; wherein the second page table only contains a mapping to the first memory segment; The sandbox manager is configured to start the first sandbox, run a target application deployed by a third party in the first sandbox, and provide a trusted execution environment for the target application.

11. The apparatus of claim 10, wherein, The secure monitor further comprises an SMMU manager; The memory protector is further configured to update the second page table in response to the first sandbox requesting to use a first peripheral, such that the updated second page table contains a mapping in a memory mapped I / O (MMIO) segment corresponding to the first peripheral; The SMMU manager is configured to make an update to an SMMU page table corresponding to the first peripheral, such that the SMMU page table only contains a mapping to the first memory segment.

12. The apparatus of claim 11, before or when the first sandbox requests to use the first peripheral, the first peripheral is used by the host OS; The memory protector is further configured to make a second update to the first page table, the second update comprising clearing a mapping in an MMIO segment corresponding to the first peripheral in the first page table; The SMMU manager is specifically configured to remove a mapping of a memory segment used by the host OS from the SMMU page table and add a mapping of the first memory segment.

13. A computing device comprising a memory having executable code stored therein and a number of processors, the processors, when executing the executable code, implement the method of any one of claims 1-9.

Images