TEE os starting method, device, and storage medium

Abstract

Embodiments of the present application provide a TEE OS starting method, a device, and a storage medium. After cold start is completed on the basis of BIOS firmware, in a user state of an REE, an SMC message used for instructing to perform TEE OS starting can be sent to a runtime component in trusted basic firmware; moreover, a compiled TEE OS image in the user state of the REE can be loaded to a specified memory address by the runtime component, and on the basis, under the instruction of the SMC message, by means of the runtime component, the image loaded to the specified memory address can be triggered to run in a TEE, so as to start a TEE OS. Accordingly, loading of the TEE OS image can be achieved by means of mutual cooperation of the user state of the REE and the runtime component in the trusted basic firmware, and the BIOS firmware does not need to be relied on any more, so that the maintainability of the TEE OS can be effectively improved.

Description

[0001] A method, device and storage medium for starting a TEE OS Technical Field 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.

[0002] A TEE, or Trusted Execution Environment (TEE), is a secure, isolated area built on a computing platform using hardware and software methods. This ensures that the confidentiality and integrity of the data and code within this secure, isolated area are protected throughout its lifecycle. A TEE OS (Trusted Execution Environment-Operating System) is the operating system running within the TEE. Currently, the TEE OS image required for TEE OS startup must be packaged into the BIOS (Basic Input Output System) firmware image and pre-burned into the flash memory along with the BIOS firmware image. Therefore, TEE OS startup relies on the BIOS firmware. This BIOS-dependent TEE OS startup method results in poor TEE OS maintainability and fails to meet user requirements for flexible and versatile TEE OS usage. SUMMARY OF THE INVENTION Various aspects of this application provide a TEE OS startup method, device, and storage medium to improve TEE OS maintainability. An embodiment of the present application provides a method for booting a TEE OS, comprising: in user mode of a conventional execution environment (REE), initiating a secure mode call (SMC) message to a runtime component in trusted base firmware to instruct booting the TEE OS; using the runtime component to load an image compiled for the TEE OS in user mode of the REE to a specified memory address; and using the runtime component to trigger execution of the image at the specified memory address in a trusted execution environment (TEE) in accordance with the SMC message to boot the TEE OS. An embodiment of the present application also provides a computing device comprising a memory and a processor; the memory being configured to store one or more computer instructions; and the processor being coupled to the memory and configured to execute the one or more computer instructions to perform the aforementioned method for booting the TEE OS. An embodiment of the present application also provides a computer-readable storage medium storing computer instructions, which, when executed by one or more processors, causes the one or more processors to execute the aforementioned method for booting the TEE OS.In an embodiment of the present application, after a cold boot is completed based on the BIOS firmware, a secure mode call SMC message can be initiated in the user state of the regular execution environment (REE) to instruct the runtime component in the trusted base firmware to boot the TEE OS. Furthermore, the runtime component can load the image compiled for the TEE OS in the user state of the REE to a specified memory address. Based on this, under the instruction of the SMC message, the runtime component can trigger the execution of the image loaded to the specified memory address in the trusted execution environment (TEE), thereby booting the TEE OS. Therefore, in an embodiment of the present application, the user state of the REE and the runtime component in the trusted base firmware can cooperate to load the TEE OS image, eliminating the need for reliance on the BIOS firmware. Therefore, on-demand online booting of the TEE OS can be achieved without restarting the BIOS firmware, effectively improving the maintainability of the TEE OS. BRIEF DESCRIPTION OF THE DRAWINGS The drawings described herein are provided to provide a further understanding of the present application and constitute a part of the present application. The exemplary embodiments of the present application and their description are provided to explain the present application and do not constitute undue limitations thereon. In the accompanying drawings: Figure 1 is a schematic diagram of an exemplary conventional TEE OS startup logic; Figure 2 is a flowchart of a TEE OS startup method provided by an exemplary embodiment of the present application; Figure 3 is a logical diagram of a TEE OS startup method provided by an exemplary embodiment of the present application; Figure 4 is a flowchart of another TEE OS startup method provided by an exemplary embodiment of the present application; Figure 5 is a logical diagram of yet another TEE OS startup method provided by an exemplary embodiment of the present application; Figure 6 is a schematic diagram of an exemplary boot process corresponding to a main core provided by an exemplary embodiment of the present application; and Figure 7 is a structural diagram of a computing device provided by another exemplary embodiment of the present application. DETAILED DESCRIPTION To further clarify the objectives, technical solutions, and advantages of this application, the technical solutions of this application will be described clearly and completely below in conjunction with the specific embodiments of this application and the corresponding drawings. Obviously, the described embodiments are only some of the embodiments of this application, and not all of them. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application. Before describing the technical solutions provided by the embodiments of the present application, several technical concepts involved in the present application are briefly explained as follows:

[0003] BIOS: Basic Input / Output System. It is the program that starts the computer system after the computer microprocessor is powered on. It also manages the flow of data between the computer's operating system and attached devices such as the hard drive, video adapter, keyboard, mouse, and printer.

[0004] TEE: Trusted Execution Environment. A secure area within the processor that helps protect the code and data loaded into it in terms of confidentiality and integrity.

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

[0006] REE: Rich Execution Environment. Contains the regular operating system and its combination with the rest of the execution environment. It does not have sufficient security to meet the tasks required by the device.

[0007] CA: Client Application. Applications that usually run in a REE environment are referred to as CA.

[0008] TA: Trusted Application. An application typically running in a TEE environment is referred to as a TA. Hafnium: A secure partition manager (SPM) used to implement the Armv8.4-A S-EL2 extension, allowing multiple isolated secure partitions (SPs) to run at the S-EL1 level.

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

[0010] ATF: Trusted Firmware-A, a type of trusted foundation firmware. It is a reference implementation of secure world software for the Arm A-profile architecture (Armv8-A and Armv7-A), including an EL3-level security controller.

[0011] Runtime, the runtime component in ATF, is used to support the interaction between the TA in the TEE and the CA in the REE at runtime.

[0012] FF-A: Firmware Framework-A profile, a firmware framework.

