CN118193070A

CN118193070A - Linux-based system safe starting method, electronic equipment and storage medium

Info

Publication number: CN118193070A
Application number: CN202410382466.6A
Authority: CN
Inventors: 张波; 谢利洪; 单飞; 刘传
Original assignee: PAX Computer Technology Shenzhen Co Ltd
Current assignee: PAX Computer Technology Shenzhen Co Ltd
Priority date: 2024-03-29
Filing date: 2024-03-29
Publication date: 2024-06-14

Abstract

The application provides a Linux-based system security starting method, electronic equipment and a storage medium, which comprise the following steps: clearing an original certificate of the main board and generating a new certificate chain; generating a boot loader and a GNU privacy protection public key corresponding to the GNU privacy protection private key respectively; generating an initial guide file based on a guide loading program and a preset guide loading module; signing the initial guide file according to the new certificate chain to obtain a target guide file; signing the kernel of the system and the configuration file of the boot loader respectively by using the GNU privacy protection private key to generate a signature file; signature verification is carried out on the signature files by using the GNU privacy protection public key, so that corresponding signature verification results are obtained; when the signature verification results are successful, executing the safe starting of the system according to the target guide file; the application realizes the replacement of the certificate chain, and signs and verifies the configuration files of the kernel and the boot loader after the replacement, thereby improving the starting security of the Linux system.

Description

Linux-based system safe starting method, electronic equipment and storage medium

Technical Field

The application belongs to the technical field of Linux operating systems, and particularly relates to a Linux-based system safe starting method, electronic equipment and a storage medium.

Background

Currently Linux systems typically rely on certificates provided by some manufacturers when supporting secure booting. For example, UEFI (Unified Extensible FIRMWARE INTERFACE ) default certificate chains are provided by some vendors. For the Linux system using the certificates provided by the manufacturers to issue, the private key equivalent to the root certificate is mastered in the hands of the manufacturers, and the risk of leakage exists at any time, so the security risk is high. In addition, if the certificates provided by the manufacturer are not used, how to sign and verify some key files (such as modules files) to ensure that the files are not tampered is a problem to be further solved.

Disclosure of Invention

The embodiment of the application provides a Linux-based system safe starting method, electronic equipment and a storage medium, which can solve the problem that the starting safety of a Linux system cannot be ensured.

In a first aspect, an embodiment of the present application provides a method for securely starting a Linux-based system, including:

clearing an original certificate of the main board and generating a new certificate chain;

Generating a boot loader and a GNU privacy protection public key corresponding to the GNU privacy protection private key respectively;

Generating an initial guide file based on the guide loading program and a preset guide loading module;

Signing the initial guide file according to the new certificate chain to obtain a target guide file;

Signing the kernel of the system and the configuration file of the boot loader by using the GNU privacy protection private key respectively to generate signature files corresponding to the kernel and the configuration file of the boot loader respectively;

Signature verification is carried out on signature files corresponding to the kernel and the boot loader configuration files respectively by utilizing the GNU privacy protection public key, so that signature verification results corresponding to the kernel and the boot loader configuration files are obtained respectively; the signing verification result is signing verification success or signing verification failure;

and executing the safe starting of the system according to the target guide file when the corresponding signature verification results are successful.

In a possible implementation manner of the first aspect, the generating a bootloader includes:

Acquiring an initial source code of a boot loader in the system;

Deleting an initial signature verification calling module in the initial source code to obtain a processed source code related to the boot loader;

compiling the processed source code of the boot loader to generate a boot loader.

In a possible implementation manner of the first aspect, the GNU privacy protection private key is built into an encryptor; the signing is performed on the kernel and the boot loader configuration file of the system by using the GNU privacy protection private key, and the generating of the signature files corresponding to the kernel and the boot loader configuration file respectively includes:

And the encryptor respectively signs the kernel of the system and the configuration file of the boot loader by utilizing the GNU privacy protection private key to generate respective corresponding signature files.

the local computer corresponding to the system sends a signature request to a signature server; the signature request is used for requesting to sign the kernel and boot loader configuration files of the system;

after receiving the signature request, the signature server judges whether to approve the signature request;

If the signature server approves the signature request, the signature server calculates the kernel and the boot loader configuration file of the system according to the signature request to obtain respective corresponding abstracts;

And the encryptor encrypts the abstract based on the built-in GNU privacy protection private key to obtain signature files corresponding to the kernel and boot loader configuration files of the system.

