A package management based secure boot method and computer storage medium

Abstract

The application relates to a package management-based safe starting method and a computer storage medium, characterized in that a BOOT booting kernel and a root file system are used to start a computer system, the method comprises the following steps: decomposing one or more versions of computer operating systems and corresponding application software into multiple software packages, and storing the software packages in a single-partition system area; dividing the multiple software packages into a rootfs package and a non-rootfs package, and making the content of the rootfs package point to the corresponding actual file or directory in the form of a soft link; gathering the stored software packages into the rootfs package under a determined path through the establishment of a soft link; and taking the rootfs package as a root file system to complete starting during starting. The reliability of embedded device starting can be effectively ensured.

Description

Technical Field

[0001] This invention relates to the field of Linux operating systems, and in particular to a secure boot method based on package management and a computer storage medium. Background Technology

[0002] With the support of the Linux Foundation, the File Hierarchy Standard (FHS) was developed, and numerous development teams have released Linux / GNU operating systems based on the FHS. However, these releases merely provide a standard tree-like management architecture based on the FHS, and this architecture does not involve the design of file reliability; reliability is entirely left to the file system to guarantee.

[0003] In this context, we often observe abnormal situations, such as a power outage during normal operation. Upon restarting, the file system performs an integrity check, indicating that the previous shutdown was "incomplete," requiring the execution of fsck (file system check) to resolve file storage anomalies. While this action resolves some anomalies in many cases, fsck is powerless in extreme situations. In embedded systems, since system and application software are typically written to Flash memory using a programmer, an anomaly might necessitate rewriting the Flash memory with a programmer, which is unacceptable for end users of embedded devices.

[0004] To address this issue, in applications where embedded devices have high reliability requirements, common approaches include dual-image and differentiated data storage, which can solve the problem to varying degrees. However, these methods are not flexible enough and have unsatisfactory usage and management costs. Summary of the Invention

[0005] This invention provides a secure boot method and computer storage medium based on package management to solve problems in related technologies.

[0006] On one hand, embodiments of the present invention provide a secure boot method based on package management, characterized in that a BOOT-booted kernel and root file system are used to boot the computer system, and the method includes the following steps:

[0007] One or more versions of computer operating systems and their corresponding application software are decomposed into multiple software packages, and the software packages are stored in a single partition of the system area;

[0008] The multiple software packages are divided into roofts packages and non-rootfs packages, and the contents of the rootfs packages are linked to their corresponding actual files or directories in the form of symbolic links.

[0009] The stored software packages are aggregated into a rootfs package under a defined path by establishing symbolic links;

[0010] The rootfs package is used as the root file system during startup.

[0011] In some embodiments, storing the software package in a single-partition system area includes the steps of:

[0012] For storage-constrained devices, the software package is saved directly to the designated location as an unopened package;

[0013] For devices with ample storage, the package is unpacked and stored in the corresponding store directory.

[0014] In some embodiments, the step of summarizing the stored software packages into a rootfs package at a defined path by establishing a symbolic link includes the following steps:

[0015] Create a store directory in the root directory of the hardware storage;

[0016] Create a pkg directory under the store directory, expand the package in the pkg directory and name the pkg directory according to the hash value of the package;

[0017] Create a boot directory in the root directory of the hardware storage, and create a symbolic link pointing to the rootfs package in the boot directory.

[0018] In some embodiments, creating a symbolic link pointing to the rootfs package in the boot directory includes the following steps:

[0019] Create up to three symbolic links: rootfs_prev pointing to the last successfully started version of the rootfs package, rootfs_curr pointing to the currently used version of the rootfs package, and rootfs_next pointing to the next used version of the rootfs package.

[0020] Create symbolic links pointing to the paths rootfs_curr / boot / initramfs and rootfs_curr / boot / kernel in the boot directory so that the device can use the initramfs and kernel under the paths rootfs_curr / boot / initramfs and rootfs_curr / boot / kernel when it powers on.

[0021] In some embodiments, the startup process involves using the rootfs package as the root file system to complete the startup, including the following steps:

[0022] During startup, check the consistency between rootfs_next and rootfs_curr. If they are inconsistent, check the integrity of the rootfs_next environment and start based on rootfs_next if the rootfs_next environment is complete.

[0023] Start based on rootfs_curr when the rootfs_next environment is not complete;

