Test methods, systems, terminals, and storage media for secure boot functionality

CN116185859BActive Publication Date: 2026-09-01INSPUR SUZHOU INTELLIGENT TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202310174294.9
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2023-02-28
Publication Date
2026-09-01
Estimated Expiration
2043-02-28

AI Technical Summary

Technical Problem

[0004]针对现有测试方法存在的步骤繁琐、低效的问题,本发明提供一种安全引导功能的测试方法、系统、终端及存储介质,以解决上述技术问题

Benefits of technology

[0056]本发明的有益效果在于,本发明提供的安全引导功能的测试方法、系统、终端及存储介质,通过借用两个存储器并为两个存储器分配秘钥,对两个存储器的秘钥进行分别设置并交替从两个存储器引导进入操作系统来验证安全引导功能的有效性,本发明能够实现对安全引导功能有效性的快速测试,步骤简单,大大提升了测试效率。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN116185859B_ABST
    Figure CN116185859B_ABST
Patent Text Reader

Abstract

This invention relates to the field of server technology, specifically providing a method, system, terminal, and storage medium for testing secure boot functionality. The method includes: using a key tool to generate keys for a first storage device and a second storage device, and embedding these keys into a whitelist library; both the first and second storage devices storing default boot files; booting into the operating system via the secure boot functionality through the first and second storage devices respectively, and generating log entries; embedding the keys for the first and second storage devices into a blacklist library; booting into the operating system via the secure boot functionality through the first and second storage devices respectively, and generating log entries again; and outputting all log entries as test results. This invention enables rapid testing of the effectiveness of secure boot functionality, with simple steps and significantly improved testing efficiency.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention belongs to the field of server technology, specifically relating to a testing method, system, terminal, and storage medium for a secure boot function. Background Technology

[0002] Secure Boot is a security standard developed by members of the computer industry to help ensure that devices boot using only software trusted by the original equipment manufacturer (OEM). When a computer boots, the firmware checks the signature of each boot software segment, including the UEFI firmware driver (also known as the option ROM), EFI applications, and the operating system. If the signature is valid, the computer will boot, and the firmware will transfer control to the operating system. Therefore, verifying the effectiveness of Secure Boot is essential when testing servers.

[0003] Existing verification methods require updating the key (verification) and applying for a signature for the boot device through a security agency. Only after approval, while adhering to various security standards, can the signed boot device be obtained. The verification process is relatively cumbersome and not conducive to the rapid deployment of work. Summary of the Invention

[0004] To address the problems of cumbersome and inefficient steps in existing testing methods, this invention provides a testing method, system, terminal, and storage medium for secure boot functions, thereby solving the aforementioned technical problems.

[0005] In a first aspect, the present invention provides a method for testing a secure boot function, comprising:

[0006] The key tool is called to generate keys for the first and second storage devices respectively, and the keys for the first and second storage devices are added to the whitelist library. Both the first and second storage devices store default boot files.

[0007] The system boots into the operating system via the first and second memory using the secure boot function, and generates a log record.

[0008] The keys for the first and second memories are implanted into the blacklist database;

[0009] The system boots into the operating system via the first and second memory using the secure boot function, generates logs, and outputs all logs as test results.

[0010] Furthermore, a keying tool is invoked to generate keys for the first and second storage devices respectively, and these keys are then added to a whitelist library. Both the first and second storage devices store default boot files, including:

[0011] In the BIOS, set the storage as the first boot device, enable secure boot, and clear all keys;

[0012] Create a default boot file under the operating system and name the first and second memory locations;

[0013] The operating system's keying tools are invoked to generate a first key and a second key for the first and second storage devices, respectively, and then the first key and the second key are inserted into the whitelist library.

[0014] Furthermore, the operating system is accessed via the first and second memory respectively using the secure boot function, and a log is generated, including:

[0015] Identify the first and second ports where the first and second memories intersect;

[0016] Uninstall the second driver on the second port and restart the operating system to trigger the secure boot function to boot from the first memory and enter the operating system, and write whether the entry into the operating system is successful to the log.

[0017] Uninstall the first driver for the first port, install the second driver for the second storage, and restart the operating system to trigger the secure boot function to boot from the second storage and enter the operating system. Write the success or failure of entering the operating system into the log.