In a possible implementation manner of the first aspect, the generating an initial boot file based on the boot loader and a preset boot loader module includes:

And generating the initial boot file based on the boot loader, a preset boot loader module and the GNU privacy protection public key.

In a possible implementation manner of the first aspect, before the performing the secure system start according to the target boot file when the respective corresponding signature verification results are all that the signature verification is successful, the method further includes:

And when the signature verification results corresponding to the cores are successful in signature verification, backing up the cores, the boot loader configuration files and signature files corresponding to the cores and the boot loader configuration files to a preset catalog.

And backing up the target boot file to a system boot partition.

In a possible implementation manner of the first aspect, the executing the system security boot according to the target boot file includes:

establishing a guide entry in the main board firmware according to the path of the system guide partition and the file name of the target guide file;

Establishing a mapping relation between the guide inlet and the target guide file;

And executing the safe start of the system according to the guide entrance and the mapping relation.

In a second aspect, an embodiment of the present application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and capable of running on the processor, where the processor implements the Linux-based system security startup method according to any one of the first aspects when executing the computer program.

In a third aspect, an embodiment of the present application provides a computer readable storage medium storing a computer program, where the computer program when executed by a processor implements the Linux-based system security startup method of any one of the first aspects above.

Compared with the prior art, the embodiment of the application has the beneficial effects that:

According to the embodiment of the application, when the Linux system is started, the original certificate of the main board is cleared, and a new certificate chain is regenerated, so that the certificate chain of some manufacturers is avoided; generating an initial guide file based on a guide loading program, a modules preset guide loading module and the like, signing the initial guide file by utilizing the new certificate chain to obtain a target guide file, and starting the system safely; the problem of safety caused by the fact that the preset boot loading modules such as modules are not checked at present is avoided, and the starting safety of the Linux system is improved; and after the certificate chain is replaced, the configuration files of the kernel and the boot loader are signed and checked, so that the safety problem caused by using a checking tool with built-in manufacturer certificates for checking the signature can be avoided, and the starting safety of the Linux system is further ensured.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the embodiments or the description of the prior art will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings can be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a flowchart of a method for secure boot of a Linux-based system according to an embodiment of the present application;

fig. 2 is a flowchart of step S120 in a Linux-based system security boot method according to another embodiment of the present application;

FIG. 3 is a flow chart of an online signature method according to another embodiment of the present application;

FIG. 4 is a flowchart of a method for secure boot of a Linux-based system according to another embodiment of the present application;

FIG. 5 is a schematic diagram of a portion of a prior art motherboard firmware;

FIG. 6 is a schematic diagram of a portion of a motherboard firmware according to an embodiment of the present application;

FIG. 7 is a schematic view of a portion of a prior art memory device;

FIG. 8 is a schematic diagram of a portion of a memory device according to an embodiment of the present application;

fig. 9 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

Detailed Description

In the following description, for purposes of explanation and not limitation, specific details are set forth such as the particular system architecture, techniques, etc., in order to provide a thorough understanding of the embodiments of the present application. It will be apparent, however, to one skilled in the art that the present application may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary detail.

It should be understood that the terms "comprises" and/or "comprising," when used in this specification and the appended claims, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

It should also be understood that the term "and/or" as used in the present specification and the appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes such combinations.

As used in the present description and the appended claims, the term "if" may be interpreted as "when..once" or "in response to a determination" or "in response to detection" depending on the context. Similarly, the phrase "if a determination" or "if a [ described condition or event ] is detected" may be interpreted in the context of meaning "upon determination" or "in response to determination" or "upon detection of a [ described condition or event ]" or "in response to detection of a [ described condition or event ]".

Furthermore, the terms "first," "second," "third," and the like in the description of the present specification and in the appended claims, are used for distinguishing between descriptions and not necessarily for indicating or implying a relative importance.

Reference in the specification to "one embodiment" or "some embodiments" or the like means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," and the like in the specification are not necessarily all referring to the same embodiment, but mean "one or more but not all embodiments" unless expressly specified otherwise. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless expressly specified otherwise.

The Linux-based system security starting method provided by the application is mainly applied to the field of security servers aiming at the Linux system. Such as banking systems, other server systems involving large amounts of private data, etc.

The following presents some background of the application:

