Burning method and device of linux system, electronic equipment and storage medium

Abstract

The invention discloses a burning method and device of a linux system, electronic equipment and a storage medium. The method comprises the steps of obtaining a first source code used for generating a first mirror image file, and generating a to-be-burnt first mirror image file comprising a verification file and a first root file system file based on the first source code; the verification file is generated based on a directory file corresponding to the first root file system file through the first tool; the first tool is used for generating and verifying a hash value of the hash function; writing the first mirror image file into a first non-volatile storage medium, so that the to-be-burnt device burns the first mirror image file in the first non-volatile storage medium into a second non-volatile storage medium of the to-be-burnt device, and verifying the verification file through the first tool, so that the to-be-burnt device can burn the first mirror image file in the first non-volatile storage medium on the basis of a verification result. And determining whether to prompt the user to re-burn the first mirror image file to the to-be-burnt device.

Description

Technical Field

[0001] The present application belongs to the technical field of data burning, and specifically relates to a burning method, device, electronic equipment and storage medium of a Linux system. Background Art

[0002] Embedded Linux systems are widely used in the fields of Internet of Things, industrial control, consumer electronics, etc. System burning and booting are crucial links in the embedded development process, which usually involves writing system image files, such as boot loader files, kernel files, device tree files (DTB, Device Tree Blob) and root file system files, to non-volatile storage media, such as memory cards (SD) or (Embedded Multi Media Card, eMMC) embedded multimedia storage cards, and loading these system image files when the device starts.

[0003] Related Linux system burning solutions usually rely on simple version verification or basic cyclic redundancy check (CRC), however, they cannot effectively prevent system image files from being tampered with or damaged, resulting in potential problems being exposed during device operation. Alternatively, they rely on complex external tools or hardware encryption modules, such as hash verification, which requires complex device mapper (DM)-target Verity and hash tree implementation, or rely on trusted platform modules (TPM) or hardware security modules (HSM), etc., which increase the complexity of system design and implementation due to limited resources on embedded devices, and are not suitable for small and medium-sized embedded development projects with limited device resources.

[0004] In other words, the burning solutions for related Linux systems have problems of low security or poor adaptability. Summary of the invention

[0005] The embodiments of the present application provide a burning method, device, electronic device and storage medium for a Linux system, which can solve the problems of low security or poor adaptability in related burning solutions for Linux systems.

[0006] In a first aspect, an embodiment of the present application provides a burning method for a Linux system, the method comprising: obtaining a first source code for generating a first image file, and generating a first image file to be burned including a verification file and a first root file system file based on the first source code; wherein the verification file is generated by a first tool based on a directory file corresponding to the first root file system file; the first tool is a tool for generating and verifying a hash value of a hash function; the first image file is an image file required by the Linux system during the startup process; writing the first image file to a first non-volatile storage medium so that the device to be burned burns the first image file in the first non-volatile storage medium to a second non-volatile storage medium of the device to be burned, and verifying the verification file by the first tool to determine whether to prompt the user to re-burn the first image file to the device to be burned based on the verification result.

[0007] In a second aspect, an embodiment of the present application provides a burning device for a Linux system, the device comprising: an acquisition module, used to acquire a first source code for generating a first image file, and based on the first source code, generate a first image file to be burned including a verification file and a first root file system file; wherein the verification file is generated by a first tool based on a directory file corresponding to the first root file system file; the first tool is a tool for generating and verifying a hash value of a hash function; the first image file is an image file required by the Linux system during the startup process; a burning module, used to write the first image file to a first non-volatile storage medium, so that the device to be burned burns the first image file in the first non-volatile storage medium to a second non-volatile storage medium of the device to be burned, and verifies the verification file through the first tool to determine whether to prompt the user to re-burn the first image file to the device to be burned based on the verification result.

[0008] In a third aspect, an embodiment of the present application provides an electronic device, comprising: a processor; and a memory arranged to store computer executable instructions, wherein the executable instructions are configured to be executed by the processor, and the executable instructions include a method for executing a burning method of a Linux system as described in the first aspect.

[0009] In a fourth aspect, an embodiment of the present application provides a storage medium, wherein the storage medium is used to store computer executable instructions, wherein the computer executable instructions enable a computer to execute the burning method of the Linux system as described in the first aspect.

[0010] In a fifth aspect, an embodiment of the present application provides a chip, comprising a processor and a communication interface, wherein the communication interface is coupled to the processor, and the processor is used to run a program or instruction to implement the burning method of the Linux system as described in the first aspect.

[0011] In a sixth aspect, an embodiment of the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the burning method of the Linux system as described in the first aspect.

[0012] In an embodiment of the present application, a first source code for generating a first image file is obtained, and based on the first source code, a first image file to be burned, including a verification file and a first root file system file, is generated; wherein the verification file is generated by a first tool based on a directory file corresponding to the first root file system file; the first tool is a tool for generating and verifying a hash value of a hash function; the first image file is an image file required by the Linux system during the startup process; the first image file is written to a first non-volatile storage medium, so that the device to be burned burns the first image file in the first non-volatile storage medium to a second non-volatile storage medium of the device to be burned, and the verification file is verified by the first tool to determine whether to prompt the user to re-burn the first image file to the device to be burned based on the verification result. Compared with the burning scheme of related Linux systems, which rely on complex external tools or hardware encryption modules, the present application adopts a first tool for generating and verifying the hash value of a hash function, generates a verification file for the directory file corresponding to the first root file system file, and then verifies the verification file in the first image file to be burned. The present application is simple and easy to implement, and effectively prevents the system image file from being tampered with or damaged, thereby improving the reliability of the Linux system burned into the device to be burned and the security of the burning. The use of the first tool does not require additional support, reduces the cost of system implementation, and has better compatibility, thereby solving the problems of low security or poor adaptability of the burning scheme of related Linux systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1 It is a flowchart of a burning method of a Linux system provided in an embodiment of the present application; Figure 2 It is a flowchart of another method for burning a Linux system provided in an embodiment of the present application; Figure 3 It is a structural schematic diagram of a web page prediction device provided in an embodiment of the present application; Figure 4 It is a structural schematic diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0014] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0015] The terms "first", "second", etc. in the specification and claims of the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable under appropriate circumstances, so that the embodiments of the present application can be implemented in an order other than those illustrated or described here, and the objects distinguished by "first", "second", etc. are generally of one type, and the number of objects is not limited. For example, the first object can be one or more. In addition, "and / or" in the specification and claims represents at least one of the connected objects, and the character " / " generally indicates that the objects associated with each other are in an "or" relationship.

