TEE OS starting method and device and storage medium

Abstract

The embodiment of the invention provides a TEE OS starting method and device and a storage medium. The method comprises the following steps: after cold boot is completed based on BIOS firmware, in a user mode of REE, initiating an SMC message used for indicating TEE OS boot to a runtime component in trusted basic firmware; moreover, the mirror image compiled for the TEE OS in the user mode of the REE can be loaded to the specified memory address by the runtime component, so that the mirror image loaded to the specified memory address can be triggered to run in the TEE by means of the runtime component under the indication of the SMC message, thereby starting the TEE OS. Therefore, the loading of the TEE OS mirror image can be realized through the mutual cooperation of the user state of the REE and the runtime component in the trusted basic firmware without depending on BIOS firmware, so that the maintainability of the TEE OS can be effectively improved.

Description

Technical Field

[0001] This application relates to the field of trusted computing technology, and in particular, to a method, device, and storage medium for starting a TEE OS. Background Art

[0002] TEE, full name Trusted Execution Environment, refers to a secure isolation area constructed by software and hardware methods on a computing platform, so as to ensure that the life cycles of data and code in this secure isolation area are protected in terms of confidentiality and integrity. TEE OS (Trusted Execution Environment - Operating System) refers to an operating system running in the trusted execution environment.

[0003] Currently, the TEE OS image required during the startup process of TEE OS needs to be packaged into the firmware image of BIOS (Basic Input Output System), and pre-burned into the Flash space of the flash memory together with the BIOS firmware image. Therefore, the startup of TEE OS depends on the BIOS firmware. And this TEE OS startup method that depends on the BIOS firmware results in poor maintainability of TEE OS and cannot meet the flexible and variable usage requirements of users for TEE OS. Summary of the Invention

[0004] Multiple aspects of this application provide a method, device, and storage medium for starting a TEE OS to improve the maintainability of TEE OS.

[0005] An embodiment of this application provides a method for starting a TEE OS, including:

[0006] In the user mode of the regular execution environment REE, initiate a secure mode call SMC message for indicating the startup of TEE OS to the runtime component in the trusted base firmware;

[0007] Use the runtime component to load the image compiled for the TEE OS in the user mode of the REE to a specified memory address;

[0008] Use the runtime component to trigger the running of the image in the specified memory address in the trusted execution environment TEE according to the SMC message to start the TEE OS.

[0009] An embodiment of this application also provides a computing device, including a memory and a processor;

[0010] The memory is used to store one or more computer instructions;

[0011] The processor is coupled to the memory and is configured to execute the one or more computer instructions for performing the foregoing method for starting the TEE OS.

[0012] An embodiment of the present application further provides a computer-readable storage medium storing computer instructions, which, when executed by one or more processors, cause the one or more processors to execute the foregoing method for starting the TEE OS.

[0013] In an embodiment of the present application, after a cold start is completed based on the BIOS firmware, a secure mode call SMC message for instructing to start the TEE OS can be initiated in the user mode of the regular execution environment REE to the runtime component in the trusted base firmware; moreover, the runtime component can load the image compiled for the TEE OS in the user mode of the REE to a specified memory address. Based on this, under the indication of the SMC message, the runtime component can be used to trigger the running of the image loaded to the specified memory address in the trusted execution environment TEE, thereby starting the TEE OS. Accordingly, in the embodiment of the present application, the loading of the TEE OS image can be achieved through the cooperation between the user mode of the REE and the runtime component in the trusted base firmware, and there is no longer a need to rely on the BIOS firmware. Therefore, without restarting the BIOS firmware, the TEE OS can be started online on demand, which can effectively improve the maintainability of the TEE OS. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation to the present application. In the drawings:

[0015] Figure 1 is a schematic diagram of the startup logic of an exemplary existing TEE OS;

[0016] Figure 2 is a schematic flowchart of a method for starting a TEE OS provided by an exemplary embodiment of the present application;

[0017] Figure 3 is a schematic diagram of the logic of a method for starting a TEE OS provided by an exemplary embodiment of the present application;

[0018] Figure 4 is a schematic flowchart of another method for starting a TEE OS provided by an exemplary embodiment of the present application;

[0019] Figure 5 is a schematic diagram of the logic of yet another method for starting a TEE OS provided by an exemplary embodiment of the present application;

[0020] Figure 6 A schematic diagram of an exemplary boot process corresponding to a main core provided for an exemplary embodiment of the present application;

[0021] Figure 7 A schematic structural diagram of a computing device provided for another exemplary embodiment of the present application. Detailed implementation manners

[0022] To make the objectives, technical solutions, and advantages of the present application clearer, the technical solutions of the present application will be clearly and completely described below in conjunction with the specific embodiments of the present application and the corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

[0023] Before starting to describe the technical solutions provided by the embodiments of the present application, several technical concepts involved in the present application are briefly described as follows:

[0024] BIOS: Basic Input / Output System, which is a program used to start a computer system after a computer microprocessor is powered on. It also manages the data flow between a computer operating system and attached devices (such as hard disks, video adapters, keyboards, mice, and printers).

[0025] TEE: Trusted Execution Environment, a secure area in a processor that helps protect the code and data loaded therein in terms of confidentiality and integrity.

[0026] TEE OS (Trusted Execution Environment-Operating System) refers to the operating system running in the trusted execution environment TEE.

[0027] REE: Rich Execution Environment, a conventional execution environment. It includes a conventional operating system and its combination with the rest of the execution environment, and does not have sufficient security to meet the tasks required by the device.

[0028] CA: Client Application, a conventional application. An application that usually runs in the REE environment is simply referred to as CA.

[0029] TA: Trusted Application, a trusted application. An application that usually runs in the TEE environment is simply referred to as TA.

[0030] Hafnium: A Secure Partition Manager (SPM) used to implement the Armv8.4-AS-EL2 extension, which allows multiple isolated secure partitions (SPs) to run at the S-EL1 level.

[0031] SMC: Secure Monitor Call. It is used to enter the secure mode and execute the Secure Monitor (SM) kernel service call. This instruction can only be executed in privileged mode.

[0032] ATF: Trusted Firmware-A, a kind of trusted base firmware. It is a reference implementation of the secure world software for the Arm A-profile architecture (Armv8-A and Armv7-A), including the secure monitor at the EL3 level.

[0033] Runtime, a runtime component in ATF, is used to support the interaction between TAs in TEE and CAs in REE in the runtime state.

[0034] FF-A: Firmware Framework-A profile, a kind of firmware framework.

[0035] SPMD: A scheduler deployed in the runtime component of ATF under the FF-A specification for scheduling the Secure Partition Manager (SPM).

