Method for secure boot verification based on virtualization system

CN123013074APending Publication Date: 2026-10-30DONGFENG MOTOR GRP
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202611082191.X
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-07-21
Publication Date
2026-10-30

AI Technical Summary

Technical Problem

现有技术采用顺序依次校验,依次对按顺序启动组件(如Bootloader、内核、应用固件)进行数字签名或哈希校验,校验消耗较长,设备启动时间慢

Benefits of technology

[0013]本发明的第四方面还提供了一种计算机可读存储介质,其上存储有可执行指令,该指令被处理器执行时使处理器执行上述基于虚拟化系统的安全启动校验方法。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN123013074A_ABST
    Figure CN123013074A_ABST
Patent Text Reader

Abstract

The application provides a kind of security start verification method based on virtualization system, belong to the field of automobile control technology, the security start verification method based on virtualization system, method executes in the stage of starting loader, including: in response to system start flow, then call custom loading interface to load target image, custom loading interface at least receives the partition name of target image, image name and loading address as parameter;Based on partition name, obtain the security policy index corresponding to target image, and determine whether target image needs to be checked according to security policy index;If needed, execute security check process to target image, and load target image to loading address after passing the check;If not needed, directly load target image to loading address.The application skips the check of non-critical or trusted image, reduces the fixed time consumption in system start process, significantly shortens the system start time under the premise of meeting the security start.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of automotive control technology, and in particular to a secure boot verification method based on a virtualization system. Background Technology

[0002] With the increasing prevalence of intelligent connected vehicles, vehicle information security has received growing attention. Device startup security directly determines the operational security of the entire system and serves as the first line of defense for ensuring data confidentiality, integrity, and availability. Secure boot, as a core security mechanism, aims to perform security verification on each component in the boot chain (such as the bootloader, firmware, and operating system kernel) during the device startup process. This ensures that only authorized and tamper-proof components can be loaded and executed, thereby blocking attacks such as malicious software and unauthorized firmware modifications, and preventing device hijacking, data leakage, or system damage. Current technologies employ sequential verification, performing digital signatures or hash verification on sequentially booting components (such as the bootloader, kernel, and application firmware). This verification process is time-consuming and slows down device startup. Summary of the Invention

[0003] This invention aims to solve at least one of the technical problems existing in the prior art, and proposes a secure boot verification method based on a virtualization system to improve boot efficiency.

[0004] In a first aspect, embodiments of the present invention provide a secure boot verification method based on a virtualization system. The method is executed during the boot loader stage and includes: responding to the system boot process by calling a custom loading interface to load a target image; the custom loading interface receives at least the partition name, image name, and load address of the target image as parameters; based on the partition name, obtaining the security policy index corresponding to the target image, and determining whether the target image needs security verification according to the security policy index; if so, performing a security verification process on the target image, and loading the target image to the load address after successful verification; if not, directly loading the target image to the load address.

[0005] According to an embodiment of the present invention, determining whether a target image needs to undergo security verification based on a security policy index includes: returning a Boolean value or status code indicating whether security verification is required by using the security policy index and calling a security policy query function.

[0006] According to an embodiment of the present invention, after calling the custom loading interface, the method further includes: in response to the global security software support function not being enabled, skipping the process of obtaining the security policy index and security verification, and directly loading the target image to the loading address.

[0007] According to an embodiment of the present invention, a security verification process is performed on the target image, and the target image is loaded to the loading address after the verification is successful. This includes: calling a security verification initialization function and passing in the partition name and image name to verify the certificate chain of the target image; if the certificate chain verification fails, an error is returned and the system startup process is terminated; if the certificate chain verification is successful, the target image is loaded to the loading address; calling a post-verification function and passing in the loading address and size of the loaded target image to authenticate the content of the target image; if the content authentication fails, an error is returned and the system startup process is terminated; if the content authentication is successful, the loading of the target image is completed.

[0008] According to an embodiment of the present invention, before loading the target image to the loading address, a rollback prevention check step is further included, specifically including: calling a rollback prevention check function to verify that the version of the target image is not lower than the security version already stored in the system; if the rollback prevention check fails, an error is returned and the system startup process is terminated; if the rollback prevention check succeeds, the loading step continues.

[0009] According to an embodiment of the present invention, after the target image is loaded, the method further includes: recording a security verification completion event or a timestamp of the target image.