[0013] SPMD: Under the FF-A specification, a scheduler deployed within the ATF runtime component for scheduling the Secure Partition Manager (SPM). As described in the background, TEE OS startup currently relies on BIOS firmware. Specifically, TEE OS startup is one of the steps in a BIOS-based cold boot process. Figure 1 shows an exemplary logic diagram for conventional TEE OS startup. In existing startup schemes, when a CPU contains multiple processing cores, a master core and a slave core are typically designated. Referring to Figure 1 , the overall cold boot process can be divided into two phases. The first phase is the power-on startup of the master core. At this point, the other slave cores are not powered on. The master core can load each component one by one according to the secure boot chain (composed of the SCP ROM, BL2, and BL31 in Figure 1 , which is an existing solution and will not be described in detail here). This completes the startup of the operating system kernel (OS kernel) in the REE based on the BIOS firmware (UEFI in Figure 1 ), completing the master core's core startup process. The second phase then begins. After the master core completes the initialization process of the OS kernel's main modules, the OS kernel, based on the relevant configuration information obtained from the BIOS firmware, calls the PSCI interface (a standard interface for multi-core processors) to access the runtime components of the trusted foundation firmware (ATF), powering on the slave cores. It then enters the slave core's boot entry and completes the initialization of Hafnium and TEE OS in Figure 1 , completing the slave core startup process. Furthermore, when there are multiple slave cores, the OS kernel will repeatedly execute the aforementioned slave core deactivation actions to complete the deactivation of other slave cores. Based on the cold boot process shown in Figure 1, it can be seen that TEE OS startup is interspersed with the cold boot process. As described in the background technology section, the TEE OS image must be burned into the BIOS firmware image. Therefore, existing TEE OS startup solutions have a strong dependency on the BIOS firmware. This obviously leads to poor TEE OS maintainability. This poor maintainability can be understood as inflexible TEE OS startup timing or the inability to recompile the image after startup. Therefore, existing TEE OS startup solutions cannot meet users' demand for flexible and versatile TEE OS usage.In addition, because the TEE OS image needs to be packaged within the BIOS firmware image, which is burned into the flash memory, if multiple TEE OSes need to be deployed in a processor, the size of the BIOS firmware image will continue to increase as the number of TEE OSes increases. This places significant storage pressure on the BIOS flash memory, potentially exceeding the flash memory's storage limit. Furthermore, TEE OS startup also increases computer cold boot latency. Due to its heavy reliance on the BIOS firmware, as the number of TEE OSes continues to increase, computer cold boot latency can reach hours, resulting in a poor user experience. To address this, embodiments of the present application propose a new TEE OS startup solution that supports on-demand online TEE OS startup without relying on the BIOS firmware. The following, in conjunction with the accompanying drawings, details the technical solutions provided by various embodiments of the present application. Figure 2 is a flow chart illustrating a TEE OS startup method according to an exemplary embodiment of the present application. Figure 3 is a logic diagram illustrating a TEE OS startup method according to an exemplary embodiment of the present application. Referring to Figure 2, the method may include: Step 100: Initiating a secure mode call SMC message instructing the startup of a TEE OS in user mode of a conventional execution environment (REE) to a runtime component in the trusted base firmware; Step 101: Using the runtime component, loading the image compiled for the TEE OS in user mode of the REE to a specified memory address; Step 102: Using the runtime component, triggering the execution of the image at the specified memory address in the trusted execution environment (TEE) in accordance with the SMC message, to start the TEE OS. The TEE OS startup method provided in this embodiment can be applied to various scenarios requiring the use of a TEE OS, thereby supporting on-demand online startup of the TEE OS. This embodiment does not limit the application scenario. It should be understood that the TEE OS startup method provided in this embodiment is implemented after completing the conventional cold boot process mentioned above. Specifically, for a TEE OS intended to be started according to the TEE OS startup method provided in this embodiment, it is no longer necessary to package the corresponding image into a BIOS firmware image or burn the corresponding image into flash memory. That is, in the conventional cold boot process mentioned above, it is no longer necessary to boot these unburned TEE OS images. Instead, after completing the cold boot process, these unburned TEE OS images can be booted online on demand according to the boot method provided in this embodiment.Therefore, the TEE OS startup method provided in this embodiment can be performed independently after the conventional cold boot process, no longer relying on BIOS firmware and eliminating the need to occupy flash memory and delay during the cold boot process. This makes the cold boot process more efficient and reduces flash storage pressure. It is worth noting that this embodiment does not prohibit the startup of the TEE OS during the cold boot process. In other words, some TEE OSs that are expected to be booted immediately upon startup can still be booted using the traditional cold boot method, and this embodiment does not interfere with the cold boot process of these TEE OSs. However, for these TEE OSs that are booted immediately upon startup, version upgrades can be implemented using the TEE OS startup method provided in this embodiment. In other words, the TEE OS startup method provided in this embodiment supports online restart of an already booted TEE OS, thereby supporting online upgrades of the TEE OS. 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 already been established during the aforementioned cold boot process. In practical applications, technologies such as TrustZone can be used to support the establishment of these two execution environments. Taking TrustZone as an example, it provides two spaces: Secure and Non-Secure, corresponding to the TEE and REE execution environments, respectively. It provides hardware-enforced isolation between the two execution environments and supports the computer's CPU switching operating modes, allowing it to operate between the two execution environments as needed. For example, operating mode switching can be enabled by switching the Secure Configuration Register system register. The last bit of this register is 0, indicating that the CPU is currently in secure mode. TrustZone technology also supports configuring system resources to a secure state. By manipulating relevant registers, resources such as the system bus, memory, DMA, and cache can be configured to a secure state. Once configured to a secure state, programs running in the REE (CA) cannot access these hardware resources, thus achieving hardware-enforced isolation between the two execution environments. The process of establishing these two execution environments will not be described in detail here. Thus, in this embodiment, after completing the cold boot process, the CPU in the computer enters runtime, which supports two operating states: secure and non-secure. When in the secure state, the CPU can only run code on the TEE side and has access to the REE side address space.When the CPU is in a non-secure state, it can only run code on the REE side and can only access specific data and call specific functions on the TEE side through pre-defined interfaces. Furthermore, referring to Figure 3, based on the establishment of the aforementioned TEE and REE execution environments, this embodiment also introduces trusted base firmware to further ensure the trustworthiness of TEE OS startup. For example, the trusted base firmware in this embodiment can utilize ATF (ARM Trusted Firmware). Based on ATF, while maintaining the secure and non-secure spaces provided by Trustzone, it can also divide the system into four exception levels, EL0 (Exception level 0) to EL3, to further ensure security during the startup and runtime phases. The aforementioned CA and TA can run at EL0, the aforementioned OS kernel and the TEE OS after startup in this embodiment can run at EL1, and the BISO can run at EL2. Referring to Figure 3, this embodiment proposes using runtime components in the trusted base firmware to support the TEE OS startup method in this embodiment. The runtime component runs in the aforementioned EL3 and remains in the Secure space, effectively ensuring the security and trustworthiness of the TEE OS startup method in this embodiment. Based on this, referring to Figure 2, in step 100, a secure mode call (SMC) message instructing the loading of the TEE OS can be initiated in the user state of the regular execution environment (REE) to the runtime component in the trusted base firmware. In this embodiment, a custom CA (regular application) can be deployed in the user state of the REE, and this custom CA implements the processing logic required in the user state of the REE. Of course, in this embodiment, other types of logical carriers can also be used as the method execution subject in the user state of the REE. For example, in addition to the aforementioned 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 state of the REE. Later, when the method execution subject in the user state of the REE is required, the custom CA will be used as an example. Here, in step 100, the custom CA can send an SMC message to the runtime component in the trusted base firmware. As defined above for SMC, the SMC message initiated in the user state of the REE is a message used for calling the security mode.This can be understood as transferring CPU control from the user state of the REE to the runtime component in the trusted base firmware by sending an SMC message to the runtime component in the trusted base firmware. Furthermore, in this embodiment, the SMC message initiated in the user state of the REE is used to instruct the startup of a TEE OS. In practical applications, the SMC message initiated in the user state of the REE can be used to instruct the startup of a single TEE OS or multiple TEE OSes 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, the startup logic will be described from the perspective of a single TEE OS. Continuing with Figures 2 and 3, in step 101, the runtime component can be used to load the image compiled for the TEE OS in the user state of the REE into a specified memory address. This involves two aspects of the processing logic: First, in this embodiment, the image can be compiled for the TEE OS in the user state of the REE. In practical applications, the aforementioned custom CA can be used to complete the image compilation. Based on this, this embodiment supports on-demand TEE OS image compilation based on flexible and diverse user requirements, and also supports TEE OS image recompilation. Specifically, in this embodiment, multiple image compilations can be performed for a single TEE OS in the user state of the REE. During step 101, the most recently compiled image for the TEE OS is used. Therefore, in this embodiment, the TEE OS version can be updated by switching the image version used when the TEE OS is started. In actual applications, after recompiling a TEE OS image in the user state of the REE, the TEE OS can be restarted according to the TEE OS startup method provided in this embodiment to achieve a version upgrade. In this embodiment, the image compiled for the TEE OS in the user state of the REE can be stored in a designated directory in the user state of the REE. On this basis, in this embodiment, in the user state of the REE, the aforementioned custom CA can also call the custom interface provided by the TEE driver to use the custom interface to obtain the image compiled for the TEE OS from the specified directory in the user state of the REE, and store the image in the specified buffer area; then, the address of the buffer area is configured in the second register; wherein, the second register is the buffer area address transmission medium agreed 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. This custom interface function can be called in user mode within the REE. Its functionality can be defined as: calling the Linux firmware subsystem interface function request_firmware to obtain the newly compiled TEE OS image from a specified directory within the OS file system, requesting a buffer area to temporarily store the image, and finally writing the buffer address along with the function ID into the second register. Meanwhile, the runtime component can obtain the image compiled for the TEE OS in user mode within the REE and load it into a specified memory address. A specified memory address for the TEE OS image can be preconfigured in the trusted base firmware. In step 101, the runtime component can store the TEE OS image at the specified memory address according to the trusted base firmware. Subsequent processing logic will also adhere to this specification within the trusted base firmware, ensuring that the image can be accurately found and subsequently executed within the TEE. Continuing with the second register mentioned above, in actual applications, the runtime component can query the address of the buffer area where the TEE OS image is located from the second register, thereby reading the TEE OS image from the buffer area and then transferring the read TEE OS image to a specified memory address. It is worth noting that the image loading process in step 101 can be completed before step 100, that is, the image compilation and loading can be completed before the TEE OS enters the boot process. Of course, this process can also be performed after step 100, that is, the TEE OS image is loaded under the trigger of the SMC message initiated in step 100. Both loading timings are acceptable and are not limited in this embodiment. It is sufficient to ensure that the TEE OS image loading has been completed correctly before step 102. In addition, in this embodiment, after reading the image compiled by the REE user mode for TEE OS, the runtime component can also perform a signature verification on the read image. If the image passes the signature verification, the image is loaded to the specified memory address. In this embodiment, the implementation method of signature verification is not limited. In an exemplary solution, the TEE public key can be stored in the hardware root of trust, and the TEE OS image can be encrypted with the TEE private key in the user state of the REE. In this way, the runtime component can use the TEE public key to perform signature verification on the read TEE OS.Since the TEE public key can only be known within the TEE, its security is guaranteed, thereby ensuring the credibility of the signature verification. In this embodiment, adding a signature verification step to the TEE OS image before image loading effectively ensures the security and credibility of the TEE OS image, avoiding security issues introduced by the REE user state participating in the TEE OS startup process. As can be seen, in this embodiment, through the interaction between the REE user state and the runtime components in the trusted base firmware, it is possible to support on-demand compilation of TEE OS images in the REE user state, and successfully load the compiled image to the default image read address during TEE OS startup (i.e., the specified memory address mentioned above). The entire image loading process completely eliminates BIOS firmware dependency and completely decouples from the aforementioned cold boot process. Therefore, in this embodiment, on-demand online compilation and loading of the TEE OS image can be achieved without restarting the BIOS firmware. This provides a maintainable startup foundation for TEE OS startup. Continuing with Figures 2 and 3 , based on the loaded TEE OS image, in step 102, under the guidance of the runtime component, the image at the specified memory address can be executed in the trusted execution environment (TEE) to boot the desired TEE OS. Since the TEE OS image has been stored at the specified memory address as agreed upon, the runtime component only needs to guide the boot process as agreed upon to enter the TEE OS image's execution entry point, thereby seamlessly starting to run the TEE OS image in the trusted execution environment (TEE) to complete the TEE OS startup. In this embodiment, the boot process for completing step 102 can be defined in the code of the trusted base firmware. This embodiment does not limit the specific boot process; in actual applications, the boot process can be defined as needed. In this embodiment, it is sufficient to ensure that the boot process can trigger the execution 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 described in detail here.In summary, in this embodiment, after a cold boot is completed based on the BIOS firmware, a secure mode call SMC message for instructing TEE OS startup can be initiated in the user state of the conventional execution environment REE to the runtime component in the trusted basic firmware; moreover, the runtime component can load the image compiled for TEE OS in the user state of the REE to a specified memory address. Based on this, under the instruction of the SMC message, the runtime component can be used to trigger the execution of the image loaded to the specified memory address in the trusted execution environment TEE, thereby starting the TEE OS. Accordingly, in this embodiment of the present application, the loading of the TEE OS image can be achieved through the cooperation between the user state of the REE and the runtime component in the trusted basic firmware, without relying on the BIOS firmware. Therefore, the TEE OS can be started online on demand without restarting the BIOS firmware, which can effectively improve the maintainability of the TEE OS. In addition to improving the maintainability of the TEE OS, this embodiment provides an on-demand online TEE OS startup solution with a TEE OS startup latency of seconds. Compared to the hours-long startup latency in traditional startup solutions, this embodiment effectively improves TEE OS startup efficiency. Furthermore, in this embodiment, the online TEE OS startup no longer requires BIOS flash memory, effectively reducing flash memory storage pressure. Figure 4 is a flowchart of another TEE OS startup method provided by an exemplary embodiment of the present application. 4 , the method may include: step 400, initiating a secure mode call SMC message for instructing TEE OS startup in a user state of a conventional execution environment (REE) to a runtime component in the trusted base firmware; step 401, initiating an SMC message for conveying resource requirements in a user state of the REE to the runtime component; step 402, using the runtime component to compile a resource configuration file that matches the resource requirements for the TEE OS, so that the runtime component allocates resources for the TEE OS according to the resource configuration file; step 403, using the runtime component to load the image compiled for the TEE OS in the user state of the REE to a specified memory address; step 404, using 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, so as to startup the TEE OS. Regarding steps 400 and steps 403-404, reference may be made to the description in the aforementioned embodiment. In this embodiment, a further improved TEE OS startup method is provided based on steps 401 and 402.During their research, the inventors discovered that in the traditional cold boot process, the TEE OS boot process not only relies on BIOS firmware to load the TEE OS image, but also requires BIOS support for resource allocation for the TEE OS. This reliance on BIOS for resource allocation results in rigid TEE OS resource configuration, which fails to support elastic resource scalability and, consequently, fails to meet users' flexible and diverse resource usage requirements for the TEE OS. Therefore, this embodiment proposes a technical concept for on-demand online resource configuration to further improve the maintainability of the TEE OS. Referring to Figure 4, in step 401, an SMC message can be initiated in user mode of the REE to convey resource requirements to the runtime component. The SMC message conveying resource requirements can include resource configuration parameters that describe the required resource specifications. Resource configuration parameters may include, but are not limited to, memory size, the number of physical cores, or a device list, and further examples are not provided here. In this way, by initiating an SMC message in the user state of the REE to convey resource requirements, the aforementioned resource configuration parameters can be passed to the runtime component. Continuing with Figure 4, in step 402, in response to the SMC message in the user state of the REE to convey resource requirements, the runtime component can compile a resource configuration file for the corresponding TEE OS. This embodiment proposes that a runtime component be responsible for resource configuration for the TEE OS based on the resource configuration file. As mentioned above, the runtime component runs at the EL3 level, therefore, it has access to all hardware resources in the computer and can be used to schedule hardware resources. In actual applications, the resource configuration process can be implemented by the SPMD deployed in the runtime component, but this embodiment is not limited to this. Thus, in this embodiment, resource configuration parameters can be adjusted on demand for the TEE OS in the user state of the REE, and by initiating an SMC message to the runtime component, the runtime component is prompted to compile the resource configuration file for the TEE OS online. Therefore, this embodiment supports flexible resource configuration for the TEE OS. If TEE OS is allocated too many resources, you can adjust the resource configuration parameters for TEE OS in REE user mode and pass the adjusted resource configuration parameters to the runtime component through SMC messages. The runtime component can then update the corresponding resource configuration file for TEE OS. On this basis, you can restart TEE OS to make the updated resource configuration file take effect, thereby allocating fewer resources to TEE OS and solving the problem of resource waste.If the resources allocated to the TEE OS are insufficient, the on-demand online resource configuration technology provided in this embodiment can be used to allocate more resources to the TEE OS and improve its performance. Since this embodiment supports multiple compilations of TEE OS resource configuration parameters, in this embodiment, if a resource configuration file corresponding to the TEE OS already exists, the runtime component can modify the corresponding resource configuration file in accordance with the currently received SMC message conveying resource requirements, thereby updating the resource configuration file. Furthermore, it is worth emphasizing that this embodiment supports on-demand online compilation of resource configuration parameters and images for the TEE OS in the user state of the REE. During research, the inventors discovered that the TEE OS image may contain some configuration content related to resource configuration. Therefore, in this embodiment, if resource configuration parameters for the TEE OS are adjusted in the user state of the REE, the relevant configuration content in the TEE OS image should be adjusted simultaneously. In other words, the resource configuration file in the runtime component maintains consistency with the resource requirements described in the compiled image for the TEE OS. In summary, this embodiment supports online compilation of resource configuration parameters for the TEE OS in the user state of the REE. Before loading the TEE OS image to a specified memory address, the compiled resource configuration parameters can be passed to the runtime component, enabling the runtime component to compile a resource configuration file for the TEE OS. This allows the runtime component to dynamically allocate resources for the TEE OS according to the resource configuration file, thereby supporting elastic resource scalability of the TEE OS. This further improves the maintainability of the TEE OS and better meets users' flexible and variable resource specifications for the TEE OS. Through actions such as creating and deleting the TEE OS, system resources can be requested and released on demand, improving system resource utilization. Figure 5 is a logical diagram of another TEE OS startup method provided in an exemplary embodiment of the present application. Referring to Figure 5, this embodiment still follows the TEE OS startup process shown in Figure 1 and provides exemplary implementations of the processing concepts in the user state of the REE and the processing concepts in the runtime component. Let's first examine the user state of the REE. This embodiment proposes an exemplary implementation of initiating a secure mode call SMC message for instructing TEE OS startup. Referring to FIG5 , in this implementation, a trigger thread can be created in user mode of the REE for the processing cores required for the TEE OS.If the TEE OS requires multiple processing cores, trigger threads are created for each of these cores in the user state of the REE. As mentioned above, resource configuration parameters can be compiled for the TEE OS in the user state of the REE. Therefore, the user state of the REE is aware of the processing cores required by the TEE OS. Based on this, trigger threads can be created for each of these cores in the user state of the REE. In practical applications, glibc interface functions such as pthread_create and pthread_setaffinity_np can be called to create trigger threads for these cores in the user state of the REE. In this implementation, the trigger thread is used to initiate an SMC message. Specifically, an SMC message initiated by a single trigger thread instructs the TEE OS to initiate the corresponding processing core. It is worth noting that, here, initiating a processing core is no longer the core-starting action in the cold boot 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 TEE OS operation on the processing core. It is worth emphasizing that, in this implementation, the SMC message instructing TEE OS startup does not cause the processing core to power off, nor does it affect the execution of other workloads on the processing core. In this implementation, during trigger thread creation: trigger threads can be created in user mode within the REE, as many as the number of processing cores required by the TEE OS; and core affinity can be configured for each created trigger thread, thereby establishing a binding relationship between the trigger thread and the processing core based on the core affinity. In actual applications, the core affinity between the bound processing core and the trigger thread is sufficiently high to allow the binding of the trigger thread to a unique core based on the core affinity. Of course, other methods can also be used to implement the binding relationship between the processing core and the trigger thread, and are not limited to this method. Further examples are not provided here. In this way, in user mode of the REE, the trigger threads corresponding to the multiple processing cores can be run sequentially according to the startup order set for the multiple processing cores required by the TEE OS, thereby initiating SMC messages to each of the multiple processing cores. In actual applications, a mutex can be added to ensure that the trigger threads run in the startup order. During research, the inventors discovered that when the TEE OS requires multiple processing cores, a master core and slave cores are typically set, and the master core is typically started first, followed by the slave cores in sequence.To this end, in this implementation, the startup order among multiple processing cores can be set in the user state of the REE, following the master-first, slave-later order. It's important to emphasize again that startup here does not deactivate a core. Furthermore, in actual applications, the SMC messages initiated for multiple processing cores in the user state of the REE can be identical, primarily used to drive the runtime component into subsequent processing logic. Now let's look at the runtime component. Referring to Figure 5 , in this implementation, the trusted base firmware defines different boot processes for the runtime component for the master and slave cores, respectively. Upon receiving an SMC message initiated in the user state of the REE, the runtime component can first determine whether the current SMC message corresponds to the master or slave core, thereby initiating the corresponding boot process. To enable the runtime component to accurately determine whether the received SMC message corresponds to the master or slave core, in an exemplary support solution: Core identifiers can be configured for each of the master and slave cores in the multiple processing cores in the user state of the REE; and the core identifiers of the master and slave cores are recorded in the first register, respectively. Based on this, the runtime component can access the first register. If it recognizes that the core identifier of the processing core corresponding to the target SMC message is that of a master core, it determines that the processing core corresponding to the target SMC message is the master core. In practical applications, the first register can be the mpidr register, which represents the master-slave relationship between processing cores by recording the topological relationship between each processing core. Of course, this is merely exemplary, and the first register is not limited herein. The following uses the example of the runtime component receiving a target SMC message to describe in detail the boot processes defined for the master and slave cores in the runtime component. The target SMC message can be any SMC message initiated for each of the multiple processing cores required by the TEE OS. Referring to Figure 5 , after receiving the target SMC message, the runtime component can determine whether the target SMC message corresponds to the master core. If so, it can execute the boot process corresponding to the master core; if not, it can execute the boot process corresponding to the slave core. Figure 6 is a schematic diagram of an exemplary boot process corresponding to the master core, provided in an exemplary embodiment of the present application. Referring to Figure 6 , continuing with the target SMC message as an example, if the runtime component determines that the target SMC message corresponds to the primary core, then, triggered by the target SMC message, it can execute the aforementioned operation of loading the image compiled for the TEE OS in user mode within the REE to the specified memory address. After the image is loaded, it triggers the execution of the initialization logic corresponding to the primary core within the trusted execution environment (TEE). In other words, step 101 in Figure 2 can be executed within the boot process corresponding to the primary core.Accordingly, the aforementioned signature verification process for the TEEOS image can also be performed within the boot process corresponding to the main core. Referring to Figure 6 , in the main core boot process, the runtime component can trigger the execution of the initialization logic corresponding to the main core in the Trusted Execution Environment (TEE) after completing the image loading operation. It should be understood that in this embodiment, for SMC messages corresponding to the main core, after the runtime component completes the aforementioned image signature verification and image loading operations, it then instructs the relevant components in the TEE to begin executing the initialization logic corresponding to the main core. The runtime component can simply perform the boot process, while the specific initialization logic can be implemented by the relevant components in the TEE. In an exemplary solution, as shown in Figure 6 , a secure partition manager, such as Hafnium mentioned above, can be introduced into the TEE to manage multiple TEE OSes. The runtime component can send a first trigger notification to the secure partition manager in the TEE, transferring control of the primary core to the secure partition manager. The secure partition manager can then perform initialization and configuration operations for the TEE OS on the primary core based on the first trigger notification. After completing the initialization and configuration operations, it can invoke a preset instruction to trigger the execution entry corresponding to the primary core in the image. The initialization and configuration operations performed on the primary core for the TEE OS may include, but are not limited to, memory initialization, page table initialization, and VCPU initialization, among other things, which are not exhaustive. Furthermore, due to the presence of multiple processing cores, the TEE OS image typically provides different execution entry points for the primary core and slave cores. For example, the execution entry point for the primary core is typically the reset_primary function, while the execution entry point for the slave core is typically the reset_secondary function. This is merely exemplary and is not a limitation in this embodiment. Based on this, in actual applications, the secure partition manager can trigger the TEE OS image to run by calling the start function (the entry point function of the TEE OS image). The start function can then call the reset function, which in turn calls the reset_primary function, thereby running the image code corresponding to the primary core in the TEE OS. The image execution process can be carried out in the aforementioned ELI.Of course, the initialization logic executed in the TEE described above is merely an example of partial logic. This embodiment also supports the definition of other initialization logic. For example, after receiving the first trigger notification, the secure partition manager can update the number of TEE OSs it manages. After monitoring the completion of execution of the relevant image code in the TEEOS image, it can retake control of the master core and start the required VCPUs for the TEE OS on the master core. This does not provide an exhaustive list of initialization logic. This completes the work related to TEE OS startup on the master core. Taking the target SMC message as an example, if the target SMC message corresponds to a slave core, the runtime component executes the boot process corresponding to the slave core according to the target SMC message, triggering the execution of the initialization logic corresponding to the slave core in the trusted execution environment (TEE). In the boot process corresponding to the slave core, the runtime component no longer needs to perform image signature verification and loading operations, which is different from the boot process corresponding to the master core. For other details, please refer to the boot process corresponding to the master core. Similarly, when multiple TEE OSes exist within a TEE, the runtime component sends a second trigger notification to the secure partition manager within the TEE, which manages the TEE OSes, in accordance with the target SMC message. The secure partition manager performs initialization and configuration operations for the TEE OS on the slave core in response to the second trigger notification. After completing the initialization and configuration operations, it invokes a preset instruction to trigger entry into the execution entry corresponding to the slave core in the image. The process of executing the initialization logic corresponding to the slave core within the TEE is substantially identical to the aforementioned process of executing the initialization logic corresponding to the slave core within the TEE. To conserve space, this description will not be repeated here. 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 operations for the TEE OS on both the master and slave cores, without relying on BIOS firmware. Further preferably, referring to Figure 5, in this embodiment, upon detecting that the SMC message initiated for the current processing core has completed processing, the runtime component can return a process completion notification to the user state of the REE. After receiving the process completion notification, the user state of the REE then initiates an SMC message for the next processing core. In actual applications, after the runtime component detects that the processing flow for the current SMC message has been completed, it can restore the EL3 level context and 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 initiate an SMC message to the next processing core.This repetitive cycle completes the relevant startup tasks for the TEE OS on each processing core it requires. In summary, in this embodiment, boot processes corresponding to the master and slave cores can be defined separately. The runtime component can execute the corresponding boot processes for the master and slave cores required by the TEE OS, coordinating with other components in the TEE to complete the tasks related to TEE OS startup on the master and slave cores required by the TEE OS, thereby completing the startup of the TEE OS. The entire process does not rely on BIOS firmware. Moreover, the relevant components perform their respective functions and work together smoothly, ensuring the efficiency, security, accuracy, and reliability of TEE OS startup. It should be noted that some processes described in the above embodiments and figures include multiple operations that appear in a specific order. However, it should be understood that these operations can be executed in a different order or in parallel. Operation sequence numbers, such as 801 and 802, are merely used to distinguish different operations and do not represent any execution order. Furthermore, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that the terms "first" and "second" herein are used to distinguish between different trigger notifications or registers, and do not represent a sequential order, nor do they limit "first" and "second" to different types. Figure 7 is a schematic diagram of the structure of a computing device provided in another exemplary embodiment of the present application. As shown in Figure 7, the computing device includes: a memory 70 and a processor 71. The processor 71 is coupled to the memory 70 and is configured to execute a computer program in the memory 70, so as to: initiate a secure mode call SMC message for instructing the startup of the TEE OS in the user state of the conventional execution environment (REE) to a runtime component in the trusted basic firmware; use the runtime component to load the image compiled for the TEE OS in the user state of the REE to a specified memory address; use 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. In this embodiment, the processor may include multiple processing cores, and the above-mentioned computer program in the memory 70 may be executed by one or more processing cores.In an optional embodiment, the processor 71 may be further configured to: before loading the image to the specified memory address, initiate an SMC message in user mode of the REE to the runtime component for transmitting resource requirements; and utilize the runtime component to compile a resource configuration file for the TEE OS that is compatible with the resource requirements, so that the runtime component allocates resources for the TEE OS according to the resource configuration file. In an optional embodiment, when utilizing the runtime component to compile the resource configuration file for the TEE OS that is compatible with the resource requirements, the processor 71 may be specifically configured to: if a resource configuration file corresponding to the TEE OS already exists, modify the resource configuration file according to the currently received SMC message for transmitting the resource requirements; wherein the modified resource configuration file is consistent with the resource requirements described in the image compiled for the TEE OS. In an optional embodiment, when the processor 71 initiates a secure mode call SMC message for instructing TEE OS startup, it can be specifically configured to: if the TEE OS needs to occupy multiple processing cores, create trigger threads for each of the multiple processing cores in the user state of the REE; and run the trigger threads corresponding to each of the multiple processing cores in sequence in the user state of the REE according to the startup order set for the multiple processing cores, so as to initiate the SMC messages for each of the multiple processing cores. In an optional embodiment, the multiple processing cores include a master core and a slave core. When the processor 71 uses 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, it can be specifically set to: after receiving the target SMC message in the multiple SMC messages, the runtime component determines whether the target SMC message corresponds to the master core; if the target SMC message corresponds to the master core, the runtime component is used to execute the boot process corresponding to the master core according to the target SMC message to trigger the execution of the initialization logic corresponding to the master core in the trusted execution environment TEE; wherein, the target SMC message is any one of the multiple SMC messages.In an optional embodiment, when the processor 71 uses the runtime component to execute 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), the processor 71 may be specifically configured to: upon triggering the target SMC message, use the runtime component to load the image compiled for the TEE OS in user mode of the REE into a specified memory address; and after completing the image loading, use the runtime component to trigger the execution of the initialization logic corresponding to the main core in the trusted execution environment (TEE). In an optional embodiment, when the processor 71 uses the runtime component to trigger the execution of the initialization logic corresponding to the main core in the trusted execution environment (TEE), the processor 71 may be specifically configured to: if multiple TEE OSes exist in the TEE, use the runtime component to send a first trigger notification to a secure partition manager in the TEE for managing TEE OSes according to the target SMC message; use the secure partition manager to perform initialization configuration operations for the TEE OS on the main core according to the first trigger notification, and after completing the initialization configuration operations, invoke a preset instruction to trigger entry into the execution entry corresponding to the main core in the image. In an optional embodiment, the processor 71 may further be configured to: if the target SMC message corresponds to a slave core, use the runtime component to execute the boot process corresponding to the slave core in accordance with the target SMC message, thereby triggering the execution of initialization logic corresponding to the slave core in the trusted execution environment (TEE). In an optional embodiment, when using the runtime component to execute the boot process corresponding to the slave core in accordance with the target SMC message, thereby triggering the execution of initialization logic corresponding to the slave core in the trusted execution environment (TEE), the processor 71 may be configured to: if multiple TEE OSes exist in the TEE, use the runtime component to send a second trigger notification to a secure partition manager configured to manage the TEE OS in the TEE in accordance with the target SMC message; use the secure partition manager to perform an initialization configuration operation for the TEE OS on the slave core in accordance with the second trigger notification, and after completing the initialization configuration operation, call a preset instruction to trigger entry into the execution entry corresponding to the slave core in the image.In an optional embodiment, the processor 71 may be further configured to: in user mode of the REE, configure core identifiers for the master core and slave cores of the multiple processing cores; and record the core identifiers of the master core and the slave cores in a first register. The processor 71, when using a runtime component, determines whether the processing core corresponding to the target SMC message is the master core, by: accessing the first register using the runtime component, and if the core identifier of the processing core corresponding to the target SMC message is identified as the core identifier of the master core, determining that the processing core corresponding to the target SMC message is the master core. In an optional embodiment, when the processor 71 creates trigger threads for each of the multiple processing cores in user mode of the REE, the processor may be specifically configured to: create trigger threads in user mode of the REE that match the number of processing cores required to be occupied by the TEE OS; and configure a processing core affinity for each created trigger thread, so as to establish a binding relationship between the trigger thread and the processing core through the processing core affinity. In an optional embodiment, the processor 71 may be further configured to: utilize the runtime component to, upon detecting that the SMC message initiated for the current processing core has completed processing, return a process end notification to the user state of the REE; and upon receiving the process end notification, the user state of the REE may initiate an SMC message for the next processing core. In an optional embodiment, the processor 71 may be further configured to: utilize the runtime component to read from a specified register the storage address of the image compiled for the TEE OS by the user state of the REE; perform a signature verification on the image at the storage address; and, upon determining that the image passes the signature verification, load the image to a specified memory address. In an optional embodiment, the processor 71 may be further configured to: utilize the runtime component to, in the user state of the REE, call a custom interface provided by the TEE driver to utilize the custom interface to retrieve the image compiled for the TEE OS from a specified directory in the user state of the REE, and store the image in a specified buffer area; and configure the address of the buffer area in a second register; wherein the second register is a medium for transmitting the buffer area address agreed upon between the TEE driver and the runtime component. Furthermore, as shown in FIG7 , the computing device also includes other components, such as a communication component 72 and a power supply component 73. FIG7 schematically illustrates only some of the components and does not necessarily mean that the computing device includes only the components shown in FIG7 . It is worth noting that for the technical details of the above-mentioned computing device embodiments, reference can be made to the relevant descriptions in the aforementioned method embodiments. To save space, these details will not be repeated here, but this should not affect the scope of protection of this application.Accordingly, embodiments of the present application also provide a computer-readable storage medium storing a computer program. When executed, the computer program can implement the steps performed in the above-described method embodiments. The memory in FIG. 7 is configured to store the 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 or method operating on the computing platform, contact data, phone book data, messages, images, 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. The communication component in FIG. 7 is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device containing the communication component can access a wireless network based on a communication standard, such as WiFi, 2G, 3G, 4G / LTE, 5G, or other mobile communication networks, or a combination thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component also 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), infrared data association (IrDA), ultra-wideband (UWB), Bluetooth (BT), or other technologies. The power supply assembly in Figure 7 provides power to various components of the device containing the power supply assembly. The power supply assembly may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device containing the power supply assembly. Those skilled in the art will appreciate that embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. The present application is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present application.It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, such that the instructions, when executed by the processor of the computer or other programmable data processing device, produce a device for implementing the functions specified in one or more processes in the flowcharts and / or one or more blocks in the block diagrams. These computer program instructions can also be stored in a computer-readable memory capable of directing the computer or other programmable data processing device to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including an instruction device that implements the functions specified in one or more processes in the flowcharts and / or one or more blocks in the block diagrams. These computer program instructions can also be loaded onto a computer or other programmable data processing device, causing the computer or other programmable device to execute a series of operational steps to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device with steps for implementing the functions specified in one or more flow charts and / or one or more blocks in a block diagram. It should also be noted that the terms "comprise," "include," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a..." does not preclude the presence of additional identical elements in the process, method, commodity, or apparatus comprising the element. 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 used for analysis, storage, and display) involved in this application are all information and data authorized by the user or fully authorized by all parties. The collection, use, and processing of relevant data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or reject. The above description is merely an embodiment of this application and is not intended to limit this application. It will be apparent to those skilled in the art that various modifications and variations of this application are possible. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of this application are intended to be included within the scope of protection of this application.

