A program running method, device, processor, chip and electronic device

Abstract

This application provides a program execution method, apparatus, processor, chip, and electronic device. The method includes: determining a program to be executed; transmitting program information of the program to a security device, so that the security device matches the program with a whitelist based on the program information; receiving a matching result transmitted by the security device; if the matching result indicates that the program matches the whitelist, executing the program; if the matching result indicates that the program does not match the whitelist, starting a security container and executing the program within the security container. This application can ensure the security of the computer system while avoiding the high false alarm rate of the whitelist mechanism and improving the flexibility of program execution under the whitelist mechanism, thereby achieving program execution while balancing security and flexibility.

Description

Technical Field

[0001] This application relates to the field of trusted computing technology, specifically to a program execution method, apparatus, processor, chip, and electronic device. Background Technology

[0002] Trusted computing is a technology promoted and developed by the Trusted Computing Group (TCG). One of the core goals of trusted computing is to ensure the integrity of computer systems and programs, thereby ensuring that computer systems and programs operate in a trusted state.

[0003] Trusted computing involves the execution of programs. Therefore, how to ensure the security of computer systems while running programs and improve the flexibility of computer systems in running programs has become a technical problem that needs to be solved by those skilled in the art. Summary of the Invention

[0004] In view of this, embodiments of this application provide a program running method, apparatus, processor, chip, and electronic device to ensure the security of a computer system when running a program and to improve the flexibility of the computer system in running programs.

[0005] To achieve the above objectives, the embodiments of this application provide the following technical solutions.

[0006] In a first aspect, embodiments of this application provide a program execution method, including:

[0007] Identify the program to be run;

[0008] The program information of the program is transmitted to the security device so that the security device can match the program with the whitelist based on the program information.

[0009] Receive the matching result transmitted by the security device;

[0010] If the matching result indicates that the program matches the whitelist, then run the program;

[0011] If the matching result indicates that the program does not match the whitelist, a secure container is started, and the program is run in the secure container.

[0012] Secondly, embodiments of this application provide a program running apparatus, including:

[0013] The program determination module is used to determine the program to be run;

[0014] The program information transmission module is used to transmit the program information of the program to the security device, so that the security device can match the program with the whitelist based on the program information.

[0015] A matching result receiving module is used to receive the matching result transmitted by the security device;

[0016] The program execution module is used to run the program if the matching result indicates that the program matches the whitelist.

[0017] A secure container runtime module is used to start a secure container and run the program in the secure container if the matching result indicates that the program does not match the whitelist.

[0018] Thirdly, embodiments of this application provide a processor configured to execute the program execution method as described in the first aspect above.

[0019] Fourthly, embodiments of this application provide a chip, the chip including the processor as described in the third aspect above.

[0020] Fifthly, embodiments of this application provide an electronic device, which includes the chip described in the fourth aspect above.

[0021] In the program execution method provided in this application embodiment, when the processor needs to run a program, the processor can transmit the program information of the program to be run to a security device. The security device then matches the program with a whitelist based on the program information to determine the matching result. Subsequently, the processor can obtain the matching result transmitted by the security device. If the matching result is that the program matches the whitelist, the processor can run the program normally. If the matching result is that the program does not match the whitelist, the processor can start a security container to run the program in the security container, so that untrusted programs that do not match the whitelist can be executed in the secure and trusted environment provided by the security container. The program execution method provided in this application embodiment is based on a whitelist mechanism. Unlike the whitelist mechanism's approach of alerting and blocking untrusted programs, this application embodiment can launch a secure container for untrusted programs that do not match the whitelist, allowing the untrusted program to run within the secure container. This avoids erroneous alerts and blocking when the untrusted program is not malicious. Furthermore, even if the untrusted program is malicious, the secure and trusted environment provided by the secure container in this application embodiment makes it difficult for the malicious program to escape from the secure container, thus preventing the malicious program's execution from impacting the security of the computer system.

[0022] As can be seen, the program execution method provided in this application embodiment can, under the whitelist mechanism, utilize a secure container to run untrusted programs that do not match the whitelist. This ensures computer system security while avoiding erroneous alarms and execution blockages when the untrusted program is not malicious, thus improving the flexibility of program execution on the computer system. Therefore, this application embodiment can, while ensuring computer system security, avoid the high false alarm rate of the whitelist mechanism and improve the flexibility of program execution on the computer system under the whitelist mechanism, thereby achieving program execution based on the whitelist mechanism while balancing security and flexibility. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0024] Figure 1 This is an example diagram illustrating key technologies for trusted computing.

[0025] Figure 2 This is an example diagram of a trusted computing architecture.

[0026] Figure 3 A flowchart of the program execution method provided in the embodiments of this application.

[0027] Figure 4 This is an example diagram illustrating the relationship between processors, security devices, and operating systems.

[0028] Figure 5 This is a flowchart illustrating a method for setting a whitelist in a security device, as provided in an embodiment of this application.

[0029] Figure 6 This is an example diagram illustrating the relationship between processors, security devices, operating systems, and trusted servers.

[0030] Figure 7 Another flowchart of the program execution method provided in the embodiments of this application.

[0031] Figure 8 A block diagram of a program running apparatus provided in an embodiment of this application. Detailed Implementation

[0032] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0033] The basic idea of ​​trusted computing is to establish a root of trust in a computer system, and then measure the hardware platform, operating system, and programs layer by layer from the root of trust, thereby extending the trust of computing to the entire computer system. At the same time, security protection measures are taken to ensure the data integrity and predictability of computing resources, thereby improving the trustworthiness of the computer system.