[0016] In conjunction with the accompanying drawings, the following describes in detail the burning method, device, electronic device and storage medium of the Linux system provided by the embodiments of the present application through specific embodiments and their application scenarios.

[0017] Figure 1 A method for burning a Linux system provided by an embodiment of the present invention is shown. The method can be executed by an electronic device, and the electronic device may include: a server and / or a terminal device, wherein the terminal device may be, for example, a vehicle-mounted terminal or a mobile phone terminal. In other words, the method can be executed by software or hardware installed in the electronic device, and the method includes the following steps: S102: Obtain a first source code for generating a first image file, and generate a first image file to be burned including a verification file and a first root file system file based on the first source code.

[0018] Among them, the verification file is generated by the first tool based on the directory file corresponding to the first root file system file; the first tool is a tool for generating and verifying the hash value of the hash function; the first image file is the image file required by the Linux system during the startup process.

[0019] In practical applications, the first source code used to generate the first image file may include: a first Linux system building source code (such as the source code provided by the Linux system building tool buildroot or Yocto) used to generate the first image file, a first Linux system kernel source code and a first boot loader (such as the boot loader uboot) source code.

[0020] Specifically, the hash function may be, for example, a message digest algorithm (Message-Digest Algorithm 5, MD5), etc. The first tool may be an md5sum tool.

[0021] Exemplarily, the md5sum tool may be used to compile a directory file (eg, output / target directory) corresponding to the first root file system file to generate a verification file.

[0022] S104: writing the first image file into the first non-volatile storage medium, so that the device to be burned burns the first image file in the first non-volatile storage medium into the second non-volatile storage medium of the device to be burned, and verifying the verification file through the first tool to determine whether to prompt the user to re-burn the first image file to the device to be burned based on the verification result.

[0023] In practical applications, the first non-volatile storage medium may be an SD card, and the second non-volatile storage medium may be an eMMC card. Of course, they may also be other non-volatile storage media, which are not specifically limited. The device to be burned may be a development board or other device, which are not specifically limited.

[0024] The verification file may include the hash values ​​of each file under the directory file corresponding to the first root file system file. In other words, a "snapshot" verification and record is generated based on the file path and content, relying on the stored MD5 verification value file to compare the original state and the current state, and verifying all files corresponding to the directory file one by one. Afterwards, if the verification passes, the Linux system can be started normally. If the verification fails, the user is prompted to re-burn the first image file to the device to be burned.

[0025] In actual applications, a variety of verification failure prompts can be provided, such as buzzer sounding, LED flashing, or liquid crystal display (LCD) displaying corresponding prompt messages to prompt the user to re-burn.

[0026] The burning method of the Linux system provided by the embodiment of the present invention obtains a first source code for generating a first image file, and generates a first image file to be burned including a verification file and a first root file system file based on the first source code; wherein the verification file is generated by a first tool based on a directory file corresponding to the first root file system file; the first tool is a tool for generating and verifying a hash value of a hash function; the first image file is an image file required by the Linux system during the startup process; the first image file is written into a first non-volatile storage medium, so that a device to be burned burns the first image file in the first non-volatile storage medium into a second non-volatile storage medium of the device to be burned, and the verification file is verified by the first tool, so as to determine whether to prompt a user to re-burn the first image file to the device to be burned based on the verification result. Compared with the burning scheme of related Linux systems, which rely on complex external tools or hardware encryption modules, the present application adopts a first tool for generating and verifying the hash value of a hash function, generates a verification file for the directory file corresponding to the first root file system file, and then verifies the verification file in the first image file to be burned. The present application is simple and easy to implement, and effectively prevents the system image file from being tampered with or damaged, thereby improving the reliability of the Linux system burned into the device to be burned and the security of the burning. The use of the first tool does not require additional support, reduces the cost of system implementation, and has better compatibility, thereby solving the problems of low security or poor adaptability of the burning scheme of related Linux systems.

[0027] In one implementation, the method may also write the second image file to the first non-volatile storage medium by executing the following steps A1 to A2: Step A1, obtaining a second source code for generating a second image file, and generating a second image file based on the second source code.

[0028] The second image file is an image file required by the temporary file system during the startup process.

[0029] In practical applications, the second source code used to generate the second image file may include: a second Linux system build source code, a second Linux system kernel source code, and a second boot loader source code. Since the boot loader source code can pass parameters to the kernel to set, for example, the memory (Double Data Rate, DDR) size, serial port debugging device, etc., these settings will vary depending on the hardware configuration. Therefore, the first boot loader source code and the second boot loader source code may be the same or different, which may be determined according to the actual development environment, and no specific limitation is made to this.

[0030] Specifically, the temporary file system may be initramfs or ramfs, etc., which is not specifically limited.

[0031] Step A2: writing the second image file into the first non-volatile storage medium.

[0032] Burning the first image file in the first non-volatile storage medium to the second non-volatile storage medium of the device to be burned (ie S104) can be specifically performed as follows: Step A3 to Step A4: Step A3: start the temporary file system based on the second image file.

