Computer equipment starting method and electronic equipment

Abstract

The invention discloses a computer equipment starting method and electronic equipment, and relates to the technical field of safety protection. The method comprises the following steps: in an initialization stage of a UEFI (Unified Extensible Firmware Interface) starting process, generating memory mapping reference information, storing the memory mapping reference information in a trusted storage mode, and authorizing a target firmware module of the UEFI to access; in a verification stage of the UEFI starting process, reading memory mapping data of a starting service memory area through a physical address in the memory mapping reference information; and when the memory mapping data is consistent with the memory mapping reference information, continuing to execute the starting process, monitoring the memory service attribute of the starting service memory area in the starting process, and recovering the memory service attribute to an original state when monitoring that the memory service attribute is modified. The problem that persistent malicious codes reside in the prior art can be solved, and the attack behavior that memory mapping is tampered can be effectively prevented.

Description

Technical Field

[0001] This invention relates to the field of security protection technology, and in particular to a computer device startup method and electronic device. Background Technology

[0002] As the UEFI (Unified Extensible Firmware Interface) BIOS (Basic Input / Output System) codebase in computer devices continues to grow, attacks during the boot phase are becoming increasingly common. While related technologies can provide basic security protection, they cannot effectively monitor memory mapping tampering, and therefore cannot effectively prevent the malicious retention of UEFI BIOS boot services. Summary of the Invention

[0003] This invention provides a computer device startup method and electronic device that can effectively prevent attacks that tamper with memory mappings, retain various device drivers and services at startup, and solve the problem of persistent malicious code residency.

[0004] To solve the above-mentioned technical problems, the present invention provides the following technical solution: This invention provides a method for starting a computer device, comprising: During the initialization phase of the Unified Extensible Firmware Interface (UEMI) startup process, memory mapping baseline information is generated, stored in a trusted storage manner, and access is authorized to the target firmware modules of the UEMI. During the verification phase of the UEMI startup process, memory mapping data of the startup service memory region is read through the physical address in the memory mapping baseline information. If the memory mapping data is consistent with the memory mapping baseline information, the startup process continues. During the startup process, the memory service attributes of the startup service memory region are monitored, and if the memory service attributes are detected to have been modified, the memory service attributes are restored to their original state.

[0005] The present invention also provides an electronic device, including a memory and a processor, wherein the processor is configured to implement the steps of any of the above-described computer device startup methods when executing a computer program stored in the memory.

[0006] The present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of any of the above-described computer device startup methods.

[0007] Finally, the present invention also provides a computer program product, including a computer program / instruction that, when executed by a processor, implements the steps of any of the above-described computer device startup methods.

[0008] The advantages of the technical solution provided by this invention are as follows: By generating and securely storing memory mapping baseline information during the UEFI initialization phase and authorizing access only to the target firmware module, the integrity and tamper-proof nature of the memory mapping baseline information are ensured; during the UEFI verification phase, memory mapping data is read directly through the physical address, bypassing the potentially hookable and insecure GetMemoryMap application programming interface, thus avoiding interference from potential malicious hooks to the standard interface and ensuring the authenticity of the data acquisition; by comparing the memory mapping data with the memory mapping baseline information and automatically restoring it when the memory type is detected to have been illegally modified, the malicious retention of startup service memory as runtime service memory type is effectively prevented, thus effectively preventing attacks that tamper with memory mappings, thereby blocking the path for attackers to achieve persistent residency by using memory mapping tampering, solving the problem of persistent malicious code residency, retaining various device drivers and services at startup, and improving the security and reliability of the computer device startup process. In addition, the verification operation is performed only on this node, with an impact of less than 0.5% on system boot performance. It does not require modification of the existing operating system and UEFI specifications, and can be seamlessly integrated into the existing BIOS firmware. It works in conjunction with the existing UEFI secure boot mechanism to form a multi-layered firmware security protection system.

[0009] Furthermore, the present invention also provides corresponding electronic devices, computer-readable storage media, and computer program products for the computer device startup method, further making the method more practical, and the electronic devices, computer-readable storage media, and computer program products have corresponding advantages. Attached Figure Description

[0010] To more clearly illustrate the technical solutions of the present invention or related technologies, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 A schematic diagram of the hardware framework applicable to the computer device startup method provided by the present invention.

[0012] Figure 2 This is a flowchart illustrating a computer device startup method provided by the present invention.

[0013] Figure 3 This is a schematic diagram of the UEFI boot process provided by the present invention.

[0014] Figure 4This is a flowchart illustrating the initialization phase of the present invention.

[0015] Figure 5 This is a flowchart illustrating the verification phase of the present invention.

[0016] Figure 6 This is a structural framework diagram of an exemplary embodiment of the computer device startup device provided by the present invention.

[0017] Figure 7 This is a schematic diagram of an exemplary embodiment of the electronic device provided by the present invention. Detailed Implementation

[0018] To enable those skilled in the art to better understand the technical solutions of the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. In this specification and the aforementioned drawings, the terms "first," "second," "third," "fourth," etc., are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. The term "exemplary" means "serving as an example, embodiment, or illustration." Any embodiment described herein as "exemplary" is not necessarily to be construed as superior to or better than other embodiments.

[0019] As the UEFI BIOS codebase continues to grow, it includes an increasing number of device drivers and services, leading to a rise in attacks targeting the boot phase, such as the Shade BIOS attack. This type of attack illegally modifies the BS (Boottime Service) memory type to RT (Runtime Service), allowing boot-time services that should be overwritten after operating system takeover to remain intact. This creates an attack environment completely invisible to the operating system and traditional security detection tools.

[0020] To combat this type of attack, related technologies utilize Boot Guard and Secure Boot to detect whether firmware and software have been tampered with during the device's boot process, thus protecting the integrity of the boot process. However, this method only provides basic protection and cannot effectively detect tampering with memory mappings during the Exit Boot Services phase. This allows attackers to change the BS type in the memory mapping to RT type, enabling persistent malicious code residency.

[0021] Therefore, to prevent attackers from modifying the Memory Map to change the memory type of the BS service from "Boottime" to "Runtime" and thus retaining the boot-time service, this invention provides security protection for the computer device boot process. Applied to computer systems using a unified extensible firmware interface, it performs integrity verification and dynamic monitoring of the memory mapping during boot to prevent malicious retention of boot service memory, thereby improving the security of the system boot phase. The specific application environment architecture or hardware architecture upon which the execution of the computer device boot method depends is described below. Figure 1 Examples of possible application scenarios related to the technical solutions of this invention are provided below: Large data centers deploy multiple high-performance business servers and management servers. Each business server hosts the operation of business systems. Attackers may modify the memory mapping of one or more business servers to change the startup service memory type to the runtime service type, thereby establishing malicious code residency and illegally obtaining business data. To address the threat of attacks such as Shade BIOS, the BIOS firmware of each server encapsulates the computer program code of the computer device boot method of this invention, and each server is configured to automatically restart at midnight every day to load security updates.