[0024] If startup from rootfs_next fails, keep the current values ​​of rootfs_next, rootfs_curr, and rootfs_prev unchanged, and record that startup from rootfs_next failed.

[0025] If the startup from rootfs_next is successful, then rootfs_prev will be modified to point to rootfs_curr, rootfs_curr will be modified to point to rootfs_next, and rootfs_next will be set to NULL, where NULL represents empty.

[0026] In some embodiments, the startup process involves using the rootfs package as the root file system to complete the startup, including the following steps:

[0027] The kernel is expanded to the store directory via kexec;

[0028] After the kernel starts, a storage pool is created under the / dev / path in the corresponding initramfs and the external storage is mounted to the path corresponding to the storage pool, which is / dev / diskpools / $externaldisk.

[0029] In some embodiments, the startup process involves using the rootfs package as the root file system to complete the startup, including the following steps:

[0030] Mount the path corresponding to rootfs_curr, / dev / diskpools / $externaldisk / store / runtime / [hash_of_rootfs], to / newroot / .

[0031] Mount / dev / diskpools / $externaldisk / store / to / newroot / store in read-only mode;

[0032] Switch to / newroot / via the switchroot action.

[0033] In some embodiments, when adding a new software package, if the new software package is for single-run use, the new software package is directly expanded into memory for execution.

[0034] If the newly added software continues to be used after the device restarts, then:

[0035] Save it to the rootfs_addon configuration directory, and write a soft link pointing to the newly added software in the rootfs_addon configuration directory;

[0036] Create three symbolic links, prev, curr, and next, in the rootfs_addon configuration directory. Prev points to the symbolic link of the newly added package in the last startup, curr points to the symbolic link of the newly added package currently in use, and next points to the symbolic link of the newly added package to be used next. Also, make opt in all versions of rootfs point to rootfs_addon / curr.

[0037] In some embodiments, when a software package is added manually, a symbolic link is created to the rootfs_addon configuration directory, so that the symbolic link rootfs / opt / bin / excutable_binary points to the entity file located at the path addon / [hash_of_rootfsX] / opt / bin / excutable_binary.

[0038] On the other hand, embodiments of the present invention also provide a computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, it implements the steps of a secure boot method.

[0039] The beneficial effects of the technical solution provided by this invention include: by storing the operating system and application software packages in a single partition, the operating system and upper-layer application software are uniformly stored in the form of packages (packages are stored expanded or directly in the form of packages), which is flexible and convenient; since the system is broken down into small packages and stored independently, the actual storage space utilization of the device is greatly improved. Software can be added as needed, and the system can be restored to its original state after a restart, ensuring the integrity, reliability, and scalability of the system. Attached Figure Description

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

[0041] Figure 1 A flowchart illustrating a secure boot method based on package management, provided as an embodiment of the present invention; Detailed Implementation

[0042] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0043] like Figure 1 As shown, this embodiment of the invention provides a secure boot method based on package management, characterized by using BOOT to boot the kernel and root file system to start the computer system. The method includes the following steps:

[0044] S100: Decompose one or more versions of computer operating systems and corresponding application software into multiple software packages, and store the software packages in a single partition of the system area;

[0045] S200: Divide the multiple software packages into roofts packages and non-rootfs packages, and make the contents of the rootfs packages point to their corresponding actual files or directories in the form of symbolic links;

[0046] S300: By establishing a soft link, the stored software packages are aggregated into the rootfs package under a defined path;

[0047] S400: During startup, the rootfs package is used as the root file system to complete the boot process.

[0048] It should be noted that for x86 desktop computers, UEFI or BIOS boot is used, followed by GRUB to boot the kernel and root file system. This invention primarily describes the process of using U-Boot to boot the kernel and root file system (rootfs) in an embedded environment. The method of using GRUB to boot the kernel and root file system is similar and will not be elaborated upon. The secure boot method based on package management provided in this invention allows the storage of one or more "complete operating system and application software" versions and provides atomic operations for version switching. In step S100, the operating system and application software are decomposed into multiple interdependent software packages. These packages have various attributes, including: kernel packages, driver packages, application packages, and hot-patching packages. Each package contains detailed package description information and can use a high compression ratio to form a compressed package. The file structure within the compressed package can be built based on the Linux Foundation's FHS (filehierarchy standard).