[0033] Specifically, in response to the startup of the first non-volatile storage medium, the temporary file system may be started based on the second image file.

[0034] Step A4: load the first script pre-configured in the second image file through the temporary file system, and burn the first image file into the second non-volatile storage medium of the device to be burned.

[0035] The pre-configured first script instructs the device to be burned to determine the corresponding file system partition and the storage capacity of the file system partition in the second non-volatile storage medium based on the total storage capacity of the second non-volatile storage medium, and determine whether to format the file system partition according to the first script, and burn the first image file to the file system partition. The file system partition is used to store the first image file.

[0036] Exemplarily, the first script may be a startup script such as S110sysupdate in a directory file (eg, target / etc / init.d directory) corresponding to the second root file system file (the root file system file corresponding to the temporary file system generated by the Linux system building tool).

[0037] In the present embodiment, considering that the burning process usually requires manual operation, including partitioning, formatting, burning file system, etc., it is easy to cause burning failure or system unavailability due to improper operation, and the storage layout of different devices to be burned is not unified, resulting in the burning script lacking versatility, therefore, an automated script, i.e., a first script, is pre-configured, and the automated burning of different devices to be burned is realized by the first script pre-configured in the temporary file system. On the other hand, the temporary file system is used as the startup environment of the device to be burned, and after the temporary file system is started, automatic partitioning, formatting and burning operations are completed, thereby reducing the risk of human intervention and ensuring the reliability of startup.

[0038] In one implementation, the first script instructs the device to be programmed to perform the following steps B1 to B3: Step B1, based on the first parameter in the first script, obtain the total storage capacity of the second non-volatile storage medium, and based on the total storage capacity of the second non-volatile storage medium, determine the corresponding file system partition and the storage capacity of the file system partition in the second non-volatile storage medium.

[0039] The first parameter is used to characterize the device node to be operated, and the device node to be burned points to the second non-volatile storage medium of the device to be burned.

[0040] Specifically, a plurality of the first parameters and a plurality of the second parameters described below may be provided in the first script for the user to select and configure, thereby obtaining a pre-configured first script.

[0041] Exemplarily, the first parameter of the automation script may be set to specify the device node to run, such as setting / dev / mmcblk0 to specify / dev / mmcblk0 as the device node to be operated by the system, thereby dynamically adapting the storage paths of different devices to be burned.

[0042] In actual applications, a tool program for hard disk partitioning can be called to obtain the total storage capacity of the second non-volatile storage medium. Specifically, the second non-volatile storage medium includes a RAW partition and a file system partition; then, according to the total storage capacity of the second non-volatile storage medium, the RAW partition of the device to be burned, the storage capacity of the RAW partition, the corresponding file system partition, and the storage capacity of the file system partition are determined. Among them, the tool program for hard disk partitioning can be sfdisk. RAW partition refers to a partition without a file system and raw data storage. Therefore, the partition layout can be automatically adjusted according to the actual storage size of the device to be burned, avoiding fixed partition size and layout.

[0043] In practical applications, before executing step B1, the first script can also be used to instruct the device to be burned to execute the following steps: Determine whether the user is the super administrator root user; If not, the program will be exited and the user will be prompted to re-program. If yes, the first non-volatile storage medium is mounted to a temporary directory ( / mnt directory), and then the following steps B2 to B3 are executed.

[0044] Step B2: determining whether to format the file system partition based on whether the second parameter exists in the first script.

[0045] The second parameter is used to indicate that the file system partition is not to be formatted.

[0046] Exemplarily, the second parameter may be -nf. If -nf does not exist in the first script, the file system partition in the second non-volatile storage medium is formatted.

[0047] Afterwards, the following steps may be performed: determine whether the first image file exists in the first non-volatile storage medium; if not, exit the burning process and prompt the user to burn again; if exists, perform the following step B3.

[0048] Step B3, burning the first image file to the file system partition.

[0049] In one implementation, writing the first image file into the first non-volatile storage medium (ie, step A2) may be specifically performed as follows: step C1 to step C2: Step C1, encrypting the target root file system file in the first image file through an encryption program to obtain an encrypted target root file system file.

[0050] The target root file system file includes a first root file system file and a verification file.

[0051] Specifically, the encryption program may be openssl or the like.

[0052] Exemplarily, the storage path of the verification file can be added to the first directory file (i.e., the directory file corresponding to the first root file system file mentioned above) to obtain the second directory file; then, based on the second directory file, the first root file system file and the verification file are packaged together through a Linux system building tool (such as Buildroot, etc.) to generate the target root file system file; then, on the x86 host, the target root file system file is encrypted through openssl using a symmetric encryption algorithm such as aes-256 to obtain the encrypted target root file system file.

[0053] Step C2: writing the first image file including the encrypted target root file system file into a first non-volatile storage medium.

[0054] Before the verification file is verified by the first tool (ie, S104), the following step C3 may be specifically performed: Step C3, decrypting the encrypted target root file system file through the encryption program configured in the second image file to obtain the first root file system file and the verification file.

[0055] In actual application, the second image file includes a second root file system file, and the encryption program can be configured in the second root file system file. In addition, the second root file system file can also be configured with a second tool for formatting a disk partition and a third tool for writing the first image file to a partition corresponding to a non-volatile storage medium. The second tool is, for example, mkfs; the third tool is, for example, dd or other commands.

[0056] The encryption program, the second tool and the third tool are configured into the second root file system file. Exemplarily, the second Linux system can be built by compiling the source code, and a minimum file system can be made by using a Linux system building tool such as buildroot. After that, the package options of Buildroot are configured to ensure that the encryption program, the second tool and the third tool are included in the minimum file system. Then, the make command is executed to generate the second root file system file, which can be the output / image / rootfs.cpio file.