[0022] After the server powers on, it enters the unified extensible firmware interface startup process. At the end of the driver execution environment phase, the firmware directly reads physical memory in the isolated environment, identifies all startup service memory regions, generates hashes and signs them, and stores the baseline information in the trusted platform module. When the operating system loader calls the exit startup service function, the firmware reads the baseline information from the trusted platform module and verifies its integrity. After successful verification, it reads the current memory mapping information and finds that the type of a startup service memory has been changed to "runtime". The firmware immediately restores it to "startup time", recalculates the hash value and compares it with the baseline, and allows startup to continue after confirming consistency. After the system enters the operating system, the monitoring module continuously checks the memory type at a low frequency. Because the previous tampering has been repaired, the system starts normally and completes the security update loading without triggering any alarms. If the memory type is found to have changed from startup service to runtime service, it is immediately and automatically restored, and a security alert is sent to the administrator's email. The data center server successfully resisted multiple memory mapping tampering attacks, with no malicious code residing there. The security of business data was effectively guaranteed, and the server's startup stability and operational reliability were significantly improved.

[0023] The various non-limiting embodiments of the present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. First, please refer to... Figure 2According to the computer device boot method provided by the present invention, it can be implemented as a computer program product, installed and run on the BIOS firmware of any computer device with a BIOS, for implementing security protection processing of the computer device during the boot phase. The computer device includes, but is not limited to, servers, desktops, all-in-one computers, mini-PCs, laptops, 2-in-1 tablets, workstations, embedded industrial control computers, and network devices. The UEFI boot process of the computer device is as follows: Figure 3 As shown, the hardware initialization phase includes the following stages in sequence: PEI (Pre-EFI Initialization), DXE (driver execution environment), initialization, BDS (Boot Device Selection), verification, and operating system operation. The PEI stage is the earliest hardware initialization stage executed after the computer system is powered on. It initializes the CPU, hardware processor group, motherboard controller, etc., and prepares the basic operating environment for subsequent stages (such as DXE). This stage is the security verification and temporary environment establishment stage before hardware initialization (also known as the SEC stage). The DXE phase loads the core driver, establishes system services, and fully initializes memory through the DXE scheduler. The initialization phase is a newly added memory mapping baseline information generation and trusted storage phase in this invention. The BDS phase is the boot media selection phase, selecting the physical storage device (such as a hard drive, USB flash drive, or network) for loading the operating system. The verification phase is also a newly added phase in this invention, occurring when the operating system calls Exit BootServices. The operating system running phase refers to the operating system fully controlling and taking over the device driver; this node represents the attack window corresponding to the attack behavior. This invention can effectively block attack paths through the initialization and verification phases. In some embodiments of this method, the computer device boot method includes the following steps: S201: During the initialization phase of the Unified Extensible Firmware Interface startup process, memory-mapped baseline information is generated, stored in a trusted storage manner, and access is authorized to the target firmware module of the Unified Extensible Firmware Interface.

[0024] The Unified Extensible Firmware Interface (UEFI) is a firmware standard for computer booting. It defines the interface between the operating system and platform firmware, used for hardware initialization and operating system booting during the computer device boot process. The initialization phase refers to the stage in the UEFI boot process after basic hardware initialization, core driver loading, and full memory initialization are completed. In this implementation, it refers to the end of the DXE (Driver Execution Environment) phase. Memory mapping baseline information is memory layout information recorded at the initial boot stage, including, but not limited to, the memory type, address, and length of each memory region, as well as data after integrity verification and encryption of this information. Trusted storage refers to using secure hardware such as the Trusted Platform Module (TPM2.0) for data storage to ensure that data is not illegally accessed or tampered with. The target firmware module refers to the module in the system authorized to access memory mapping baseline information. This module is a security module within the UEFI firmware and is a functional module used to access and process memory mapping baseline information.

[0025] S202: During the verification phase of the unified extensible firmware interface startup process, the memory mapping data of the startup service memory region is read through the physical address in the memory mapping baseline information.

[0026] The verification phase refers to the stage in the UEFI boot process where memory-mapped data is verified when the Exit Boot Services function is called. The verification phase is the transition phase during the computer device's boot process, from the UEFI boot phase to the operating system runtime phase. Through this verification phase, the system formally transfers control from the firmware to the operating system. The boot service memory area refers to the memory area whose memory type is boot service code memory or boot service data memory, and whose memory service attribute is boottime. It stores the service programs and data required during the UEFI boot process and is released after the operating system takes over. Memory-mapped data refers to the actual memory information of the boot service memory area read during the verification phase, including physical address, length, memory type, etc. The memory-mapped address is read through the underlying physical address. This method bypasses potentially hookable and insecure APIs (Application Programming Interfaces, which obtain memory mappings) and directly accesses the underlying memory mapping.

[0027] S203: When the memory mapping data is consistent with the memory mapping baseline information, continue to execute the startup process, and monitor the memory service attributes of the startup service memory region during the startup process. When the memory service attributes are detected to have been modified, restore the memory service attributes to their original state.

[0028] The read memory-mapped data is compared with the memory-mapped baseline information. If an inconsistency is detected (indicating that the memory mapping has been tampered with), the startup process is immediately terminated, and optional security response operations, such as alarms and error messages, can be triggered. If the two are consistent, the startup process continues. Throughout the startup process, the memory service attributes of the startup service memory region are continuously or frequently monitored. For example, the type field in the memory mapping can be monitored for changes. Once a memory service attribute is detected to have been modified from the startup service to another type, it is immediately restored to its original state, which is also the startup service state. For example, an automatic rollback mechanism can be triggered to restore the memory service attributes to their original state. If an illegal modification of the memory type is detected, the "Runtime" type is automatically reset to the original "Boottime" type. By generating a trusted baseline during initialization, comparing during verification, and dynamically monitoring and restoring during the startup process, full-cycle protection against memory mapping tampering is achieved, effectively blocking the persistent residence of malicious code.

[0029] In the technical solution provided in this embodiment, by generating and securely storing memory mapping baseline information during the UEFI initialization phase and authorizing access only to the target firmware module, the integrity and tamper-proof nature of the memory mapping baseline information are ensured. During the UEFI verification phase, memory mapping data is read directly through the physical address, bypassing the potentially hookable and insecure GetMemoryMap application programming interface, thus avoiding interference from potential malicious hooks to the standard interface and ensuring the authenticity of the data acquisition. By comparing the memory mapping data with the memory mapping baseline information and automatically restoring it when the memory type is detected to have been illegally modified, the malicious retention of startup service memory as runtime service memory type is effectively prevented. This effectively prevents attacks that tamper with memory mapping, thereby blocking the path for attackers to achieve persistent residency by using memory mapping tampering, solving the problem of persistent malicious code residency, retaining various device drivers and services at startup, and improving the security and reliability of the computer device startup process. In addition, the verification operation is performed only on this node, with an impact of less than 0.5% on system boot performance, resulting in low performance overhead. Furthermore, it does not require modification of the existing operating system and UEFI specifications, and can be seamlessly integrated into the existing BIOS firmware. It has strong compatibility and works in conjunction with the existing UEFI secure boot mechanism to form a multi-layered firmware security protection system that complies with secure boot standards. It can not only detect attacks that have already occurred, but also prevent potential memory mapping tampering, providing forward-looking security protection.