[0010] According to an embodiment of the present invention, the partition name is associated with a configurable security policy, the partition name includes at least the Android system and the Yocto system, and the target image is a specific image that needs to be loaded before starting the Android system and / or the Yocto system; a custom loading interface is called to load the target image, and before that, the following steps are included: setting the target image of the Android system to not require security verification; setting the target image of the Yocto system to require security verification.

[0011] Secondly, this invention provides a secure boot verification system based on a virtualization system, which can be used to implement the aforementioned secure boot verification method based on a virtualization system. The system includes: an initial loading module, used to call a custom loading interface to load a target image in response to the system boot process; the custom loading interface receives at least the partition name, image name, and loading address of the target image as parameters; a policy determination module, used to obtain a security policy index corresponding to the target image based on the partition name; and a verification loading module, used to determine whether the target image needs security verification based on the security policy index; if so, to perform a security verification process on the target image and load the target image to the loading address after successful verification; if not, to directly load the target image to the loading address.

[0012] A third aspect of the present invention provides an electronic device, comprising: one or more processors; and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors perform the above-described secure boot verification method based on a virtualization system.

[0013] A fourth aspect of the present invention also provides a computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor, cause the processor to perform the above-described secure boot verification method based on a virtualization system.

[0014] The secure boot verification method based on virtualization system provided by this invention defines a software interface to load a partially signed image. By skipping the verification process for non-critical or trusted images, it reduces the time consumed during system boot. This method at least partially solves the technical problem of slow device boot time caused by sequential verification of all boot components in the prior art, and achieves the technical effect of shortening system boot time while meeting secure boot requirements. Attached Figure Description

[0015] Figure 1 A flowchart illustrating a secure boot verification method based on a virtualization system provided in an embodiment of the present invention;

[0016] Figure 2 This is a function call flowchart of the security verification process performed on the target image in an embodiment of the present invention;

[0017] Figure 3 This is a flowchart illustrating an optional specific implementation method for performing a security verification process on a target image in an embodiment of the present invention;

[0018] Figure 4 A structural block diagram of a secure boot verification system based on a virtualization system provided in an embodiment of the present invention;

[0019] Figure 5 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0020] To enable those skilled in the art to better understand the technical solutions of the present invention, exemplary embodiments of the present invention are described below in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0021] Where there is no conflict, the various embodiments of the present invention and the features thereof may be combined with each other.

[0022] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0023] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Terms such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0024] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having the meaning consistent with their meaning in the context of the relevant art and the invention, and will not be interpreted as having an idealized or overly formal meaning unless expressly so defined herein.

[0025] In the technical solution of this invention, the collection, storage, use, processing, transmission, provision, and disclosure of user personal information all comply with relevant laws and regulations and do not violate public order and good morals. The use of user data in this technical solution follows relevant national laws and regulations (e.g., the "Information Security Technology - Personal Information Security Specification"). For example: appropriate measures are taken for personal information access control; restrictions are imposed on the display of personal information; the purpose of using personal information does not exceed the scope of direct or reasonable association; and explicit identity targeting is eliminated when using personal information to avoid precisely locating a specific individual.

[0026] First, the boot process based on a dual-system is as follows:

[0027] 1. In the Preloader stage, the basic components required for startup are loaded sequentially: A / B partition information is loaded; sspm, lk, tee, g2 are loaded sequentially; then the process jumps to the LK stage.

[0028] 2. LK phase: Load kernel and virtualization components: Load mcupm and other platform components; Load in sequence: Hypervisor, Kernel & DTB, Yocto kernel, Android kernel; Allocate reserved memory.

[0029] 3. Android startup phase: The Android system starts running; the file system is mounted; the backend kernel modules are waited for and loaded; the Android kernel officially starts running.

[0030] 4. Yocto startup phase: The Yocto system begins to run; the Yocto kernel runs.

[0031] The entire process from Preloader to dual-system startup of Android and Yocto is executed sequentially, with each stage only starting after the previous one is completed.

[0032] Verifying all images during the dual-system boot process consumes a significant amount of boot time. Therefore, a software interface is designed to load only the signed images. This completes the verification process for the dual-system boot process. During system power-on, specific signed images undergo a security verification process. This invention provides a secure boot verification method for virtualization systems during the LK boot phase. Figure 1 This is a flowchart illustrating a secure boot verification method based on a virtualization system, provided by an embodiment of the present invention. The present invention aims to solve at least one of the technical problems existing in the prior art and proposes a secure boot verification method based on a virtualization system. The method is executed during the boot loader stage and includes: responding to the system boot process by calling a custom loading interface to load a target image; the custom loading interface at least receives the partition name, image name, and loading address of the target image as parameters; based on the partition name, obtaining the security policy index corresponding to the target image, and determining whether the target image needs security verification according to the security policy index; if so, performing a security verification process on the target image, and loading the target image to the loading address after successful verification; if not, directly loading the target image to the loading address.