[0057] In addition, the second image file corresponding to the temporary file system also includes: a second kernel image file, a second device tree file, a third boot loader file and a fourth boot loader file; wherein the second root file system file is embedded in the second kernel image file. Specifically, the second kernel image file (i.e., Image file) and the second device tree file (i.e., DTB file) can be generated by compiling the second Linux system kernel source code; the third boot loader file (i.e., spl file) and the fourth boot loader file (i.e., uboot file) can be generated by compiling the second boot loader (i.e., uboot) source code.

[0058] The second root file system file is embedded in the second kernel image file. Following the above example, the RAM Disk Support option can be configured in the second Linux system kernel source code to make the kernel support ramfs, and then the path of the second root file system file is specified by the environment variable ROMFSDIR, so that the second kernel image file embedded with the second root file system file can be compiled. So that the second root file system file can be directly used as the root file system file when the second kernel image file is started.

[0059] In the present embodiment, considering the burning scheme of the relevant linux system, it is often dependent on complex hardware encryption modules or external tools, which increases the complexity of system design and implementation, and the development cost is high, which is not suitable for small and medium-sized embedded development projects. Therefore, on the one hand, by encrypting the target root file system file in the first image file, it is ensured that the target root file system file is not intercepted or tampered by unauthorized parties during transmission, storage and burning. At the same time, it is avoided that the file system is leaked due to the loss of the first non-volatile storage medium, or the file system is leaked due to other reasons, and the data is exposed in plain text, thereby improving the security of the entire burning process. On the other hand, the encryption and decryption and verification functions are fully realized based on software, without the support of additional hardware security modules, and are applicable to a variety of embedded platforms, reducing the system implementation cost, and having a wide range of applicability. In addition, a temporary file system is used as the startup environment of the embedded device, and after the temporary file system is started, the decryption operation is completed, the risk of human intervention is reduced, and the reliability of startup is guaranteed.

[0060] In one implementation, the first image file further includes a first kernel image file, a first device tree file, a first boot loader file, and a second boot loader file; the file system partition includes a first partition, a second partition, and a third partition. The above-mentioned determination of the corresponding file system partition and the storage capacity of the file system partition in the second non-volatile storage medium based on the total storage capacity of the second non-volatile storage medium (i.e., step B1) can be specifically performed as the following step D1: Step D1, based on the total storage capacity, determine the corresponding first partition, second partition, third partition, storage capacity of the first partition, storage capacity of the second partition and storage capacity of the third partition.

[0061] Specifically, a partition table may be generated based on the total storage capacity, the partition table including the names of the partitions (the first partition, the second partition, the third partition and the above RAW partition), the storage capacity of each partition, and the file system format of each partition, wherein the file system format is, for example, ext4.

[0062] Continuing with the example of step B2 above, the first partition can be named boot0 partition; the second partition can be named sys partition; the third partition can be named root partition; when -nf does not exist, the second partition is formatted as FAT32, and the third partition is formatted as ext4.

[0063] Exemplarily, the target root file system file obtained by decryption in the above step C3 may be written into the third partition.

[0064] The above-mentioned burning of the first image file to the file system partition (ie, step B3) can be specifically performed as the following step D2: Step D2, writing the first boot loader file into the first partition, and writing the first kernel image file, the first device tree file and the second boot loader file into the second partition, and writing the first root file system file and the checksum file into the third partition.

[0065] The first boot loader file is used to boot and load the second boot loader file; the second boot loader file is used to boot and load the first kernel image file and the first device tree file.

[0066] Correspondingly, the following steps can also be performed in sequence: determine whether the first boot loader file is successfully written; if the writing is successful, determine whether the second boot loader file, the first kernel image file and the first device tree file are successfully written to the second partition; if so, determine whether the decryption of the target root file system file is successful; if the decryption is successful, write the first root file system file and the verification file to the third partition; if any of the judgment results is no, exit the burning and prompt the user to burn again.

[0067] In addition, the first kernel image file corresponding to the Linux system and the second kernel image file (mentioned above) corresponding to the temporary file system are different. Since the first kernel image file will eventually be burned into the second non-volatile storage medium to support normal Linux system operation, it will be configured and compiled for the actual operating environment, including complete drivers (such as screen display, RTC, USB, network port, etc.), file system support, encryption, decryption, decompression and other functions. The second kernel image file is mainly a lightweight kernel, which is used to provide an operating environment for the next steps.

[0068] Considering different hardware configurations of the device to be burned, such as DDR configuration, different boot loaders may be required to ensure that the system can correctly start and identify the hardware configuration. That is, in order to make the first script compatible with devices to be burned with different DDR sizes, in one implementation, the first image file is pre-configured with multiple first boot loader files and / or multiple second boot loader files; the first script is also used to instruct the device to be burned to execute the following steps E1: Step E1, receiving information of a target first boot loader file selected by a user according to the input / output pin information of the device to be burned, and / or information of a target second boot loader file selected, so as to start the Linux system based on the target first boot loader file and / or the target second boot loader file.

[0069] Specifically, the user may select a target first boot loader file from a plurality of first boot loader files according to the I / O pin information of the device to be burned, and the device to be burned obtains the information of the target first boot loader file. Referring to the same method, the device to be burned obtains the information of the target second boot loader file, thereby starting the Linux system based on the target first boot loader file and / or the target second boot loader file. The user may also input the pin information of the device to be burned, and the device to be burned receives the information, and matches the target first boot loader file and / or the target second boot loader file from the pre-configured plurality of first boot loader files and / or the plurality of second boot loader files, thereby starting the Linux system based on the target first boot loader file and / or the target second boot loader file.

[0070] In one implementation, the verification file is verified by a first tool to determine whether to prompt the user to re-burn the first image file to the device to be burned based on the verification result (ie, S104), which can be specifically performed as follows: Step F1, in response to the startup of the second non-volatile storage medium, the device to be burned reads a second script pre-configured in the first root file system file.