[0030] Considering that the memory mapping baseline information generated during the initialization phase is easily interfered with or tampered with by malicious code, subsequent verification phases cannot be compared based on accurate baseline information, thus failing to effectively defend against memory mapping tampering attacks. Based on the above embodiment, at the end of the DXE phase, the original business logic can be modified to perform the following operations, generating verification encryption information such as memory signature values ​​and storing the original data in TPM (Trusted Platform Module), such as TPM 2.0, which may include the following: When the driver environment phase of firmware execution ends, a secure execution environment isolated from the main system of the computer device is created. In the secure execution environment, the memory layout information of the startup service memory area is obtained by directly accessing physical memory. The memory layout information is verified for integrity and encrypted, and the verified and encrypted information and the memory layout information are stored in different locations of the trusted platform module, respectively.

[0031] The Driver Environment (DXE) stage is a phase in the UEFI boot process, performing most of the system initialization work and loading the core drivers. At this point, memory is fully usable. The Secure Execution Environment (SEE) is an independent operating environment isolated from the main computer system, authorized to access only through a single secure interface. Access is only permitted through predefined secure interfaces to ensure critical operations are not interfered with by malicious code. Physical memory is the storage medium in a computer device that directly exchanges data with the CPU; it is the actual storage location of memory-mapped data. Memory layout information contains key information describing the memory distribution and attributes, such as the physical starting address, region length, and memory type of the memory region used to start services. Integrity verification and encryption are processes that ensure the memory layout information has not been tampered with and perform integrity verification and encryption protection through hash operations, digital signatures, etc. The Trusted Platform Module (TPM) is a hardware module used to store and process security-related data, providing secure storage and encrypted computation functions.

[0032] In this embodiment, a secure execution environment isolated from the main system can be created using TDX (Trust Domain eXtensions) hardware isolation technology or SEV-SNP (Secure Encrypted Virtualization-Secure Nested Paging) technology. This environment can only be accessed through predefined secure interfaces to prevent potential malicious code from interfering with the initialization process. It is used to verify the integrity of the environment itself and ensure that it has not been tampered with. This step bypasses gBS. The GetMemoryMap() API directly accesses the BootService (BS) memory region via the underlying physical address. Here, gBS refers to the BootService within the SystemTable. The SystemTable serves as the channel between user space and kernel space. The BootService table is initialized when the system enters the DXE stage, and ultimately, the BootService (BS) table is passed to UEFI applications or drivers via the SystemTable pointer. UEFI applications and drivers can access the BootService table through either the BootServices or gBS within the gST (global system table).

[0033] As can be seen from the above, this embodiment directly reads physical memory through an isolated environment and combines it with trusted platform module storage to ensure the authenticity and tamper-proof nature of the benchmark information.

[0034] Furthermore, considering that the acquisition of startup service memory region information is susceptible to interference, leading to inaccurate information and an inability to accurately identify the true startup service memory region, thus affecting the effectiveness of subsequent benchmark information generation and verification, this embodiment also addresses this problem through the following method, which may include the following: The system reads the memory descriptor structure of the Unified Extensible Firmware Interface in system memory. Multiple memory descriptor structures form a memory descriptor list. Each memory descriptor structure contains at least the memory type, physical start address, and region length fields. The system traverses the memory descriptor list to identify target memory regions whose memory type is boot service code memory type and boot service data memory type. From each target memory region, the system selects the memory region with the memory service attribute of boot service as the boot service memory region. The system reads the physical start address and data length of each boot service memory region to obtain memory layout information.

[0035] The memory descriptor structure (EFI (Extensible Firmware Interface)_MEMORY_DESCRIPTOR) is an array in the UEFI system used to describe memory region attributes, containing key fields such as memory type, physical starting address, and region length. The memory descriptor list is a list of multiple memory descriptor structures arranged in a specific order, comprehensively presenting the distribution and attribute information of the system memory. The boot service code memory type (Efi BootServices Code) stores the memory type of the boot service program code during UEFI startup. The boot service data memory type (Efi Boot Services Data) stores the memory type of boot service-related data during UEFI startup. The target memory region is the memory region in the memory descriptor list whose memory type is either the boot service code memory type or the boot service data memory type. The boot service is a memory service attribute identifier for the memory region, indicating that this memory region is used for boot services during the UEFI startup process and should be overwritten after the operating system takes over.

[0036] In this embodiment, an array of EFI_MEMORY_DESCRIPTOR (EFI memory descriptor) structures can be read from system memory. The physical address of the memory descriptor list is located through the page table, avoiding reliance on potentially hooked UEFI services to establish a memory descriptor list integrity verification process and checking the consistency between memory and actual data. The memory descriptor list is traversed to identify all memory regions of type Efi Boot Services Code and Efi Boot Services Data, and the start address and length information of the BS service region with the attribute "Boottime" are recorded.

[0037] As can be seen from the above, this embodiment ensures the originality of memory region information by directly reading the memory descriptor structure in the system memory and constructing a memory descriptor list; by traversing the list to filter the target memory region and further selecting the memory region for starting the service, the memory region for starting the service is accurately located; and its physical starting address and data length are accurately obtained, providing accurate data support for generating reliable memory layout information.

[0038] Considering the insufficient security of a single verification / encryption method, the integrity and authenticity of memory layout information are difficult to guarantee, and it is easily tampered with by attackers to pass verification. Based on the above embodiments, this invention also provides an implementation process for integrity verification and encryption of memory layout information, which may include the following: Perform hash operations on each startup service memory region to obtain the region hash value of each startup service memory region; concatenate the region hash values ​​in a predefined order to generate the initial memory mapping hash value corresponding to the memory layout information; digitally sign the initial memory mapping hash value using the internal key of the trusted platform module to obtain the memory signature; perform hash calculation on the memory signature using the internal key of the trusted platform module to obtain the memory mapping hash value.

[0039] The memory parameters describe memory characteristics, such as the physical starting address, region length, and memory type of the startup service memory region. Hash operations are data processing algorithms that convert input data of arbitrary length into fixed-length hash values ​​to verify data integrity. The region hash value is a fixed-length value obtained by hashing the memory parameters of a single startup service memory region. For example, SHA3-512 or SM3 is used to perform segmented hash calculations on all identified BS service memory regions to generate a hash value for each memory region. The predefined order is a pre-defined sorting rule for startup service memory regions, ensuring the consistency of the hash value concatenation order. The initial memory mapping hash value is the overall hash value generated by concatenating the region hash values ​​of each startup service memory region in a predefined order, used to represent the overall integrity of all startup service memory regions. The Trusted Platform Module (TPM) internal key is an encrypted key stored internally, used for digital signatures and hash calculations, ensuring high security. The memory signature is the data obtained by digitally signing the initial memory mapping hash value using the TPM internal private key, such as using the TPM internal private key to perform an SM2 digital signature on the memory mapping hash, used to verify the authenticity of the initial memory mapping hash value. The memory-mapped hash value refers to the value obtained by hashing the memory signature using the TPM internal key, such as using the TPM internal key to perform an SM3 hash on the signature result, for dual verification of data integrity.