[0049] It is understandable that storing software packages in a single partition's system area results in a partition divided into a boot area and a system area for single-memory devices; some devices have independent boot memory, so the system area does not need to be partitioned. The package-management-based secure boot method provided by this invention stores the operating system and application software packages in a single partition, which has the following advantages:

[0050] Assuming a total memory space of 64MB, using a conventional mirroring scheme, the actual effective space is 64MB / 2 = 32MB. In reality, embedded device software won't use all 32MB of storage. Let's assume the overall application software actually occupies 20MB. Because the dual-mirror scheme, to ensure the reliability of the currently running image, can only utilize the space of the half of the image not currently in use, the actual effective space is 32MB. 32 - 20 = 12MB of space is unusable in the currently running image partition. In contrast, in this embodiment of the invention, since the system area is no longer partitioned, the overall storage space is not divided. The actual overall software occupies 20MB, therefore the actual effective space is 64 - 20 = 44MB, increasing the effective space utilization by 37%.

[0051] In step S200, the rootfs package refers to a complete operating system software package, but all its files are replaced with symbolic links pointing to the actual files. The non-rootfs package refers to a file package formed by splitting and independently releasing support libraries and files according to requirements.

[0052] In this embodiment, the operating system and application software packages are stored in a single partition. The operating system and upper-layer application software are stored in packages (either stored as expanded packages or directly as packages), which is flexible and convenient. Because the system is broken down into small packages and stored independently, the actual storage space utilization of the device is greatly improved. Based on the boot method of this embodiment, the required software can be added at any time according to the actual situation, and the original state can be restored after a restart, ensuring the integrity, reliability, and scalability of the system.

[0053] In some embodiments, S100 involves storing the software package in a single-partition system area, including the following steps:

[0054] S110: For storage-constrained devices, the software package is directly saved to a designated location as an unopened package;

[0055] S120: For devices with sufficient storage, the package is expanded and stored in the corresponding store directory.

[0056] It should be noted that the store allows storing rootfs configurations for multiple versions of the same functional package, facilitating version switching.

[0057] In some embodiments, S300 includes the step:

[0058] S310: Create a store directory in the root directory of the hardware storage;

[0059] S320: Create a pkg directory under the store directory, expand the software package in the pkg directory, and name the pkg directory according to the hash value of the software package;

[0060] S330: Create a boot directory in the root directory of the hardware storage, and create a soft link pointing to the rootfs package in the boot directory.

[0061] It should be noted that multiple versions of the decomposed rootfs package are allowed (such as rootfs_1, rootfs_2, etc.). The rootfs package itself is a special software package used to describe how other non-rootfs packages located in the pkg directory should be used. The rootfs package itself is located in the pkg directory, and its contents are linked to its corresponding actual files and directories in the form of symbolic links.

[0062] In some embodiments, S330 includes the step of:

[0063] S331: Create up to three soft links, namely: rootfs_prev pointing to the last successfully started version of the rootfs package, rootfs_curr pointing to the currently used version of the rootfs package, and rootfs_next pointing to the next used version of the rootfs package;

[0064] S332: Create symbolic links pointing to the paths rootfs_curr / boot / initramfs and rootfs_curr / boot / kernel in the boot directory so that the device can use the initramfs and kernel under the paths rootfs_curr / boot / initramfs and rootfs_curr / boot / kernel when powered on.

[0065] In this embodiment, since the rootfs is maintained using the soft links rootfs_prev, rootfs_curr, and rootfs_next, the operating system upgrade action is transformed into a rootfs soft link switching action. This action is very close to an atomic operation, which can prevent anomalies during the switching and upgrade process to the greatest extent and ensure reliability. It can guarantee 100% reliability in scenarios with high reliability requirements.

[0066] In some embodiments, S400 includes the step:

[0067] S410: During startup, check the consistency between rootfs_next and rootfs_curr. If they are inconsistent, check the integrity of the rootfs_next environment and start based on rootfs_next if the rootfs_next environment is complete.

[0068] S420: Starts based on rootfs_curr when the rootfs_next environment is not complete;

[0069] S430: If startup from rootfs_next fails, keep the current values ​​of rootfs_next, rootfs_curr, and rootfs_prev unchanged, and record that startup from rootfs_next failed;

[0070] S440: If the startup from rootfs_next is successful, then modify rootfs_prev to point to rootfs_curr, modify rootfs_curr to point to rootfs_next, and set rootfs_next to NULL, where NULL represents empty.