[0018] Furthermore, the keys for the first and second memories are implanted into the blacklist database, including:

[0019] After booting into the operating system through the first memory, the key tool is invoked to implant the first key of the first memory into the blacklist database;

[0020] After booting into the operating system via the second storage, the key tool is invoked to implant the second key of the second storage into the blacklist database.

[0021] Furthermore, the operating system is accessed via the secure boot function in both the first and second memory, and a log is generated. All log entries are then output as test results, including:

[0022] Identify the first and second ports where the first and second memories intersect;

[0023] Uninstall the second driver for the second port, install the first driver for the first memory, and restart the operating system to trigger the secure boot function to boot from the first memory and enter the operating system, and write whether the entry into the operating system is successful to the log.

[0024] The system is pre-set to boot up at a set time. If the system fails to boot into the operating system within the set time, the system will then boot up normally.

[0025] After a normal boot, uninstall the first driver for the first port, install the second driver for the second storage, and restart the operating system to trigger the secure boot function to boot from the second storage and enter the operating system. Record whether the boot into the operating system was successful in the log.

[0026] Furthermore, after outputting all recorded logs as test results, the method also includes:

[0027] The test determines whether the execution result of entering the operating system is consistent with the expected result. If they are completely consistent, the test is considered to have passed; if they are not completely consistent, the test is considered to have failed. The expected result is that when the first key in the first memory is on the whitelist, the test successfully enters the operating system through the first memory; when the second key in the second memory is on the whitelist, the test successfully enters the operating system through the second memory; when the first key is on the blacklist, the test fails to enter the operating system through the first memory; and when the second key is on the blacklist, the test fails to enter the operating system through the second memory.

[0028] Secondly, the present invention provides a testing system for secure boot functionality, comprising:

[0029] The first setting unit is used to call the key tool to generate keys for the first memory and the second memory respectively, and to implant the keys of the first memory and the second memory into the whitelist library. Both the first memory and the second memory store default boot files.

[0030] The first boot unit is used to enter the operating system based on the secure boot function through the first memory and the second memory respectively, and to generate a log.

[0031] The second setting unit is used to implant the keys of the first memory and the second memory into the blacklist database;

[0032] The second boot unit is used to enter the operating system through the first memory and the second memory respectively based on the secure boot function, generate a log, and output all logs as test results.

[0033] Furthermore, the first setting unit includes:

[0034] The basic setup module is used to set the storage as the first boot device under BIOS, enable secure boot functionality, and clear all keys;

[0035] The naming generation module is used to create a default boot file under the operating system and name the first and second storage devices;

[0036] The key management module is used to call the operating system's key tools to generate a first key and a second key for the first memory and the second memory respectively, and to insert the first key and the second key into the whitelist library.

[0037] Furthermore, the first guiding unit specifically performs the following:

[0038] Identify the first and second ports where the first and second memories intersect;

[0039] Uninstall the second driver on the second port and restart the operating system to trigger the secure boot function to boot from the first memory and enter the operating system, and write whether the entry into the operating system is successful to the log.

[0040] Uninstall the first driver for the first port, install the second driver for the second storage, and restart the operating system to trigger the secure boot function to boot from the second storage and enter the operating system. Write the success or failure of entering the operating system into the log.

[0041] Furthermore, the second setting unit specifically performs the following:

[0042] After booting into the operating system through the first memory, the key tool is invoked to implant the first key of the first memory into the blacklist database;

[0043] After booting into the operating system via the second storage, the key tool is invoked to implant the second key of the second storage into the blacklist database.

[0044] Furthermore, the second guiding unit specifically performs the following:

[0045] Identify the first and second ports where the first and second memories intersect;

[0046] Uninstall the second driver for the second port, install the first driver for the first memory, and restart the operating system to trigger the secure boot function to boot from the first memory and enter the operating system, and write whether the entry into the operating system is successful to the log.

[0047] The system is pre-set to boot up at a set time. If the system fails to boot into the operating system within the set time, the system will then boot up normally.

[0048] After a normal boot, uninstall the first driver for the first port, install the second driver for the second storage, and restart the operating system to trigger the secure boot function to boot from the second storage and enter the operating system. Record whether the boot into the operating system was successful in the log.

[0049] Furthermore, the system also includes:

