Method for setting root file system of computer, and computer program

Abstract

To provide a technology capable of ensuring the authenticity of an entire root file system.SOLUTION: The disclosed method includes the steps of (a) reading a compressed file obtained by compressing the entire partition of a root file system and an electronic signature of the compressed file from an external storage device and loading the compressed file into a work area of a RAM of a computer, (b) performing verification of the electronic signature on the compressed file loaded into the work area, and (c) setting the root file system by expanding the compressed file into an external storage device when the verification is successful.SELECTED DRAWING: Figure 2

Description

Technical Field

[0001] The present disclosure relates to a method for setting a computer's root file system and a computer program.

Background Art

[0002] The root file system is a file system that stores the root directory and is at the apex of all other file systems that are mounted when the system boots. The root file system contains a number of startup files used when the computer starts up. Although the root file system is written to the computer's ROM, there may be cases where it is desired to update it to a new root file system using an external storage device such as an SD card in order to upgrade a part of it.

[0003] In recent years, in order to improve security, it has been required to verify that the firmware has not been tampered with. In order to securely boot a computer, it is necessary to verify the authenticity of the files contained in the root file system. However, since the root file system on the SD card contains a large number of files, it takes time to verify the signature of each one.

[0004] Patent Document 1 discloses a method for verifying the authenticity of a plurality of files. In this method, the system startup storage in the information processing apparatus is divided into a partition 1 that stores the files to be verified and a partition 2 that stores the files not to be verified. Then, a plurality of files are compressed to create a compressed file, its authentication data is generated, and both are stored in partition 1. When using the compressed file, the compressed data is signature-verified using the authentication data, and if the authentication is successful, the plurality of files are decompressed to partition 2.

Prior Art Documents

Patent Documents

[0005] [Patent Document 1] Japanese Unexamined Patent Application Publication No. 2021-177593 [Summary of the Invention] [Problems to be Solved by the Invention]

[0006] However, in the above prior art, before verifying the signature of the compressed file, the system startup file in the root file system has already been started, so there is a problem that the authenticity of the entire root file system cannot be guaranteed. Therefore, a technology that can guarantee the authenticity of the entire root file system is desired. [Means for Solving the Problems]

[0007] According to a first aspect of the present disclosure, a method for setting a root file system of a computer is provided. This method includes: (a) reading a compressed file obtained by compressing the entire partition of the root file system and an electronic signature of the compressed file from an external storage device and loading them into a work area of the computer's RAM; (b) executing verification of the electronic signature for the compressed file loaded into the work area; and (c) when the verification is successful, setting the root file system by expanding the compressed file in the external storage device.

[0008] According to a second aspect of the present disclosure, there is provided a computer program that executes a process of setting a root file system of a computer. This computer program causes the computer to execute: (a) a process of reading a compressed file obtained by compressing the entire partition of the root file system and an electronic signature of the compressed file from an external storage device and loading them into a work area of the computer's RAM; (b) a process of verifying the electronic signature for the compressed file loaded into the work area; and (c) a process of setting the root file system by expanding the compressed file into the external storage device when the verification is successful.

Brief Description of the Drawings

[0009]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Embodiments for Carrying Out the Invention

[0010] A. First Embodiment: FIG. 1 is a block diagram showing the configuration of a robot system 400 according to an embodiment. The robot system 400 includes a controller 100, an information processing device 200, and a robot body 300. The controller 100 is a computer called a "robot controller". The controller 100 and the information processing device 200 function as a control system for controlling the robot body 300. For example, the controller 100 functions as a lower-level control device, and the information processing device 200 functions as a higher-level control device. Alternatively, the information processing device 200 may be omitted, and the robot body 300 may be controlled only by the controller 100. As the information processing device 200, for example, a personal computer can be used.

[0011] The controller 100 has a CPU 110 as a processor, a RAM 120, a ROM 130, and an external memory card 140. The ROM 130 is composed of, for example, a flash ROM. The external memory card 140 is, for example, an SD card and is inserted into the memory card slot of the controller 100. The memory card slot may be connected to the controller 100 via a USB interface. A compressed file CFa including the entire root file system is stored in the external memory card 140.

[0012] The present disclosure is applicable not only to the controller 100 for robots but also to other types of computers. Further, as the external storage device for storing the compressed file CFa, other types of external storage devices other than SD cards can also be used.