When the Linux system is started, three main phases are passed, and each phase is responsible for different tasks so as to ensure that the computer can normally and safely enter an operable state from a closed state. Three main phases include:

Motherboard Firmware (Firmware):

The main board firmware is software embedded on the main board and is responsible for the initialization and self-checking process after the computer is powered on. For most modern computers, this firmware is commonly referred to as BIOS (basic input output System) or UEFI (unified extensible firmware interface). At this stage, the computer checks whether its hardware devices (e.g., memory, CPU, hard disk, etc.) are working properly and is ready to hand them to the next boot phase.

Bootstrap (Bootloader):

The boot program is the second stage in the computer startup process. Its main task is to load and boot the operating system. The boot program is typically stored on a boot device (e.g., hard disk, USB drive, or network location) of the computer and loaded by the motherboard firmware after the self-test is completed. Once loaded, the boot program will load the kernel file of the operating system, such as a kernel, into memory for execution. In order to support kernel booting of multiple systems or different versions, a configuration file generally specifies the kernel location, and the kernel may also depend on other files during operation, so that in addition to loading the kernel, the boot stage needs to load the configuration file and other files on which the kernel is started to depend.

Operating System (Operating System):

The operating system is the last stage of the computer boot process. Once loaded into memory by the boot program, the operating system takes over control of the computer and begins to manage the hardware and software resources of the computer. The operating system provides the core functions of a user interface, file management, device drivers, network connectivity, and application execution environments.

In the secure boot process of the Linux system, after the UEFI completes hardware initialization in the motherboard firmware stage, a grub (Grand Unified Bootloader) file such as grub.efi is read from an EFI (EFI SYSTEM part) partition according to the UEFI boot entry setting and executed, and then the next stage of boot program stage is entered. Wherein grub is a bootstrap program (Bootloader) of the Linux system.

In the boot program stage, grub firstly reads a configuration file grub.cfg, reads a path of a kernel and an initrd file (Linux initial RAM disk) from the configuration file, loads the file according to the path, transfers relevant parameters to the kernel and starts the kernel, and then enters the operating system stage. In the operating system phase, drivers are loaded and applications are executed. Wherein the initrd file is a temporary root file system mounted during system boot.

For a brand new computer, the firmware of the main board is solidified in the main board, and the boot program and the operating system are copied into the hard disk when the operating system is installed. Thus, modifying the hard disk data can change the system and application, resulting in system damage or loss of control of the system.

To ensure system security, the program executing on the computer must be trusted, i.e., to ensure that the source of the program is reliable and that the data has not been tampered with, this step is accomplished by verifying the signature. Except for the solidified program on the main board, the program on the hard disk needs to be verified, that is, in the starting process of the computer, the files and the programs loaded in the later stage need to be verified in the previous stage, that is, the main board firmware signature verification bootstrap program, the bootstrap program signature verification operating system and the operating system signature verification application are guided, so that the safety of the system is ensured.

After the system is started and started safely, the UEFI in the system boot stage uses a certificate chain to check the bootstrap program, the first step of checking the signature is the next step of checking the signature, and the system is stopped to be started if the signature checking fails, so that the system safety is ensured.

UEFI has a certificate chain built in for signing the bootstrap. The certificate chain mainly includes PK (Platform Key), KEK (Key Exchange Keys, key exchange Key), db (Signature Database ). Wherein PK is a unique self-signed certificate; the KEK is a plurality of certificate sets issued by PK and used for verifying the signature db; db also contains a plurality of certificates, signatures, digest sets for verifying the bootstrapping procedure. UEFI provides an interface modification certificate chain.

This three-layer certificate chain is a common form of certificate chain, taking the above-mentioned UEFI certificate chain as an example: PK is a self-signed certificate, also called root certificate, that is typically written to the device at the time of shipment or later written to the device via a secure pathway. When a PK is trusted, the KEK issued by the PK is trusted. When the KEK is trusted, the DB from which the KEK is issued is trusted, and the bootstrapping subsequently issued by the DB is trusted.

During the starting process of the Linux system, whether the related files are legal or not needs to be checked, namely, the UEFI firmware checks the grub bootstrap program, the grub bootstrap program checks the files before reading the configuration files (i.e. grub. Cfg), the kernel and the initrd files need to be checked before executing the kernel, and the kernel loads the application and the driver. Since the UEFI firmware needs to use a certificate chain in the signing process of the grub bootstrap program, the certificate chain needs to be signed, namely, signed.