[0034] Trusted computing encompasses various technological aspects, including hardware, software, and networks. Figure 1 An example diagram illustrating key technologies of trusted computing is shown, such as... Figure 1 As shown, the key technologies involved in trusted computing mainly include: root of trust 110, trusted platform module 120, trust chain transmission technology 130, trusted BIOS (Basic Input Output System) technology 140, trusted computing software stack technology 150, trusted network connection technology 160, etc.

[0035] Among them, the Root of Trust 110 is the foundation of trusted computing and the starting point for implementing security controls. The Root of Trust defined by the TCG includes the RTM (Root of Trust for Measurement), responsible for integrity measurement; the RTR (Root of Trust for Report), responsible for reporting the Root of Trust; and the RTS (Root of Trust for Storage), responsible for storing the Root of Trust. The core function of the Root of Trust is to measure and verify the trusted software stack to ensure trustworthiness.

[0036] The Trusted Platform Module 120 is part of the root of trust in trusted computing. It can be a chip, such as a System-on-Chip (SoC), including components like a processor, memory, input / output, cryptographic coprocessor, random number generator, and embedded operating system. The Trusted Platform Module has cryptographic computation and storage capabilities, providing functions such as key generation and public key signing. It internally contains non-volatile memory to permanently store user identity or secret information. For ease of understanding, let's take the Trusted Platform Module 120 as an example, consisting of a hardware platform and an operating system. Figure 2 An exemplary diagram of a trusted computing architecture is shown, such as... Figure 2As shown, trusted computing involves hardware platform 210, operating system 220 and program 230.

[0037] The hardware platform 210 includes a processor 211, a security device 212, and a BIOS 213. In one example, the processor 211 can be considered the core of the computer system's computation and control, and the final execution unit for information processing and program execution; for example, a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), or an ASIC (Application Specific Integrated Circuit). The security device 212 can be a device dedicated to data security, such as a specially designed security processor or a trusted chip for data security.

[0038] It should be further explained that the BIOS, based on trusted computing and trusted BIOS technology 140, can perform hardware-level control of the computer system's input and output devices, serving as the hub connecting software programs and hardware devices. The BIOS is responsible for operations such as detecting and initializing various hardware devices after the computer system powers on, loading and booting the operating system, providing interrupt services, and setting system parameters. In possible implementations, for highly trusted computer systems, the BIOS and security devices (such as security chips) can jointly constitute the physical root of trust for the computer system.

[0039] Additionally, it should be noted that trust chains are used to describe the trustworthiness of a computer system; based on trusted computing-based trust chain transmission technology 130, the trust chain transmission of a computer system can start from the root of trust, then proceed to the BIOS execution upon power-up of the hardware platform, and then to... Figure 2 The loading of operating system 220 is shown, and finally, the operating system starts up. Figure 2 The process of running program 230 shown above involves a series of steps; the trust chain is passed from the root of trust to each layer in the above process, thereby ensuring that the computing environment of the computer system is in a trustworthy state.

[0040] Furthermore, the trust chain can acquire various data affecting the trustworthiness of trusted platform modules through a trust measurement mechanism, and determine the trustworthiness of the trusted platform modules by comparing these data with expected data. The measurement referred to here can be understood as collecting data such as the state of the operating system or program, and verifying whether the collected data is consistent with the reference data. If they are consistent, the verification is successful; if they are inconsistent, the verification fails.

[0041] Back Figure 2As shown, during the layer-by-layer transmission of the root of trust, it can be passed from hardware platform 210 to operating system 220. Operating system 220 may include hardware drivers 221, kernel 222, and APIs (Application Programming Interfaces) 223. Hardware drivers 221 may include device drivers and program drivers, used to drive the devices on the hardware platform; the kernel 222 is the core of the operating system, used to manage memory, files, peripherals, and system resources; and API 223 may be an interface to program 230. Program 230 can be understood as the software program running on processor 211 in hardware platform 210.

[0042] In trusted computing, the security of the operating system and programs can be enhanced by trusted computing software stack technology 150. The trusted computing software stack can be understood as supporting software for trusted computing, providing interfaces for other software to use secure devices and enhancing the security of the operating system and programs by implementing security mechanisms. Furthermore, the trusted computing software stack creates trust by constructing a hierarchical secure and trusted protocol stack, which can provide functions such as basic data privacy protection, platform identification, and authentication.

[0043] Furthermore, if Figure 2 The architecture shown also involves network connectivity, which can be enhanced by trusted network connectivity technology 160 based on trusted computing. Trusted network connectivity technology 160 primarily addresses the issue of trusted network access for computer systems such as terminal hosts in a network environment. For example, before a computer system accesses the network, trusted network connectivity technology can check whether the computer system complies with the network access policy, thereby isolating or restricting suspicious or problematic computer systems from accessing the network until the computer system is modified or appropriate security measures are taken to ensure compliance with the network access policy.

[0044] As can be seen from the above introduction, trusted computing involves the execution of upper-layer programs. These programs may be trusted programs (such as secure programs, trustworthy ordinary programs, etc.) or malicious programs (such as viruses or attack software with malicious intent). Therefore, during program execution, it is necessary to identify whether the program is trusted or malicious in order to prevent malicious programs from running in the computer system and ensure the security of the computer system.

[0045] One way to identify whether a program is trusted or malicious is to use a blacklist to identify malicious programs, and another way is to use a whitelist to identify trusted programs. These will be introduced separately below.

[0046] A blacklist is a database that records information about malicious programs, such as a virus database that records information about antivirus software. If a program running on a computer system is recorded in the blacklist, the program can be considered malicious, and the computer system can block the program from running, thus avoiding the security risks caused by the malicious program.