[0013] FIG. 2 is an explanatory diagram of the startup process of the controller 100 in the first embodiment. FIGS. 3 and 4 are flowcharts showing the procedure of the startup process. In FIG. 2, some of the step numbers in FIGS. 3 and 4 are attached. Hereinafter, with reference to FIGS. 2 to 4, the processes related to the setting of the root file system will be described, and other processes such as the initialization of hardware will be omitted from the description.

[0014] The ROM 120 has a first bootloader area 121, a second bootloader area 122, a first ROM area 123, and a second ROM area 124. The primary bootloader is stored in the first bootloader area 121. The IPL (Initial Program Loader) as the secondary bootloader is stored in the second bootloader area 122. For example, U-boot is used as the IPL. A plurality of programs including the deployment program DPM for file deployment and electronic signature authentication are stored in the first ROM area 123. The startup file SF1 used when starting up the controller 100 and the root file system are stored in the second ROM area 124. The startup file SF1 includes the OS kernel.

[0015] In the following description, the first ROM area 123 is referred to as the "ROM area 1", and the second ROM area 124 is referred to as the "ROM area 2". In this embodiment, Linux (registered trademark) is used as the OS (Operating System). However, the content of the present disclosure is also applicable to other OSs other than Linux (registered trademark).

[0016] The RAM 130 has a kernel area 131 and a work area 132. In the first embodiment, a part of the area of the RAM 130 is used as the RAM disk 133.

[0017] The external memory card 140 stores a compressed file CFa that includes the entire root file system. This compressed file CFa is stored in a normal file system that is not the root file system. This normal file system is, for example, FAT32. In the present embodiment, since the compressed file CFa is compressed in the zip format, it is named FAT32.zip in FIG. 2. An electronic signature DSa is attached to the compressed file CFa. The compressed file CFa includes a compressed file CFb that compresses the entire partition of the root file system, and a startup file SF2 for starting the system with the external memory card 140 as the root file system.

[0018] The compressed file CFb obtained by compressing the entire partition of the root file system is a file in the squashfs format, which is a compressed file format for Linux (registered trademark), and is named rootfs.squashfs in FIG. 2. The entire partition of the root file system has a configuration compliant with EXT4, which is a file system commonly used in Linux (registered trademark).

[0019] The compressed file CFa is created by further compressing the compressed file CFb obtained by compressing the entire partition of the root file system in another compressed file format. In the following description, the compressed file CFa is also referred to as the "upper compressed file CFa", and the compressed file CFb is also referred to as the "lower compressed file CFb". The reason for performing two-stage compression is that, in addition to the lower compressed file CFb, a startup file SF2 for starting the system with the external memory card 140 as the root file system and other data are compressed to create the upper compressed file CFa, and an electronic signature is attached to the upper compressed file CFa so that these can be verified collectively. However, the startup process of the present disclosure may be executed using a compressed file obtained by compressing the entire partition of the root file system in a single-stage compression without performing such two-stage compression.

[0020] When the signature verification of the upper compressed file CFa is successful in the procedure described below, the root directory is set in the external memory card 140, and the root file system is expanded from the lower compressed file CFb. The root file system includes various programs and data such as the following, for example. (1) Command (2) Application program (3) Setting data These programs and data are stored in their respective directories provided below the root directory. The lower compressed file CFb is created by compressing the image file of the root file system expanded in a format that can be written to the external memory card 140. An "image file" is data that stores the data recorded in a storage device while maintaining the file and folder structure.

[0021] The process of FIG. 3 is started in response to the power-on of the controller 100. In step S01, the primary boot loader verifies the electronic signature DS1 of the IPL. The public key PK1 pre-stored in the first boot loader area 121 is used for this verification.

[0022] In step S02, the primary boot loader determines whether the verification of the IPL was successful. If the verification of the IPL fails, the system is stopped and the process of FIG. 3 is terminated. On the other hand, if the verification of the IPL is successful, the process proceeds to step S03, and the IPL loads the upper compressed file CFa in the external memory card 140 into the work area 132 of the RAM 130.

[0023] In step S04, the IPL verifies the electronic signature DS2 of ROM area 1. This verification is preferably for the entire ROM area 1, but may also be for the verification of the expansion program DPM stored in ROM area 1. The public key PK2 pre-stored in the second boot loader area 122 is used for this verification.

[0024] In step S05, the IPL determines whether the verification of ROM area 1 is successful. If the verification of ROM area 1 fails, the system is stopped and the process in FIG. 3 is terminated. On the other hand, if the verification of ROM area 1 is successful, the process proceeds to step S06, and the IPL starts the program in ROM area 1. The started program includes at least the deployment program DPM.