[0040] In this embodiment, after obtaining memory parameters such as the physical starting address, length, and memory type of each startup service memory region, the memory parameters of each startup service memory region are hashed using the SHA3-512 algorithm to obtain the region hash value corresponding to each region. Following a pre-set order (e.g., in ascending order of physical starting address), the region hash values ​​of all startup service memory regions are concatenated to generate an initial memory mapping hash value. This hash value represents the overall memory layout information of all startup service memory regions. The initial memory mapping hash value is digitally signed using the private key within the Trusted Platform Module (TPM) to obtain a memory signature, which is used to prove the authenticity of the initial memory mapping hash value. Finally, the memory signature is hashed again using the key within the TPM to obtain the memory mapping hash value, forming a triple protection chain of "hash-signature-secondary hash," as shown below. Figure 4As shown, multiple encryption and integrity verification processes are completed for memory layout information.

[0041] As can be seen from the above, this embodiment ensures the integrity of individual region information by performing hash operations on each startup service memory region separately; it generates an initial memory mapping hash value by connecting the region hash values ​​in a fixed order, thereby realizing the integrity verification of the overall memory layout information; and it forms a multi-protection chain of "region hash - overall hash - digital signature - secondary hash" by performing digital signature and secondary hash through the TPM internal key, which greatly improves the security and authenticity of the memory layout information and effectively resists tampering attacks.

[0042] If the verification encryption information and memory layout information are stored in the same location, once that location is compromised, all data will be at risk of being leaked or tampered with, resulting in insufficient security. Based on this, this embodiment also provides a more secure storage method, which may include the following: Extend the memory-mapped hash value to the platform configuration register of the Trusted Platform Module; store the memory signature in the non-volatile index of the Trusted Platform Module; and store the memory layout information in the firmware security partition of the Trusted Platform Module.

[0043] The Platform Configuration Register (PCR) is an internal register of the TPM used to store integrity measurement data such as hash values. Its value can only be modified through specific extended operations and cannot be directly written to. The Non-Volatile Index (NV) is a non-volatile storage area within the TPM used to securely store important data such as digital signatures and keys; the data is not lost even when the device is powered off. The firmware security partition is a specially designated secure storage area in the UEFI firmware used to store metadata such as memory layout information, and access is only permitted to authorized modules.

[0044] In this embodiment, the starting address, length information, signature value, and generated final hash value of the BS service area are saved to different locations to improve information security: First layer: the secondary hash value is extended into the PCR register of the TPM; Second layer: the complete signature data is stored in the NV index of the TPM; Third layer: the metadata (i.e., the values ​​of the starting address and length information) is stored in the firmware security partition.

[0045] As shown above, this embodiment stores the memory-mapped hash value, memory signature, and memory layout information in the TPM's platform configuration register, non-volatile index, and firmware security partition, respectively, achieving distributed data storage. Different storage locations have different security protection mechanisms, providing multiple layers of protection for data security. Even if one storage location is attacked, the data in other locations remains secure, further improving the reliability of the memory-mapped baseline information.

[0046] Considering that during the initialization phase when generating memory-mapped baseline information, non-security-related threads running in the system may interfere with the execution of critical operations, or even pose a risk of malicious threads tampering with data, affecting the accuracy and security of the baseline information, based on the above embodiments, this embodiment also provides corresponding solutions, which may include the following: Get all system threads; iterate through each system thread, and if the current system thread is not the initialization process of the unified extensible firmware interface startup process or is not the target monitoring process, then pause the current system thread.

[0047] System threads are program execution units running in a computer device, responsible for performing specific tasks. The initialization process is used during UEFI boot to complete initialization tasks such as generating and storing memory mapping baseline information. The target monitoring process is used to monitor the system's security status, such as Secure Boot verification chain, IMA (Integrity Measurement Architecture) / EVM (Extended Verification Module) integrity measurement, and KASLR (Kernel Address Space Layout Randomization), ensuring that the initialization process is not disturbed.

[0048] In this embodiment, all non-security-related system threads are suspended, and only the initialization process and necessary system monitoring processes are retained to ensure that there is no external interference during critical operations.

[0049] Considering that only restoring the modified memory service attributes lacks a further response mechanism against attacks, it is impossible to promptly notify users or take more stringent protective measures, which is not conducive to users investigating security risks. Based on the above embodiments, the following may also be included: Retrieve the monitoring response list and whitelist; the monitoring response list contains the security response operations configured by the user and their corresponding triggering conditions; the whitelist contains the address range of the trusted startup service memory region; based on the whitelist, when the memory service attribute is detected to be changed from startup service to runtime service, the corresponding security response operation is triggered based on the monitoring response list.

[0050] The monitoring response list is a user-configured list containing trigger conditions for different security events and corresponding security response operations. Trigger conditions are pre-defined events that require a security response; in this implementation, this may refer to changing the memory service attribute type from a startup service to a runtime service. Security response operations are the actions performed by the system when the trigger conditions are met, such as recording the security event or sending a security alert. Runtime services (RT) are services in UEFI that continue to run after the operating system starts; their corresponding memory areas are not overwritten during operating system operation.