[0047] A whitelist is the counterpart to a blacklist. It can be understood as a database of trusted programs that are allowed to execute, established under trusted computing rules. For example, a whitelist might record program information such as attributes, process name, file name, and digital signature. In the implementation of the whitelist mechanism, programs matching the whitelist are considered trusted and can run in specific environments. Conversely, programs that do not match the whitelist are considered untrusted. The whitelist mechanism can issue alerts for untrusted programs and, in severe cases, block or delete them, thereby maximizing the security of the computer system.

[0048] Compared to blacklist mechanisms, whitelist mechanisms are more difficult to deploy and manage, but blacklist mechanisms have the following drawbacks:

[0049] The blacklist mechanism relies on databases such as virus databases to identify malicious programs. If the virus databases or other databases are not updated in a timely manner, or if the malicious program is a new malicious program that has not yet been recorded in the blacklist, the blacklist mechanism will be less effective in identifying malicious programs, thus limiting the effectiveness of the blacklist mechanism.

[0050] In addition, with the increasing number of viruses, Trojans and other malicious programs, the blacklist has become increasingly large, which increases the workload and time required to identify malicious programs using the blacklist. Therefore, the speed and efficiency of identifying malicious programs using the blacklist have decreased accordingly.

[0051] Given the aforementioned shortcomings of blacklist mechanisms, in the context of the information age, utilizing whitelist mechanisms to ensure secure program operation has become a better choice. This is because whitelist mechanisms based on trusted computing can fundamentally address security vulnerabilities in computer systems. For example, any program (such as software or process) not recorded in the whitelist will be alerted or prevented from executing, and in severe cases, it may even prompt the user to take security measures. It should be noted that in the context of the information age, the attack and defense technologies in the software security industry are constantly upgrading, and new security threats are emerging more frequently and causing greater harm, which places more diverse demands on security strategies and security products.

[0052] However, the performance of the whitelist mechanism still needs improvement. For example, although the whitelist mechanism can solve security vulnerabilities in computer systems, it still has the following shortcomings:

[0053] Programs not matching the whitelist are not necessarily malicious. For example, with computer system upgrades, application updates, and network changes, program information may change accordingly. Even if a program with changed information is not recorded in the whitelist, it is not necessarily malicious (i.e., no malicious program is attacking the computer system at this time). If the whitelist mechanism alerts for every program not matching the whitelist, it will result in a high false alarm rate (the false alarm rate can be considered the probability of false alarms). With a high false alarm rate under the whitelist mechanism, users may need to check each alarm message individually, increasing their unnecessary workload. In other words, the whitelist mechanism's approach of alerting for every program not matching the whitelist may lead to a high false alarm rate even when the program not matching the whitelist is not malicious, resulting in poor flexibility in program execution on the computer system.

[0054] Based on this, this application provides a trusted computing program execution scheme under the whitelist mechanism to ensure the security of the computer system during program execution and improve the flexibility of the computer system in running programs, thereby avoiding the high false alarm rate under the whitelist mechanism and improving the performance of trusted computing. The program execution scheme provided by this application can directly run programs that match the whitelist and use a secure container to run programs that do not match the whitelist. This allows the program to run when the program that does not match the whitelist is not malicious, avoiding false alarms or blocking of non-malicious programs. Furthermore, even if the program that does not match the whitelist is malicious, because it runs using a secure container, the malicious program is unlikely to escape from the secure container. Therefore, this application can use a secure container to run programs that do not match the whitelist under the whitelist mechanism, ensuring the security of the computer system while avoiding the high false alarm rate of the whitelist mechanism and improving the flexibility of the computer system in running programs under the whitelist mechanism.

[0055] Based on the above ideas Figure 3 An exemplary flowchart of an optional program execution method provided in an embodiment of this application is shown. This method can be implemented by a processor (e.g., a CPU, GPU, ASIC, or other processor used to run and execute programs) and a security device (e.g., a security processor, security chip, or other device dedicated to data security). Refer to... Figure 3 The method process may include the following steps.

[0056] In step S310, the processor determines the program to be run.

[0057] In step S311, the processor transmits the program information of the program to the security device.

[0058] When a processor needs to run a program, it can determine the program to be run and its program information, and then pass the program information to a security device so that the security device can perform whitelist matching. In some embodiments, the program information may include at least one of the following: program attributes, process name, file name, and digital signature.

[0059] In step S312, the security device matches the program with the whitelist based on the program information of the program and determines the matching result.

[0060] In step S313, the security device transmits the matching result to the processor.

[0061] In this embodiment, the whitelist is stored by a dedicated security device for data security, thereby preventing the whitelist from being illegally tampered with or attacked. After obtaining the program information of the program transmitted by the processor, the security device can match the program with the whitelist based on the program information to determine whether the program is recorded in the whitelist, thus obtaining a matching result. In some embodiments, the security device can query the whitelist to see if it records the program information, thereby matching the program with the whitelist and obtaining a matching result. As an optional implementation, the matching result obtained by the security device may be that the program matches the whitelist (i.e., the program is a trusted program), or it may be that the program does not match the whitelist. When the program does not match the whitelist, the program is an untrusted program. This untrusted program may be a non-malicious program whose information has changed (e.g., due to changes in program information caused by computer system upgrades, application updates, network changes, etc.), or it may be a malicious program.

[0062] After obtaining the matching result, the security device can pass the matching result to the processor so that the processor can perform subsequent processing on the program.

[0063] As an optional implementation, the security device can be a dedicated security device such as a security processor, which can be heterogeneous with the processor running the program. In other optional implementations, the security device can also be a specific security mode of the processor (e.g., CPU). This application does not limit the specific configuration of the security device, as long as it ensures that the security device is in a trusted state and is not affected by the operating system.