[0071] It should be noted that during normal startup, the consistency between `rootfs_next` and `rootfs_curr` is checked. If they are inconsistent, the integrity of all packages corresponding to the configuration pointed to by `rootfs_next` is checked (the integrity of the `rootfs_next` environment is checked). If the integrity is complete, the system starts from `rootfs_next`; otherwise, it starts from `rootfs_curr`. If startup from `rootfs_next` fails, the pointer value is left unchanged, and the startup failure is recorded. The purpose of recording startup failures is to ensure that the system can switch to the previous reliable configuration at any time.

[0072] It should be noted that when you need to switch the system to rootfs_prev, you can use a rollback action to set the value of rootfs_next to be consistent with rootfs_prev, and then restart the device. When the device restarts, it will still start based on the verification of rootfs_next, and its startup process can be consistent with the version upgrade process.

[0073] Preferably, the bootloader uses a default version of the kernel and a default version of the initramfs, which will never be modified or replaced. Using the default version of the initramfs, the aforementioned actions of verifying the consistency of rootfs_next and rootfs_curr are performed, and then the kernel and rootfs (root filesystem) specified under the corresponding configuration are booted.

[0074] It should be noted that the rootfs boot process varies depending on the actual device. For storage-constrained devices, the rootfs is built during system startup based on configuration information (the requirements of the root file system itself). The specific construction process includes: verifying and expanding each package specified in the configuration information, directly expanding each package to tmpfs, forming an FHS-based rootfs under tmpfs, where the kernel is expanded into memory; if verification fails, it switches to the last successfully booted version. Preferably, a symbolic link at the path / store / pkg is set to point to tmpfs, and the original packages are stored in / store / localmirror. When the package management software recognizes the local configuration as a storage-constrained device, during startup in initramfs, it first creates tmpfs and its corresponding directory, expands the corresponding packages into tmpfs according to the rootfs configuration, and mounts it as / store.

[0075] For devices with ample storage space, the rootfs is based on the contents of the expanded store path. By creating symbolic links, all files are aggregated into a "virtual" file system under a specific path. The overall file structure of the "virtual" rootfs conforms to FHS requirements.

[0076] In some embodiments, the S400 boot process includes: booting the kernel to the store directory via kexec; after the kernel boots, creating a storage pool in the corresponding initramfs under the / dev / path and mounting the external storage to the path corresponding to the storage pool, where the path corresponding to the storage pool is / dev / diskpools / $externaldisk.

[0077] It should be noted that kexec boots the kernel located in the store directory and then boots the rootfs associated with that kernel.

[0078] In some embodiments, S400 includes the steps of: mounting the path / dev / diskpools / $externaldisk / store / runtime / [hash_of_rootfs] corresponding to rootfs_curr to / newroot / ; mounting / dev / diskpools / $externaldisk / store / in read-only mode to / newroot / store; and switching to / newroot / via the switchroot action.

[0079] It's important to note that switching to ` / newroot / ` means switching to the working rootfs. The difference between using `switchroot` to switch rootfs depends on the application scenario—whether it's a storage-constrained device or a storage device with ample storage—lies in whether the rootfs is located in the memory-based tmpfs or on fixed flash storage (or hard drive). For storage-constrained devices, during startup, the initramfs used needs to expand the unexpanded packages in pkgcache to the ` / store / runtime / ` directory mounted as tmpfs. For storage-amplified devices, the pkgcache directory doesn't need to store the original unexpanded compressed packages; instead, it fully expands the packages to the ` / store / runtime` path on disk. Regardless of whether the device has limited or ample storage, the actual path referencing the rootfs is under ` / store / runtime / [hash_of_rootfs]`.

[0080] In some embodiments, S400 includes the step of: at startup, mounting the store directory in read-only mode and mounting emmc to the path / mnt. Mounting the store directory in read-only mode ensures its availability for future updates and version replacements.

[0081] In some embodiments, when adding a new software package, if the new software is for a single run, the new software package is directly expanded into memory for execution; if the new software continues to be used after the device restarts, it is saved to the rootfs_addon configuration directory, and a symbolic link pointing to the new software is written into the rootfs_addon configuration directory; at the same time, three symbolic links, prev, curr, and next, are created in the rootfs_addon configuration directory, where prev points to the symbolic link of the previously started new software package, curr points to the symbolic link of the currently used new software package, and next points to the symbolic link of the next new software package to be used, and the opt in all versions of rootfs points to rootfs_addon / curr.