[0036] As introduced in the background art, currently, the startup of the TEE OS depends on the BIOS firmware. That is, during the cold startup based on the BIOS firmware, the startup of the TEE OS is one of the links in the cold startup process. Figure 1 It is a schematic diagram of the startup logic of an exemplary existing TEE OS. In the existing startup scheme, when there are multiple processing cores (cores) in the CPU, usually the main core and slave cores are specified. Refer to Figure 1 , the cold startup process can be generally divided into two stages: The first stage is the power-on startup of the main core. At this time, the other slave cores are not powered on. For the main core, each component can be loaded one by one according to the secure startup link (consisting of Figure 1 the SCP ROM, BL2, BL31, etc. in [reference], which is an existing scheme and will not be elaborated here) based on the BIOS firmware ( Figure 1As shown in the figure (UEFI in this case), the REE completes the startup of the operating system kernel (OS kernel) in the REE to complete the core activation process of the main core. After that, it can enter the second stage. After the main core completes the initialization process of the main modules of the OS kernel, the OS kernel can follow the relevant configuration information obtained from the BIOS firmware and call the PSCI interface (Power State Coordination Interface, a standard interface for handling multi-core processors) to enter the runtime component of the Trusted Firmware - ATF, power on the secondary cores, then enter the startup entry of the secondary cores, and complete Figure 1 the initialization of Hafnium and TEE OS in Figure 1 to complete the core activation process of the secondary cores. Additionally, when there are multiple secondary cores, the OS kernel will repeatedly execute the above - mentioned core activation actions for the secondary cores to complete the core activation work of other secondary cores.

[0037] Based on Figure 1 the cold - start process shown, the startup of the TEE OS is interspersed in the cold - start process. And as introduced in the background technology, the image of the TEE OS needs to be burned into the BIOS firmware image. Therefore, the existing TEE OS startup solution has a strong dependence on the BIOS firmware.

[0038] Obviously, this will lead to poor maintainability of the TEE OS. The poor maintainability here can be understood as the inflexible startup timing of the TEE OS or the inability to re - compile the image after startup, etc. Therefore, the existing TEE OS startup solution cannot meet the flexible usage requirements of users for the TEE OS. In addition, since the image of the TEE OS needs to be packaged in the BIOS firmware image, and the BIOS firmware image is burned into the flash memory space, when multiple TEE OSs need to be deployed in the processor, the size of the BIOS firmware image will continuously increase with the increase in the number of TEE OSs, which brings relatively serious storage pressure to the BIOS flash space and may even exceed the storage limit of the flash space. Moreover, the startup of the TEE OS will also cause the cold - start latency of the computer to become longer. Due to the large dependence on the BIOS firmware, when the number of TEE OSs increases continuously, the cold - start latency of the computer may even reach the hour level, resulting in poor user experience.

[0039] Therefore, the embodiments of this application propose a new TEE OS startup solution that supports on - demand online startup of the TEE OS without relying on the BIOS firmware.

[0040] The following will detail the technical solutions provided by the embodiments of this application in conjunction with the accompanying drawings.

[0041] Figure 2 Schematic flow chart of a method for starting a TEE OS provided by an exemplary embodiment of the present application. Figure 3 Logical schematic diagram of a method for starting a TEE OS provided by an exemplary embodiment of the present application. Refer to Figure 2 , the method may include:

[0042] Step 100, in the user mode of the regular execution environment REE, initiate a secure mode call SMC message for indicating the start of the TEE OS to the runtime component in the trusted base firmware;

[0043] Step 101, use the runtime component to load the image compiled for the TEE OS in the user mode of the REE to a specified memory address;

[0044] Step 102, use the runtime component to trigger the image in the specified memory address to run in the trusted execution environment TEE according to the SMC message to start the TEE OS.

[0045] The method for starting the TEE OS provided by this embodiment can be applied to various scenarios that require the use of the TEE OS to support the on-demand online start of the TEE OS in the scenario. This embodiment does not limit the application scenario.

[0046] It should be understood that the method for starting the TEE OS provided by this embodiment is implemented after completing the conventional cold start process mentioned above. Among them, for the TEE OS that is expected to be started according to the method for starting the TEE OS provided by this embodiment, it is no longer necessary to package the corresponding image into the BIOS firmware image, nor is it necessary to burn its corresponding image into the flash. That is to say, in the conventional cold start process mentioned above, it is no longer necessary to start these TEE OSs without burned images, but after completing the cold start process, the on-demand online start of these TEE OSs without burned images can be performed according to the start method provided by this embodiment. Therefore, the method for starting the TEE OS provided by this embodiment can be independent after the conventional cold start process, no longer relying on the BIOS firmware, and no longer occupying the flash space and working delay in the cold start process, which makes the cold start process more efficient and the flash storage pressure smaller.

[0047] It should be noted that this embodiment does not prohibit the startup of the TEE OS during the cold start process. That is to say, some TEE OSs that are expected to be started up immediately after power-on can still be started according to the traditional cold start method, and this embodiment does not interfere with the cold start process of these TEE OSs. However, for these TEE OSs that are started up immediately after power-on, the version upgrade can be achieved through the TEE OS startup method provided in this embodiment. In other words, the TEE OS startup method provided in this embodiment supports the online restart of the already started TEE OS, and thus supports the online upgrade of the TEE OS.

[0048] Referring to Figure 3 , in this embodiment, two execution environments are provided in the computer: TEE and REE. It should be understood that these two execution environments have been constructed during the aforementioned cold start process. In practical applications, technologies such as Trustzone can be used to support the construction of these two execution environments. Taking TrustZone as an example, it can provide two spaces: Secure space and Non-Secure space, which respectively correspond to the two execution environments of TEE and REE, and perform hardware-enforced isolation between the two execution environments, and support the switching of the CPU of the computer between working modes to work in the two execution environments as needed. Exemplarily, the switching of the working mode can be enabled by switching the Secure Configuration Register system register. The last 1 bit of this register is 0, indicating that the current CPU is in the secure mode. And the Trustzone technology also supports configuring the system resources into a secure state. By operating the relevant registers, resources such as the system bus, memory, DMA, and cache can be configured into a secure state. After being configured into a secure state, the program CA running in the REE cannot access these hardware resources, thereby achieving hardware-enforced isolation between the two execution environments. The construction process of the two execution environments will not be described in more detail here.

[0049] In this way, in this embodiment, after the cold start process is completed, the CPU in the computer enters the runtime, and during the runtime, it supports dividing the working state into two types: secure state and non-secure state. When the CPU is in the secure state, it can only run the code on the TEE side and has access rights to the address space on the REE side. When the CPU is in the non-secure state, it can only run the code on the REE side and can only obtain specific data and call specific functions on the TEE side through pre-defined interfaces.

[0050] In addition, referring to Figure 3, on the basis of constructing the above two execution environments of TEE and REE, in this embodiment, a trusted base firmware is further introduced to further ensure the trustworthiness of the TEE OS startup. Exemplarily, the trusted base firmware in this embodiment may adopt ATF (ARM Trusted Firmware). Based on ATF, while maintaining the Secure space and Non-Secure space provided by Trustzone, four exception levels from EL0 (Exception level 0) to EL3 can be divided to further ensure the security during the startup and runtime phases. Among them, the foregoing CA and TA can run at EL0, the foregoing OSkernel and the TEE OS after startup in this embodiment can run at EL1, and BISO can run at EL2.

[0051] Reference Figure 3 , in this embodiment, it is proposed to use the runtime components in the trusted base firmware to support the startup method of the TEE OS in this embodiment. Among them, this runtime component runs at the foregoing EL3 and is always located in the Secure space, which can effectively ensure the security and trustworthiness of the startup method of the TEE OS in this embodiment.

[0052] On this basis, reference Figure 2 , in step 100, a secure mode call SMC message for indicating the loading of the TEE OS can be initiated in the user mode of the regular execution environment REE to the runtime components in the trusted base firmware.

[0053] In this embodiment, a custom CA (regular application) can be deployed in the user mode of REE, and the processing logic that needs to be performed in the user mode of REE can be implemented by this custom CA. Of course, in this embodiment, other types of logical carriers can also be used as the method execution subject in the user mode of REE. For example, in addition to the foregoing custom CA, custom scripts or other types of custom programs can also be used. This embodiment does not limit the form of the method execution subject deployed in the user mode of REE. Hereinafter, when it is necessary to mention the method execution subject in the user mode of REE, the custom CA will be used as an example. Here, in step 100, this custom CA can send an SMC message to the runtime components in the trusted base firmware.

[0054] Among them, as the definition of SMC provided above, the SMC message initiated in the user mode of REE is a message for secure mode call. Here, it can be understood that by sending the SMC message from the user mode of REE to the runtime components in the trusted base firmware, the control right of the CPU is transferred from the user mode of REE to the runtime components in the trusted base firmware.

[0055] In addition, in this embodiment, the SMC message initiated in the user space of the REE is used to indicate the startup of the TEE OS. In practical applications, the SMC message initiated in the user space of the REE can be used to indicate the startup of a single TEE OS or the startup of multiple TEE OSs simultaneously. In the latter case, the runtime component can be triggered to automatically repeat the startup logic for a single TEE OS. For ease of understanding, in the following text, the startup logic will be described from the perspective of a single TEE OS.

[0056] Continuing to refer to Figure 2 and Figure 3 , in step 101, the runtime component can be used to load the image compiled for the TEE OS in the user space of the REE to the specified memory address. There are two aspects of processing logic here:

[0057] On the one hand, in this embodiment, the image for the TEE OS can be compiled in the user space of the REE. In practical applications, the aforementioned custom CA can complete the image compilation work. Based on this, in this embodiment, it is possible to support compiling the image for the TEE OS on demand according to the flexible usage requirements of the user for the TEE OS, and it is also possible to support recompiling the image for the TEE OS. That is to say, in this embodiment, the image for a single TEE OS can be compiled multiple times in the user space of the REE, and during the execution of step 101, the latest compiled image for the TEE OS is used. Therefore, in this embodiment, the version update of the TEE OS can be achieved by switching the image version used when the TEE OS starts up. In practical applications, when the image of a certain TEE OS is recompiled in the user space of the REE, the TEE OS can be restarted according to the TEE OS startup method provided in this embodiment to achieve version upgrade.

[0058] In this embodiment, the image compiled for the TEE OS in the user state of the REE can be stored in a specified directory in the user state of the REE. On this basis, in the user state of the REE in this embodiment, the aforementioned custom CA can also call the custom interface provided by the TEE driver to obtain the image compiled for the TEE OS from the specified directory in the user state of the REE by using this custom interface, and store the image in a specified buffer area; then, configure the address of the buffer area into the second register; where the second register is the address transfer medium of the buffer area agreed upon between the TEE driver and the runtime component. In practical applications, a custom interface function ffa_tos_load can be added to the TEE driver. In the user state of the REE, this custom interface function can be called, and the function of this custom interface function can be defined as: calling the Linux firmware subsystem interface function request_firmware to obtain the newly compiled TEE OS image in the specified directory of the OS file system, applying for a buffer area buffer to temporarily store the image, and finally writing the buffer address together with the Function ID, etc. into the second register.

[0059] On the other hand, the runtime component can obtain the image compiled for the TEE OS in the user state of the REE and load the image into the specified memory address.

[0060] Among them, a specified memory address can be pre-configured for the TEE OS image in the trusted base firmware. In this way, in step 101, the runtime component can store the image of the TEE OS into the specified memory address according to the specification in the trusted base firmware. In the subsequent processing logic, this specification in the trusted base firmware will also be followed, so as to ensure that the image can be accurately found in the TEE and then the image can be run.

[0061] Continuing with the second register in the previous text, in practical applications, the runtime component can query the address of the buffer area where the TEE OS image is located from the second register, so that the TEE OS image can be read from this buffer area, and then the read TEE OS image can be transferred to the specified memory address.

[0062] It should be noted that the image loading link in step 101 mentioned above can be completed in advance before step 100, that is, the image compilation and loading can be completed in advance before the TEE OS enters the startup process; of course, this link can also be executed after step 100, that is, under the trigger of the SMC message initiated in step 100, the TEE OS image is loaded again. Both loading times are acceptable, and this embodiment does not limit this, as long as it can ensure that the image loading of the TEE OS has been correctly completed before step 102.

[0063] In addition, in this embodiment, after the runtime component reads the mirror image compiled by the REE's user mode for the TEE OS, it can also perform signature verification on the read mirror image; when it is determined that the mirror image passes the signature verification, the operation of loading the mirror image to the specified memory address is then executed. In this embodiment, the implementation method of signature verification is not limited. In an exemplary solution, the public key of the TEE can be stored in the hardware trusted root, and in the user mode of the REE, the TEE OS mirror image can be encrypted with the TEE private key. In this way, since the runtime component can perform signature verification on the read TEE OS with the TEE public key. Since the TEE public key can only be known in the TEE, the security of the TEE public key can be guaranteed, and thus the credibility of the signature verification can be guaranteed. In this embodiment, adding a signature verification link for the TEE OS mirror image before mirror image loading can effectively guarantee the security and credibility of the TEE OS mirror image, and avoid introducing security problems due to the participation of the REE's user mode in the startup process of the TEE OS.

[0064] It can be seen that in this embodiment, with the mutual cooperation of the runtime component in the user mode of the REE and the trusted basic firmware, it is possible to support compiling the mirror image on demand for the TEE OS in the user mode of the REE, and successfully load the compiled mirror image into the mirror image reading address (i.e., the specified memory address mentioned above) default at the startup of the TEE OS. The entire process of mirror image loading does not need to rely on the BIOS firmware at all and is completely separated from the aforementioned cold startup process.

[0065] Therefore, in this embodiment, without restarting the BIOS firmware, it is possible to achieve on-demand online compilation and loading of the TEE OS mirror image. This can provide a maintainable startup basis for the startup of the TEE OS.

[0066] Continue to refer to Figure 2 and Figure 3 , based on the loaded TEE OS mirror image, in step 102, under the guidance of the runtime component, the mirror image at the specified memory address can be run in the trusted execution environment TEE to start the required TEE OS.

[0067] Since the image of the TEE OS has been stored at the specified memory address as agreed, during runtime, the component only needs to boot the startup process as agreed to enter the runtime entry of the TEE OS image, and then start running the TEE OS image in the trusted execution environment (TEE) without obstacles to complete the startup of the TEE OS. In this embodiment, the boot process for completing step 102 can be defined in the code of the trusted base firmware. In this embodiment, the specific boot process is not limited. In practical applications, the boot process can be defined as needed. In this embodiment, it is only necessary to ensure that the boot process can trigger the running of the image at the specified memory address in the trusted execution environment (TEE). An exemplary boot process will be provided later and will not be elaborated here.

[0068] In summary, in this embodiment, after a cold start is completed based on the BIOS firmware, a secure mode call (SMC) message for indicating the startup of the TEE OS can be initiated in the user mode of the regular execution environment (REE) to the runtime component in the trusted base firmware. Moreover, the runtime component can load the image compiled for the TEE OS in the user mode of the REE to the specified memory address. Based on this, under the indication of the SMC message, the runtime component can be used to trigger the running of the image that has been loaded to the specified memory address in the trusted execution environment (TEE), thereby starting the TEE OS. Accordingly, in the embodiment of this application, the loading of the TEE OS image can be achieved through the cooperation between the user mode of the REE and the runtime component in the trusted base firmware, and there is no longer a need to rely on the BIOS firmware. Therefore, the TEE OS can be started online as needed without restarting the BIOS firmware, which can effectively improve the maintainability of the TEE OS.

[0069] In addition to improving the maintainability of the TEE OS, for the solution of starting the TEE OS online as needed provided in this embodiment, the startup latency of the TEE OS can reach the second level. Compared with the startup latency at the hour level in the traditional startup scheme, the startup efficiency of the TEE OS can be effectively improved in this embodiment. Moreover, in this embodiment, the online-started TEE OS no longer needs to occupy the flash space of the BIOS. Therefore, the storage pressure on the flash space can be effectively reduced.

[0070] Figure 4 It is a schematic flowchart of another method for starting the TEE OS provided in an exemplary embodiment of this application. Refer to Figure 4 , this method may include:

[0071] Step 400: In the user mode of the regular execution environment (REE), initiate a secure mode call (SMC) message for indicating the startup of the TEE OS to the runtime component in the trusted base firmware;

[0072] Step 401: In the user mode of the REE, initiate an SMC message for transmitting resource requirements to the runtime component;

[0073] Step 402: Use the runtime component to compile a resource configuration file adapted to the resource requirements for the TEE OS, so that the runtime component allocates resources for the TEE OS according to the resource configuration file;

[0074] Step 403: Use the runtime component to load the image compiled for the TEE OS in the user mode of the REE to a specified memory address;

[0075] Step 404: Use the runtime component to trigger the image in the specified memory address to run in the trusted execution environment (TEE) according to the SMC message to start the TEE OS.

[0076] Among them, Step 400 and Steps 403-404 can refer to the descriptions in the foregoing embodiments. In this embodiment, a further improved method for starting the TEE OS is provided based on Steps 401 and 402.

[0077] The inventor found in the research process that in the traditional cold start process, during the startup process of the TEE OS, in addition to relying on the BIOS firmware to load the image of the TEE OS, BIOS support is also required for resource allocation for the TEE OS. This resource allocation method relying on the BIOS makes the resource configuration of the TEE OS too rigid to support elastic resource scaling, and thus cannot meet the flexible and variable resource occupancy requirements of users for the TEE OS.

[0078] Therefore, in this embodiment, a technical concept of on-demand online resource configuration is proposed to further improve the maintainability of the TEE OS.

[0079] Reference Figure 4 , in Step 401, in the user mode of the REE, an SMC message for transmitting resource requirements can be initiated to the runtime component. Among them, the SMC message for transmitting resource requirements may include resource configuration parameters for describing the resource specifications to be occupied. The resource configuration parameters may include, but are not limited to, the size of the memory space, the number of physical cores, or the list of IO devices, etc., and no more examples are given here. In this way, by initiating an SMC message for transmitting resource requirements in the user mode of the REE, the foregoing resource configuration parameters can be transmitted to the runtime component.

[0080] Continue to refer to Figure 4, in step 402, in response to the SMC message for transmitting resource requirements initiated in the user mode of the REE, the runtime component can compile a resource configuration file for the corresponding TEE OS. In this embodiment, it is proposed that the runtime component is responsible for configuring resources for the TEE OS based on the resource configuration file. As mentioned above, the runtime component runs at the EL3 level. Therefore, the runtime component has access to the entire hardware resources in the computer and can be used for scheduling hardware resources. In practical applications, the SPMD deployed in the runtime component can be used to implement this resource configuration process, but this embodiment is not limited to this.

[0081] In this way, in this embodiment, the resource configuration parameters of the TEE OS can be adjusted on demand in the user mode of the REE, and by sending an SMC message to the runtime component, the runtime component can be driven to compile a resource configuration file for the TEE OS online. Therefore, in this embodiment, the elastic resource configuration of the TEE OS can be supported. When the resources allocated to the TEE OS are excessive, the resource configuration parameters of the TEE OS can be adjusted in the user mode of the REE, and the adjusted resource configuration parameters can be transmitted to the runtime component through the SMC message. Then, the runtime component can update the corresponding resource configuration file for the TEE OS. On this basis, the TEE OS can be restarted to make the updated resource configuration file take effect, so as to allocate fewer resources to the TEE OS to solve the problem of resource waste. When the resources allocated to the TEE OS are insufficient, the technical concept of on-demand online resource configuration provided in this embodiment can also be used to allocate more resources to the TEE OS to improve the performance of the TEE OS.

[0082] Since this embodiment supports multiple compilations of the resource configuration parameters of the TEE OS, for the runtime component in this embodiment, if there is already a resource configuration file corresponding to the TEE OS, the resource configuration file corresponding to the TEE OS can be modified according to the SMC message for transmitting resource requirements received this time, so as to realize the update of the resource configuration file.

[0083] In addition, it is worth emphasizing that in this embodiment, on-demand online compilation of resource configuration parameters and images for the TEE OS is supported in the user mode of the REE. The inventor found in the research process that part of the configuration content related to resource configuration may be included in the image of the TEE OS. Therefore, in this embodiment, if the resource configuration parameters of the TEE OS are adjusted in the user mode of the REE, the relevant configuration content in the TEE OS image should be adjusted synchronously. That is, the resource configuration file in the runtime component is consistent with the resource requirements described in the image compiled for the TEE OS.

[0084] In summary, in this embodiment, it is possible to support configuring resource parameters for online compilation of the TEE OS in the user space of the REE, and before loading the image of the TEE OS to the specified memory address, the compiled resource configuration parameters can be passed to the runtime component for the runtime component to compile the resource configuration file for the TEE OS. In this way, the runtime component can dynamically allocate resources for the TEE OS according to the resource configuration file, thereby supporting the elastic scaling of the resources of the TEE OS, which can further improve the maintainability of the TEE OS and better meet the flexible and variable specification requirements of users for the resources occupied by the TEE OS. Through actions such as the creation and deletion of the TEE OS, system resources can be applied for and released on demand, improving the utilization rate of system resources.

[0085] Figure 5 It is a logical schematic diagram of another TEE OS startup method provided by an exemplary embodiment of the present application. Refer to Figure 5 , in this embodiment, it still follows the Figure 1 shown TEE OS startup process. In this embodiment, an exemplary implementation manner is provided for the processing concept in the user space of the REE and the processing concept in the runtime component.

[0086] Let's first look at the user space of the REE.

[0087] In this embodiment, an exemplary implementation manner of initiating a secure mode call SMC message for indicating TEE OS startup is proposed.

[0088] Refer to Figure 5 , in this implementation manner, trigger threads can be created for the processing cores required by the TEE OS in the user space of the REE. Among them, if the TEE OS needs to occupy multiple processing cores, trigger threads are created for multiple processing cores core respectively in the user space of the REE. As mentioned above, it is possible to compile resource configuration parameters for the TEE OS in the user space of the REE. Therefore, the user space of the REE knows the processing cores required by the TEE OS. Based on this, trigger threads can be created for the processing cores required by the TEE OS respectively in the user space of the REE. In practical applications, interface functions such as pthread_create and pthread_setaffinity_np in glibc can be called to create trigger threads for the processing cores in the user space of the REE.

[0089] In this implementation manner, the triggering thread is used to initiate SMC messages. Specifically, the SMC messages initiated by a single triggering thread are used to indicate to start the corresponding processing core for the TEE OS. It should be noted that here, starting the processing core is no longer the core activation action in the cold start process, but can be understood as performing relevant initialization work for the TEE OS on the corresponding processing core. This includes but is not limited to memory initialization, page table initialization, VCPU initialization, execution of relevant code in the image file, and other preparatory work required for the TEE OS to run on this processing core. It should be emphasized that in this implementation manner, the SMC message used to indicate the start of the TEE OS will not cause the power-off of the processing core, nor will it affect the operation of other loads on the processing core.

[0090] In this implementation manner, during the process of creating the triggering thread: triggering threads with the same number as the number of processing cores required by the TEE OS can be created in the user mode of the REE; and the core affinity can be configured for each created triggering thread respectively, so as to form a binding relationship between the triggering thread and the processing core through the core affinity. In practical applications, the core affinity between the mutually bound processing core and the triggering thread is high enough to support uniquely determining the bound processing core for the triggering thread according to the core affinity. Of course, other methods can also be used to implement the binding relationship between the processing core and the triggering thread, and it is not limited to this, and no more examples are given here.

[0091] In this way, in the user mode of the REE, according to the startup sequence set for the multiple processing cores required by the TEE OS, the triggering threads corresponding to each of the multiple processing cores can be run in sequence to initiate SMC messages for each of the multiple processing cores. In practical applications, mutex locks can be added to enable each triggering thread to run according to the startup sequence. Among them, the inventor found during the research process that when the TEE OS needs to occupy multiple processing cores, a main core and slave cores are usually set, and usually the main core is started first, and then each slave core is started in sequence. Therefore, in this implementation manner, in the user mode of the REE, the startup sequence between the multiple processing cores can be set in the order of main first and then slave. It should be emphasized again here that the startup here is not the core activation action.

[0092] In addition, in practical applications, the SMC messages initiated for each of the multiple processing cores in the user mode of the REE can be the same, mainly used to drive the runtime component into the subsequent processing logic.

[0093] Let's look at the runtime component again.

[0094] Refer to Figure 5, in this implementation, different boot processes are defined for runtime components for the main core and the secondary core respectively in the trusted base firmware. After receiving the SMC message initiated in the user space of the REE, the runtime component can first determine whether the current SMC message corresponds to the main core or the secondary core, so as to enter the corresponding boot process.

[0095] To support the runtime component to accurately determine whether the received SMC message corresponds to the main core or the secondary core, in an exemplary support solution: in the user space of the REE, core identifiers can be configured for the main core and the secondary core among multiple processing cores respectively; the core identifiers belonging to the main core and the core identifiers belonging to the secondary core are respectively recorded in the first register. Based on this, the runtime component can access the first register. If it is recognized that the core identifier of the processing core corresponding to the target SMC message is the core identifier belonging to the main core, it is determined that the processing core corresponding to the target SMC message is the main core. In practical applications, the first register can adopt the mpidr register, and the master-slave relationship between processing cores is characterized by recording the topological relationship between each processing core. Of course, this is only exemplary, and no limitation is made to the first register here.

[0096] The following will take the runtime component receiving the target SMC message as an example to elaborate in detail on the boot processes defined for the main core and the secondary core respectively in the runtime component. Among them, the target SMC message can be any one of the SMC messages respectively initiated for multiple processing cores required to be occupied by the TEE OS.

[0097] Reference Figure 5 , for the runtime component, after receiving the target SMC message, it can be determined whether the target SMC message corresponds to the main core;

[0098] If so, the boot process corresponding to the main core can be executed;

[0099] If not, the boot process corresponding to the secondary core can be executed.

[0100] Figure 6 It is a schematic diagram of an exemplary boot process corresponding to the main core provided by an exemplary embodiment of the present application. Reference Figure 6 , continuing with the target SMC message as an example, if the runtime component determines that the target SMC message corresponds to the main core, it can, under the trigger of the target SMC message, execute the operation of loading the image compiled for the TEE OS in the user space of the REE to the specified memory address; after completing the image loading, trigger the execution of the initialization logic corresponding to the main core in the trusted execution environment TEE. That is, the Figure 2 step 101 in can be executed in the boot process corresponding to the main core. Correspondingly, the signature verification link for the TEE OS image mentioned above can also be executed in the boot process corresponding to the main core. Reference Figure 6, during the boot process of the main core, after the runtime component completes the mirror loading operation, it can trigger the initialization logic corresponding to the main core to run in the Trusted Execution Environment (TEE).

[0101] It should be understood that in this embodiment, for the SMC message corresponding to the main core, after the runtime component completes the aforementioned mirror signature verification and mirror loading operations, it can guide the relevant components in the TEE to start running the initialization logic corresponding to the main core. The runtime component can only be responsible for the guiding work, and the specific initialization logic can be implemented by the relevant components in the TEE.

[0102] In an exemplary solution: Refer to Figure 6 , a security partition manager can be introduced in the TEE, such as Hafnium mentioned above, to manage multiple TEE operating systems. The runtime component can send a first trigger notification to the security partition manager in the TEE to transfer the control right of the main core to the security partition manager; the security partition manager can then perform an initialization configuration operation for the main core for the TEE operating system according to the first trigger notification, and call a preset instruction after completing the initialization configuration operation to trigger entry into the running entry corresponding to the main core in the mirror. Here, performing an initialization configuration operation for the main core for the TEE operating system may include, but is not limited to, memory initialization, page table initialization, and VCPU initialization, etc., which will not be enumerated here. In addition, due to the reason of multiple processing cores, different running entries are usually provided for the main core and the secondary core in the TEE operating system mirror. For example, the running entry corresponding to the main core is usually the reset_primary function, while the running entry of the secondary core is usually the reset_secondary function. Of course, this is only exemplary, and this embodiment does not limit this. Based on this, in practical applications, the security partition manager can trigger the running of the TEE operating system mirror by calling the start function (the entry function of the TEE operating system mirror). After that, the start function can continue to call the reset function, and the reset function can continue to call the reset_primary function, so as to run the mirror code corresponding to the main core in the TEE operating system. Among them, the running process of the mirror can be carried out in the aforementioned EL1.

[0103] Of course, the above initialization logic executed in the TEE is only an exemplary part of the logic. In this embodiment, other initialization logics are also supported. For example, after receiving the first trigger notification, the security partition manager can update the number of TEE operating systems it manages, and after monitoring that the relevant mirror code in the TEE operating system mirror has been executed, it can take over the control right of the main core again and start the required VCPU for the TEE operating system on the main core, etc. The initialization logic will not be enumerated here.

[0104] So far, the work related to the startup of the TEE OS on the main core can be completed.

[0105] Still taking the target SMC message as an example, if the target SMC message corresponds to the secondary core, the runtime component executes the boot process corresponding to the secondary core according to the target SMC message to trigger the initialization logic corresponding to the secondary core to run in the Trusted Execution Environment (TEE).

[0106] In the boot process corresponding to the secondary core, the runtime component no longer needs to perform the signature verification and loading operations of the image, which is different from the boot process corresponding to the main core. Others can refer to the boot process corresponding to the main core. Similarly, in the case where there are multiple TEE OSs in the TEE, the runtime component sends a second trigger notification to the security partition manager in the TEE for managing the TEE OS according to the target SMC message; the security partition manager performs the initialization configuration operation for the secondary core for the TEE OS according to the second trigger notification, and calls a preset instruction to trigger entry into the running entry corresponding to the secondary core in the image after the initialization configuration operation is completed.

[0107] Regarding the process of running the initialization logic corresponding to the secondary core in the TEE, it is basically the same as the aforementioned process of running the initialization logic corresponding to the secondary core in the TEE. For the sake of brevity, it will not be repeated here.

[0108] It can be seen that in this embodiment, the user state of the REE can cooperate with the runtime component to complete the relevant startup work of the TEE OS on the main core and the secondary core, and the entire process does not need to rely on the BIOS firmware.

[0109] Further preferably, referring to Figure 5 , in this embodiment, after the runtime component monitors that the processing flow of the SMC message initiated for the current processing core has been completed, it can return a process end notification to the user state of the REE; after receiving the process end notification, the user state of the REE initiates an SMC message for the next processing core. In practical applications, after the runtime component monitors that the processing flow of the current SMC message has been completed, it can restore the EL3-level context, then call the eret instruction to return to the OS kernel in the REE. Finally, the custom CA in the REE can end the startup process for the current SMC message by calling the TEEC_FinalizeContext interface function, and can initiate an SMC message for the next processing core. Repeating this cycle can complete the relevant startup work of the TEE OS on each processing core it needs to occupy.

[0110] In summary, in this embodiment, the boot processes corresponding to the main core and the slave core can be defined separately. At runtime, the runtime component can execute the corresponding boot processes for the main core and the slave core required by the TEE OS respectively, so as to cooperate with other components in the TEE, complete the work related to the startup of the TEE OS on the main core and the slave core required by the TEE OS respectively, and thus complete the startup of the TEE OS. The entire process does not rely on the BIOS firmware. Moreover, the relevant components perform their respective duties and cooperate smoothly, ensuring the startup efficiency, security, accuracy, and trustworthiness of the TEE OS.

[0111] It should be noted that in some of the processes described in the above embodiments and the accompanying drawings, a plurality of operations appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order in which they appear herein or may be executed in parallel. The operation numbers such as 801 and 802 are only used to distinguish different operations, and the numbers themselves do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be executed in sequence or in parallel. It should be noted that the descriptions such as "first" and "second" in this article are used to distinguish different trigger notifications or registers, etc., and do not represent a sequence, nor do they limit that "first" and "second" are of different types.

[0112] Figure 7 The structure diagram of a computing device provided for another exemplary embodiment of the present application. As Figure 7 shown, the computing device includes: a memory 70 and a processor 71.

[0113] The processor 71, coupled to the memory 70, is configured to execute a computer program in the memory 70 for:

[0114] In the user mode of the regular execution environment REE, initiate a secure mode call SMC message for indicating the startup of the TEE OS to the runtime component in the trusted base firmware;

[0115] Utilize the runtime component to load the image compiled for the TEE OS in the user mode of the REE to a specified memory address;

[0116] Utilize the runtime component to trigger the execution of the image in the specified memory address in the trusted execution environment TEE according to the SMC message to start the TEE OS.

[0117] In this embodiment, the processor may include multiple processing cores, and one or more of the processing cores may execute the above computer program in the memory 70.

[0118] In an optional embodiment, the processor 71 may further be configured to:

[0119] Before loading the mirror to the specified memory address, in the user mode of the REE, initiate an SMC message for transmitting resource requirements to the runtime component;

[0120] Utilize the runtime component to compile a resource configuration file adapted to the resource requirements for the TEE OS, so that the runtime component allocates resources for the TEE OS according to the resource configuration file.

[0121] In an optional embodiment, when the processor 71 utilizes the runtime component to compile a resource configuration file adapted to the resource requirements for the TEE OS, it can specifically be used for:

[0122] If there already exists a resource configuration file corresponding to the TEE OS, modify the resource configuration file according to the SMC message received this time for transmitting resource requirements;

[0123] Among them, the modified resource configuration file is consistent with the resource requirements described in the mirror compiled for the TEE OS.

[0124] In an optional embodiment, when the processor 71 initiates a secure mode call SMC message for instructing the startup of the TEE OS, it can specifically be used for:

[0125] If the TEE OS needs to occupy multiple processing cores, create trigger threads for the multiple processing cores respectively in the user mode of the REE;

[0126] According to the set startup order of the multiple processing cores, sequentially run the trigger threads corresponding to the multiple processing cores respectively in the user mode of the REE, so as to initiate the SMC message for the multiple processing cores respectively.

[0127] In an optional embodiment, the multiple processing cores include a main core and slave cores. When the processor 71 utilizes the runtime component to trigger the mirror in the specified memory address to run in the trusted execution environment TEE according to the SMC message, it can specifically be used for:

[0128] After the runtime component receives the target SMC message among multiple SMC messages, determine whether the target SMC message corresponds to the main core;

[0129] If the target SMC message corresponds to the main core, utilize the runtime component to execute the boot process corresponding to the main core according to the target SMC message, so as to trigger the initialization logic corresponding to the main core to run in the trusted execution environment TEE;

[0130] Among them, the target SMC message is any one of the multiple SMC messages.

[0131] In an alternative embodiment, when the processor 71 executes the boot process corresponding to the main core according to the target SMC message by using the runtime component to trigger the initialization logic corresponding to the main core to run in the trusted execution environment TEE, it can specifically be used for:

[0132] Under the trigger of the target SMC message, use the runtime component to execute the operation of loading the image that has been compiled for the TEE OS in the user state of the REE to a specified memory address;

[0133] After completing the image loading, use the runtime component to trigger the initialization logic corresponding to the main core to run in the trusted execution environment TEE.

[0134] In an alternative embodiment, when the processor 71 triggers the initialization logic corresponding to the main core to run in the trusted execution environment TEE by using the runtime component, it can specifically be used for:

[0135] In the case where there are multiple TEE OSs in the TEE, use the runtime component to send a first trigger notification to the security partition manager in the TEE for managing the TEE OS according to the target SMC message;

[0136] Use the security partition manager to perform the initialization configuration operation for the main core for the TEE OS according to the first trigger notification, and after completing the initialization configuration operation, call a preset instruction to trigger entry into the running entry corresponding to the main core in the image.

[0137] In an alternative embodiment, the processor 71 can also be used for:

[0138] If the target SMC message corresponds to a secondary core, use the runtime component to execute the boot process corresponding to the secondary core according to the target SMC message to trigger the initialization logic corresponding to the secondary core to run in the trusted execution environment TEE.

[0139] In an alternative embodiment, when the processor 71 executes the boot process corresponding to the secondary core according to the target SMC message by using the runtime component to trigger the initialization logic corresponding to the secondary core to run in the trusted execution environment TEE, it can be used for:

[0140] In the case where there are multiple TEE OSs in the TEE, use the runtime component to send a second trigger notification to the security partition manager in the TEE for managing the TEE OS according to the target SMC message;

[0141] Use the security partition manager to perform an initialization configuration operation for the slave core for the TEEOS according to the second trigger notification, and call a preset instruction to trigger entry into the running entry corresponding to the slave core in the mirror after the initialization configuration operation is completed.

[0142] In an optional embodiment, the processor 71 may further be configured to:

[0143] In the user mode of the REE, configure core identifiers for the master core and the slave core among the multiple processing cores respectively;

[0144] Record the core identifier belonging to the master core and the core identifier belonging to the slave core in the first register respectively;

[0145] When the processor 71 determines whether the processing core corresponding to the target SMC message is the master core by using the runtime component, it includes:

[0146] Use the runtime component to access the first register. If the core identifier of the processing core corresponding to the target SMC message is identified as the core identifier belonging to the master core, determine that the processing core corresponding to the target SMC message is the master core.

[0147] In an optional embodiment, when the processor 71 creates trigger threads for the multiple processing cores respectively in the user mode of the REE, it may specifically be configured to:

[0148] Create trigger threads in the user mode of the REE with the same number as the number of processing cores required by the TEE OS;

[0149] Configure the core affinity for each created trigger thread respectively, so as to form a binding relationship between the trigger thread and the processing core through the core affinity.

[0150] In an optional embodiment, the processor 71 may further be configured to:

[0151] After the runtime component monitors that the processing of the SMC message initiated for the current processing core has been completed, return a process end notification to the user mode of the REE;

[0152] After receiving the process end notification, the user mode of the REE initiates an SMC message for the next processing core.

[0153] In an optional embodiment, the processor 71 may further be configured to:

[0154] Use the runtime component to read the storage address of the mirror compiled by the user mode of the REE for the TEE OS from a specified register;

[0155] Perform signature verification on the mirror in the storage address;

[0156] When it is determined that the mirror image passes the signature verification, the operation of loading the mirror image to a specified memory address is then performed.

[0157] In an optional embodiment, the processor 71 may further be configured to:

[0158] In the user mode of the REE, call a custom interface provided by the TEE driver to obtain, by using the custom interface, the mirror image compiled for the TEE OS from a specified directory in the user mode of the REE, and store the mirror image in a specified buffer area;

[0159] Configure the address of the buffer area in a second register;

[0160] Wherein, the second register is an address transfer medium for the buffer area agreed upon between the TEE driver and the runtime component.

[0161] Furthermore, as Figure 7 shown, the computing device further includes: a communication component 72, a power supply component 73 and other components. Figure 7 Only some components are schematically shown in Figure 7 and it does not mean that the computing device only includes

[0162] the components shown.

[0163] It should be noted that for the technical details in the embodiments of the computing device above, reference may be made to the relevant descriptions in the foregoing method embodiments. To save space, they are not repeated herein, but this should not cause loss of the protection scope of this application.

[0163] Correspondingly, an embodiment of the present application further provides a computer-readable storage medium storing a computer program, and when the computer program is executed, it can implement each step performed in the foregoing method embodiment.

[0164] The above Figure 7 The memory is used to store a computer program and can be configured to store various other data to support operations on the computing platform. Examples of such data include instructions for any application program or method for operating on the computing platform, contact data, phone book data, messages, pictures, videos, etc. The memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0165] The above Figure 7The communication component therein is configured to facilitate communication between the device where the communication component is located and other devices in a wired or wireless manner. The device where the communication component is located can access a wireless network based on communication standards, such as WiFi, 2G, 3G, 4G / LTE, 5G and other mobile communication networks, or a combination thereof. In an exemplary embodiment, the communication component receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component further includes a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on Radio Frequency Identification (RFID) technology, Infrared Data Association (IrDA) technology, Ultra Wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