[0050] The result processing unit is used to determine whether the execution result of entering the operating system is consistent with the expected result. If they are completely consistent, the test is deemed to have passed; if they are not completely consistent, the test is deemed to have failed. The expected result is that when the first key in the first memory is on the whitelist, the system is successfully booted into the operating system through the first memory; when the second key in the second memory is on the whitelist, the system is successfully booted into the operating system through the second memory; when the first key is on the blacklist, the system fails to boot into the operating system through the first memory; and when the second key is on the blacklist, the system fails to boot into the operating system through the second memory.

[0051] Thirdly, a terminal is provided, including:

[0052] Processor, memory, among which,

[0053] This memory is used to store computer programs.

[0054] The processor is used to retrieve and run the computer program from memory, causing the terminal to perform the terminal method described above.

[0055] Fourthly, a computer storage medium is provided, wherein instructions are stored therein, which, when executed on a computer, cause the computer to perform the methods described in the above aspects.

[0056] The beneficial effects of the present invention are that the testing method, system, terminal and storage medium for the secure boot function provided by the present invention verify the effectiveness of the secure boot function by borrowing two memory and assigning keys to the two memory, setting the keys of the two memory separately and booting into the operating system alternately from the two memory. The present invention can realize rapid testing of the effectiveness of the secure boot function, with simple steps and greatly improved testing efficiency.

[0057] Furthermore, the design principle of this invention is reliable, the structure is simple, and it has a very wide range of application prospects. Attached Figure Description

[0058] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0059] Figure 1 This is a schematic flowchart of a method according to an embodiment of the present invention.

[0060] Figure 2 This is a schematic block diagram of a system according to an embodiment of the present invention.

[0061] Figure 3This is a schematic diagram of the structure of a terminal provided in an embodiment of the present invention. Detailed Implementation

[0062] To enable those skilled in the art to better understand the technical solutions of this invention, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this invention.

[0063] The key terms used in this invention will be explained below.

[0064] BIOS is an abbreviation for "Basic Input Output System." On IBM PC-compatible systems, it's an industry-standard firmware interface. It's a set of programs embedded in a ROM chip on the computer's motherboard. It stores the computer's most important basic input / output programs, power-on self-test (POST) programs, and system startup programs. It can read and write specific system settings from the CMOS. Its main function is to provide the lowest-level, most direct hardware settings and control for the computer. In addition, BIOS provides some system parameters to the operating system. Changes to the system hardware are hidden by BIOS; programs use BIOS functions rather than directly controlling the hardware. Modern operating systems often ignore the abstraction layer provided by BIOS and directly control hardware components.

[0065] WINDOWS: Generally refers to the Windows operating system, an operating system developed by Microsoft Corporation in the United States. It was released in 1985. Initially, it was just a Microsoft-DOS emulation environment. Due to continuous updates and upgrades by Microsoft, subsequent system versions have not only become easy to use, but have also become the most widely used operating system today.

[0066] Secure boot: Secure boot is a process or mechanism that ensures the integrity of programs running on a platform. Secure boot establishes a trust relationship between firmware and applications. With secure boot enabled, unsigned firmware or programs will not be able to run on the device.

[0067] EFI boot: bootx64.efi is the computer's default boot file. EFI booting on removable disk media does not depend on an operating system and can be considered as an operating system-less environment.

[0068] Database key (db): Allows access to a database used to sign or verify running binaries (bootloaders, boot managers, shells, drivers, etc.). The db can store multiple key values—an important fact for certain purposes. Note that the db can contain a public key (matching a private key that can be used to sign multiple binaries) and a hash value (used to describe a single binary).

[0069] Database blacklist (dbx): Denies access to the database. dbx is an anti-database; it contains keys and hash values ​​corresponding to known malware or other unwanted software. Keys or hash values ​​can be installed just like db. If a binary matches a key or hash value that exists in both db and dbx, dbx should take precedence.

[0070] Figure 1 This is a schematic flowchart illustrating a method according to an embodiment of the present invention. Wherein, Figure 1 The executing entity can be a test management system for a secure boot function.

[0071] like Figure 1 As shown, the method includes:

[0072] Step 110: Use the key tool to generate keys for the first memory and the second memory respectively, and implant the keys of the first memory and the second memory into the whitelist library. Both the first memory and the second memory store default boot files.