[0082] Understandably, software that can develop and manage software packages can manage the addition and deletion of these packages. For storage-constrained devices, the installed software packages are saved directly to the designated location as individual packages. For devices with ample storage, the installed software packages are expanded and stored in the `store` directory. Understandably, regardless of storage constraints, the tool needs to manage the `rootfs` directory pointed to by the three symbolic links `rootfs_prev`, `rootfs_curr`, and `rootfs_next` mentioned earlier to determine how the software packages should be used.

[0083] Understandably, when adding a new software package, the software managing the packages issues the command to add the package. The command may differ depending on the attributes of the new package, and whether it can be used after a reboot depends on the actual product requirements. Adding software for single-use means it takes effect only once and is no longer used after a device reboot. In this case, the corresponding package is directly expanded into memory and then run. If the added software will continue to be used after a device reboot, the added package is saved in the rootfs_addon configuration. In rootfs, opt always points to rootfs_addon / curr. In actual use, newly installed binary tools are located at the following path ($tools refers to the newly installed binary): [rootfs] / opt / bin / $tools.

[0084] In some embodiments, the required software can be added at any time as needed, and can be permanently retained or restarted to restore the original state, ensuring the integrity and reliability of the system while ensuring scalability.

[0085] In some embodiments, when a software package is added manually, a symbolic link is created to the rootfs_addon configuration directory, so that the symbolic link rootfs / opt / bin / excutable_binary points to the entity file located at the path addon / [hash_of_rootfsX] / opt / bin / excutable_binary.

[0086] It should be noted that `excutable_binary` is a symbolic link pointing to the entity file `... / store / [hash_of_pkg] / bin / excutable_binary`. Within the rootfs, a ` / opt` is also created pointing to `... / addon / [hash_of_rootfsX] / opt`. It can be understood that other file types, such as configuration files and various resource files, can be deduced in the same way.

[0087] In some embodiments, after the system starts up and upgrades successfully, the path of the store directory is set to read-only.

[0088] In some embodiments, emmc is mounted to / def / diskpool / emmc

[0089] The method for creating the store directory in its root directory is as follows:

[0090] / dev / diskpool / emmc / store / pkg / [hash_of_package_1.0]

[0091] / dev / diskpool / emmc / store / pkg / [hash_of_package_1.1]

[0092] / dev / diskpool / emmc / store / pkg / [hash_of_package_2.0]

[0093] / dev / diskpool / emmc / store / pkg / [hash_of_package_3.0]

[0094] / dev / diskpool / emmc / store / pkg / [hash_of_package_3.1]

[0095] / dev / diskpool / emmc / store / pkg / [hash_of_package_n.0]

[0096] / dev / diskpool / emmc / store / pkg / [hash_of_rootfs_1.0]

[0097] / dev / diskpool / emmc / store / pkg / [hash_of_rootfs_2.0]

[0098] / dev / diskpool / emmc / boot / rootfs_curr-> / store / pkg / [hash_of_rootfs_1.0]

[0099] / dev / diskpool / emmc / boot / rootfs_next-> / store / pkg / [hash_of_rootfs_2.0]

[0100] / dev / diskpool / emmc / rootfs_addon / [hash_of_rootfs_1.0] / curr

[0101] / dev / diskpool / emmc / rootfs_addon / [hash_of_rootfs_2.0] / curr

[0102] In this context, it can be understood that hash_of_package_1.0 refers to the package with version 1.0, and hash_of_rootfs_1.0 refers to the rootfs file with version 1.0.

[0103] In some embodiments, a version of rootfs (rootfs1) contains the following:

[0104] bin / file1-> / store / pkg / [hash_of_pkg_1.0] / bin / file1

[0105] lib / libfile1.so-> / store / pkg / [hash_of_pkg_1.0] / lib / libfile1.so

[0106] usr / lib / libfile1.so-> / store / pkg / [hash_of_pkg_1.0] / usr / lib / libfile1.so

[0107] bin / file2-> / store / pkg / [hash_of_pkg_2.0] / bin / file2

[0108] Another version of rootfs (rootfs2) includes:

[0109] / bin / file1-> / store / pkg / [hash_of_pkg_1.1] / bin / file1

[0110] / lib / libfile1.so-> / store / pkg / [hash_of_pkg_1.1] / lib / libfile1.so