[0064] In step S314, if the processor determines that the matching result is that the program matches the whitelist, it runs the program.

[0065] In step S315, if the processor determines that the matching result is that the program does not match the whitelist, it starts a secure container and runs the program in the secure container.

[0066] After receiving the matching result from the security device, the processor can perform different processing on the program based on the different matching results. If the matching result shows that the program matches the whitelist, the program is a trusted program, and the processor can run the program normally; for example, the processor can use the operating system to run the program. If the matching result shows that the program does not match the whitelist, the program is an untrusted program. Unlike the processor outputting alarm information or even blocking the program from running, the processor can start a secure container to run the program in the secure container. This allows the program to run in the secure environment provided by the secure container even when it does not match the whitelist. Furthermore, even if the program that does not match the whitelist is a malicious program, it is difficult for the malicious program to escape from the secure container, thus avoiding the impact of the malicious program on the security of the computer system. At the same time, when the program that does not match the whitelist is a non-malicious program with changing information, this embodiment of the application can ensure that the non-malicious program is run, avoid the non-malicious program being alerted or blocked from running, and avoid a high false alarm rate.

[0067] In some embodiments, the secure container can be implemented based on a hardware-based TEE (Trusted Execution Environment), and the memory space corresponding to the secure container can be encrypted with a separate key. This ensures that even if a program that does not match the whitelist is considered malicious, the hardware TEE implementation of the secure container and the separate key encryption of the memory space prevent malicious programs from attacking the computer system or other programs through buffer overflows or other vulnerabilities within the secure container, thus protecting the security of the computer system.

[0068] It should be noted that the container provided in this application embodiment for running programs that do not match the whitelist is a secure container with security features. This secure container has the characteristics of hardware-based TEE implementation and memory space encrypted with a separate key, which is different from ordinary containers that share operating system and file system.

[0069] For ease of understanding, Figure 4 An exemplary diagram illustrating the relationship between the processor, security device, and operating system (OS) is shown below. Figure 4As shown, the processor and security device can be configured on the hardware platform. For a program to be run on the processor, if the security device determines that the program matches a whitelist, the program is considered trusted, and the hardware platform can run the trusted program using the operating system. If the security device determines that the program does not match the whitelist, the program is considered untrusted, and the hardware platform can launch a secure container and run the untrusted program within the secure container using the operating system. In one implementation example, Figure 4 The security device shown can be a hardware device (e.g., a security processor) that is set up independently of the processor. In other possible implementations, the security device can be implemented through processor mode switching, for example, the processor switches to a security mode to be in a secure and trusted state, and then the processor in security mode implements the functions of the security device.

[0070] As an optional implementation, the secure container referred to in this application embodiment can be various forms of confidential computing sandboxes, which have the characteristics of hardware-based TEE implementation and separate encryption of memory space; for example, the secure container can be an encrypted Kata container, an encrypted virtual machine, etc. It should be noted that an encrypted Kata container is a form of Kata container with encryption properties. For example, Kata containers do not need to share the host's hardware resources and kernel. Each Kata container runs on an independent virtual machine, thereby isolating Kata containers through different virtual machines, solving the security and isolation problems between Kata containers; on this basis, Kata containers introduce key encryption properties (for example, an encrypted Kata container is a Kata container with key encryption properties), which can make Kata containers more secure and make programs running in Kata containers less likely to escape.

[0071] An encrypted virtual machine is a virtual machine based on secure virtualization technology. The memory space of an encrypted virtual machine can be encrypted using the virtual machine key, thereby ensuring the data security of the encrypted virtual machine. Furthermore, the memory space of an encrypted virtual machine can be isolated by hardware (for example, memory is isolated into secure memory space and ordinary memory space at the hardware level, and the memory space of the encrypted virtual machine is allocated from the secure memory space), ensuring that the memory space of the encrypted virtual machine is secure under hardware isolation and cannot be accessed by the host or other virtual machines.

[0072] Of course, the form of the secure container in the above example is only optional. Any confidential computing sandbox with hardware TEE implementation features and memory space encrypted with a separate key can be used as a secure container for running untrusted programs in the embodiments of this application. The confidential computing sandbox with the above-mentioned characteristics, given the hardware TEE implementation features and the memory space encrypted with a separate key, has a trusted state and is not affected by the operating system.

[0073] It should be further explained that the inventors of this application had considered constructing an isolated environment using separate physical machines and isolated networks to run untrusted programs. However, the implementation of separate physical machines and isolated networks is relatively complex and costly, and the security still needs to be improved. Therefore, the inventors of this application have innovatively utilized a secure container to run untrusted programs under a whitelist mechanism. Based on the hardware TEE characteristics and individual key properties of the secure container, a secure environment is provided for the execution of untrusted programs, ensuring the security of the computer system during the execution of untrusted programs and improving the flexibility of the computer system in running programs.

[0074] In the program execution method provided in this application embodiment, when the processor needs to run a program, the processor can transmit the program information of the program to be run to a security device. The security device then matches the program with a whitelist based on the program information to determine the matching result. Subsequently, the processor can obtain the matching result transmitted by the security device. If the matching result is that the program matches the whitelist, the processor can run the program normally. If the matching result is that the program does not match the whitelist, the processor can start a security container to run the program in the security container, so that untrusted programs that do not match the whitelist can be executed in the secure and trusted environment provided by the security container. The program execution method provided in this application embodiment is based on a whitelist mechanism. Unlike the whitelist mechanism's approach of alerting and blocking untrusted programs, this application embodiment can launch a secure container for untrusted programs that do not match the whitelist, allowing the untrusted program to run within the secure container. This avoids erroneous alerts and blocking when the untrusted program is not malicious. Furthermore, even if the untrusted program is malicious, the secure and trusted environment provided by the secure container in this application embodiment makes it difficult for the malicious program to escape from the secure container, thus preventing the malicious program's execution from impacting the security of the computer system.