[0166] The above Figure 7 The power supply component therein provides power for various components of the device where the power supply component is located. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power for the device where the power supply component is located.

[0167] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system, or a computer program product. Therefore, the present application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0168] The present application is described with reference to the flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each flow and / or block in the flowchart and / or block diagram, and the combination of flows and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing devices generate means for implementing the functions specified in Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0169] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, such that the instructions stored in the computer-readable memory generate a manufactured article including instruction means, and the instruction means implements the functions specified in Figure 1 one flow or multiple flows and / or blocks Figure 1The functions specified in one or more boxes.

[0170] These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operation steps are executed on the computer or other programmable device to generate a computer-implemented process. Thus, the instructions executed on the computer or other programmable device provide for implementing the steps of the functions specified in one Figure 1 one process or more processes and / or boxes Figure 1 or more boxes.

[0171] It should also be noted that the term "including", "comprising" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements but also other elements not expressly listed, or also includes elements inherent in such process, method, commodity or device. Without further limitation, an element defined by the statement "including one..." does not exclude the existence of additional identical elements in the process, method, commodity or device including the said element.

[0172] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. And the collection, use and processing of relevant data need to comply with the relevant laws, regulations and standards of relevant countries and regions, and corresponding operation entrances are provided for users to choose to authorize or refuse.