Claims

Claims 1. A method for starting TEE OS, comprising: In the user state of the conventional execution environment REE, a secure mode call SMC message for instructing the startup of the TEE OS is initiated to the runtime component in the trusted basic firmware; Using the runtime component, the image compiled for the TEE OS in the user state of the REE is loaded to the specified memory address; using the runtime component, according to the SMC message triggering the running of the image in the specified memory address in the trusted execution environment TEE to start the TEE OS.

2. The method according to claim 1, wherein: Also includes: Before loading the image to the specified memory address, in the user state of the REE, an SMC message for transmitting resource requirements is initiated to the runtime component; using the runtime component, a resource configuration file adapted to the resource requirements is compiled for the TEE OS, so that the runtime component allocates resources to the TEE OS according to the resource configuration file.

3. The method according to claim 2, wherein: Using the runtime component, compile a resource configuration file that is adapted to the resource requirement for the TEE OS, including: if a resource configuration file corresponding to the TEE OS already exists, modify the resource configuration file according to the SMC message received this time for transmitting the resource requirement; wherein the modified resource configuration file is consistent with the resource requirement described in the image compiled for the TEE OS.

4. The method according to claim 1, wherein: Initiating a secure mode call SMC message for instructing TEE OS startup, including: if the TEE OS needs to occupy multiple processing cores, creating trigger threads for the multiple processing cores respectively in the user state of the REE; and running the trigger threads corresponding to the multiple processing cores respectively in the user state of the REE according to the startup order set for the multiple processing cores, so as to initiate the SMC messages for the multiple processing cores respectively.