[0075] As can be seen, the program execution method provided in this application embodiment can, under the whitelist mechanism, utilize a secure container to run untrusted programs that do not match the whitelist. This ensures computer system security while avoiding erroneous alarms and execution blockages when the untrusted program is not malicious, thus improving the flexibility of program execution on the computer system. Therefore, this application embodiment can, while ensuring computer system security, avoid the high false alarm rate of the whitelist mechanism and improve the flexibility of program execution on the computer system under the whitelist mechanism, thereby achieving program execution based on the whitelist mechanism while balancing security and flexibility.

[0076] In some further embodiments, embodiments of this application may obtain a whitelist through interaction with a trusted server, and then set the whitelist in a security device dedicated to data security. As an optional implementation, Figure 5 An exemplary flowchart of an optional method for setting a whitelist in a security device is shown in an embodiment of this application. This method can be implemented by a processor, a trusted server, and a security device.

[0077] Reference Figure 5 The method process may include the following steps.

[0078] In step S510, the processor initializes the operating system.

[0079] In step S511, the processor measures the elements involved in trusted computing during operating system initialization and generates a trusted report based on the measurement results.

[0080] The processor can initialize the operating system upon power-up of the computer system; during the initialization process, the processor can generate a trust report for the computer system. In some embodiments, the processor can measure the elements involved in trusted computing during operating system initialization, and generate a trust report based on the measurement results. As an optional implementation, the elements involved in trusted computing during operating system initialization may be, for example, BIOS, GRUB (GRand Unified Bootloader), and Kernel; where GRUB is a multi-boot manager that can select the operating system to boot when multiple operating systems coexist. GRUB can load the operating system's kernel and initialize the operating system, or delegate boot control to the operating system to complete the boot process. In optional implementations, embodiments of this application can measure the BIOS, GRUB, and Kernel.

[0081] It should be noted that the metrics involved in operating system initialization can be understood as collecting data from elements during operating system initialization and comparing the collected data with reference data to obtain the measurement result. For example, embodiments of this application can collect data from the BIOS, GRUB, and Kernel during operating system initialization, and then compare the collected data from the BIOS, GRUB, and Kernel with reference data from the BIOS, GRUB, and Kernel during operating system initialization to obtain the measurement result.

[0082] After obtaining the measurement results, the processor can generate a trusted report corresponding to the operating system initialization and pass the trusted report to the trusted server for processing.

[0083] In step S512, the processor transmits the trusted report to the trusted server.

[0084] In step S513, the trusted server provides correctness feedback on the trusted report and transmits the feedback result to the processor.

[0085] After receiving the trusted report from the processor, the trusted server verifies its correctness and provides feedback, resulting in a response. The feedback may indicate that the trusted report is correct or that it is invalid. The trusted server can then pass this feedback to the processor, allowing the processor to perform different subsequent processing based on the different feedback outcomes.

[0086] In step S514, if the processor determines that the feedback result is a reliable report exception, it performs a shutdown process.

[0087] After receiving feedback from the trusted server, if the feedback indicates that the trusted report generated by the processor is abnormal, the processor can confirm that there is an abnormality in the operating system initialization process. The processor can then terminate the computer system's boot process and shut down the computer system.

[0088] In step S515, if the processor determines that the feedback result is a correct trusted report, it requests a whitelist from the trusted server.

[0089] In step S516, the trusted server passes the whitelist to the processor.

[0090] After receiving feedback from the trusted server, if the feedback indicates that the trusted report generated by the processor is correct, the processor can confirm that the operating system initialization process is correct. Thus, the processor can continue to request the whitelist of programs from the trusted server, so that the program execution scheme based on the whitelist mechanism in this application embodiment can have an implementation basis.

[0091] Upon receiving a request from a processor to access a whitelist, the trusted server can pass the whitelist of programs to the processor. Alternatively, the trusted server can periodically update the records in the whitelist based on the trustworthiness of the programs, ensuring that the whitelist maintains the most up-to-date list of trusted programs.

[0092] In step S517, the processor sets the whitelist in the security device.

[0093] In step S518, the processor completes the startup of the operating system.

[0094] After obtaining the whitelist from the trusted server, the processor can set the whitelist in the security device, allowing the security device to use the whitelist to match and process programs running on the processor. After setting the whitelist in the security device, the processor can complete the operating system startup, thus implementing the whitelist setting during the operating system's initialization process.

[0095] For ease of understanding, Figure 6 An exemplary diagram illustrating the relationship between a processor, security device, operating system, and trusted server is provided, in conjunction with... Figure 4 , Figure 5 and Figure 6 As shown, during the operating system initialization process, the processor can obtain a whitelist from a trusted server and set the whitelist in the security device. Then, after the processor completes the initialization and startup of the operating system, if there are programs to be run, the security device can match the programs with the whitelist based on the program information. If the program is a trusted program that matches the whitelist, the processor can use the already started operating system to run the program normally. If the program is an untrusted program that does not match the whitelist, the processor can start a security container and use the operating system to run the untrusted program in the security container.