[0173] The above are only the embodiments of the present application and are not used to limit the present application. For those skilled in the art, various changes and modifications can be made to the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included within the protection scope of the present application.

Claims

1. A method for starting a TEE OS, characterized in that, Including: In the user mode of the regular execution environment (REE), initiate a secure mode call (SMC) message for indicating the start of the TEE OS to the runtime component in the trusted base firmware. Using the runtime component, load the image compiled for the TEE OS in the user mode of the REE to a specified memory address. Using the runtime component, trigger the execution of the image in the specified memory address in the trusted execution environment (TEE) according to the SMC message to start the TEE OS.

2. The method according to claim 1, characterized in that, Also including: Before loading the image to the specified memory address, in the user mode of the REE, initiate an SMC message for transmitting resource requirements to the runtime component. Using the runtime component, compile a resource configuration file adapted to the resource requirements for the TEE OS, so that the runtime component allocates resources for the TEE OS according to the resource configuration file.

3. The method according to claim 2, characterized in that, Using the runtime component, compiling a resource configuration file adapted to the resource requirements for the TEE OS includes: If there already exists a resource configuration file corresponding to the TEE OS, modify the resource configuration file according to the SMC message for transmitting resource requirements received this time. Wherein, the modified resource configuration file is consistent with the resource requirements described in the image compiled for the TEE OS.