[0111] / usr / lib / libfile1.so-> / store / pkg / [hash_of_pkg_1.1] / usr / lib / libfile1.so

[0112] / bin / file2-> / store / pkg / [hash_of_pkg_2.1] / bin / file2

[0113] After mounting rootfs to / newroot, creating / boot under / newroot, and mounting the boot directory in emmc to this directory using the mount--bind method, the following path will be obtained:

[0114] / newroot / boot / rootfs_curr->[hash_of_rootfs_1.0]

[0115] / newroot / boot / rootfs_curr->[hash_of_rootfs_2.0]

[0116] / newroot / boot / rootfs_addon / [hash_of_rootfs_1.0] / curr

[0117] / newroot / boot / rootfs_addon / [hash_of_rootfs_2.0] / curr

[0118] In one specific embodiment, the implementation process is described for a device with ample storage. The environment used in this embodiment is an ARM64-bit CPU, booting via u-boot, and 4GB of eMMC external storage.

[0119] First, a software package is built using an ipk file. Based on this ipk package, a further description of the package is added, explaining its purpose. The external eMMC storage is formatted as an ext4 partition and mounted using the ordered method to ensure reliability.

[0120] Then, create a store directory under the emmc root directory, and a pkg directory under store; expand the required packages, and name the directory after the hash value of the package; among them, there are one or more special packages, which are rootfs directories, and the subdirectories under them are a complete rootfs (all files and directories in the rootfs), and the directory name is still the hash value of the package, and the files inside are symbolic links pointing to their corresponding actual files and directories.

[0121] Create a `boot` directory under the eMMC root directory. Within this directory, create up to three symbolic links: `roofs_prev`, `roofs_curr`, and `roofs_next`. Note that `roofs_prev` and `roofs_next` do not need to be created during the initial system build. These symbolic links will only exist after the device has undergone multiple updates to the system rootfs configuration. These symbolic links point to the hash value directory of the rootfs under the `pkg` directory mentioned earlier.

[0122] In the boot directory, create symbolic links for initramfs and kernel, pointing to rootfs_curr / boot / initramfs and rootfs_curr / boot / kernel respectively. The initramfs and kernel in this path are used when the device powers on. Pointing the symbolic links to the corresponding entries in roofs_curr ensures that even if there is incomplete data written to the disk, the device will always boot from the last successfully loaded environment.

[0123] The loaded initramfs checks the relationship between rootfs_curr and rootfs_next. If rootfs_next and rootfs_curr are different (inconsistent), the integrity of the rootfs_next environment is checked (the integrity of all packages corresponding to the configuration pointed to by rootfs_next is checked). If complete, a brand new environment based on rootfs_next is started using kexec; otherwise, it is started directly based on rootfs_curr. Regardless of which rootfs is used for startup, after the kernel starts, a switchroot operation is performed to switch to the working rootfs.

[0124] While still in the initramfs environment, mount the emmc to / dev / diskpool / emmc / . Before the switchroot operation, mount the emmc to / newroot / dev / diskpool / emmc using the mount--bind-o ro method (read-only mount):

[0125] Mount / newroot / dev / diskpool / emmc / store to / newroot / store;

[0126] Mount / newroot / dev / diskpool / emmc / boot to / newroot / boot;

[0127] After the switchroot operation, the relevant directories listed in the previous steps can also be accessed in the new rootfs based on / store: the boot directory located in the emmc root directory; and the store directory located in the emmc root directory.

[0128] The developed package management software supports expanding packages to the / store directory of the currently used root file system (the actual physical path corresponding to / store is / dev / diskpool / emmc / store mentioned earlier).

[0129] During initial device production, the bootloader pulls the initial initramfs to the local machine. The package management software within this initramfs then pulls and expands the corresponding software packages based on the initial rootfs. The expansion uses the hash value of the corresponding package as the directory name. After expansion, all files within the package are verified. Only after all files in each package have been verified correctly does the expansion of the next package begin, ensuring that every file is written correctly. It's important to note that the rootfs itself is a special software package. The officially used rootfs is a symbolic link `rootfs_curr` created by the package management software under a separate ` / boot / ` directory, pointing to the rootfs with the corresponding hash directory name under ` / store / pkg / `.

[0130] After all files are prepared, a symbolic link to rootfs_curr is created pointing to the directory specified in the aforementioned roofs configuration directory, and symbolic links to kernel and initramfs are created under / boot. The rootfs_prev and rootfs_next directories are not created during the initial production run.