Since the default certificate chain is of some manufacturers, most release plates choose to use the certificate issuing bootstrap program of the above manufacturer, so that besides the certificate security and the starting security cannot be guaranteed, the website signature of some manufacturers needs to be applied for every update of one version, and the website signature of some manufacturers needs to be applied for frequently, which can slow the issuing speed of the system and is charged for the cost.

Therefore, the technical scheme of adopting a shim signature verification kernel exists in the related technology at present. The key idea of the shim scheme is to design an extensible middle layer with relatively stable codes, and only needs to be signed once by the manufacturer, so that certificates of the manufacturer are isolated. In short, a manufacturer certificate can be built in the shim compiling process, in the shim signing kernel verification process, the shim tries to sign the kernel with the main board certificate chain first, and if the sign verification fails, the built-in manufacturer certificate signing kernel of the shim is used. When the system is updated, the manufacturer certificate is used for issuing, so that the trouble of frequently applying for signature to websites of some manufacturers is avoided. However, even though the kernel verification is realized through the shim scheme, the manufacturer certificate is not needed, and the fact that the shim scheme is internally provided with the manufacturer certificate makes it unsafe to use the shim scheme to verify and sign the specific signature file.

Based on the above, an embodiment of the application discloses a system security starting method based on Linux. As shown in fig. 1, the method comprises the steps of:

S110, clearing the original certificate of the main board and generating a new certificate chain. That is, the original certificate chain in the motherboard is deleted and then the certificate chain is regenerated, thereby avoiding the use of certificate chains provided by some manufacturers. The certificate chain generation process comprises the following steps: firstly, generating a certificate in an x.509 format, then adding information such as a variable type (PK, KEK, db and the like), a variable GUID (Global Unique Identifier, a global unique identifier), an attribute, a secret key UUID (Universally Unique Identifier, a global unique identifier) and the like to the x.509 certificate, then carrying out PKCS7 signature, adding data such as a timestamp, a signature type, version information and the like to generate a file in an AUTH format, and writing the updated certificate chain into a main board firmware, so that the certificate in the x.509 format is converted into the certificate in the AUTH format. The certificate chain is then written to the motherboard using efitools tools. This also enables replacement of the original certificate chain.

S120, generating a boot loader and a GNU privacy protection public key corresponding to the GNU privacy protection private key respectively. Specifically, in order to avoid the security problem caused by the fact that the shim scheme is internally provided with other manufacturer certificates, the embodiment modifies and recompiles the original grub, deletes the part of the grub, which is related to invoking the shim to check the kernel, so as to avoid the security risk, and recompiles the part to generate a new bootloader.

Wherein, the English spelling of the GNU is GNU's Not Unix, which is a computer operating system item. GNU privacy protection (GNU Privacy Guard, GPG) is an encryption software used for data encryption, digital signature, and key management tasks. The GNU privacy protection private key, i.e., the GPG private key, is built in the encryptor. An encryptor is a hardware device or software module dedicated to encryption and decryption operations. The GNU privacy protection public key is the GPG public key and is generated by the encryptor according to the GNU privacy protection private key.

According to the embodiment, the GPG private key is stored in the encryption machine, so that local contact with the private key can be avoided, the key safety is ensured, and the starting safety of a Linux system is improved; on the other hand, the online signature is convenient for the subsequent realization.

S130, generating an initial boot file based on the boot loader and a preset boot loader module. Specifically, the boot loader and the preset boot loader module are both assigned to the boot loader grub. In this embodiment, the bootloader is grub. The preset boot loading module is modules modules. The modules module is a set of a series of modules, including a module for searching configuration files, searching kernels, checking files, hard disk partition driving, file system driving and the like. By way of example and not limitation, this step may package the bootloader grub.efi and modules modules into an initial boot file, which may be bootx64.efi, through grub-mkstandalone tool. In some preferred embodiments, this step may package the bootloader grub.efi, the preset bootloader module, and the GPG public key together into an initial boot file.