4. The method according to claim 1, characterized in that, Initiating a secure mode call (SMC) message for indicating the start of the TEE OS includes: If the TEE OS needs to occupy multiple processing cores, create trigger threads for the multiple processing cores respectively in the user mode of the REE. According to the set start order of the multiple processing cores, sequentially run the trigger threads corresponding to the multiple processing cores respectively in the user mode of the REE to initiate the SMC message for the multiple processing cores respectively.

5. The method according to claim 4, characterized in that, The multiple processing cores include a main core and slave cores. Using the runtime component, triggering the execution of the image in the specified memory address in the trusted execution environment (TEE) according to the SMC message includes: After the runtime component receives the target SMC message among multiple SMC messages, determine whether the target SMC message corresponds to the main core. If the target SMC message corresponds to the main core, the runtime component executes the boot process corresponding to the main core according to the target SMC message to trigger the execution of the initialization logic corresponding to the main core in the trusted execution environment (TEE). Wherein, the target SMC message is any one of the multiple SMC messages.

6. The method according to claim 5, characterized in that, The runtime component executes the boot process corresponding to the main core according to the target SMC message to trigger the execution of the initialization logic corresponding to the main core in the trusted execution environment (TEE) includes: Under the trigger of the target SMC message, execute the operation of loading the image compiled for the TEE OS in the user mode of the REE to the specified memory address. After the image loading is completed, trigger the execution of the initialization logic corresponding to the main core in the trusted execution environment (TEE).