[0071] Specifically, the second script may be a boot-up script. For example, the second script may be an SXXmd5check script. In the / etc / init.d / directory, the command chmod+x / etc / init.d / SXXmd5check is used to give execution permission, and the SXXmd5check script is set to be boot-up.

[0072] The second script instructs the device to be programmed to execute the following steps F2 to F6: Step F2, determining whether there is a verification mark in the log file recorded when the Linux system is booted.

[0073] The verification mark is used to indicate that the verification has passed.

[0074] In practical applications, the log file recorded by the Linux system during booting, such as the / first_boot.log file, contains all startup information and error information during the startup of the Linux system. The verification mark can be "ok", and it is understandable that the verification mark can also be other marks, which is not specifically limited.

[0075] Step F3: if it exists, start the Linux system based on the first image file.

[0076] Step F4: If it does not exist, verify the verification file using the first tool.

[0077] Step F5: If the verification is passed, a verification mark is written into the log file, and the device to be burned is restarted.

[0078] Step F6: If the verification fails, the user is prompted to re-burn the first image file to the device to be burned.

[0079] Exemplarily, the verification file is verified by md5sum. If 0 is returned, it means the verification is passed. If a non-zero value is returned, it means the verification is not passed.

[0080] Figure 2 FIG. 1 is a flow chart of another method for burning a Linux system provided in an embodiment of the present application. Figure 2 As shown, the method includes: Step 202, obtain a first source code for generating a first image file, and based on the first source code, generate a first image file to be burned including a verification file and a first root file system file; the verification file is generated by a first tool based on a directory file corresponding to the first root file system file; the first tool is a tool for generating and verifying a hash value of a hash function.

[0081] The first image file is an image file required by the Linux system during the startup process.

[0082] Step 204: Obtain a second source code for generating a second image file, and generate a second image file based on the second source code.

[0083] The second image file is an image file required by the temporary file system during the startup process.

[0084] Step 206: encrypt the target root file system file in the first image file through an encryption program to obtain an encrypted target root file system file.

[0085] The target root file system file includes a first root file system file and a verification file.

[0086] Step 208: write the second image file and the first image file including the encrypted target root file system file into the first non-volatile storage medium.

[0087] Step 210: The device to be burned starts a temporary file system based on the second image file, and loads a first script pre-configured in the second image file through the temporary file system.

[0088] Step 212, a first script, instructs the device to be burned, obtains the total storage capacity of the second non-volatile storage medium based on the first parameter in the first script, and determines the corresponding first partition, second partition, third partition, storage capacity of the first partition, storage capacity of the second partition and storage capacity of the third partition in the second non-volatile storage medium based on the total storage capacity of the second non-volatile storage medium.

[0089] The first parameter is used to characterize the device node to be operated, and the device node to be burned points to the second non-volatile storage medium of the device to be burned.

[0090] Step 214, the first script instructs the device to be burned to determine whether to format the file system partition based on whether the second parameter exists in the first script, and decrypts the encrypted target root file system file through the encryption program configured in the second image file to obtain the first root file system file and the verification file.

[0091] The second parameter is used to indicate that the file system partition is not to be formatted.

[0092] Step 216, the first script instructs the device to be burned to write the first boot loader file to the first partition of the second non-volatile storage medium, and write the first kernel image file, the first device tree file and the second boot loader file to the second partition, and write the first root file system file and the checksum file to the third partition.

[0093] Step 218: In response to the startup of the second non-volatile storage medium, the device to be burned reads the second script pre-configured in the first root file system file.

[0094] Step 220, the second script instructs the device to be burned to determine whether there is a verification mark in the log file recorded by the Linux system when it is booted; if it exists, the Linux system is started based on the first image file.

[0095] The verification mark is used to indicate that the verification has passed.

[0096] Step 222: If it does not exist, the verification file is verified by the first tool; if the verification passes, a verification mark is written into the log file, and the device to be burned is restarted.

[0097] Step 224: If the verification fails, the user is prompted to re-burn the first image file to the device to be burned.

[0098] The specific process of the above steps 202 to 224 has been described in detail in the above embodiment and will not be repeated here.

[0099] In this embodiment, a first source code for generating a first image file is obtained, and based on the first source code, a first image file to be burned, including a verification file and a first root file system file, is generated; wherein the verification file is generated by a first tool based on a directory file corresponding to the first root file system file; the first tool is a tool for generating and verifying a hash value of a hash function; the first image file is an image file required by the Linux system during the startup process; the first image file is written to a first non-volatile storage medium, so that the device to be burned burns the first image file in the first non-volatile storage medium to a second non-volatile storage medium of the device to be burned, and the verification file is verified by the first tool to determine whether to prompt the user to re-burn the first image file to the device to be burned based on the verification result. Compared with the burning scheme of related Linux systems, which rely on complex external tools or hardware encryption modules, the present application adopts a first tool for generating and verifying the hash value of a hash function, generates a verification file for the directory file corresponding to the first root file system file, and then verifies the verification file in the first image file to be burned. The present application is simple and easy to implement, and effectively prevents the system image file from being tampered with or damaged, thereby improving the reliability of the Linux system burned into the device to be burned and the security of the burning. The use of the first tool does not require additional support, reduces the cost of system implementation, and has better compatibility, thereby solving the problems of low security or poor adaptability of the burning scheme of related Linux systems.

[0100] Corresponding to the burning method of the Linux system provided in the above embodiment, based on the same technical concept, the embodiment of the present invention also provides a burning device of the Linux system, Figure 3 is a schematic diagram of the structure of a burning device for a Linux system according to an embodiment of the present invention, wherein the burning device for a Linux system is used to execute Figure 1 to Figure 2 The burning method of the Linux system described in Figure 3 As shown, the burning device of the Linux system includes: an acquisition module 310 and a burning module 320.