[0073] Step 120: Enter the operating system through the first memory and the second memory respectively based on the secure boot function, and generate a log record;

[0074] Step 130: Implant the keys of the first and second memories into the blacklist database;

[0075] Step 140: Enter the operating system through the first memory and the second memory respectively based on the secure boot function, generate a log, and output all logs as test results.

[0076] To facilitate understanding of the present invention, the following description further illustrates the testing method for the secure boot function provided by the present invention, based on the principle of the testing method for the secure boot function and in conjunction with the testing process for the secure boot function in the embodiments.

[0077] Specifically, the testing method for the secure boot function includes:

[0078] S 1. Call the key tool to generate keys for the first memory and the second memory respectively, and implant the keys of the first memory and the second memory into the whitelist library. Both the first memory and the second memory store default boot files.

[0079] Prepare a test machine and two USB flash drives. In the BIOS, set the USB flash drive as the first boot device, enable secure boot (Secure Cure Boot), and clear all security keys. Create EFI bootable USB flash drives within the operating system and name them USB1 and USB2. Use the operating system's built-in key generation tool (a black-box principle-based key generation tool) to generate authentication keys for each drive and embed them into the database.

[0080] S2. The operating system is accessed through the first memory and the second memory respectively using the secure boot function, and a log is generated.

[0081] In one implementation, a manual plugging and unplugging operation is used, and the specific steps are as follows:

[0082] (1) Keep USB drive 1 inserted, remove USB drive 2, restart the system, the system boots from the USB drive and enters the system normally, and logs are recorded. The log content includes whether the system entered successfully and the time when the operation took effect.

[0083] (2) Remove USB drive 1, insert USB drive 2, restart the system, the system boots from the USB drive and enters the system normally, and logs are recorded. The log content includes whether the system entered successfully and the time when the operation took effect.

[0084] In another implementation method, an automatic control approach is adopted, and the specific steps are as follows:

[0085] (1) Identify the first port and the second port where the first memory and the second memory are connected.

[0086] (2) Uninstall the second driver on the second port and restart the operating system to trigger the secure boot function to boot from the first memory and enter the operating system, and write whether the entry into the operating system is successful to the log.

[0087] (3) Uninstall the first driver of the first port (at this time, it is assumed that the operating system has been successfully booted through the first storage and the server is in the power-on state), install the second driver of the second storage, and restart the operating system to trigger the secure boot function to boot from the second storage and enter the operating system, and write whether the operating system has been successfully entered into the log.

[0088] S3. Implant the keys of the first and second memories into the blacklist database.

[0089] In the manual implementation, after removing USB drive 1, inserting USB drive 2, and successfully booting from the USB drive and entering the operating system normally, the key of USB drive 2 is implanted into the dbx library using a keying tool. Then, after removing USB drive 2, inserting USB drive 1, restarting the system, and successfully booting from the USB drive and entering the system normally, the key is implanted into the dbx library using a keying tool.

[0090] In the automated implementation, the specific execution steps are as follows: after booting and entering the operating system through the first memory, the key tool is invoked to implant the first key of the first memory into the blacklist database; after booting and entering the operating system through the second memory, the key tool is invoked to implant the second key of the second memory into the blacklist database.

[0091] S4. Enter the operating system through the first memory and the second memory respectively based on the secure boot function, generate a log, and output all logs as test results.

[0092] In the manual implementation, remove USB drive 1, insert USB drive 2, restart the system. The system prompts an invalid key, the USB drive boot fails, enters the system, and logs are recorded. Remove USB drive 2, insert USB drive 1, restart the system. The system prompts an invalid key, the USB drive boot fails, enters the system, and the device records logs. Remove USB drive 1, insert USB drive 2, restart the system. The system prompts an invalid key, the USB drive boot fails, enters the system, and the device records logs.

[0093] In the automated implementation method, the specific implementation steps are as follows:

[0094] (1) Identify the first port and the second port of the first memory and the second memory in the power-on state to ensure that both memory are in place.

[0095] (2) Uninstall the second driver of the second port, install the first driver of the first memory, and restart the operating system to trigger the secure boot function to boot from the first memory and enter the operating system, and write whether the operating system was successfully entered into the log.