[0025] In step S07, the deployment program DPM in ROM area 1 verifies the electronic signature DS3 of ROM area 2. This verification is preferably for the entire ROM area 2, but may also be for the verification of the startup file SF1 and the root file system stored in ROM area 2. The public key PK3 pre-stored in ROM area 1 is used for this verification.

[0026] In step S08, the deployment program DPM determines whether the verification of ROM area 2 is successful. If the verification of ROM area 2 fails, the system is stopped and the process in FIG. 3 is terminated. On the other hand, if the verification of ROM area 2 is successful, the process proceeds to step S09, and the deployment program DPM deploys the startup file SF1 for ROM startup from ROM area 2 to RAM130. This startup file SF1 includes the OS kernel. The OS kernel is deployed to the kernel area 131 of RAM130. This startup file SF1 is referred to as the "first startup file SF1". If the first startup file SF1 is deployed at this point, when the verification of the upper compressed file CFa fails in the procedure described later, the OS kernel can be started using the genuine first startup file SF1 pre-stored in ROM130.

[0027] In step S10 of FIG. 4, the expansion program DPM in the ROM area 1 verifies the electronic signature DSa of the upper compressed file CFa loaded into the work area 132 of the RAM 130 in step S03. The public key PK3 stored in the ROM area 1 is used for this verification. In the example of FIG. 2, this public key PK3 is the same as the one used for the verification of the ROM area 2, but they may also be different public keys. If the verification in step S10 is successful, the authenticity of the lower compressed file CFb included in the upper compressed file CFa, that is, the compressed file CFb obtained by compressing the partitions of the entire root file system, is guaranteed.

[0028] In step S11, the expansion program DPM determines whether the verification of the upper compressed file CFa has succeeded. If the verification of the upper compressed file CFa fails, the process proceeds to step S18, where the ROM 120 is specified as the root file system and the OS kernel expanded in the kernel area 131 in step S09 is started. After the OS kernel is started, the application program for the update mode included in the root file system is started. The "update mode" is a processing mode in which the upper compressed file CFa stored in the external memory card 140 is overwritten with another upper compressed file considered to be authentic. Another upper compressed file with an electronic signature is transferred from an external device such as the information processing apparatus 200. After step S18, it is preferable to execute the rewriting of the upper compressed file CFa stored in the external memory card 140 in the update mode.

[0029] If the verification of the upper compressed file CFa is successful, the process proceeds to step S12, where the decompression program DPM reads the upper compressed file CFa from the external memory card 140 and expands the startup file SF2 contained in the upper compressed file CFa to the RAM 130. This startup file SF2 is a file for starting the system with the external memory card 140 as the root file system. This startup file SF2 is called the "second startup file SF2". The second startup file SF2 contains the OS kernel and overwrites the first startup file SF1 that was expanded to the RAM 130 in step S09 described above. If the second startup file SF2 overwrites the first startup file SF1, the OS kernel can be started using the genuine second startup file SF2 contained in the upper compressed file CFa for which the electronic signature verification was successful.

[0030] The first startup file SF1 and the second startup file SF2 may have different functions. For example, the first startup file SF1 may have the function of the update mode and may not have the function as a robot controller. On the other hand, the second startup file SF2 preferably has the function as a robot controller. Also, it is preferable that the first startup file SF1 has a smaller data volume than the second startup file SF2.

[0031] In step S13, the decompression program DPM designates the ROM 120 as the root file system and starts the OS kernel. At this time, it is preferable that the device tree for ROM startup is set using the init= / root command. At this point, since the root file system is designated as the ROM 120, the external memory card 140 is not used as the root file system.

[0032] In step S14, the OS kernel creates a RAM disk 133 and mounts the partition of the root file system of the external memory card 140 as a normal file system. The reason for mounting the partition of the root file system as a normal file system is that in step S13 described above, the ROM 120 is specified as the root file system.

[0033] In step S15, the OS kernel expands the upper compressed file CFa of the external memory card 140 and stores the lower compressed file CFb in the RAM disk 133. In step S16, the OS kernel expands the lower compressed file CFb stored in the RAM disk 133 to the external memory card 140. As a result, as shown in FIG. 2, a root file system is set in the external memory card 140. In step S17, the OS kernel switches the root file system from the ROM 120 to the external memory card 140. Specifically, the root file system is switched using the pivot_root command.

[0034] When the root file system is set in step S17, the application program for the robot control mode is started. The "robot control mode" means a mode in which the controller 100 functions as a robot controller. The description of the subsequent processing is omitted.