[0051] In this embodiment, the user pre-configures a monitoring response list according to their own security needs. For example, the trigger condition is set to "memory type changed from boottime service to runtime service," and the corresponding security response operations are "logging security event," "sending security alert to administrator's email," and "preventing system from entering operating system." During the computer device startup process, the system continuously monitors the memory type information of the boottime service memory region. When it detects that the memory type of a certain boottime service memory region has been changed from boottime service to runtime service, the system immediately queries the monitoring response list. According to the preset correspondence in the list, the system simultaneously performs the operations of logging security event (writing attack time, memory region, and other information to the log), sending security alert (sending an email containing attack details to the administrator's preset email address), and preventing the system from entering operating system (pausing the startup process and displaying a security warning interface).

[0052] As shown above, this embodiment enables customization of security response operations by configuring a monitoring response list, meeting the security needs of different users. When unauthorized modification of memory type is detected, the corresponding security response operation is triggered according to the list, which can promptly record attack events, notify users, or take blocking measures, improving the system's proactive defense capabilities and facilitating users to promptly detect and handle security risks.

[0053] Furthermore, if high-frequency monitoring is used throughout the process, it will consume a lot of system resources and affect the operating performance of computer equipment; if low-frequency monitoring is used throughout the process, memory type tampering attacks may not be detected in time during critical stages such as startup. Based on the above embodiments, the following may also be included: The system acquires a first monitoring frequency and a second monitoring frequency. During the system startup process and the initial stage of operating system operation, the system monitors the memory service attributes of the startup service memory region using the first monitoring frequency. When the operating system enters the normal operation stage, the system automatically switches to the second monitoring frequency to monitor the memory service attributes of the startup service memory region.

[0054] The monitoring frequency is divided into two levels: a first monitoring frequency, which is a higher frequency for monitoring memory service attributes and is suitable for the system startup process and the initial stage of operating system operation, enabling timely detection of attacks; and a second monitoring frequency, which is a lower frequency for monitoring memory service attributes and is suitable for the normal operation of the operating system, reducing performance overhead while ensuring basic security. The first monitoring frequency is higher than the second monitoring frequency, and there is no explicit limit to the value. The monitoring frequency can be dynamically configured according to actual needs. For example, users can preset the first monitoring frequency to 5 times per second and the second monitoring frequency to 1 time per minute. The initial stage of operating system operation refers to the stage immediately after the operating system has finished loading and has not yet entered a stable operating state. The normal operating system operation stage refers to the stage where the operating system is running stably and all functions are providing services normally.

[0055] For example, a lightweight monitoring module can be implemented in the UEFI BIOS. "Lightweight" means the module is small and focused on monitoring and processing, without interfering with other business logic. This module provides a configurable monitoring list, allowing users to define actions to trigger security responses, and continuously monitors modifications to the Memory Map during system startup. The monitoring module periodically checks the type of the memory service attribute in the BS region of the Memory Map. When it detects that the type of the memory service attribute in the BS region has been changed to Runtime, it triggers a security response according to user configuration, such as logging a security event, sending a security alert, preventing the system from entering the operating system, or entering safe mode. To reduce performance overhead, the monitoring module only performs high-frequency monitoring during critical startup phases, and then switches to low-frequency monitoring thereafter.

[0056] As shown above, this embodiment's custom security response mechanism can handle detected changes in memory attributes differently based on user needs. It can not only detect existing attacks but also prevent potential memory mapping tampering, providing proactive security protection. The monitoring frequency is dynamically adjusted according to the security needs and performance requirements of different system operating stages. High-frequency monitoring is used during critical stages such as startup and the start of operating system operation to ensure timely attack detection; low-frequency monitoring is switched during normal operating system operation to reduce system performance overhead, achieving a balance between security protection and performance optimization.

[0057] Considering that directly using memory-mapped baseline information for comparison during the verification phase without first verifying the integrity and authenticity of the baseline information itself may result in the use of tampered baseline information for comparison, leading to verification failure, this embodiment also provides a dual verification mechanism to ensure that BS service memory is not illegally reserved for RT service, fundamentally blocking the implementation process of such attack paths. This mechanism may include the following: At the entry point of the exit startup service function, a security verification operation is performed. The security verification operation includes: verifying the memory layout information and verification encryption information of the memory mapping baseline information in trusted storage based on the same integrity verification method; if the verification is successful, determining the physical address of each startup service memory region based on the physical start address and region length field of the memory layout information; and reading the memory mapping data of the corresponding startup service memory region based on the physical address of each startup service memory region.

[0058] The Exit Boot Services function, a UEFI function, terminates the boot service and transfers control to the operating system loader. Its entry point is a critical node for verifying memory mapping. Security verification operations are a series of verification processes performed at the Exit Boot Services function entry point to ensure that the memory mapping baseline information has not been tampered with. Integrity verification methods, such as hash operations and digital signature verification, are used to verify data integrity; in this implementation, the methods are consistent with those used in the initialization phase.

[0059] When the operating system calls the `ExitBootServices` function, the system initiates a security verification operation at the function's entry point. First, using the same integrity verification method as during the initialization phase, the system verifies the memory mapping baseline information stored in the trusted platform module, including memory layout information and verification encryption information. If the verification result shows that the baseline information is authentic, complete, and untampered with, the system determines the specific location of each startup service memory region in physical memory based on the physical start address and region length recorded in the memory layout information. Finally, based on the determined physical address, the system directly accesses physical memory and reads the actual memory mapping data of each startup service memory region, preparing for subsequent comparison with the baseline information.

[0060] As can be seen from the above, this embodiment verifies the memory mapping baseline information in trusted storage before reading and comparing the memory mapping data, ensuring that the memory mapping baseline information has not been tampered with. Based on the verified memory mapping baseline information, the physical address of the memory region for starting the service is determined, and then the memory mapping data is read, ensuring the accuracy of subsequent comparisons and further improving the reliability of the verification stage.

[0061] Considering that the above embodiments lack a multi-verification mechanism for the memory mapping baseline information itself, it is difficult to fully ensure that the baseline information has not been tampered with through a single verification step, which may lead to inaccurate subsequent comparison results. Therefore, this embodiment also provides the following implementation method. In this embodiment, the verification of encrypted information includes memory signature and memory mapping hash value, the trusted storage is a trusted platform module, and the verification process of memory layout information of memory mapping baseline information and verification of encrypted information may include: The system reads the unverified memory layout information, unverified memory signature, and unverified memory mapping hash value from the memory mapping baseline information from the trusted platform module. It then performs a hash calculation on the unverified memory signature using the trusted platform module's internal key to obtain the target memory mapping hash value. If the target memory mapping hash value and the unverified memory mapping hash value are the same, it calculates the target region hash value for each startup service memory region of the unverified memory layout information and concatenates these target region hash values ​​in a predefined order to form the target initial memory mapping hash value. The trusted platform module then performs public key verification on the target initial memory mapping hash value and the unverified memory signature. If the public key verification passes, the memory mapping baseline information read from the trusted platform module has not been tampered with. If the target memory mapping hash value and the unverified memory mapping hash value are different, an error is returned, and the system is prevented from continuing to start. If the public key verification fails, an error is returned, and the system is prevented from continuing to start.

[0062] The memory layout information to be verified is read from the Trusted Platform Module (TPM) and requires integrity and authenticity verification. The memory signature to be verified is also read from the TPM and requires verification. The memory mapping hash value to be verified is read from the TPM and requires comparison. The memory layout information, memory signature, and memory mapping hash value to be verified may be the same as when stored in S201, or they may have been tampered with, therefore verification is required. The target memory mapping hash value is the hash value obtained by hashing the memory signature to be verified read from the TPM and is used for comparison with the target memory mapping hash value. The target region hash value is the hash value obtained by hashing each startup service memory region in the memory layout information to be verified read from the TPM. The target initial memory mapping hash value is the hash value obtained by concatenating the target region hash values ​​in a predefined order and is used for public key verification of the memory signature to be verified. Public key verification is the process of verifying a digital signature using a public key to confirm the authenticity of the original data corresponding to the digital signature. Returning an error occurs when verification fails; the system sends an error message to the boot process indicating that the memory-mapped baseline information may have been tampered with. Preventing the system from continuing boot occurs when verification fails; the system pauses the UEFI boot process to prevent the use of tampered baseline information for subsequent operations, thus avoiding security risks.

[0063] In this embodiment, the memory layout information to be verified, the memory signature to be verified, and the memory mapping hash value to be verified are read from the Trusted Platform Module (TPM). First, the memory signature to be verified is hashed using the key inside the TPM to obtain the target memory mapping hash value. The target memory mapping hash value is compared with the memory mapping hash value to be verified read from the TPM to check if they are consistent. If they are consistent, each startup service memory region in the memory layout information to be verified read from the TPM is hashed using the SHA3-512 algorithm to obtain the hash value of each target region. The hash values ​​of each target region are concatenated in a predefined order to generate the target initial memory mapping hash value. If the calculated target memory mapping hash value is inconsistent with the memory mapping hash value to be verified read from the Trusted Platform Module (TPM), it indicates that the memory signature or hash value may have been tampered with. The system immediately returns an error message to the startup process and suspends the UEFI startup process, preventing the system from continuing to start. Finally, the public key of the Trusted Platform Module (TPM) is used to verify the target initial memory mapping hash and the memory signature to be verified. If the verification passes, it confirms that the memory mapping baseline information read from the TPM has not been tampered with. If the target memory mapping hash matches the memory mapping hash to be verified, but the public key verification of the target initial memory mapping hash and the memory signature to be verified fails, it indicates that the memory layout information may have been tampered with. The system will also return an error message and prevent the system from continuing to start, thus avoiding the expansion of security risks.

[0064] As shown above, this embodiment completes the first layer of verification by hashing the memory signature and comparing it with the hash value of the memory mapping to be verified; then, it completes the second layer of verification by calculating the initial target memory mapping hash value and verifying it with the public key signature of the memory signature. This dual verification mechanism comprehensively ensures the integrity and authenticity of the memory mapping baseline information read from the trusted platform module, providing a reliable basis for subsequent comparisons of memory mapping data. A clear handling mechanism for verification failures is defined: when the target memory mapping hash value is inconsistent with the hash value of the memory mapping to be verified, or when the public key verification fails, an error is promptly returned and the system is prevented from continuing to start. This effectively avoids using tampered baseline information for subsequent operations, blocking the attack path at the source and further improving system security.

[0065] If only the hash values ​​of the memory mapping data and the baseline information are compared without first checking for changes in the memory service attribute type identifier, it may be impossible to detect and repair memory type tampering in a timely manner. Furthermore, the lack of comparison of the physical address and length of the memory region may lead to inaccurate comparison results. Based on the above embodiments, the present invention also provides the following to solve this problem, which may include: The current memory descriptor structure is read based on the physical address, and the current memory descriptor structures constitute the current memory descriptor list. The current memory descriptor list is traversed to obtain the current physical starting address, current data length, and memory service attribute type identifier of each startup service memory region. If the memory service attribute type identifier of a target startup service memory region changes from startup service to runtime service, the memory service attribute type identifier of the target startup service memory region is modified to startup service. If there is no startup service memory region with the memory service attribute type identifier of runtime service, the current region hash value of each startup service memory region is calculated based on the same integrity verification method, and the current region hash values ​​are concatenated into the current initial memory mapping hash value in a predefined order. If the current initial memory mapping hash value is the same as the initial memory mapping hash value in the verification encryption information, the memory mapping data is consistent with the memory mapping base information.

[0066] The current memory descriptor structure is an EFI_MEMORY_DESCRIPTOR structure read from physical memory during the verification phase, reflecting the attributes of the current memory region. The current memory descriptor list is a list of multiple current memory descriptor structures, presenting the actual distribution and attributes of the current system memory. The current physical start address is the physical start address of the boot service memory region recorded in the current memory descriptor structure. The current data length is the data length of the boot service memory region recorded in the current memory descriptor structure. The memory service attribute type identifier is an identifier used to identify the type of memory service attribute, such as "Boottime" or "Runtime". The target boot service memory region is the boot service memory region whose memory service attribute type identifier changes from boot service to runtime service. The current region hash value is the hash value obtained by hashing the memory parameters of the current boot service memory region. The current initial memory mapping hash value is the hash value obtained by concatenating the current region hash values ​​in a predefined order, used for comparison with the initial memory mapping hash value in the baseline information.

[0067] In this embodiment, the system reads the EFI_MEMORY_DESCRIPTOR structure from the current physical memory based on the physical address of the boot service memory region. These structures form the current memory descriptor list. The system iterates through the current memory descriptor list to obtain the current physical start address, current data length, and memory service attribute type identifier for each boot service memory region. If the memory service attribute type identifier of a target boot service memory region changes from "Boottime" to "Runtime", the system automatically modifies the memory service attribute type identifier of that target boot service memory region back to "Boottime". If no boot service memory region with its memory service attribute type identifier modified to "Runtime" is found, the system performs a hash operation on the current memory parameters of each boot service memory region using the SHA3-512 algorithm to obtain the current region hash value. The current region hash values ​​are concatenated in a predefined order to generate the current initial memory mapping hash value. The current initial memory mapping hash value is compared with the initial memory mapping hash value in the memory mapping baseline information. If they are the same, the current memory mapping data is confirmed to be consistent with the memory mapping baseline information.

[0068] As shown above, this embodiment obtains detailed information about the memory region of the currently started service by reading the current memory descriptor list; it first compares the memory service attribute type identifier, promptly restores it after tampering is detected, and then compares the hash value to ensure the integrity of the memory layout. This dual comparison mechanism comprehensively verifies the consistency between the memory mapping data and the baseline information, accurately identifies and repairs memory type tampering behavior, and further improves the effectiveness of the verification.

[0069] For example, such as Figure 5 As shown, this embodiment also provides an exemplary implementation of the verification phase. At the entry point of the ExitBootServices function, the following process is added to compare memory information. If the comparison passes, the original process continues: A1: Acquisition and verification of trusted benchmarks.

[0070] The system reads the starting address, length information, signature value, and final hash value of the BS service areas stored in the TPM and firmware security partition. It then performs an SM3 hash on the signature value extracted from the TPM using the TPM's internal key and compares it with the final hash value obtained from the TPM. If they don't match, it indicates a problem with the signature or hash, returns an error, and prevents the system from continuing to boot. Otherwise, it performs segmented hash calculations using the SHA3-512 algorithm on all BS service memory areas extracted from the firmware security partition, generating a hash value for each memory area. These hash values ​​are then concatenated in a predefined order to generate a total memory-mapped hash. This hash value and the signature value are then verified using the TPM's SM2 public key. Only if the verification passes can execution continue; otherwise, an error is returned, preventing the system from continuing to boot.

[0071] A2: Memory mapping acquisition and comparison.

[0072] The system accesses the `EFI_MEMORY_DESCRIPTOR` array via physical addresses, locates the memory descriptor list using page table traversal, and records the starting address, length, and attribute flags of all BS service regions. It then compares the BS service region information retrieved from memory with that retrieved from the TPM, verifying attribute similarities. If a type changes from "Boottime" to "Runtime," it reverts to "Boottime" and continues. Otherwise, it performs segmented hashing on all identified BS service memory regions using the same SHA3-512 algorithm as in the initialization phase, concatenates all hash values ​​in the order stored in the TPM, and verifies if the hash matches the hash value retrieved and generated in the TPM. If they differ, an error is returned, preventing the system from booting. Otherwise, subsequent boot operations can continue.

[0073] It should be noted that there is no strict order of execution between the steps in this invention. As long as they conform to the logical order, these steps can be executed simultaneously or in a certain preset order. Figure 2 This is just an illustrative example and does not mean that this is the only possible execution order.

[0074] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0075] This invention also provides a corresponding apparatus for the computer device startup method, further enhancing the practicality of the method. The apparatus can be described from both a functional module perspective and a hardware perspective. The following describes the computer device startup apparatus provided by this invention, which is used to implement the computer device startup method provided by this invention. In this embodiment, the computer device startup apparatus may include or be divided into one or more program modules. These program modules are stored in a storage medium and executed by one or more processors to complete the computer device startup method disclosed in Embodiment 1. The program module referred to in this embodiment is a series of computer program instruction segments capable of performing specific functions, which is more suitable than the program itself for describing the execution process of the computer device startup apparatus in the storage medium. The following description will specifically introduce the functions of each program module in this embodiment. The computer device startup apparatus described below can be referred to in correspondence with the computer device startup method described above.