[0096] In some further embodiments, if the program to be run by the processor is an untrusted program, the program may be a malicious program or a non-malicious program not recorded in the whitelist. In this case, the embodiments of this application can further identify whether the untrusted program is a malicious program, and thus output alarm information and / or block the program from running when the untrusted program is a malicious program, so as to avoid the computer system from unnecessarily executing the malicious program, thereby saving the computing resources of the computer system.

[0097] From the processor's perspective, as an optional implementation... Figure 7 An exemplary flowchart of another optional program execution method provided in the embodiments of this application is shown. This method flow can be implemented by a processor. (Refer to...) Figure 7 The method process may include the following steps.

[0098] In step S710, the program to be run is determined.

[0099] In step S711, the program information of the program is transmitted to the security device so that the security device can match the program with the whitelist based on the program information.

[0100] In step S712, the matching result transmitted by the security device is received.

[0101] In step S713, if the matching result is that the program matches the whitelist, the program is run.

[0102] As an optional implementation, the descriptions of steps S710 to S713 can be found in the corresponding sections above, and will not be repeated here.

[0103] In step S714, if the matching result is that the program does not match the whitelist, it is determined whether the program is malicious. If yes, step S715 is executed; otherwise, step S716 is executed.

[0104] In this embodiment of the application, when the matching result of the security device is that the program does not match the whitelist, the program can be confirmed as an untrusted program. Since an untrusted program may be a malicious program or a non-malicious program, this embodiment of the application can further determine whether the program to be run by the processor is a malicious program. In this way, when the program is a malicious program, alarm information is output and the program is blocked from running, so as to save the computing resources of the computer system.

[0105] In some embodiments, this application can incorporate a blacklist mechanism, matching the program against the blacklist based on the program's information to determine whether the program is malicious. Alternatively, the blacklist can be stored in a security device. The security device can further match the program against the blacklist based on the program's information to obtain a matching result. The security device can then feed back the blacklist matching result to the processor, enabling the processor to determine whether the program is malicious. In one implementation example, if the security device confirms a mismatch between the program and the whitelist when matching the program, it can further match the program against the blacklist to obtain a matching result, which is then fed back to the processor. The processor can then, based on the whitelist matching result fed back by the security device, further confirm whether the program is malicious by using the blacklist matching result fed back by the security device if it confirms a mismatch between the program and the whitelist.

[0106] In other embodiments, the present application embodiments can identify whether a program is a malicious program based on the sampling information of the program's historical execution in the secure container, and thus output alarm information and block the program's execution when the program is identified as a malicious program; furthermore, when the processor confirms that the program is a malicious program, it can record the program information of the program in the blacklist (for example, the processor can send a blacklist update request to a trusted server to request that the program information of the program be recorded in the blacklist).

[0107] In step S715, an alarm message is output and the program is blocked from running.

[0108] In this embodiment of the application, when it is further confirmed that a program that does not match the whitelist is a malicious program, an alarm message can be output and the program's operation can be blocked, thereby blocking the unnecessary operation of the malicious program and saving the computer system's computing resources while ensuring the security of the computer system.

[0109] In step S716, a secure container is started, and the program is run within the secure container.

[0110] In this embodiment of the application, when it is further confirmed that a program that does not match the whitelist is not a malicious program, the program can be run through a secure container, so that programs that are not malicious but are not recorded in the whitelist can be run smoothly, thereby accurately improving the flexibility of the computer system in running programs.

[0111] It should be noted that, Figure 7 The illustrated method further determines whether the program is malicious when it is determined that the program does not match the whitelist. Only if the program is not malicious is a secure container started and the program run within the secure container. Alternatively, this embodiment can start a secure container first when a program is determined to be mismatched with the whitelist, and run the program within the started secure container. During the program's execution within the secure container, this embodiment can determine whether the program is malicious. If the program is not malicious, it continues running within the secure container; if the program is malicious, an alarm message is output and the program's execution is blocked.