5. The method according to claim 4, wherein: The multiple processing cores include a master core and a slave core, and using 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, including: after receiving the target SMC message in the multiple SMC messages, the runtime component determines whether the target SMC message corresponds to the master core; if the target SMC message corresponds to the master core, the runtime component executes the boot process corresponding to the master core according to the target SMC message to trigger the running of the initialization logic corresponding to the master 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, wherein: The runtime component executes the target SMC message according to the target SMC message. The boot process corresponding to the main core is to trigger the initialization logic corresponding to the main core to run in the trusted execution environment TEE, including: under the trigger of the target SMC message, executing the operation of loading the image compiled for the TEE OS in the user state of the REE to the specified memory address; after completing the image loading, triggering the initialization logic corresponding to the main core to run in the trusted execution environment TEE.

7. The method according to claim 6, wherein: The runtime component triggers the execution of initialization logic corresponding to the main core in the trusted execution environment TEE, including: when there are multiple TEE OSes in the TEE, the runtime component sends a first trigger notification to the secure partition manager configured to manage the TEE OS in the TEE according to the target SMC message; the secure partition manager performs an initialization configuration operation on the main core for the TEE OS according to the first trigger notification, and after completing the initialization configuration operation, calls a preset instruction to trigger entry into the running entry corresponding to the main core in the image.