[0076] From the perspective of functional modules, such as Figure 6 The diagram shown illustrates the structure of a computer device startup device provided in this embodiment under a specific implementation. The device may include: The startup initialization processing module 601 is used to generate memory mapping baseline information during the initialization phase of the unified extensible firmware interface startup process, store it through trusted storage, and authorize the target firmware module of the unified extensible firmware interface to access it.

[0077] The startup security verification module 602 is used to read the memory-mapped data of the startup service memory region through the physical address in the memory-mapped baseline information during the verification phase of the unified extensible firmware interface startup process.

[0078] The anomaly monitoring and repair module 603 is used to continue the startup process when the memory mapping data is consistent with the memory mapping baseline information. During the startup process, it monitors the memory service attributes of the startup service memory region and restores the memory service attributes to their original state when it detects that the memory service attributes have been modified.

[0079] For example, in some embodiments of this example, the above-mentioned startup initialization processing module 601 can also be used to: create a secure execution environment isolated from the main system of the computer device when the driver environment stage of firmware execution ends; authorize a unique secure interface to access the secure execution environment; obtain the memory layout information of the startup service memory area by directly accessing physical memory in the secure execution environment; perform integrity verification and encryption processing on the memory layout information, and store the verification encryption information and the memory layout information in different locations of the trusted platform module respectively.