[0096] (3) Since the key to the first memory has been implanted into the blacklist, there is a high probability that booting into the operating system through the first memory will fail. Therefore, it is necessary to pre-set a timed boot. If the operating system is not successfully entered within the timed period, the normal boot command will be executed, so that the test can continue. If the operating system is successfully booted through the first memory, it means that the secure boot function has failed and the test cannot continue.

[0097] (4) After normal power-on, uninstall the first driver of the first port, install the second driver of the second memory, and restart the operating system to trigger the secure boot function to boot from the second memory and enter the operating system, and write whether the operating system was successfully entered into the log.

[0098] The test determines whether the execution result upon entering the operating system matches the expected result. If they match completely, the test passes; otherwise, it fails. The expected result is that the first key in the first memory successfully boots into the operating system when it is on the whitelist, and the second key in the second memory successfully boots into the operating system when it is on the whitelist. Booting into the operating system fails when the first key is on the blacklist, and booting into the operating system fails when the second key is on the blacklist. The test result can be determined based on timestamps; the first two expected results should be successful booting into the operating system, and the last two expected results should be failure. By sorting the timestamps of successful and unsuccessful booting into the operating system in the log and comparing them with the expected results, the test's success or failure can be quickly determined.

[0099] like Figure 2 As shown, the system 200 includes:

[0100] The first setting unit 210 is used to call the key tool to generate keys for the first memory and the second memory respectively, and to implant the keys of the first memory and the second memory into the whitelist library. Both the first memory and the second memory store default boot files.

[0101] The first boot unit 220 is used to enter the operating system based on the secure boot function through the first memory and the second memory respectively, and generate a log record.

[0102] The second setting unit 230 is used to implant the keys of the first memory and the second memory into the blacklist database;

[0103] The second boot unit 240 is used to enter the operating system through the first memory and the second memory respectively based on the secure boot function, generate a log, and output all logs as test results.

[0104] Optionally, as an embodiment of the present invention, the first setting unit includes:

[0105] The basic setup module is used to set the storage as the first boot device under BIOS, enable secure boot functionality, and clear all keys;

[0106] The naming generation module is used to create a default boot file under the operating system and name the first and second storage devices;

[0107] The key management module is used to call the operating system's key tools to generate a first key and a second key for the first memory and the second memory respectively, and to insert the first key and the second key into the whitelist library.

[0108] Optionally, as an embodiment of the present invention, the first guiding unit specifically performs:

[0109] Identify the first and second ports where the first and second memories intersect;

[0110] Uninstall the second driver on the second port and restart the operating system to trigger the secure boot function to boot from the first memory and enter the operating system, and write whether the entry into the operating system is successful to the log.

[0111] Uninstall the first driver for the first port, install the second driver for the second storage, and restart the operating system to trigger the secure boot function to boot from the second storage and enter the operating system. Write the success or failure of entering the operating system into the log.

[0112] Optionally, as an embodiment of the present invention, the second setting unit specifically performs the following:

[0113] After booting into the operating system through the first memory, the key tool is invoked to implant the first key of the first memory into the blacklist database;

[0114] After booting into the operating system via the second storage, the key tool is invoked to implant the second key of the second storage into the blacklist database.

[0115] Optionally, as an embodiment of the present invention, the second guiding unit specifically performs the following:

[0116] Identify the first and second ports where the first and second memories intersect;

[0117] Uninstall the second driver for the second port, install the first driver for the first memory, and restart the operating system to trigger the secure boot function to boot from the first memory and enter the operating system, and write whether the entry into the operating system is successful to the log.

[0118] The system is pre-set to boot up at a set time. If the system fails to boot into the operating system within the set time, the system will then boot up normally.

[0119] After a normal boot, uninstall the first driver for the first port, install the second driver for the second storage, and restart the operating system to trigger the secure boot function to boot from the second storage and enter the operating system. Record whether the boot into the operating system was successful in the log.

[0120] Optionally, as an embodiment of the present invention, the system further includes:

[0121] The result processing unit is used to determine whether the execution result of entering the operating system is consistent with the expected result. If they are completely consistent, the test is deemed to have passed; if they are not completely consistent, the test is deemed to have failed. The expected result is that when the first key in the first memory is on the whitelist, the system is successfully booted into the operating system through the first memory; when the second key in the second memory is on the whitelist, the system is successfully booted into the operating system through the second memory; when the first key is on the blacklist, the system fails to boot into the operating system through the first memory; and when the second key is on the blacklist, the system fails to boot into the operating system through the second memory.