[0101] The acquisition module 310 is used to acquire a first source code for generating a first image file, and based on the first source code, generate a first image file to be burned including a verification file and a first root file system file; the verification file is generated by a first tool based on a directory file corresponding to the first root file system file; the first tool is a tool for generating and verifying a hash value of a hash function.

[0102] The first image file is an image file required by the Linux system during the startup process.

[0103] The burning module 320 is used to write the first image file into the first non-volatile storage medium so that the device to be burned burns the first image file in the first non-volatile storage medium into the second non-volatile storage medium of the device to be burned, and verifies the verification file through the first tool to determine whether to prompt the user to re-burn the first image file to the device to be burned based on the verification result.

[0104] In one implementation, the burning device of the Linux system further includes a second image acquisition module. The second image acquisition module is used to: Obtaining a second source code for generating a second image file, and generating a second image file based on the second source code; wherein the second image file is an image file required by the temporary file system during the startup process; Writing the second image file to the first non-volatile storage medium; The burning module 320 is specifically used for: Based on the second image file, start the temporary file system; Through a temporary file system, a pre-configured first script in the second image file is loaded, and the first image file is burned into a second non-volatile storage medium of a device to be burned; the pre-configured first script instructs the device to be burned to determine, based on the total storage capacity of the second non-volatile storage medium, a corresponding file system partition and a storage capacity of the file system partition in the second non-volatile storage medium, and determine whether to format the file system partition according to the first script, and burn the first image file into the file system partition; wherein the file system partition is used to store the first image file.

[0105] In one implementation, the first script instructs the device to be programmed to perform the following steps: Based on the first parameter in the first script, the total storage capacity of the second non-volatile storage medium is obtained, and based on the total storage capacity of the second non-volatile storage medium, the corresponding file system partition and the storage capacity of the file system partition in the second non-volatile storage medium are determined; wherein the first parameter is used to characterize the device node to be operated, and the device node to be burned points to the second non-volatile storage medium of the device to be burned; Determine whether to format the file system partition based on whether the second parameter exists in the first script; wherein the second parameter is used to indicate that the file system partition is not to be formatted; Burn the first image file to the file system partition.

[0106] In one implementation, the burning module 320 is specifically used for: Encrypting the target root file system file in the first image file by an encryption program to obtain an encrypted target root file system file; wherein the target root file system file includes the first root file system file and a verification file; Writing a first image file including the encrypted target root file system file into a first non-volatile storage medium; The encrypted target root file system file is decrypted by the encryption program configured in the second image file to obtain the first root file system file and the verification file.

[0107] In one implementation, the first image file further includes a first kernel image file, a first device tree file, a first boot loader file, and a second boot loader file; the file system partition includes a first partition, a second partition, and a third partition; based on the total storage capacity of the second non-volatile storage medium, determining the corresponding file system partition and the storage capacity of the file system partition in the second non-volatile storage medium includes: Based on the total storage capacity, the corresponding first partition, second partition, third partition, storage capacity of the first partition, storage capacity of the second partition, and storage capacity of the third partition are determined.

[0108] Burn the first image file to the file system partition, including: The first boot loader file is written into the first partition, the first kernel image file, the first device tree file and the second boot loader file are written into the second partition, and the first root file system file and the checksum file are written into the third partition.

[0109] The first boot loader file is used to boot and load the second boot loader file; the second boot loader file is used to boot and load the first kernel image file and the first device tree file.

[0110] In one implementation, the first image file is pre-configured with a plurality of first boot loader files and / or a plurality of second boot loader files; the first script is further used to instruct the device to be burned to perform the following steps: Receive information of a target first boot loader file selected by a user according to input and output I / O pin information of a device to be burned, and / or information of a target second boot loader file selected, so as to start a Linux system based on the target first boot loader file and / or the target second boot loader file.

[0111] In one implementation, the burning module 320 is specifically used for: In response to the startup of the second non-volatile storage medium, the device to be burned reads a second script pre-configured in the first root file system file; The second script instructs the device to be burned to perform the following steps: Determine whether there is a verification mark in the log file recorded when the Linux system is booted; wherein the verification mark is used to indicate that the verification has passed; If it exists, start the Linux system based on the first image file; If it does not exist, verify the verification file through the first tool; If the verification passes, a verification mark is written to the log file and the device to be burned is restarted; If the verification fails, the user is prompted to re-burn the first image file to the device to be burned.

[0112] Those skilled in the art should understand that the above-mentioned burning device of Linux system can be used to implement the burning method of Linux system mentioned above, and the detailed description thereof should be similar to the description of the method part mentioned above, and will not be repeated here to avoid repetition.

[0113] In this embodiment, a first source code for generating a first image file is obtained, and based on the first source code, a first image file to be burned, including a verification file and a first root file system file, is generated; wherein the verification file is generated by a first tool based on a directory file corresponding to the first root file system file; the first tool is a tool for generating and verifying a hash value of a hash function; the first image file is an image file required by the Linux system during the startup process; the first image file is written to a first non-volatile storage medium, so that the device to be burned burns the first image file in the first non-volatile storage medium to a second non-volatile storage medium of the device to be burned, and the verification file is verified by the first tool to determine whether to prompt the user to re-burn the first image file to the device to be burned based on the verification result. Compared with the burning scheme of related Linux systems, which rely on complex external tools or hardware encryption modules, the present application adopts a first tool for generating and verifying the hash value of a hash function, generates a verification file for the directory file corresponding to the first root file system file, and then verifies the verification file in the first image file to be burned. The present application is simple and easy to implement, and effectively prevents the system image file from being tampered with or damaged, thereby improving the reliability of the Linux system burned into the device to be burned and the security of the burning. The use of the first tool does not require additional support, reduces the cost of system implementation, and has better compatibility, thereby solving the problems of low security or poor adaptability of the burning scheme of related Linux systems.