[0080] As an exemplary implementation of the above embodiments, the startup initialization processing module 601 can be further configured to: read the memory descriptor structure of the Unified Extensible Firmware Interface in the system memory, wherein multiple memory descriptor structures constitute a memory descriptor list, and each memory descriptor structure includes at least memory type, physical start address, and region length fields; traverse the memory descriptor list to identify target memory regions whose memory type is boot service code memory type and boot service data memory type; select memory regions with the memory service attribute of startup service from each target memory region as startup service memory regions, and read the physical start address and data length of each startup service memory region to obtain memory layout information.

[0081] As another exemplary implementation of the above embodiments, the startup initialization processing module 601 can be further configured to: perform a hash operation on each startup service memory region to obtain a region hash value for each startup service memory region; connect the region hash values ​​in a predefined order to generate an initial memory mapping hash value corresponding to the memory layout information; digitally sign the initial memory mapping hash value using the internal key of the trusted platform module to obtain a memory signature; and perform a hash calculation on the memory signature using the internal key of the trusted platform module to obtain a memory mapping hash value.

[0082] As an exemplary implementation of the above embodiments, the startup initialization processing module 601 may further be used to: extend the memory-mapped hash value to the platform configuration register of the trusted platform module; store the memory signature in the non-volatile index of the trusted platform module; and store the memory layout information in the firmware security partition of the trusted platform module.

[0083] As another exemplary implementation of the above embodiments, the startup initialization processing module 601 can be further used to: obtain all system threads; traverse each system thread, and if the current system thread is not the initialization process of the unified extensible firmware interface startup process or is not the target monitoring process, then pause the current system thread.

[0084] For example, in some other embodiments of this embodiment, the above-mentioned anomaly monitoring and repair module 603 can also be used to: obtain a monitoring response list and a whitelist; the monitoring response list is the security response operation configured by the user and its corresponding triggering conditions; the whitelist is the address range of the trusted startup service memory region; based on the whitelist, when it is detected that the memory service attribute has been changed from startup service to runtime service, the corresponding security response operation is triggered based on the monitoring response list.

[0085] For example, in some other embodiments of this embodiment, the above-mentioned anomaly monitoring and repair module 603 can also be used to: obtain a first monitoring frequency and a second monitoring frequency; the value of the first monitoring frequency is greater than the value of the second monitoring frequency; during the system startup process and the operating system running start phase, monitor the memory service attributes of the startup service memory region through the first monitoring frequency; when the operating system enters the normal running phase, automatically switch to the second monitoring frequency to monitor the memory service attributes of the startup service memory region.

[0086] For example, in some other embodiments of this embodiment, the above-mentioned startup security verification module 602 can also be used to: perform a security verification operation at the entry point of the exit startup service function. The security verification operation includes: verifying the memory layout information and verification encryption information of the memory mapping baseline information in the trusted storage based on the same integrity verification method; if the verification is successful, determining the physical address of each startup service memory region according to the physical start address and region length field of the memory layout information; and reading the memory mapping data of the corresponding startup service memory region according to the physical address of each startup service memory region.

[0087] As an exemplary implementation of the above embodiments, the startup security verification module 602 can be further used to: verify that the encrypted information includes a memory signature and a memory mapping hash value, the trusted storage is a trusted platform module, read the memory layout information to be verified, the memory signature to be verified, and the memory mapping hash value to be verified from the memory mapping baseline information from the trusted platform module; perform hash calculation on the memory signature to be verified using the internal key of the trusted platform module to obtain the target memory mapping hash value; if the target memory mapping hash value and the memory mapping hash value to be verified are the same, calculate the target area hash value of each startup service memory area of ​​the memory layout information to be verified, and connect the target area hash values ​​in a predefined order to form the target initial memory mapping hash value; use the trusted platform module to perform public key verification on the target initial memory mapping hash value and the memory signature to be verified; if the public key verification passes, the memory mapping baseline information read from the trusted platform module has not been tampered with.

[0088] As another exemplary implementation of the above embodiments, the startup security verification module 602 can be further configured to: return an error and prevent the system from continuing to start if the target memory mapping hash value and the memory mapping hash value to be verified are different; return an error and prevent the system from continuing to start if the public key signature verification fails.

[0089] As another exemplary implementation of the above embodiments, the startup security verification module 602 can be further configured to: read the current memory descriptor structure according to the physical address, and each current memory descriptor structure constitutes a current memory descriptor list; traverse the current memory descriptor list to obtain the current physical starting address, current data length, and memory service attribute type identifier of each startup service memory region; if the memory service attribute type identifier of a target startup service memory region changes from startup service to runtime service, then modify the memory service attribute type identifier of the target startup service memory region to startup service; if there is no startup service memory region with the memory service attribute type identifier of runtime service, then calculate the current region hash value of each startup service memory region based on the same integrity verification method, and connect the current region hash values ​​into the current initial memory mapping hash value in a predefined order; if the current initial memory mapping hash value is the same as the initial memory mapping hash value in the verification encryption information, then the memory mapping data is consistent with the memory mapping base information.