[0122] Figure 3 This is a schematic diagram of the structure of a terminal 300 provided in an embodiment of the present invention. The terminal 300 can be used to execute the test method for the secure boot function provided in the embodiment of the present invention.

[0123] The terminal 300 may include a processor 310, a memory 320, and a communication unit 330. These components communicate via one or more buses. Those skilled in the art will understand that the server structure shown in the figure does not constitute a limitation of the present invention. It may be a bus topology or a star topology, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0124] The memory 320 can be used to store the execution instructions of the processor 310. The memory 320 can be implemented by any type of volatile or non-volatile memory terminal or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. When the execution instructions in the memory 320 are executed by the processor 310, the terminal 300 is able to perform some or all of the steps in the above method embodiments.

[0125] The processor 310 serves as the control center of the storage terminal, connecting various parts of the electronic terminal via various interfaces and lines. It executes software programs and / or modules stored in the memory 320, and calls data stored in the memory to perform various functions of the electronic terminal and / or process data. The processor can be composed of integrated circuits (ICs), such as a single packaged IC or multiple packaged ICs with the same or different functions connected together. For example, the processor 310 may consist only of a central processing unit (CPU). In this embodiment of the invention, the CPU may have a single processing core or include multiple processing cores.

[0126] The communication unit 330 is used to establish a communication channel, enabling the storage terminal to communicate with other terminals. It can receive user data sent by other terminals or send user data to other terminals.

[0127] The present invention also provides a computer storage medium, wherein the computer storage medium may store a program, which, when executed, may include some or all of the steps provided in the embodiments of the present invention. The storage medium may be a magnetic disk, an optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0128] Therefore, this invention verifies the effectiveness of the secure boot function by borrowing two memory devices and assigning keys to them, setting the keys for each device separately, and alternately booting into the operating system from the two devices. This invention enables rapid testing of the effectiveness of the secure boot function, with simple steps and greatly improved testing efficiency. The technical effects achieved by this embodiment can be found in the description above, and will not be repeated here.

[0129] Those skilled in the art will clearly understand that the techniques in the embodiments of the present invention can be implemented using software and necessary general-purpose hardware platforms. Based on this understanding, the technical solutions in the embodiments of the present invention, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, or any other medium capable of storing program code. It includes several instructions to cause a computer terminal (which may be a personal computer, a server, or a second terminal, a network terminal, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0130] The same or similar parts between the various embodiments in this specification can be referred to mutually. In particular, the terminal embodiments are basically similar to the method embodiments, so the description is relatively simple, and the relevant parts can be referred to the description in the method embodiments.

[0131] In the embodiments provided by this invention, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between systems or units may be electrical, mechanical, or other forms.

[0132] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0133] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0134] Although the present invention has been described in detail with reference to the accompanying drawings and preferred embodiments, the invention is not limited thereto. Various equivalent modifications or substitutions can be made to the embodiments of the invention by those skilled in the art without departing from the spirit and essence of the invention, and such modifications or substitutions should all be within the scope of the invention. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the invention should also be covered within the protection scope of the invention. Therefore, the protection scope of the invention should be determined by the scope of the claims.

Claims