[0033] The specific image loading and verification process occurs during the LK startup phase. The main implementation idea is to define a `load_custom_image` interface to customize the loading of a signed, specific image. The core logic of the interface is as follows: Figure 2As shown, in the secure boot verification process, the first step is to obtain the index of the partition security policy entry point using `get_policy_entry_idx`. Then, the security policy corresponding to each image is retrieved by traversing the index, which determines whether the image needs security verification. When image verification is required, verification initialization is performed using `sec_img_auth_init`, followed by loading the image into memory using `mboot_common_load_part`. Finally, the system can only boot normally after passing the security verification via the `sec_img_auth` interface; otherwise, booting fails. When image verification is not required, the image is directly loaded into memory using `mboot_common_load_part`.

[0034] The pseudocode for the function load_custom_image(partition_name, image_name, load_address) is as follows:

[0035] / / Initialize the return value;

[0036] Return value = 0;

[0037] / / 1. Security authentication pre-process;

[0038] If security software support is enabled:

[0039] Policy index = get_policy_entry_idx(partition name);

[0040] Mirror authentication required = get_vfy_policy(policy index);

[0041] If mirror authentication is required:

[0042] / / Initialize and verify the image certificate chain;

[0043] Security return value = sec_img_auth_init(partition name, image name, 0);

[0044] If the safety return value is non-zero (failure):

[0045] Returns -1;

[0046] / / Optional: Anti-rollback version check

[0047] If the rollback prevention mechanism is enabled:

[0048] Security return value = sec_rollback_check (1);

[0049] If the safety return value is non-zero (failure):

[0050] Returns -1;

[0051] / / 2. Load the image to the specified address;

[0052] Return value = mboot_common_load_part(partition name, image name, load address);

[0053] If the return value is 1 ≤ 0 (failure):

[0054] Returns -1;

[0055] / / 3. Post-security authentication process;

[0056] If security software support is enabled and image authentication is required:

[0057] / / Verify the image content that has been loaded into memory;

[0058] Security return value = sec_img_auth(load address, return value);

[0059] If the safety return value is non-zero (failure):

[0060] Returns -1;

[0061] / / Returns image size (success);

[0062] Returns the return value.

[0063] The function's capabilities include: loading a custom image, performing optional certificate chain verification, rollback checks, and image content authentication based on security policies; inputs: partition name, image name, and target address for image loading; output: image size on success; -1 on failure.

[0064] It should be noted that this invention is not limited to virtualization or dual systems. For example, in IoT devices with a single system but numerous modules, different policies can be configured for firmware partitions with different security levels. These policies can also be extended to specify different verification algorithm strengths or different root trust certificates for different security levels.

[0065] Through the embodiments of the present invention, in the virtualization trusted boot scheme, the design of the custom interface (load_custom_image) is the core link to realize the boot verification. This method implements a switchable, configurable, and extensible security verification interface by obtaining the index and security policy mechanism, which is used to verify a specific signed image in the LK boot stage and supports the completion of the security boot verification process of dual systems.

[0066] Based on the above embodiments, determining whether the target image needs to undergo security verification according to the security policy index includes: returning a boolean value or status code indicating whether security verification is required by using the security policy index and calling the security policy query function.

[0067] In this embodiment, if the policy can be extended to specify different verification algorithm strengths or different root trust certificates for different security levels, the returned policy status codes can be further enriched, for example, skip verification, standard verification, and strict verification (including additional integrity checks). The policy query function can also be designed to support dynamic updates of the policy table at runtime, obtaining the latest policy configuration from the server through a secure channel to achieve dynamic security responses.

[0068] Through the embodiments of the present invention, a partition security policy is obtained, and the policy judgment logic is encapsulated into a standard function call, which separates the policy query and execution logic, makes the judgment criteria clear and programmable, and achieves the technical effect of improving the flexibility of the verification process.

[0069] Based on the above embodiments, after calling the custom loading interface, the method further includes: in response to the global security software support function not being enabled, skipping the process of obtaining the security policy index and security verification, and directly loading the target image to the loading address.