[0131] During device software updates, the package management software retrieves the rootfs from the specified upgrade source and pulls relevant packages based on the above configuration. If a package with the same hash value exists, it indicates that the corresponding package already exists locally and there is no need to pull it again. If no package with the same hash value is found, it is pulled locally and expanded. Similar to the initial device production, a symbolic link is created after all files are successfully updated, with rootfs_next pointing to the current rootfs hash value directory.

[0132] During device startup, the bootloader obtains and loads the kernel and initramfs from the / boot directory of the eMMC. After loading, it mounts the eMMC to / dev / diskpool / eMMC / and, as described earlier, mounts the store, boot, and other paths to / newroot. It then verifies and compares the symbolic links rootfs_curr and rootfs_next. If rootfs_next does not exist, it's considered a normal boot, and a switchroot operation is performed to enter the final complete rootfs. If rootfs_next exists and is different from rootfs_curr, it's considered the first boot after an upgrade. The kernel specified in rootfs_next is loaded using kexec, and switchroot is used to switch to the rootfs specified in rootfs_next. If an abnormal power outage and reboot occur during device startup, since the data in the eMMC remains unchanged, the next boot will still follow the above startup process.

[0133] After startup, the package management software takes over and begins checking the local configuration. If only `rootfs_curr` exists, it indicates a clean, normal startup, and no action is taken. If `rootfs_next` exists and is different from `rootfs_curr`, it is considered the first startup after an upgrade. At this point, the following three actions are performed: a symbolic link to `rootfs_curr` is copied and renamed to `curr_backup`; the filename of `rootfs_next` is renamed to `rootfs_curr`; and `curr_backup` is renamed to `rootfs_prev`.

[0134] If an abnormal power outage occurs during this process, preventing the above actions from being completed, the following exceptions may occur: If there is a redundant file `curr_backup` and a file `rootfs_next`, it indicates that the exception occurred after backing up `rootfs_curr` but before modifying `rootfs_next`. Since `rootfs_curr` still exists, the system can start normally, and subsequent modifications can proceed as usual. If there is a redundant file `curr_backup` and a file `rootfs_curr`, but no file `rootfs_next`, it indicates that the exception occurred after `rootfs_next` was modified to `rootfs_curr` but before `curr_backup` was modified to `rootfs_prev`. Since `rootfs_next` has already been modified to `rootfs_curr`, the system has started normally, and subsequent modifications can proceed as usual. Based on the above situations, regardless of when the exception occurs, the system can still function normally.

[0135] When adding a new package, a directory with the hash value of the current rootfs directory as its name is created under the path / boot / rootfs_addon / , and a symbolic link / opt is created pointing to it. When the / opt symbolic link is valid in the rootfs, it indicates that the current rootfs has been "modified" and is not the default rootfs, nor the original release version of the project, facilitating troubleshooting and tracking.

[0136] When manually adding software packages, all files are symbolically linked to the aforementioned rootfs_addon / [hash_of_rootfsX] using the same method as maintaining rootfs. In this embodiment, the addon path is located in the emmc storage area, ensuring continued availability after software installation. If only temporary use in the current environment is required, the addon path can be customized to / dev / shm or tmpfs, so that the corresponding symbolic link is not effective on subsequent startups, preventing the software from working and ensuring the integrity of the initially released software.

[0137] Since / store and / boot are read-only mounted, all content under these paths cannot be modified during normal system operation, ensuring device reliability.

[0138] When updating or adding packages, you need to remount and unmount the read-only mounts of / store and / boot by repeatedly mounting yourself, but with the rw attribute added, where $targetdir is / store and / boot.

[0139] mount--bind-o rw$targetdir$targetdir

[0140] After making modifications and updates, you need to unmount the above-mentioned mounts:

[0141] umount$targetdir

[0142] This invention also provides a computer-readable storage medium storing a computer program, wherein when executed by a processor, the computer program implements the steps of the secure boot method mentioned in the foregoing embodiments. Those skilled in the art will understand that all or some of the steps in the methods disclosed above can be implemented as software, firmware, hardware, or suitable combinations thereof. Such software can be distributed on a computer-readable storage medium, which may include a computer-readable storage medium (or a non-transitory medium) and a communication medium (or a temporary medium).