[0090] The computer device startup device mentioned above is described from the perspective of a functional module. Furthermore, this invention also provides an electronic device, described from a hardware perspective, such as... Figure 7 As shown, the electronic device includes a memory 701 and a processor 702. The memory 701 stores a computer program, and the processor 702 is configured to run the computer program to perform the steps in any of the above-described computer device startup method embodiments.

[0091] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described computer device startup method embodiments when it is run.

[0092] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0093] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described computer device startup method embodiments.

[0094] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described computer device startup method embodiments.

[0095] The foregoing has provided a detailed description of a computer device startup method and electronic device provided by the present invention. The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. Whether the units and algorithm steps of the various examples described in the disclosed embodiments are executed in electronic hardware or computer software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, and such implementations should not be considered beyond the scope of the present invention. Several improvements and modifications can be made to the present invention without departing from its principles, and these improvements and modifications also fall within the protection scope of the present invention.

Claims

1. A method for starting a computer device, characterized in that, include: During the initialization phase of the Unified Extensible Firmware Interface startup process, memory-mapped baseline information is generated, stored in a trusted storage manner, and access is authorized to the target firmware modules of the Unified Extensible Firmware Interface. During the verification phase of the unified extensible firmware interface startup process, the memory mapping data of the startup service memory region is read through the physical address in the memory mapping baseline information; When the memory mapping data is consistent with the memory mapping baseline information, the startup process continues. During the startup process, the memory service attributes of the startup service memory region are monitored, and when the memory service attributes are detected to have been modified, the memory service attributes are restored to their original state.

2. The computer device startup method according to claim 1, characterized in that, During the initialization phase of the unified and extensible firmware interface startup process, memory-mapped baseline information is generated and stored using a trusted storage method, including: When the driver environment phase of firmware execution ends, a secure execution environment isolated from the main computer system is created; the secure execution environment is authorized to access via a unique secure interface. In the secure execution environment, the memory layout information of the startup service memory region is obtained by directly accessing physical memory; The memory layout information is verified for integrity and encrypted, and the verification and encryption information and the memory layout information are stored in different locations of the trusted platform module.

3. The computer device startup method according to claim 2, characterized in that, The memory layout information of the memory region for starting services is obtained by directly accessing physical memory, including: Read the memory descriptor structure of the unified extensible firmware interface in the system memory. Multiple memory descriptor structures constitute a memory descriptor list. Each memory descriptor structure contains at least the memory type, physical start address and region length fields. Traverse the list of memory descriptors to identify target memory regions whose memory type is either boot service code memory type or boot service data memory type; Select the memory region with the memory service attribute of startup service from each target memory region as the startup service memory region, and read the physical starting address and data length of each startup service memory region to obtain memory layout information.

4. The computer device startup method according to claim 2, characterized in that, The memory layout information includes memory parameters for multiple startup service memory regions. The memory layout information undergoes integrity verification and encryption, and the verification and encryption information, along with the memory layout information, are stored in different locations within the trusted platform module, including: Perform hash operations on each startup service memory region to obtain the region hash value of each startup service memory region; The hash values ​​of each region are concatenated in a predefined order to generate the initial memory mapping hash value corresponding to the memory layout information. The initial memory mapping hash value is digitally signed using the internal key of the trusted platform module to obtain the memory signature; The memory signature is hashed using the internal key of the trusted platform module to obtain the memory mapping hash value. Extend the memory-mapped hash value into the platform configuration register of the trusted platform module; The memory signature is stored in the non-volatile index of the trusted platform module; The memory layout information is stored in the firmware security partition of the trusted platform module.

5. The computer device startup method according to claim 1, characterized in that, After monitoring the memory service attributes of the startup service memory region, the process also includes: Obtain the monitoring response list and whitelist; the monitoring response list consists of user-configured security response operations and their corresponding triggering conditions; the whitelist is the address range of the trusted startup service memory region. Based on the whitelist, when it is detected that the memory service attribute has been changed from startup service to runtime service, a corresponding security response operation is triggered based on the monitoring response list.

6. The computer device startup method according to claim 1, characterized in that, Also includes: Obtain a first monitoring frequency and a second monitoring frequency; the value of the first monitoring frequency is greater than the value of the second monitoring frequency; During the system startup process and the initial stage of operating system operation, the memory service attributes of the startup service memory region are monitored at a first monitoring frequency. When the operating system enters the normal operation phase, it automatically switches to the second monitoring frequency to monitor the memory service attributes of the startup service memory region.

7. The computer device startup method according to any one of claims 1 to 6, characterized in that, Read the memory mapping data of the startup service memory region through the physical address in the memory mapping reference information, including: A security verification operation is performed at the entry point of the exit service startup function. The security verification operation includes: Based on the same integrity verification method, the memory layout information and verification encryption information of the memory mapping baseline information in trusted storage are verified; If the verification passes, the physical address of each startup service memory region is determined based on the physical start address and region length fields of the memory layout information. Based on the physical address of each startup service memory region, read the memory mapping data of the corresponding startup service memory region.

8. The computer device startup method according to claim 7, characterized in that, The verification encryption information includes a memory signature and a memory mapping hash value. The trusted storage method involves storage via a trusted platform module. Based on the same integrity verification method, the memory layout information and verification encryption information of the memory mapping baseline information in the trusted storage are verified, including: Read the unverified memory layout information, unverified memory signature, and unverified memory mapping hash value from the memory mapping baseline information from the trusted platform module; The target memory mapping hash value is obtained by hashing the memory signature to be verified using the internal key of the trusted platform module. If the target memory mapping hash value and the memory mapping hash value to be verified are the same, then the target region hash value of each startup service memory region of the memory layout information to be verified is calculated respectively, and the target region hash values ​​are concatenated in a predefined order to form the target initial memory mapping hash value. The trusted platform module is then used to perform public key verification on the target initial memory mapping hash value and the memory signature to be verified. If the target memory mapping hash value and the memory mapping hash value to be verified are different, then an error is returned and the system is prevented from continuing to start. If the public key verification passes, the memory mapping baseline information read from the trusted platform module has not been tampered with; if the public key verification fails, an error is returned and the system is prevented from continuing to start.

9. The computer device startup method according to claim 7, characterized in that, Read the memory-mapped data of the corresponding startup service memory region, including: The current memory descriptor structure is read according to the physical address, and the current memory descriptor structures constitute the current memory descriptor list. Traverse the current memory descriptor list to obtain the current physical starting address, current data length, and memory service attribute type identifier for each startup service memory region; If the memory service attribute type identifier of the target startup service memory region changes from startup service to runtime service, then modify the memory service attribute type identifier of the target startup service memory region to startup service. If there is no startup service memory region with the memory service attribute type identified as a runtime service, then based on the same integrity verification method, calculate the current region hash value of each startup service memory region, and concatenate the current region hash values ​​into the current initial memory mapping hash value in a predefined order; If the current initial memory mapping hash value is the same as the initial memory mapping hash value in the verification encryption information, then the memory mapping data is consistent with the memory mapping baseline information.

10. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the computer device startup method as described in any one of claims 1 to 9 when executing the computer program.

Images