Specifically, the boot loader grub in the present embodiment includes: grub.efi files, modules modules, grub.cfg files (i.e., boot loader configuration files), kernel, initrd, and GPG public keys. The kernel mounts and runs initrd, grub.efi checks and runs kernel, grub.efi reads information from a boot loader configuration file, grub.cfg, and grub.efi loads modules modules. initrd is a temporary file system compression packet mounted at the initial stage of the start-up of the Linux system kernel, and the inside of the temporary file system compression packet contains the most basic drive and command at the initial stage of the start-up of the system. grub.cfg configures kernel, initrd locations, startup commands and parameters. The modules module comprises a module for searching configuration files, searching kernels, checking files, hard disk partition driving, file system driving and the like.

After grub starts to run, the grub.cfg of the configuration file is read, kernel, initrd paths are read from the configuration file, kernel is loaded and run, and after kernel runs, the initrd root file system is decompressed and mounted. The module is loaded from the catalog of modules when the commands of configuration file searching, file system, disk partition, kernel loading, checking and the like are involved.

And S140, signing the initial guide file according to the new certificate chain to obtain the target guide file. That is, grub needs to re-sign based on a new certificate chain to pass the verification after replacing the certificate chain. By way of example and not limitation, the target boot file may be sbootx64. In specific implementation, the step can use db in the certificate chain to sign the packaged file to obtain the required target boot file sbootx64.efi, namely, the signing operation is completed based on online signing, so that a local computer can be prevented from contacting a GPG private key, the security of the GPG key is ensured, and the starting security of a Linux system is improved.

And S150, signing the kernel of the system and the configuration file of the boot loader by using the GNU privacy protection private key respectively to generate signature files corresponding to the kernel and the configuration file of the boot loader respectively. That is, the encryptor signs the kernel and the boot loader configuration file grub.cfg by using the GPG private key, respectively, to obtain a signature file corresponding to the kernel and a signature file corresponding to the boot loader configuration file grub.cfg. And the online signature is used in the step, so that the local computer can be prevented from contacting the GPG private key, and the security of the GPG key is ensured, thereby being beneficial to improving the starting security of the Linux system.

In some alternative embodiments, this step may also be: the encryption machine signs the kernel, the boot loader configuration file grub.cfg and the initrd file by using the GPG private key respectively, and generates signature files corresponding to the kernel, the boot loader configuration file grub.cfg and the initrd file respectively.

S160, signature verification is carried out on the signature files corresponding to the kernel and the boot loader configuration files respectively by using the GNU privacy protection public key, and corresponding signature verification results are obtained. The signature verification result is successful or failed. That is, the GPG public key is used for signing files to be loaded in grub, such as grub. Cfg and kernel, so that the requirement of signing essential files during the guiding period is met, the security problem caused by calling the shim signing verification module for signing verification is avoided, and the security of the starting process of the Linux system is improved.

If the initrd file is signed in the previous step S150, the signature file of the initrd file needs to be checked accordingly in this step.

S170, when the signature verification results corresponding to the kernel and the boot loader configuration files are successful in signature verification, executing system safety starting according to the target boot files.

That is, the present embodiment enables configuring a Linux system to be a secure boot using an autonomous signature. This means that only software signed by oneself can perform signature verification, and only software through signature verification can be started and run on the system, thereby improving the security of the system.

In some alternative embodiments, the step S140 further includes: and backing up the target boot file to the system boot partition. That is, the target boot file is copied to the EFI partition.

The invention discloses another Linux-based system security starting method. As shown in fig. 2, in this embodiment, based on the corresponding embodiment of fig. 1, step S120 includes:

s121, obtaining initial source codes of a boot loader in the system.

S122, deleting the initial signature verification calling module in the initial source code to obtain the processed source code of the boot loader.

S123, compiling the processed source code of the boot loader to generate a boot loader.

S124, generating the GNU privacy protection public key corresponding to the GNU privacy protection private key.

Specifically, the initial signature verification calling module is a module for calling the shim to perform signature verification on the kernel, and the embodiment deletes the part of the module for calling the shim to perform signature verification in the grub source code to obtain the processed source code of the boot loader, namely grub, and then recompiles the processed source code to generate a new grub.efi file, so that the problem of safety caused by the fact that certificates of other manufacturers are built in a shim scheme can be avoided, and the starting safety of a Linux system is improved.

The invention discloses another Linux-based system security starting method. As shown in fig. 3, in this embodiment, based on the corresponding embodiment of fig. 1, step S150 includes:

s151, the local computer corresponding to the system sends a signature request to the signature server. The signature request is used to request that the kernel and boot loader configuration files of the system be signed. Alternatively, the signature request may also be used to request that the initrd file be signed, as the application is not limited in this regard.