[0035] As described above, in the first embodiment, when the verification of the electronic signature for the compressed file CFa loaded in the work area 132 of the RAM 130 is successful, the compressed file CFa is expanded into the external memory card 140 to set up the root file system. Therefore, the authenticity of the entire root file system can be ensured. Also, in the first embodiment, unlike the prior art that verifies individual files, the compressed file CFa including the root file system is verified all at once. Thus, compared with the prior art, the time required for verification can be shortened. Furthermore, in the first embodiment, when the verification of the compressed file CFa is unsuccessful, the ROM 120 is set as the root file system. Therefore, when the verification of the compressed file CFa fails, the controller can be started using the authentic root file system stored in the ROM 120.

[0036] B. Second Embodiment: FIG. 5 is an explanatory diagram of the startup process of the controller 100 in the second embodiment, and FIG. 6 is a flowchart showing the procedure of the startup process. FIG. 5 is a partially modified version of FIG. 2 in the first embodiment, and FIG. 6 is a partially modified version of FIG. 4 in the first embodiment. The process in FIG. 3 is the same as that in the first embodiment, so the description thereof is omitted.

[0037] The second embodiment is different from the first embodiment in the following two points, and is almost the same as the first embodiment in other respects. (1) The point that the RAM disk 133 is not used. (2) The point that steps S14 to S16 in FIG. 4 are replaced by steps S21 to S22 in FIG. 6.

[0038] In step S21 of FIG. 6, the OS kernel mounts the partition of the root file system of the external memory card 140 as a normal file system. In step S22, the OS kernel expands the lower compressed file CFb, i.e., rootfs.squashfs, from the upper compressed file CFa of the external memory card 140 to the folder mounted in step S21. As a result, as shown in FIG. 5, the root file system is set in the external memory card 140. The description of other processes is omitted.

[0039] The second embodiment also has substantially the same effects as the first embodiment. Further, in the second embodiment, since the RAM disk 133 is not used, there is an advantage that memory resources can be saved.

[0040] C. Third Embodiment: FIG. 7 is an explanatory diagram of the startup process of the controller 100 in the third embodiment, and FIG. 8 is a flowchart showing the procedure of the startup process of the controller 100 in the third embodiment. FIG. 7 is a partially modified version of FIG. 5 of the second embodiment, and FIG. 8 is a partially modified version of FIG. 6 of the second embodiment. Since the processing in FIG. 3 is the same as that in the first and second embodiments, the description is omitted.

[0041] The third embodiment differs from the second embodiment only in the following one point, and is substantially the same as the second embodiment otherwise. (1) The point that step S22 in FIG. 6 is replaced by steps S31 - S32 in FIG. 8.

[0042] In step S31 of FIG. 8, the OS kernel expands the upper compressed file CFa of the external memory card 140 and stores the lower compressed file CFb in the folder mounted in step S21. In this process, the lower compressed file CFb is written to the external memory card 140. In step S32, the OS kernel expands the lower compressed file CFb in the folder mounted in step S21. Also, in step S32, using the pivot_root command, the root directory where the lower compressed file CFb was stored is moved, and a new root directory for the root file system is set. As a result, as shown in FIG. 7, the root file system is set in the external memory card 140. Explanation of other processes is omitted.

[0043] The third embodiment also has substantially the same effects as the first and second embodiments. However, in the first and second embodiments, there is no process such as step S31 of writing the lower compressed file CFb to the external memory card 140, so the number of write operations to the external memory card 140 can be reduced. Therefore, there is an advantage that the life of the external memory card 140 is not shortened.

[0044] D. Fourth Embodiment: FIG. 9 is an explanatory diagram of the startup process of the controller 100 in the fourth embodiment, and FIG. 10 is a flowchart showing the procedure of the startup process. FIG. 9 is a partially modified version of FIG. 5 of the second embodiment, and FIG. 8 is a partially modified version of FIG. 6 of the second embodiment. The process in FIG. 3 is the same as that in the first and second embodiments, so the explanation is omitted.

[0045] The fourth embodiment differs from the second embodiment only in the following one point, and is otherwise substantially the same as the second embodiment. (1) The point that step S22 in FIG. 6 is replaced by steps S41 - S42 in FIG. 10.

[0046] In step S41 of FIG. 10, the OS kernel expands the upper compressed file CFa of the external memory card 140 and stores the lower compressed file CFb in the file system of the external memory card 140. As a result, as shown in FIG. 9, the lower compressed file CFb is stored in the same file system as the upper compressed file CFa. In step S42, the OS kernel expands the lower compressed file CFb in the folder mounted in step S21. Also, in step S42, using the pivot_root command, the root directory where the lower compressed file CFb was stored is moved, and a process of setting a new root directory for the root file system is executed. As a result, as shown in FIG. 9, a root file system is set in the external memory card 140. The description of other processes is omitted.