[0114] Based on the same technical concept, the embodiment of the present application further provides an electronic device, which is used to execute the above-mentioned burning method of the Linux system or the above-mentioned web page prediction method. Figure 4A schematic diagram of the structure of an electronic device for implementing various embodiments of the present application. The electronic device may have relatively large differences due to different configurations or performances, and may include a processor (processor) 410, a communication interface (Communications Interface) 420, a memory (memory) 430 and a communication bus 440, wherein the processor 410, the communication interface 420, and the memory 430 communicate with each other through the communication bus 440. The processor 410 may call a computer program stored in the memory 430 and executable on the processor 410 to perform the following steps: Obtain a first source code for generating a first image file, and based on the first source code, generate a first image file to be burned including a verification file and a first root file system file; wherein the verification file is generated by a first tool based on a directory file corresponding to the first root file system file; the first tool is a tool for generating and verifying a hash value of a hash function; the first image file is an image file required by the Linux system during the startup process; The first image file is written into a first non-volatile storage medium, so that the device to be burned burns the first image file in the first non-volatile storage medium into a second non-volatile storage medium of the device to be burned, and the verification file is verified by a first tool to determine whether to prompt the user to re-burn the first image file to the device to be burned based on the verification result.

[0115] In this embodiment, a first source code for generating a first image file is obtained, and based on the first source code, a first image file to be burned, including a verification file and a first root file system file, is generated; wherein the verification file is generated by a first tool based on a directory file corresponding to the first root file system file; the first tool is a tool for generating and verifying a hash value of a hash function; the first image file is an image file required by the Linux system during the startup process; the first image file is written to a first non-volatile storage medium, so that the device to be burned burns the first image file in the first non-volatile storage medium to a second non-volatile storage medium of the device to be burned, and the verification file is verified by the first tool to determine whether to prompt the user to re-burn the first image file to the device to be burned based on the verification result. Compared with the burning scheme of related Linux systems, which rely on complex external tools or hardware encryption modules, the present application adopts a first tool for generating and verifying the hash value of a hash function, generates a verification file for the directory file corresponding to the first root file system file, and then verifies the verification file in the first image file to be burned. The present application is simple and easy to implement, and effectively prevents the system image file from being tampered with or damaged, thereby improving the reliability of the Linux system burned into the device to be burned and the security of the burning. The use of the first tool does not require additional support, reduces the cost of system implementation, and has better compatibility, thereby solving the problems of low security or poor adaptability of the burning scheme of related Linux systems.

[0116] The specific execution steps can refer to the various steps of the above-mentioned Linux system burning method embodiment, and can achieve the same technical effect. To avoid repetition, they will not be repeated here.

[0117] It should be noted that the electronic devices in the embodiments of the present application include: servers, terminals, or other devices except terminals.

[0118] The above electronic device structure does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently. For example, the input unit may include a graphics processing unit (GPU) and a microphone, and the display unit may be configured with a display panel in the form of a liquid crystal display, an organic light-emitting diode, etc. The user input unit includes a touch panel and at least one of other input devices. The touch panel is also called a touch screen. Other input devices may include, but are not limited to, a physical keyboard, function keys (such as volume control keys, switch keys, etc.), a trackball, a mouse, and a joystick, which will not be repeated here.

[0119] The memory can be used to store software programs and various data. The memory may mainly include a first storage area for storing programs or instructions and a second storage area for storing data, wherein the first storage area may store an operating system, an application program or instructions required for at least one function (such as a sound playback function, an image playback function, etc.), etc. In addition, the memory may include a volatile memory or a non-volatile memory, or the memory may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. Volatile memory can be random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM) and direct memory bus random access memory (DRRAM).

[0120] The processor may include one or more processing units; optionally, the processor integrates an application processor and a modem processor, wherein the application processor mainly processes operations related to the operating system, user interface, and application programs, and the modem processor mainly processes wireless communication signals, such as a baseband processor. It is understandable that the modem processor may not be integrated into the processor.

[0121] The embodiment of the present application also provides a storage medium, on which computer executable instructions are stored. When the computer executable instructions are executed by a processor, the various processes of the above-mentioned Linux system burning method embodiment or the above-mentioned web page prediction method embodiment can be implemented, and the same technical effect can be achieved. To avoid repetition, they will not be repeated here.

[0122] The processor is the processor in the electronic device described in the above embodiment. The storage medium includes a computer-readable storage medium, such as a computer read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0123] The embodiment of the present application further provides a chip, which includes a processor and a communication interface, the communication interface is coupled to the processor, and the processor is used to run programs or instructions to implement the various processes of the above-mentioned Linux system burning method embodiment, and can achieve the same technical effect. To avoid repetition, it will not be repeated here.

[0124] It should be understood that the chip mentioned in the embodiments of the present application can also be called a system-level chip, a system chip, a chip system or a system-on-chip chip, etc.

[0125] The embodiment of the present application also provides a computer program product, including a computer program. When the computer program is executed by a processor, each process of the above-mentioned Linux system burning method embodiment is implemented, and the same technical effect can be achieved. To avoid repetition, it will not be repeated here.

[0126] It should be noted that, in this article, the terms "comprise", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprises one..." does not exclude the presence of other identical elements in the process, method, article or device including the element. In addition, it should be noted that the scope of the methods and devices in the embodiments of the present application is not limited to performing functions in the order shown or discussed, and may also include multitasking and parallel processing according to the functions involved, and various steps may also be added, omitted, or combined. In addition, the features described with reference to certain examples may be combined in other examples.