S152, after receiving the signature request, the signature server judges whether to approve the signature request. That is, the signature server will audit the request, confirm the identity and rights of the requester, and confirm whether the requested file meets the requirements of the signature.

And S153, if the signature server approves the signature request, the signature server calculates the kernel of the system and the configuration file of the boot loader respectively to obtain corresponding digests according to the signature request, and sends the digests to the encryptor. That is, the signature server calculates digests of the data, i.e., kernel and boot loader configuration files, respectively, based on the signature requests that pass the audits. The digest may be calculated based on a hash algorithm. Optionally, the signature server may fill each digest separately and send the filled data to the encryptor to meet specific format or length requirements.

And S154, the encryptor encrypts the abstract based on the built-in GNU privacy protection private key to obtain a first signature file corresponding to each of the kernel and the boot loader configuration file of the system, and sends the first signature file to the signature server.

S155, the signature server determines the target signature files corresponding to the kernel of the system and the configuration file of the boot loader according to the first signature file.

And S156, the signature server sends the target signature file to the local computer.

In the above embodiment, the encryptor and the signature server are in the same secure environment, and the manager of the signature server can use the private key operation interface provided by the encryptor, but cannot access the private key. To fulfill this requirement, the original correlation tool (openssl, efitools, sbsigntool, GPG) cannot be used directly, and the private key calculation part must invoke the interface implementation of the encryptor. Based on the above, the encryptor signs the kernel of the system by using the GPG private key, and generates a signature file corresponding to the kernel. And signing the boot loader configuration file by using the GPG private key to generate a signature file corresponding to the boot loader configuration file.

In step S154, if only the digest is encrypted and the filling portion is not encrypted, the target signature file is the first signature file. If both the digest and the filler are encrypted in step S154, the first signature file corresponds to the result of the digest encryption, and the target signature file is a file obtained by combining the result of the digest encryption and the result of the filler encryption. I.e. a file obtained by combining the first signed file and the result of the filling part encryption.

In step S152, if the signature server does not approve the signature request, the flow ends.

The signing processes corresponding to the step S140 and the step S150 can be implemented based on the online signing method provided by the embodiment, so that a local computer can be prevented from contacting a GPG private key, the security of the GPG private key is ensured, and the starting security of the Linux system is improved.

The invention discloses another Linux-based system security starting method. As shown in fig. 4, this embodiment, on the basis of the corresponding embodiment of fig. 1, further includes, between step S160 and step S170, the steps of:

And S180, when the signature verification results corresponding to the kernel and the boot loader configuration files are successful, backing up the kernel, the boot loader configuration files and the signature files corresponding to the kernel and the boot loader configuration files to a preset catalog. Namely, the signature files corresponding to the kernel, the grub.cfg and the signature files corresponding to the grub.cfg are copied into the preset catalogue so as to complete the system security starting process. By way of example and not limitation, the preset directory is a root directory.

In some alternative embodiments, step S170 includes, based on the corresponding embodiment of fig. 1, steps of:

And establishing a boot entry in the motherboard firmware according to the path of the system boot partition and the file name of the target boot file.

And establishing a mapping relation between the guide entrance and the target guide file.

That is, a boot entry is newly added in the UEFI firmware, points to the target boot file, and enables the secure boot function of the motherboard, so as to perform the secure boot of the system.

By way of example and not limitation, the path of the system boot partition is/EFI, the file name of the target boot file is sbootx64.EFI, and the boot entry based on this is/EFI/sbootx 64.EFI.

Referring to fig. 5 and 6, there are shown partial schematic diagrams of the prior art and the present application with respect to motherboard firmware. As can be seen from the illustration, the certificate chain in the prior art and the present application comprises PK, KEK, db parts, but each part is different. The prior art motherboard firmware 51 uses certificate chains provided by some manufacturers, and the motherboard firmware 61 of the present application uses autonomous certificate chains generated by itself.

Referring to fig. 7 and 8, there are shown partial schematic views of the prior art and the present application with respect to a memory device. In one possible implementation, the storage device may be a hard disk. From the illustration, the prior art and the present application are different with respect to the storage of EFI partitions: the EFI partition in the prior art storage device 71 stores a boot loader grub.efi and a shim call module shim.efi. The EFI partition in the storage device 81 of the present application stores the target boot file sbootx64. The boot directory in the prior art storage device 71 stores grub. Cfg, kernel, initrd and grub modules. The boot directories in the storage device 81 of the present application store grub.cfg, kernel, initrd, grub.cfg.sig, kernel.sig, and initrd.sig. Wherein grub.cfg.sig, kernel.sig and initrd.sig correspond to the signature documents grub.cfg, kernel, initrd, respectively.