[0112] In other words, in one implementation, this embodiment can start a secure container and run the program within it when it is determined that the program does not match the whitelist and the program is not malicious. In another implementation, this embodiment can also start a secure container and run the program within it when it is determined that the program does not match the whitelist; then, during program execution, it can determine whether the program is malicious (for example, by identifying whether the program is malicious based on sampling information from the program's historical execution within the secure container); if the program is malicious, its execution within the secure container can be blocked to avoid the computer system unnecessarily opening malicious programs and to save the computer system's computing resources.

[0113] In one implementation example, taking the opening of a webpage through a browser program by a computer system as an example, if the webpage's URL or script does not match the whitelist, the computer system can start a secure container and run the webpage opened by the browser program within the secure container, thus allowing the webpage to be opened normally. Even if the webpage opened by the browser is a virus or other malicious program, this embodiment of the application can isolate the webpage opened by the browser program through the secure container, preventing the webpage program from escaping and launching malicious attacks. Furthermore, if, through a blacklist mechanism or webpage sampling information, it is identified that the webpage opened by the browser program is a virus or other malicious program, the computer system can output an alarm message and block the browser program from opening the webpage, preventing the computer system from unnecessarily opening malicious webpages through the browser program and saving the computer system's computing resources.

[0114] In further embodiments, the solutions provided in this application can effectively supplement honeypot trapping technology, enabling its deployment in a more secure and lightweight manner. For example, deploying honeypot trapping technology using secure containers is more lightweight than traditional virtual machine or host-based honeypot trapping technology, and the encryption characteristics of secure containers make it difficult for malicious programs captured by honeypot trapping technology to escape. Furthermore, based on the deployment of honeypot trapping technology using secure containers, this application's embodiments further combine whitelisting and blacklisting mechanisms to make malicious programs easier to capture. It should be noted that honeypot trapping technology evolved from traditional honeypot technology, using simulation technology to create a trapping environment, and through a series of enticing and disguised methods, inducing attackers to transfer their targets to the trapping environment; and taking measures such as interception, behavior analysis, and source tracing to protect the real business environment; compared with traditional honeypot technology, the biggest difference of honeypot trapping technology is that the defense process changes from passive to active.

[0115] The program execution method provided in this application embodiment can set a whitelist through a security device (such as a security processor) and match programs with the whitelist, thereby avoiding the security risk of the whitelist being easily tampered with by software-based whitelist matching. Simultaneously, for programs that do not match the whitelist, this application embodiment can utilize a secure container to run the program, ensuring that programs that do not match the whitelist will not pose a security threat to the computer system, and allowing non-malicious programs that do not match the whitelist to be run, improving the flexibility of the computer system in running programs. Therefore, this application embodiment can achieve program execution based on trusted computing while balancing security and flexibility.

[0116] The program execution apparatus provided in the embodiments of this application will be described below. The apparatus described below can be considered as the functional modules that the processor needs to set up to implement the program execution method provided in the embodiments of this application. These functional modules can be the hardware functional logic of the processor or the functional logic implemented based on software instructions. The contents of the program execution apparatus described below can be referred to in correspondence with the contents described above.

[0117] As an optional implementation Figure 8 An exemplary block diagram of the program running apparatus provided in an embodiment of this application is shown, such as... Figure 8 As shown, the device may include:

[0118] The program determination module 810 is used to determine the program to be run;

[0119] The program information transmission module 811 is used to transmit the program information of the program to the security device, so that the security device can match the program with the whitelist based on the program information.

[0120] The matching result receiving module 812 is used to receive the matching result transmitted by the security device;

[0121] Program execution module 813 is used to run the program if the matching result indicates that the program matches the whitelist;

[0122] The secure container runtime module 814 is used to start a secure container and run the program in the secure container if the matching result is that the program does not match the whitelist.

[0123] In some embodiments, the secure container is a confidential computing sandbox implemented using a hardware-based TEE, and the memory space corresponding to the secure container is encrypted using a separate key.

[0124] In some embodiments, the secure container includes: an encrypted Kata container, or an encrypted virtual machine;

[0125] The encrypted Kata container is a Kata container with key-based encryption. The Kata container does not need to share the host's hardware resources and kernel, and each Kata container runs on an independent virtual machine, so that Kata containers are isolated from each other through different virtual machines.

[0126] The encrypted virtual machine is a virtual machine based on secure virtualization technology. The memory space of the encrypted virtual machine is encrypted using the virtual machine key of the encrypted virtual machine, and the memory space of the encrypted virtual machine is isolated by hardware.

[0127] In some embodiments, the device can also be used for:

[0128] During the operating system initialization process, a whitelist is set for the security device.

[0129] In some embodiments, the device is used to set a whitelist in the security device during the initialization process of the operating system, including:

[0130] Perform operating system initialization;

[0131] The elements involved in trusted computing during operating system initialization are measured, and a trusted report is generated based on the measurement results.

[0132] The trusted report is transmitted to the trusted server so that the trusted server can provide feedback on the correctness of the trusted report;

[0133] Receive feedback results from the trusted server; if the feedback results indicate that the trusted report is correct, request a whitelist from the trusted server.

[0134] Set the whitelist returned by the trusted server in the security device.

[0135] In some further embodiments, the device can also be used to: perform a shutdown process if the feedback result is a reliable report of an anomaly.

[0136] In some embodiments, the means for measuring elements involved in trusted computing during operating system initialization includes:

[0137] Measuring BIOS, GRUB, and kernel.

[0138] In some embodiments, the secure container runner module 814 is configured to start a secure container and run the program in the secure container if the matching result indicates that the program does not match the whitelist, including:

[0139] If the matching result indicates that the program does not match the whitelist, determine whether the program is malicious.

[0140] If the program is not malicious, start a secure container and run the program in the secure container.

[0141] In some further embodiments, the device can also be used to: if the program is malicious, output an alarm message and block the operation of the program.

[0142] In other embodiments, the secure container runtime module 814 is configured to, if the matching result indicates that the program does not match the whitelist, start a secure container and run the program in the secure container, including:

[0143] If the matching result indicates that the program does not match the whitelist, start the secure container and run the program in the started secure container;

[0144] During the execution of the program within the secure container, it is determined whether the program is malicious.

[0145] If the program is not malicious, continue running the program in the secure container.

[0146] In some further embodiments, the device can also be used to: if the program is malicious, output an alarm message and block the operation of the program.

[0147] In some embodiments, the secure container runtime module 814 is used to determine whether the program is a malicious program, including:

[0148] Based on the matching results of the blacklist fed back by the security device, it is confirmed whether the program is malicious; wherein, when the security device matches the program with the whitelist, if it is confirmed that the program does not match the whitelist, the program is matched with the blacklist to obtain the matching result of the program and the blacklist.

[0149] Alternatively, based on sampling information from the program's historical execution within the secure container, it can be identified whether the program is malicious.

[0150] This application further provides a processor that can implement the program execution method provided in this application by configuring the program execution device described above. Alternatively, the processor can be configured to execute the program execution method provided in this application.

[0151] This application also provides a chip that includes the processor provided in the above-described embodiments of this application.

[0152] This application also provides an electronic device, such as a terminal device or a server device, which is a device in the form of a computer system. In this application embodiment, the electronic device may include the chip provided in the above application embodiment.

[0153] The foregoing describes multiple embodiment schemes provided by the embodiments of this application. The optional methods described in each embodiment scheme can be combined and cross-referenced with each other without conflict, thereby extending to a variety of possible embodiment schemes. These can all be considered as the embodiment schemes disclosed and published by the embodiments of this application.

[0154] While the embodiments disclosed above are described in this application, this application is not limited thereto. Any person skilled in the art can make various modifications and alterations without departing from the spirit and scope of this application; therefore, the scope of protection of this application should be determined by the scope defined in the claims.

Claims

1. A method for running a program, characterized in that, include: Identify the program to be run; The program information of the program is transmitted to the security device so that the security device can match the program with the whitelist based on the program information; the whitelist is set in the security device during the initialization process of the operating system. The security device is a hardware device, is in a trusted state, and is not affected by the operating system. Receive the matching result transmitted by the security device; If the matching result indicates that the program matches the whitelist, then run the program; If the matching result indicates that the program does not match the whitelist, a secure container is started, and the program is run in the secure container; the secure container is a confidential computing sandbox implemented based on a hardware-based Trusted Execution Environment (TEE), and the memory space corresponding to the secure container is encrypted with a separate key; The secure container includes: an encrypted virtual machine; The encrypted virtual machine is a virtual machine based on secure virtualization technology. The memory space of the encrypted virtual machine is encrypted using the virtual machine key of the encrypted virtual machine, and the memory space of the encrypted virtual machine is isolated by hardware. If the matching result indicates that the program does not match the whitelist, starting a secure container and running the program in the secure container includes: If the matching result indicates that the program does not match the whitelist, start the secure container and run the program in the started secure container; During the execution of the program within the secure container, it is determined whether the program is malicious. If the program is not malicious, continue running the program in the secure container; The method further includes: If the program is malicious, output an alarm message and block the program from running; The determination of whether the program is malicious includes: Based on the matching results of the blacklist fed back by the security device, it is confirmed whether the program is malicious; wherein, when the security device matches the program with the whitelist, if it is confirmed that the program does not match the whitelist, the program is matched with the blacklist to obtain the matching result of the program and the blacklist. Alternatively, based on sampling information from the program's historical execution within the secure container, it can be identified whether the program is malicious.

2. The program execution method according to claim 1, characterized in that, The secure container also includes: an encrypted kata container; The encrypted Kata container is a Kata container with key-based encryption. The Kata container does not need to share the host's hardware resources and kernel, and each Kata container runs on an independent virtual machine, so that Kata containers are isolated from each other through different virtual machines.

3. The program execution method according to claim 1, characterized in that, The step of setting the whitelist in the security device during the operating system initialization process includes: Perform operating system initialization; The elements involved in trusted computing during operating system initialization are measured, and a trusted report is generated based on the measurement results. The trusted report is transmitted to the trusted server so that the trusted server can provide feedback on the correctness of the trusted report; Receive feedback results from the trusted server; if the feedback results indicate that the trusted report is correct, request a whitelist from the trusted server. Set the whitelist returned by the trusted server in the security device.

4. The program execution method according to claim 3, characterized in that, Also includes: If the feedback result indicates a reliable report error, the system will be shut down.

5. The program execution method according to claim 3, characterized in that, The measurement of elements involved in trusted computing during operating system initialization includes: Measuring the Basic Input / Output System (BIOS), the GRand Unified Bootloader (GRUB), and the kernel.

6. The program execution method according to claim 1, characterized in that, If the matching result indicates that the program does not match the whitelist, starting a secure container and running the program in the secure container includes: If the matching result indicates that the program does not match the whitelist, determine whether the program is malicious. If the program is not malicious, start a secure container and run the program in the secure container; The method further includes: If the program is malicious, output an alarm message and block the program from running.

7. A program execution device, characterized in that, include: The program determination module is used to determine the program to be run; The program information transmission module is used to transmit the program information of the program to the security device, so that the security device can match the program with the whitelist based on the program information; the whitelist is set in the security device during the initialization process of the operating system; the security device is a hardware device, is in a trusted state, and is not affected by the operating system; A matching result receiving module is used to receive the matching result transmitted by the security device; The program execution module is used to run the program if the matching result indicates that the program matches the whitelist. A secure container runtime module is used to start a secure container and run the program in the secure container if the matching result is that the program does not match the whitelist; the secure container is a confidential computing sandbox implemented based on a hardware-based Trusted Execution Environment (TEE), and the memory space corresponding to the secure container is encrypted with a separate key; The secure container includes: an encrypted virtual machine; The encrypted virtual machine is a virtual machine based on secure virtualization technology. The memory space of the encrypted virtual machine is encrypted using the virtual machine key of the encrypted virtual machine, and the memory space of the encrypted virtual machine is isolated by hardware. If the matching result indicates that the program does not match the whitelist, starting a secure container and running the program in the secure container includes: If the matching result indicates that the program does not match the whitelist, start the secure container and run the program in the started secure container; During the execution of the program within the secure container, it is determined whether the program is malicious. If the program is not malicious, continue running the program in the secure container; Also includes: If the program is malicious, output an alarm message and block the program from running; The determination of whether the program is malicious includes: Based on the matching results of the blacklist fed back by the security device, it is confirmed whether the program is malicious; wherein, when the security device matches the program with the whitelist, if it is confirmed that the program does not match the whitelist, the program is matched with the blacklist to obtain the matching result of the program and the blacklist. Alternatively, based on sampling information from the program's historical execution within the secure container, it can be identified whether the program is malicious.

8. A processor, characterized in that, The processor is configured to execute the program execution method as described in any one of claims 1-6.

9. A chip, characterized in that, The chip includes the processor as described in claim 8.

10. An electronic device, characterized in that, The electronic device includes the chip as described in claim 9.

Images