[0143] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A secure boot method based on package management, characterized by, The method for starting a computer system by BOOT booting kernel and root file system comprises the steps of: decomposing one or more versions of computer operating system and corresponding application software into a plurality of software packages and storing the software packages in a single-partition system area; dividing the plurality of software packages into rootfs packages and non-rootfs packages, and making the contents of the rootfs packages point to their corresponding actual files or directories in the form of soft links; collecting the stored software packages into rootfs packages in a determined path by establishing soft links; starting and completing the start by taking the rootfs packages as root file system; the step of collecting the stored software packages into rootfs packages in a determined path by establishing soft links comprises the steps of: creating a boot directory under the root directory of hardware memory and creating soft links pointing to the rootfs packages under the boot directory; the step of creating soft links pointing to the rootfs packages under the boot directory comprises the steps of: creating at most three soft links, which are a soft link rootfs_prev pointing to the rootfs package of the last successful start version, a soft link rootfs_curr pointing to the rootfs package of the currently used version and a soft link rootfs_next pointing to the rootfs package of the next used version; creating soft links pointing to the paths rootfs_curr / boot / initramfs and rootfs_curr / boot / kernel under the boot directory so as to use the initramfs and kernel under the paths rootfs_curr / boot / initramfs and rootfs_curr / boot / kernel when the device is powered on; the step of starting and completing the start by taking the rootfs packages as root file system comprises the steps of: when starting, checking the consistency of rootfs_next and rootfs_curr, checking the integrity of the rootfs_next environment if the consistency is not consistent, and starting based on rootfs_next when the rootfs_next environment has integrity; starting based on rootfs_curr when the rootfs_next environment does not have integrity; keeping the values of rootfs_next, rootfs_curr and rootfs_prev unchanged and recording the failure of starting from rootfs_next if the start from rootfs_next fails; starting successfully from rootfs_next, modifying rootfs_prev to point to rootfs_curr, modifying rootfs_curr to point to rootfs_next and pointing rootfs_next to NULL, wherein NULL represents empty.

2. The secure boot method based on packet management according to claim 1, wherein, the step of storing the software packages in a single-partition system area comprises the steps of: For storage-restricted devices, the software package is saved directly in the form of an unexpanded package to a specified location; For storage-abundant devices, the software package is expanded and then stored under the store directory.

3. The secure boot method based on packet management according to claim 1, wherein, The step of gathering the stored software package into a rootfs package under a determined path by establishing a soft link comprises: Creating a store directory under the root directory of the hardware memory; Creating a pkg directory under the store directory, expanding the software package in the pkg directory, and naming the pkg directory according to the hash value of the software package.

4. The secure boot method based on packet management according to claim 1, wherein, The step of completing the startup by taking the rootfs package as a root file system during startup comprises: Booting expansion to the kernel under the store directory through kexec; After starting the kernel, creating a storage pool under the / dev / path in the corresponding initramfs and mounting the external storage to the path corresponding to the storage pool, which is / dev / diskpools / $externaldisk.

5. The secure boot method based on packet management according to claim 1, wherein, The step of completing the startup by taking the rootfs package as a root file system during startup comprises: Mounting the path corresponding to rootfs_curr, / dev / diskpools / $externaldisk / store / runtime / [hash_of_rootfs], to / newroot / ; Mounting / dev / diskpools / $externaldisk / store / to / newroot / store in read-only mode; Switching to / newroot / through a switchroot action.

6. The secure startup method based on package management according to claim 3, wherein When a new software package is added, if the corresponding new software is for single-run use, the new software package is directly expanded for memory operation; If the corresponding new software continues to be used after device restart, then: Saving to the rootfs_addon configuration directory and writing a soft link pointing to the new software in the rootfs_addon configuration directory; Creating three soft links, prev, curr, and next, under the rootfs_addon configuration directory, wherein prev points to the soft link of the last startup new software package, curr points to the soft link of the currently used new software package, and next points to the soft link of the next used new software package, and making the opt in all versions of rootfs point to rootfs_addon / curr.

7. The secure startup method based on package management according to claim 6, wherein When a software package is manually added, a soft link is established to add the software package to the rootfs_addon configuration directory, and the soft link rootfs / opt / bin / excutable_binary points to the entity file at the path addon / [hash_of_rootfsX] / opt / bin / excutable_binary.

8. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, and the computer program is executed by the processor to implement the steps of the secure boot method in any one of claims 1 to 7.

Images