It should be understood that, the sequence numbers of the steps in all the embodiments described above do not mean the sequence of execution, and the execution sequence of the processes should be determined by the functions and the internal logic, and should not limit the implementation process of the embodiments of the present application in any way.

It should be noted that, the above embodiments of the method disclosed by the application can be freely combined, and the technical scheme obtained after the free combination is also within the protection scope of the application.

The embodiment of the present application further provides an electronic device, as shown in fig. 9, where the electronic device 90 includes: at least one processor 901, a memory 902 and a computer program 903 stored in the memory and executable on the at least one processor, which processor implements the steps of any of the various method embodiments described above when it executes the computer program.

Embodiments of the present application also provide a computer readable storage medium storing a computer program which, when executed by a processor, implements steps for implementing the various method embodiments described above.

Embodiments of the present application provide a computer program product which, when run on a mobile terminal, causes the mobile terminal to perform steps that enable the implementation of the method embodiments described above.

The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the present application may implement all or part of the flow of the method of the above embodiments, and may be implemented by a computer program to instruct related hardware, where the computer program may be stored in a computer readable storage medium, and when the computer program is executed by a processor, the computer program may implement the steps of each of the method embodiments described above. Wherein the computer program comprises computer program code which may be in source code form, object code form, executable file or some intermediate form etc. The computer readable medium may include at least: any entity or device capable of carrying computer program code to a camera device/electronic apparatus, a recording medium, a computer Memory, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), an electrical carrier signal, a telecommunications signal, and a software distribution medium. Such as a U-disk, removable hard disk, magnetic or optical disk, etc. In some jurisdictions, computer readable media may not be electrical carrier signals and telecommunications signals in accordance with legislation and patent practice.

In the foregoing embodiments, the descriptions of the embodiments are emphasized, and in part, not described or illustrated in any particular embodiment, reference is made to the related descriptions of other embodiments.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the embodiments provided in the present application, it should be understood that the disclosed apparatus/network device and method may be implemented in other manners. For example, the apparatus/network device embodiments described above are merely illustrative, e.g., the division of the modules or units is merely a logical functional division, and there may be additional divisions in actual implementation, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection via interfaces, devices or units, which may be in electrical, mechanical or other forms.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

The above embodiments are only for illustrating the technical solution of the present application, and not for limiting the same; although the application has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present application, and are intended to be included in the scope of the present application.

Claims

1. The Linux-based system safe starting method is characterized by comprising the following steps of:

2. The Linux-based system secure boot method of claim 1, wherein generating a bootloader comprises:

Acquiring an initial source code of a boot loader in the system;

3. The Linux-based system security boot method of claim 1, wherein the GNU privacy protection private key is built into an encryptor; the signing is performed on the kernel and the boot loader configuration file of the system by using the GNU privacy protection private key, and the generating of the signature files corresponding to the kernel and the boot loader configuration file respectively includes:

4. The Linux-based system security boot method of claim 1, wherein the GNU privacy protection private key is built into an encryptor; the signing is performed on the kernel and the boot loader configuration file of the system by using the GNU privacy protection private key, and the generating of the signature files corresponding to the kernel and the boot loader configuration file respectively includes:

5. The Linux-based system secure boot method of claim 1, wherein the generating an initial boot file based on the boot loader and a preset boot loader module comprises:

6. The Linux-based system security startup method according to claim 1, wherein, when the respective corresponding signature verification results are all signature verification success, before executing system security startup according to the target boot file, the method further comprises:

7. The Linux-based system security startup method according to claim 1, wherein, when the respective corresponding signature verification results are all signature verification success, before executing system security startup according to the target boot file, the method further comprises:

And backing up the target boot file to a system boot partition.

8. The Linux-based system security boot method of claim 1, wherein performing a system security boot according to the target boot file comprises:

9. An electronic device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, the processor implementing the method of any one of claims 1 to 8 when the computer program is executed.

10. A computer readable storage medium storing a computer program, characterized in that the computer program when executed by a processor implements the method according to any one of claims 1 to 8.