7. The method according to claim 6, characterized in that, The runtime component triggers the initialization logic corresponding to the main core to run in the Trusted Execution Environment (TEE), including: When there are multiple TEE operating systems (TEE OSs) in the TEE, the runtime component sends a first trigger notification to the security partition manager in the TEE for managing the TEE OS according to the target SMC message; The security partition manager performs an initialization configuration operation for the main core for the TEE OS according to the first trigger notification, and calls a preset instruction to trigger entry into the running entry corresponding to the main core in the image after completing the initialization configuration operation.

8. The method according to claim 5, characterized in that, It further includes: If the target SMC message corresponds to a secondary core, the runtime component executes the boot process corresponding to the secondary core according to the target SMC message to trigger the initialization logic corresponding to the secondary core to run in the Trusted Execution Environment (TEE).

9. The method according to claim 8, characterized in that, The runtime component executes the boot process corresponding to the secondary core according to the target SMC message to trigger the initialization logic corresponding to the secondary core to run in the Trusted Execution Environment (TEE), including: When there are multiple TEE operating systems (TEE OSs) in the TEE, the runtime component sends a second trigger notification to the security partition manager in the TEE for managing the TEE OS according to the target SMC message; The security partition manager performs an initialization configuration operation for the secondary core for the TEE OS according to the second trigger notification, and calls a preset instruction to trigger entry into the running entry corresponding to the secondary core in the image after completing the initialization configuration operation.