[0070] Through embodiments of the present invention, it is possible to check whether security functions are enabled, determine whether to completely skip the entire security verification logic, and provide a fast track.

[0071] Figure 3 This is a flowchart illustrating an optional specific implementation method for performing a security verification process on a target image in an embodiment of the present invention, as shown below. Figure 3 As shown, a security verification process is performed on the target image, and the target image is loaded to the loading address after successful verification. This includes: calling the security verification initialization function and passing in the partition name and image name to verify the certificate chain of the target image; if the certificate chain verification fails, an error is returned and the system startup process is terminated; if the certificate chain verification succeeds, the target image is loaded to the loading address; calling the post-verification function and passing in the loading address and size of the loaded target image to authenticate the content of the target image; if the content authentication fails, an error is returned and the system startup process is terminated; if the content authentication succeeds, the loading of the target image is completed.

[0072] In this embodiment, the `sec_img_auth_init` function is responsible for parsing the certificate chain in the image header, verifying the certificate signature using the device's built-in public key, and establishing a trust chain. The `mboot_common_load_part` function is responsible for reading image data from the storage medium into memory. The `sec_img_auth` function then uses the public key of the leaf certificate in the certificate chain to sign and verify the image data loaded into memory.

[0073] Through the embodiments of the present invention, certificate chain verification, actual loading of the image into memory, and checking whether the loading is successful are performed. The legality and integrity of the image are double-verified before and after loading, ensuring effective defense against certificate forgery and content tampering attacks.

[0074] Based on the above embodiments, before loading the target image to the loading address, a rollback prevention check step is also included, specifically including: calling the rollback prevention check function to verify that the version of the target image is not lower than the security version already stored in the system; if the rollback prevention check fails, an error is returned and the system startup process is terminated; if the rollback prevention check succeeds, the loading step continues.

[0075] In this embodiment, when the `sec_rollback_check` function is called, it reads the version number from the target image header and simultaneously reads the preset security version number for this type of image from the device's tamper-proof storage area. The function compares the version number and the security version number; if both are true, the process proceeds. The security version number is typically updated after each successful upgrade to a security version.

[0076] Through embodiments of the present invention, a rollback prevention check step is inserted before loading the image to verify that the image version is not lower than the security version and to prevent version rollback.

[0077] Based on the above embodiments, after the target image is loaded, the method further includes: recording the security verification completion event or timestamp of the target image.

[0078] Through the embodiments of the present invention, the loaded image is signed and verified, and the verification time is recorded, leaving a traceable security audit log for the system startup process.

[0079] Based on the above embodiments, the partition name is associated with a configurable security policy. The partition name includes at least the Android system and the Yocto system. The target image is a specific image that needs to be loaded before starting the Android system and / or the Yocto system. The custom loading interface is called to load the target image. Before that, the following steps are also taken: setting the target image of the Android system to not require security verification; setting the target image of the Yocto system to require security verification.

[0080] During the system design phase, a policy configuration file is defined, containing entries such as: `[android.boot] verify=no; [yocto.boot] verify=yes`. During compilation and building, the toolchain script converts this configuration file into an array `verify_policy_table[]` in a C header file, with contents corresponding to the above configuration. The partition name used by the `load_custom_image` interface is the key for looking up this table.

[0081] Through the embodiments of the present invention, by setting the association between partitions and configurable security policies, a differentiated security boot strategy is implemented in a multi-system environment, thereby enabling different security level verifications for system components with different security requirements (such as entertainment systems and vehicle control systems), thus optimizing the overall boot efficiency.

[0082] Figure 4 A structural block diagram of a secure boot verification system based on a virtualization system provided in an embodiment of the present invention is shown below. Figure 4 As shown, this invention provides a secure boot verification system based on a virtualization system, which can be used to implement the aforementioned secure boot verification method based on a virtualization system. The system includes: an initial loading module, used to call a custom loading interface to load a target image in response to the system boot process; the custom loading interface receives at least the partition name, image name, and loading address of the target image as parameters; a policy determination module, used to obtain a security policy index corresponding to the target image based on the partition name; and a verification loading module, used to determine whether the target image needs security verification based on the security policy index; if so, to perform a security verification process on the target image and load the target image to the loading address after successful verification; if not, to directly load the target image to the loading address.