[0047] The fourth embodiment also has substantially the same effects as those of the third embodiment described above.

[0048] · Other forms: The present disclosure is not limited to the above-described embodiments, and can be implemented in various forms without departing from the gist thereof. For example, the present disclosure can also be implemented by the following aspects. The technical features in the above embodiments corresponding to the technical features in each of the following aspects can be appropriately replaced or combined in order to solve part or all of the problems of the present disclosure or to achieve part or all of the effects of the present disclosure. Also, if the technical feature is not described as essential in this specification, it can be appropriately deleted.

[0049] (1) According to the first aspect of the present disclosure, a method for setting a computer's root file system is provided. This method includes: (a) reading a compressed file obtained by compressing the entire partition of the root file system and an electronic signature of the compressed file from an external storage device and loading them into a work area of the computer's RAM; (b) performing verification of the electronic signature for the compressed file loaded into the work area; and (c) when the verification is successful, setting the root file system by decompressing the compressed file in the external storage device. According to this method, the authenticity can be ensured by verifying the signature of the entire root file system.

[0050] (2) The above method may further include: (d) when the verification is unsuccessful, setting the computer's ROM as the root file system. According to this method, when the verification of the compressed file fails, the genuine root file system stored in the ROM can be used.

[0051] (3) In the above method, the step (a) may include reading a first startup file including an OS kernel from the ROM and decompressing it into the kernel area of the RAM. According to this method, when the verification of the compressed file fails, the OS kernel can be started using the first startup file stored in the ROM.

[0052] (4) In the above method, the compressed file is compressed to include a second startup file including the OS kernel, and the step (c) may include reading the compressed file from the external storage device, decompressing the second startup file, and overwriting the first startup file in the kernel area. According to this method, when the verification of the compressed file is successful, the OS kernel can be started using the second startup file included in the compressed file.

[0053] (5) According to a second aspect of the present disclosure, there is provided a computer program that executes a process of setting a root file system of a computer. This computer program causes the computer to execute: (a) a process of reading, from an external storage device, a compressed file obtained by compressing the entire partition of the root file system and an electronic signature of the compressed file and loading them into a work area of the RAM of the computer; (b) a process of verifying the electronic signature for the compressed file loaded into the work area; and (c) a process of setting the root file system by expanding the compressed file into the external storage device when the verification is successful.

[0054] The present disclosure can also be realized in various other forms. For example, it can be realized in the form of a computer program for realizing the function of a controller, a non-transitory storage medium recording the computer program, and the like.

Description of Reference Numerals

[0055] 100... Controller, 110... CPU, 120... ROM, 121... First Boot Loader Area, 122... Second Boot Loader Area, 123... First ROM Area, 124... Second ROM Area, 130... RAM, 131... Kernel Area, 132... Work Area, 133... RAM Disk, 140... External Memory Card, 200... Information Processing Device, 300... Robot Body, 400... Robot System

Claims

1. A method for setting a root file system of a computer, comprising: (a) reading a compressed file obtained by compressing the entire partition of the root file system and an electronic signature of the compressed file from an external storage device and loading them into a work area of the computer's RAM; (b) performing verification of the electronic signature for the compressed file loaded into the work area; (c) when the verification is successful, setting the root file system by expanding the compressed file in the external storage device; A method including the above steps.

2. The method according to claim 1, further comprising: (d) when the verification is unsuccessful, setting the computer's ROM as the root file system.

3. The method according to claim 2, wherein step (a) includes reading a first startup file including an OS kernel from the ROM and expanding it into the kernel area of the RAM.

4. The method according to claim 3, wherein the compressed file is compressed to include a second startup file including the OS kernel, and step (c) includes reading the compressed file from the external storage device, expanding the second startup file, and overwriting the first startup file in the kernel area.

5. A computer program for executing a process of setting a root file system of a computer, the computer program causing the computer to perform: (a) a process of reading a compressed file obtained by compressing the entire partition of the root file system and an electronic signature of the compressed file from an external storage device and loading them into a work area of the computer's RAM; (b) a process of performing verification of the electronic signature for the compressed file loaded into the work area; (c) a process of setting the root file system by expanding the compressed file in the external storage device when the verification is successful; A computer program.

Images