[0127] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, a magnetic disk, or an optical disk), and includes a number of instructions for a terminal (which can be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to execute the methods described in each embodiment of the present application.

[0128] The embodiments of the present application are described above in conjunction with the accompanying drawings, but the present application is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of the present application, ordinary technicians in this field can also make many forms without departing from the purpose of the present application and the scope of protection of the claims, all of which are within the protection of the present application.

Claims

1. A burning method for a Linux system, characterized in that: The method comprises: Obtain a first source code for generating a first image file, and based on the first source code, generate a first image file to be burned including a verification file and a first root file system file; wherein the verification file is generated by a first tool based on a directory file corresponding to the first root file system file; the first tool is a tool for generating and verifying a hash value of a hash function; the first image file is an image file required by the Linux system during the startup process; The first image file is written into a first non-volatile storage medium, so that the device to be burned burns the first image file in the first non-volatile storage medium into a second non-volatile storage medium of the device to be burned, and the verification file is verified by the first tool to determine whether to prompt the user to re-burn the first image file to the device to be burned based on the verification result.

2. The method according to claim 1, characterized in that The method further comprises: Obtaining a second source code for generating a second image file, and generating the second image file based on the second source code; wherein the second image file is an image file required by the temporary file system during the startup process; Writing the second image file into the first non-volatile storage medium; The step of burning the first image file in the first non-volatile storage medium to the second non-volatile storage medium of the device to be burned comprises: Based on the second image file, starting the temporary file system; Through the temporary file system, load the first script pre-configured in the second image file, and burn the first image file to the second non-volatile storage medium of the device to be burned; the pre-configured first script instructs the device to be burned to determine the corresponding file system partition in the second non-volatile storage medium and the storage capacity of the file system partition based on the total storage capacity of the second non-volatile storage medium, and determine whether to format the file system partition according to the first script, and burn the first image file to the file system partition; wherein the file system partition is used to store the first image file.

3. The method according to claim 2, characterized in that The first script instructs the device to be burned to perform the following steps: Based on the first parameter in the first script, the total storage capacity of the second non-volatile storage medium is obtained, and based on the total storage capacity of the second non-volatile storage medium, the corresponding file system partition and the storage capacity of the file system partition in the second non-volatile storage medium are determined; wherein the first parameter is used to characterize the device node to be operated, and the device node to be burned points to the second non-volatile storage medium of the device to be burned; determining whether to format the file system partition based on whether a second parameter exists in the first script; wherein the second parameter is used to indicate that the file system partition is not to be formatted; Burn the first image file to the file system partition.

4. The method according to claim 2 or 3, characterized in that: Writing the first image file into the first non-volatile storage medium includes: Encrypting the target root file system file in the first image file by an encryption program to obtain the encrypted target root file system file; wherein the target root file system file includes the first root file system file and the verification file; Writing the first image file including the encrypted target root file system file into the first non-volatile storage medium; Before verifying the verification file by the first tool, the method further includes: The encrypted target root file system file is decrypted by the encryption program configured in the second image file to obtain the first root file system file and the verification file.

5. The method according to claim 2 or 3, characterized in that: The first image file also includes a first kernel image file, a first device tree file, a first boot loader file, and a second boot loader file; the file system partition includes a first partition, a second partition, and a third partition; and determining the corresponding file system partition in the second non-volatile storage medium and the storage capacity of the file system partition based on the total storage capacity of the second non-volatile storage medium includes: Based on the total storage capacity, determining the corresponding first partition, the second partition, the third partition, the storage capacity of the first partition, the storage capacity of the second partition, and the storage capacity of the third partition; The step of burning the first image file to the file system partition comprises: Writing the first boot loader file into the first partition, and writing the first kernel image file, the first device tree file, and the second boot loader file into the second partition, and writing the first root file system file and the checksum file into the third partition; The first boot loader file is used to boot and load the second boot loader file; and the second boot loader file is used to boot and load the first kernel image file and the first device tree file.

6. The method according to claim 5, characterized in that The first image file is pre-configured with a plurality of the first boot loader files and / or a plurality of the second boot loader files; the first script is further used to instruct the device to be burned to perform the following steps: Receive information of a target first boot loader file selected by a user according to the input and output I / O pin information of the device to be burned, and / or information of a target second boot loader file selected, so as to start the Linux system based on the target first boot loader file and / or the target second boot loader file.

7. The method according to claim 1, characterized in that The verifying the verification file by the first tool to determine whether to prompt the user to re-burn the first image file to the device to be burned based on the verification result includes: In response to the startup of the second non-volatile storage medium, the device to be burned reads a second script pre-configured in the first root file system file; The second script instructs the device to be burned to perform the following steps: Determine whether there is a verification mark in the log file recorded when the Linux system is booted; wherein the verification mark is used to indicate that the verification has passed; If it exists, start the Linux system based on the first image file; If it does not exist, verifying the verification file by using the first tool; If the verification is passed, the verification mark is written into the log file, and the device to be burned is restarted; If the verification fails, the user is prompted to re-burn the first image file to the device to be burned.

8. A burning device for a Linux system, characterized in that: The device comprises: an acquisition module, used for acquiring a first source code for generating a first image file, and generating a first image file to be burned including a verification file and a first root file system file based on the first source code; wherein the verification file is generated by a first tool based on a directory file corresponding to the first root file system file; the first tool is a tool for generating and verifying a hash value of a hash function; the first image file is an image file required by the Linux system during the startup process; The burning module is used to write the first image file into a first non-volatile storage medium, so that the device to be burned burns the first image file in the first non-volatile storage medium into a second non-volatile storage medium of the device to be burned, and verifies the verification file through the first tool to determine whether to prompt the user to re-burn the first image file to the device to be burned based on the verification result.

9. An electronic device, characterized in that: include: processor; as well as A memory arranged to store computer executable instructions, wherein the executable instructions are configured to be executed by the processor, and the executable instructions include instructions for executing the burning method of the Linux system according to any one of claims 1 to 7.

10. A storage medium, characterized in that: The storage medium is used to store computer executable instructions, and the computer executable instructions enable a computer to execute the burning method of the Linux system as described in any one of claims 1-7.

Images