10. The method according to claim 5, characterized in that, In the user state of the REE, core identifiers are respectively configured for the main core and the secondary core among the multiple processing cores; The core identifiers belonging to the main core and the core identifiers belonging to the secondary core are respectively recorded in the first register; Judging whether the processing core corresponding to the target SMC message is the main core includes: The runtime component accesses the first register. If the core identifier of the processing core corresponding to the target SMC message is identified as the core identifier belonging to the main core, it is determined that the processing core corresponding to the target SMC message is the main core.

11. The method according to claim 4, wherein, Creating trigger threads for the multiple processing cores respectively in the user state of the REE, including: Creating trigger threads with the same number as the number of processing cores required by the TEE OS in the user state of the REE; Respectively configuring the core affinity for each created trigger thread to form a binding relationship between the trigger thread and the processing core through the core affinity.

12. The method according to claim 4, wherein, It further includes: After the runtime component monitors that the processing process of the SMC message initiated for the current processing core has been completed, it returns a process end notification to the user state of the REE; After receiving the process end notification, the user state of the REE initiates an SMC message for the next processing core.

13. The method according to claim 1, wherein, It further includes: Using the runtime component to read the storage address of the image compiled by the user state of the REE for the TEE OS from a specified register; Performing signature verification on the image in the storage address; When it is determined that the image passes the signature verification, then perform the operation of loading the image to a specified memory address.

14. The method according to claim 1, wherein, It further includes: In the user state of the REE, call the custom interface provided by the TEE driver to obtain the image compiled for the TEE OS from a specified directory in the user state of the REE by using the custom interface, and store the image in a specified buffer area; Configure the address of the buffer area into a second register; Wherein, the second register is a medium for transmitting the address of the buffer area agreed upon between the TEE driver and the runtime component.

15. A computing device, wherein, It includes a memory and a processor; The memory is used to store one or more computer instructions; The processor is coupled to the memory and is used to execute the one or more computer instructions to execute the startup method of the TEE OS according to any one of claims 1-14.

16. A computer-readable storage medium storing computer instructions, wherein, When the computer instructions are executed by one or more processors, the one or more processors are caused to execute the startup method of the TEE OS according to any one of claims 1-14.

Images