1. A method for testing a secure boot function, characterized in that, include: The key tool is called to generate keys for the first and second storage devices respectively, and the keys for the first and second storage devices are added to the whitelist library. Both the first and second storage devices store default boot files. The key-calling tool generates keys for the first and second storage devices respectively, and inserts the keys for the first and second storage devices into a whitelist. Both the first and second storage devices store default boot files, including: setting the storage device as the first boot entry in the BIOS, enabling the secure boot function, and clearing all authentication keys; creating default boot files in the operating system and naming the first and second storage devices; calling the operating system's key-calling tool to generate first and second keys for the first and second storage devices respectively, and inserting the first and second keys into the whitelist; both the first and second keys are authentication keys. The system enters the operating system via a secure boot function through a first memory and a second memory respectively, and generates a log record. This process includes: identifying the first port and the second port that connect the first memory and the second memory; uninstalling the second driver on the second port and restarting the operating system to trigger the secure boot function to boot from the first memory and enter the operating system, and writing whether the boot was successful into the operating system log; uninstalling the first driver on the first port, installing the second driver on the second memory, and restarting the operating system to trigger the secure boot function to boot from the second memory and enter the operating system, and writing whether the boot was successful into the operating system log. The keys for the first and second memories are implanted into the blacklist database; The system boots into the operating system via the first and second memory using the secure boot function, generates logs, and outputs all logs as test results. This process includes: identifying the first and second ports connected to the first and second memory; uninstalling the second driver for the second port, installing the first driver for the first memory, and restarting the operating system to trigger the secure boot function to boot from the first memory and enter the operating system, recording whether the boot was successful in the logs; pre-setting a timed power-on; if the boot fails within the timed period, executing a normal power-on command; after a normal power-on, uninstalling the first driver for the first port, installing the second driver for the second memory, and restarting the operating system to trigger the secure boot function to boot from the second memory and enter the operating system, recording whether the boot was successful in the logs. After outputting all recorded logs as test results, the method further includes: The test determines whether the execution result upon entering the operating system matches the expected result. If they match completely, the test is considered passed; otherwise, the test is considered failed.

2. The method according to claim 1, characterized in that, The keys for the first and second memories are implanted into the blacklist database, including: After booting into the operating system through the first memory, the key tool is invoked to implant the first key of the first memory into the blacklist database; After booting into the operating system via the second storage, the key tool is invoked to implant the second key of the second storage into the blacklist database.

3. The method according to claim 1, characterized in that, The expected result is that when the first key in the first memory is on the whitelist, the system will successfully boot into the operating system through the first memory; when the second key in the second memory is on the whitelist, the system will successfully boot into the operating system through the second memory; when the first key is on the blacklist, the system will fail to boot into the operating system through the first memory; and when the second key is on the blacklist, the system will fail to boot into the operating system through the second memory.

4. A testing system for secure boot functionality, characterized in that, include: The first setting unit is used to call the key tool to generate keys for the first memory and the second memory respectively, and to implant the keys of the first memory and the second memory into the whitelist library. Both the first memory and the second memory store default boot files. The first boot unit is used to enter the operating system based on the secure boot function through the first memory and the second memory respectively, and to generate a log. The process of entering the operating system via the first memory and the second memory using the secure boot function and generating a log includes: identifying the first port and the second port that the first memory and the second memory are connected to; uninstalling the second driver of the second port and restarting the operating system to trigger the secure boot function to boot from the first memory and enter the operating system, and writing whether the entry into the operating system was successful into the log; uninstalling the first driver of the first port, installing the second driver of the second memory, and restarting the operating system to trigger the secure boot function to boot from the second memory and enter the operating system, and writing whether the entry into the operating system was successful into the log. The second setting unit is used to implant the keys of the first memory and the second memory into the blacklist database; The second boot unit is used to enter the operating system through the first memory and the second memory respectively based on the secure boot function, generate a log, and output all logs as test results. This process includes: identifying the first port and the second port that connect the first memory and the second memory; uninstalling the second driver of the second port, installing the first driver of the first memory, and restarting the operating system to trigger the secure boot function to boot from the first memory and enter the operating system, and writing whether the boot was successful into the operating system into the log; pre-setting a timed power-on; if the boot is not successful within the time limit, executing a normal power-on command; after a normal power-on, uninstalling the first driver of the first port, installing the second driver of the second memory, and restarting the operating system to trigger the secure boot function to boot from the second memory and enter the operating system, and writing whether the boot was successful into the operating system into the log. The first setting unit includes: The basic setup module is used to set the storage device as the first boot device in the BIOS, enable secure boot functionality, and clear all authentication keys; The naming generation module is used to create a default boot file under the operating system and name the first and second storage devices; The key management module is used to call the operating system's key tools to generate a first key and a second key for the first memory and the second memory respectively, and to insert the first key and the second key into the whitelist library; both the first key and the second key are authentication keys; The system is also configured to perform the following steps: After outputting all log entries as test results, determine whether the execution result upon entering the operating system matches the expected result. If they match completely, the test is considered passed; otherwise, the test is considered failed.

5. A terminal, characterized in that, include: processor; Memory used to store the processor's execution instructions; The processor is configured to perform the method according to any one of claims 1-3.

6. A computer-readable storage medium storing a computer program, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-3.