8. The method according to claim 5, wherein: It also includes: if the target SMC message corresponds to the slave core, the runtime component executes the boot process corresponding to the slave core according to the target SMC message to trigger the execution of the initialization logic corresponding to the slave core in the trusted execution environment TEE.

9. The method according to claim 8, wherein: The runtime component executes the boot process corresponding to the slave core according to the target SMC message to trigger the initialization logic corresponding to the slave core to run in the trusted execution environment TEE, including: when there are multiple TEE OSes in the TEE, the runtime component sends a second trigger notification to the secure partition manager configured to manage the TEE OS in the TEE according to the target SMC message; the secure partition manager performs an initialization configuration operation on the TEE OS on the slave core according to the second trigger notification, and after completing the initialization configuration operation, calls a preset instruction to trigger entry into the running entry corresponding to the slave core in the image.

10. The method according to claim 5, wherein: In the user state of the REE, respectively configuring core identifiers for the master core and the slave cores in the multiple processing cores; Recording the core identifier of the master core and the core identifier of the slave core in the first register respectively; Determining whether the processing core corresponding to the target SMC message is the main core includes: the runtime component accesses the first register, and if it is identified that the core identifier of the processing core corresponding to the target SMC message is the core identifier of the main core, determining 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 in the user state of the REE with a number of processing cores that are consistent with the number of processing cores that the TEE OS needs to occupy; configuring a processing 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 processing core affinity.

12. The method according to claim 4, wherein: Also includes: After monitoring that the SMC message initiated for the current processing core has completed the processing flow, the runtime component returns a flow end notification to the user state of the REE; after receiving the flow end notification, the user state of the REE initiates an SMC message for the next processing core. 19 13. The method according to claim 1, wherein: Also includes: Using the runtime component to read the storage address of the image compiled by the TEE OS in the user state of the REE from the specified register; Performing signature verification on the image in the storage address; When it is determined that the image passes the signature verification, an operation of loading the image into a specified memory address is performed.

14. The method according to claim 1, wherein: Also includes: In the user state of the REE, calling a custom interface provided by the TEE driver, so as to obtain the image compiled for the TEE OS from a specified directory in the user state of the REE using the custom interface, and storing the image in a specified buffer area; configuring the address of the buffer area into a second register; The second register is an address transmission medium of a buffer area agreed upon between the TEE driver and the runtime component.

15. A computing device, comprising a memory and a processor; the memory is configured to store one or more computer instructions; the processor is coupled to the memory and configured to execute the one or more computer instructions to execute the TEE OS startup method 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 TEE OS startup method according to any one of claims 1 to 14.

Images