[0083] Based on the same inventive concept, embodiments of the present invention also provide an electronic device. Figure 5 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Figure 5 As shown, an embodiment of the present invention provides an electronic device including: one or more processors 101, a memory 102, and one or more I / O interfaces 103. The memory 102 stores one or more programs, which, when executed by the one or more processors, enable the one or more processors to implement any of the secure boot verification methods based on a virtualization system as described in the above embodiments; the one or more I / O interfaces 103 are connected between the processor and the memory, configured to enable information interaction between the processor and the memory.

[0084] The processor 101 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 102 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read / write interface) 103 is connected between the processor 101 and the memory 102, and can realize information interaction between the processor 101 and the memory 102, including but not limited to a data bus (Bus).

[0085] In some embodiments, the processor 101, memory 102, and I / O interface 103 are interconnected via bus 104, and thus connected to other components of the computing device.

[0086] In some embodiments, the one or more processors 101 include a field-programmable gate array.

[0087] This invention also provides a computer-readable medium. The computer-readable medium stores a computer program, which, when executed by a processor, implements the steps of any of the secure boot verification methods based on a virtualization system described in the above embodiments. The computer-readable storage medium can be volatile or non-volatile.

[0088] This invention also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code. When the computer-readable code is run in the processor of an electronic device, the processor in the electronic device executes the above-described secure boot verification method based on a virtualization system.

[0089] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0090] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0091] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0092] The computer program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing state information from the computer-readable program instructions. This electronic circuitry can execute the computer-readable program instructions to implement various aspects of the invention.

[0093] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0094] Various aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0095] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0096] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0097] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0098] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of the invention as set forth in the appended claims.

Claims

1. A secure boot verification method based on a virtualization system, characterized in that, The method is executed during the startup loader phase and includes: In response to the system startup process, a custom loading interface is called to load the target image. The custom loading interface receives at least the partition name, image name, and loading address of the target image as parameters. Based on the partition name, obtain the security policy index corresponding to the target image, and determine whether the target image needs to be security verified based on the security policy index; If necessary, a security verification process is performed on the target image, and the target image is loaded into the loading address after the verification is passed; If not required, the target image is directly loaded to the loading address.

2. The method according to claim 1, wherein, The step of determining whether the target image needs to undergo security verification based on the security policy index includes: By indexing the security policy and calling the security policy query function, a boolean value or status code indicating whether security verification is required is returned.

3. The method according to claim 1, wherein, After invoking the custom loading interface, the method further includes: If the global security software support function is not enabled, the process of obtaining the security policy index and security verification is skipped, and the target image is directly loaded to the loading address.

4. The method according to claim 1, wherein, The step of performing a security verification process on the target image and loading the target image to the loading address after the verification is successful includes: Call the security verification initialization function, and pass in the partition name and the image name to verify the certificate chain of the target image; If certificate chain verification fails, an error is returned and the system startup process is terminated; If the certificate chain verification is successful, the target image is loaded into the loading address; Call the post-verification function, passing in the load address and size of the loaded target image, to authenticate the content of the target image; If content authentication fails, an error is returned and the system startup process is terminated; If content authentication is successful, the target image loading is complete.

5. The method according to claim 4, wherein, Before loading the target image to the load address, a rollback prevention check step is also included, specifically including: Call the rollback prevention check function to verify that the version of the target image is not lower than the security version already stored in the system; If the rollback prevention check fails, an error is returned and the system startup process is terminated; If the rollback prevention check is successful, continue with the loading step.

6. The method according to claim 4, wherein, After the target image is loaded, the method further includes: Record the security verification completion event or timestamp of the target image.

7. The method according to claim 1, wherein, The partition name is associated with a configurable security policy, and the partition name includes at least the Android system and the Yocto system. The target image is a specific image that needs to be loaded before starting the Android system and / or the Yocto system. The process includes calling a custom loading interface to load the target image, preceded by: Setting the target image for the Android system does not require security verification; Setting the target image for the Yocto system requires security verification.

8. A secure boot verification system based on a virtualization system, characterized in that, The method for secure boot verification based on a virtualization system as described in claim 1 includes: The initial loading module is used to call a custom loading interface to load the target image in response to the system startup process. The custom loading interface receives at least the partition name, image name and loading address of the target image as parameters. The policy determination module is used to obtain the security policy index corresponding to the target image based on the partition name; The verification loading module is used to determine whether the target image needs to be verified based on the security policy index; if so, the security verification process is performed on the target image, and the target image is loaded into the loading address after the verification is passed; if not, the target image is directly loaded into the loading address.

9. An electronic device, characterized in that, include: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1 to 7.

10. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 7.