A method and apparatus for starting an electronic device

Abstract

A starting method and device of an electronic device, relating to the electronic technical field, can form multiple sub-file systems by partitioning files of a file system, and sign each sub-file system as a whole, thereby improving the file signing efficiency when the electronic device starts, specifically: after the electronic device loads a starting program, one or more sub-file systems in the file system are signed, wherein each sub-file system includes multiple files, and each sub-file system includes a first signature file. A starting process for an electronic device.

Description

Technical Field

[0001] This application relates to the field of electronic technology, and more particularly to a method and apparatus for starting an electronic device. Background Technology

[0002] With the increasing prevalence of intelligent technology, many traditional electronic devices are embedding increasingly complex and massive software systems. The reliable and secure startup of these software systems is crucial for the normal startup and operation of electronic devices, and in some critical areas (such as autonomous driving), it can even impact the safety of life and property.

[0003] Typically, complex software systems consist of firmware files and file system data. Currently, when electronic devices boot up, critical files within the file system are verified and loaded one by one, resulting in low efficiency for file verification during boot. Summary of the Invention

[0004] This application provides a boot method and device for an electronic device, which can partition the files of the file system to form multiple sub-file systems and perform overall verification of each sub-file system, thereby improving the efficiency of file verification during the boot of the electronic device.

[0005] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0006] In a first aspect, embodiments of this application provide a booting method. The method includes: an electronic device loading a boot program; and verifying one or more sub-file systems within a signature file system. Each sub-file system includes multiple files, and each sub-file system includes a first signature file.

[0007] In the method of this application, multiple files in each sub-file system can be fully verified using a first signature file in each sub-file system. This allows the electronic device to improve file verification efficiency during startup by performing a full verification of each sub-file system.

[0008] In conjunction with the first aspect, in one possible design, the file system includes a first region, which includes one or more partitions, each partition corresponding to a sub-file system.

[0009] In this scheme, the electronic device performs whole-system signing on the corresponding sub-file system stored in each partition by setting one or more partitions in the first area of ​​the file system.

[0010] In conjunction with the first aspect, in another possible design, the electronic device also includes a second region. The first region is a read-only region, and the second region is a read-write region.

[0011] In conjunction with the first aspect, in another possible design, one or more sub-file systems in the electronic device signature verification file system include: generating a second signature file for each of the one or more sub-file systems in the file system; and comparing the first signature file with the second signature file of each sub-file system to perform signature verification.

[0012] In other words, the signature verification process in this application involves comparing the first signature file attached to each sub-file system with the generated second signature file. If the first signature file matches the second signature file, the signature verification is successful; if the first signature file does not match the second signature file, the signature verification fails.

[0013] In conjunction with the first aspect, in another possible design, prior to the electronic device verifying one or more partitioned file systems in the first area, the method further includes: verifying firmware files.

[0014] Here, after the firmware file is verified, the electronic device verifies one or more partition file systems in the first area.

[0015] In conjunction with the first aspect, in another possible design, each sub-file system includes a first signature file, which is appended to the end of each sub-file system.

[0016] Here, the first signature file is appended to the end of the sub-file system, which is compatible with existing file system formats that do not allow appending the first signature file to the beginning of the sub-file system. Furthermore, since the sub-file system and the first signature file are stored together, the distribution, management, and verification processes of the signature file are effectively simplified.

[0017] In conjunction with the first aspect, in another possible design, the partitions include the partition corresponding to the root file system.

[0018] Here, since the root file system is the first file system mounted when the kernel starts, the partitions set in this application include the partitions corresponding to the root file system.

[0019] Secondly, embodiments of this application provide an electronic device. The electronic device includes a memory and one or more processors, the memory and processors being coupled; the memory stores computer program code, the computer program code including computer instructions, which, when executed by the processor, cause the electronic device to perform: loading a startup program; verifying one or more sub-file systems in a signature file system, wherein each sub-file system includes multiple files, and each sub-file system includes a first signature file.

[0020] In conjunction with the second aspect, in another possible design, the file system includes a first region, which includes one or more partitions, each partition corresponding to a sub-file system.

[0021] In conjunction with the second aspect, in another possible design, the electronic device also includes a second region. The first region is a read-only region, and the second region is a read-write region.

[0022] In conjunction with the second aspect, in another possible design, the signature verification of one or more sub-file systems in the file system includes: generating a second signature file for each of the one or more sub-file systems in the file system; and comparing the first signature file with the second signature file of each sub-file system to perform signature verification.

[0023] In conjunction with the second aspect, in another possible design, the electronic device also performs signature verification of firmware files before verifying one or more partition file systems in the first signature area.

[0024] In conjunction with the second aspect, in another possible design, each sub-file system includes a first signature file, which is appended to the end of each sub-file system.

[0025] In conjunction with the second aspect, in another possible design, the partitions include the partition corresponding to the root file system.

[0026] Thirdly, embodiments of this application provide a chip system. The chip system includes one or more interface circuits and one or more processors. The interface circuits and processors are interconnected via lines. The interface circuits are used to receive signals from the memory of an electronic device and to send signals to the processors. The signals include computer instructions stored in the memory. When the processor executes the computer instructions, the electronic device performs the method described in the first aspect and any of its possible design embodiments.

[0027] Fourthly, embodiments of this application provide a computer storage medium including computer instructions. When the computer instructions are executed on an electronic device, they cause the electronic device to perform the method described in the first aspect and any of its possible design embodiments.

[0028] Fifthly, embodiments of this application provide a computer program product. When the computer program product is run on a computer, it causes the computer to perform the method described in the first aspect and any possible design configuration thereof. Attached Figure Description

[0029] Figure 1 A schematic diagram of a startup method for an electronic device provided by the prior art;

[0030] Figure 2A structural diagram of an electronic device provided in an embodiment of this application;

[0031] Figure 3 This is a schematic diagram of the startup process of a chip system provided in an embodiment of this application;

[0032] Figure 4 A flowchart for startup verification is provided as an embodiment of this application;

[0033] Figure 5 A flowchart illustrating a startup method for an electronic device provided in an embodiment of this application;

[0034] Figure 6 A schematic diagram illustrating a startup method for an electronic device provided in an embodiment of this application;

[0035] Figure 7 A schematic diagram illustrating a partitioning method provided in an embodiment of this application;

[0036] Figure 8 This is a structural diagram of another electronic device provided in an embodiment of this application. Detailed Implementation

[0037] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; "and / or" in this text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0038] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "a plurality of" means two or more.

[0039] Currently, when electronic devices boot up, they verify and load critical files within the file system one by one. For example... Figure 1As shown, only critical files within the file system, i.e., the signed files, are verified and loaded. Unsigned files can be considered non-critical files within the file system, and verification and loading of unsigned files are not required. Each signed file corresponds to a signature file, which includes the signature information of the corresponding signed file. In existing technologies, signed files and signature files are stored separately. Furthermore, a mapping file describes the relationship between the signed files and the signature files; for example, this mapping file indicates the correspondence between each signed file and the signature file. This mapping file may also require verification.

[0040] exist Figure 1 The described scheme, during electronic device startup, suffers from several drawbacks. Firstly, because it only verifies and loads critical files within the file system, not all files, the verification process is incomplete. Secondly, verifying and loading critical files one by one results in low efficiency. Furthermore, due to… Figure 1 In this scheme, the signature file and the signed file are stored separately, making the distribution and management of the signature file more complex.

[0041] This application provides a method for booting an electronic device. It can partition the files of a file system to form multiple sub-file systems, and perform overall signing on each sub-file system, thereby improving the efficiency of file signing during electronic device boot and ensuring that no files are missed during signing. Furthermore, in this embodiment, the signed file is jointly stored with the sub-file systems of the file system, i.e., the signed file and the signed file are unified, thereby simplifying the distribution, management, and signing process of the signed file.

[0042] For example, the electronic device in this application embodiment can be a mobile phone, tablet computer, wearable device (e.g., smartwatch), in-vehicle device, augmented reality (AR) / virtual reality (VR) device, laptop computer, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc. The electronic device can also be a V2X device, such as a smart car, digital car, unmanned car, driverless car, pilotless car, or automobile, self-driving car, battery EV, hybrid electric vehicle (HEV), range-extended electric vehicle (REEV), plug-in hybrid electric vehicle (PHEV), new energy vehicle, or roadside unit (RSU). The electronic device can also be a B2C device or a B2B device, etc. This application embodiment does not limit this.

[0043] For example, Figure 2 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application is shown. The electronic device 200 includes a processor 201, a communication line 202, a memory 203, and at least one communication interface. Figure 2 (The following is merely an example illustrating the concept of including communication interface 204).

[0044] The processor 201 may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits used to control the execution of the program of the present application.

[0045] Communication line 202 may include a path for transmitting information between the aforementioned components.

[0046] Communication interface 204 uses any transceiver-like device for communicating with other devices or communication networks, such as Ethernet, radio access network (RAN), wireless local area networks (WLAN), etc.

[0047] The memory 203 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital versatile optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. The memory may exist independently and be connected to the processor via communication line 202. The memory may also be integrated with the processor.

[0048] The memory 203 stores computer execution instructions for implementing the scheme of this application, and its execution is controlled by the processor 201. The processor 201 executes the computer execution instructions stored in the memory 203, thereby implementing the startup method provided in the following embodiments of this application.

[0049] Optionally, the computer execution instructions in the embodiments of this application may also be referred to as application code, and the embodiments of this application do not specifically limit this.

[0050] In a specific implementation, as one embodiment, the processor 201 may include one or more CPUs, for example... Figure 2 CPU0 and CPU1 in the CPU.

[0051] In a specific implementation, as one example, the electronic device 200 may include multiple processors, such as... Figure 2 Processors 201 and 208 are mentioned. Each of these processors can be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor. A processor here can refer to one or more devices, circuits, and / or processing cores used to process data (e.g., computer program instructions).

[0052] In a specific implementation, as one embodiment, the electronic device 200 may further include an output device 205 and an input device 206. The output device 205 communicates with the processor 201 and can display information in various ways. For example, the output device 205 may be a liquid crystal display (LCD), a light-emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector, etc. The input device 206 communicates with the processor 201 and can receive user input in various ways. For example, the input device 206 may be a mouse, keyboard, touchscreen device, or sensing device, etc.

[0053] The embodiments of this application can be applied to the startup scenario of a chip system. Taking the Hi1951 chip embedded in an electronic device as an example, such as... Figure 3 As shown, the startup process of the chip system includes multiple startup verification steps, the specific process of which is as follows:

[0054] First, after the electronic device is powered on or restarted, the startup program performs a startup verification on the first firmware file.

[0055] The startup program can be built into the chip.

[0056] In some embodiments, the bootloader may be BootROM secure boot code (BSBC).

[0057] Taking BSBC as the bootloader as an example, the bootloader performs boot verification on the first firmware file, including: BSBC performs boot verification on hboot1-a, then hboot1-a performs boot verification on hboot1-b. The completion of the boot verification by hboot1-b indicates that the bootloader has completed the boot verification of the first firmware file. The first firmware file includes hboot1-a and hboot1-b.

[0058] Next, the first firmware file performs a boot verification on the second firmware file.

[0059] Taking hboot2 as an example, the first firmware file performs boot verification on the second firmware file, including: hboot1-b performs boot verification on hboot2.

[0060] Next, hboot2 performs boot verification on the kernel and files in the file system. This ultimately enables the electronic device to boot.

[0061] It is understood that, depending on the business content, hboot1-a and hboot1-b can also start and verify other firmware during the startup process of electronic devices, such as Hilink firmware, high security manager (HSM) firmware, safety firmware, low power manager (LPM) firmware, etc. This application embodiment does not limit the type and number of other firmware that hboot1-a and hboot1-b start and verify.

[0062] Each of the aforementioned startup verification processes runs on the corresponding CPU. For example, the BSBC startup verification of the first firmware file runs on the CPU responsible for booting, such as CPU R52, while the startup verification of the second firmware file by the first firmware file runs on the main control CPU, such as CPU TaiShan.

[0063] In the embodiments of this application, each startup verification process is as follows: Figure 4 As shown, the startup verification process includes file decryption, file verification, file measurement, and file execution. The file can be a single file or a file system composed of multiple files. (Participate...) Figure 4 The verification process is as follows:

[0064] After the startup program is loaded, the chip system begins to boot (step 401).

[0065] First, the chip system determines whether the file is encrypted based on the file encryption flag (step 402). If it is an encrypted file, the chip system decrypts the encrypted file using the image encryption key (step 403); if it is not an encrypted file, it proceeds directly to step 404.

[0066] In step 404, the chip system determines whether to perform a secure boot based on the secure boot flag. If a secure boot is performed, the chip system performs file verification, i.e., verifies the signature of the file (step 405); if a secure boot is not performed, it proceeds directly to step 406.

[0067] In step 406, the chip system determines whether to perform trusted boot based on the trusted boot flag. If trusted boot is performed, the chip system performs file measurement (step 407) and then runs the file (step 408); if trusted boot is not performed, the chip system runs the file directly (step 408).

[0068] In some embodiments, the file encryption flag, file encryption key, secure boot flag, and trusted boot flag can all be controlled by a one-time electrically programmable FUSE (eFUSE).

[0069] The startup process of the chip system has been described above. The following section uses a mobile data center (MDC) product based on the Hi1951 chip as an example to describe in detail the startup method of the electronic device provided in this application embodiment. Figure 5 As shown, the method includes:

[0070] 501. Electronic device is powered on or restarted.

[0071] The starting point of the electronic device startup method provided in this application embodiment is that the electronic device is powered on or restarted.

[0072] Figure 6 This is a schematic diagram illustrating the startup method provided in an embodiment of this application. Figure 6 As illustrated, exemplarily, powering on an electronic device includes: initially, the microcontroller unit (MCU) in the electronic device powers on the Hi1951 chip via a complex programmable logic device (CPLD). After the chip is powered on, the electronic device can load and run the startup program, thereby completing the startup process.

[0073] In some embodiments, if the electronic device restarts, the chip can be powered on through a process similar to powering on the electronic device.

[0074] 502. Start the program to verify signature and load the first firmware file.

[0075] After the Hi1951 chip is powered on, the electronic device can load and run the chip's built-in boot program (such as BSBC), and the boot program will verify the signature and load the first firmware file.

[0076] The first firmware file is used to start and verify the second firmware file.

[0077] In some embodiments, such as Figure 6 As shown, the first firmware file is xLoader. xLoader can be stored on Norflash memory.

[0078] In other embodiments, xLoader may also be stored on other types of memory.

[0079] In some embodiments, when the boot program verifies the signature and loads the first firmware file, it can also verify the signature of other firmware files, such as the secondary public key stored on Norflash.

[0080] In the embodiments of this application, this step is run in the CPU responsible for booting, for example, this step can run on CPUR52.

[0081] 503. Verify the signature of the first firmware file and load the second firmware file.

[0082] After the first firmware file is loaded and run, it can verify the signature and load the second firmware file. The second firmware file is used to boot and verify the kernel and / or file system.

[0083] In some embodiments, such as Figure 6 As shown, the second firmware file is the Unified Extensible Firmware Interface (UEFI). UEFI can also be stored on Norflash.

[0084] In other embodiments, UEFI may also be stored on other types of memory.

[0085] In the embodiments of this application, UEFI is typically loaded onto the main control CPU to run. For example, UEFI can be loaded onto CPU TaiShan to run.

[0086] 504. Subfile system in the read-only area of ​​the second firmware file verification signature.

[0087] After the second firmware file (e.g., UEFI) is loaded and running, the second firmware file can verify the sub-file system of the read-only area.

[0088] The read-only area may include one or more sub-file systems, each sub-file system containing multiple files, and each sub-file system including a first signature file. Here, the first signature file is preset. For example, the first signature file may be added by a signature center before the electronic device leaves the factory. This application embodiment does not limit the specific signing method.

[0089] In some embodiments, the structure of universal flash storage (UFS) in MDC can be as follows: Figure 7 As shown in (a) above. See also Figure 7In (a) of this diagram, UFS can be divided into multiple regions, including a raw data storage region and a file system storage region. The raw data storage region can be used to store the kernel, device tree binary files (dtb), partial public keys, and signature files for files in non-read-only regions. The file system storage region is used to store files and data within the file system. This file system storage region can include read-only regions and read-write regions. Read-only regions store files or data that can only be read and are generally not modifiable. In other words, read-only regions typically store files or data that are unlikely to change during system operation. Read-write regions store data that can be modified at any time; that is, read-write regions typically store files or data that may change during the startup and operation of an electronic device.

[0090] In this embodiment, the read-only area can be divided into multiple partitions. These partitions must include the partition corresponding to the root file system; other partitions can be configured by the user or technical personnel according to business needs. This is because the root file system is the first file system mounted during kernel startup; only after the root file system starts can signature verification, loading, and execution of other files continue.

[0091] For example, such as Figure 7 As shown in (a), the read-only area can include three partitions, corresponding to the root file system, application file system, and custom file system, respectively. The application file system includes files or data related to certain applications. For example, for electronic devices related to autonomous driving, the application file system includes files and data related to autonomous driving applications. The custom file system includes files or data from other user-selected or customized applications.

[0092] Optionally, the read-write area can be divided into multiple partitions. For example, for electronic devices related to autonomous driving, the read-write area may include two partitions, corresponding to a map file system and another read-write file system, respectively. The other read-write sub-file systems may include files or data other than map data, such as user data and log data.

[0093] Optionally, the UFS can be partitioned before the MDC leaves the factory according to business needs. Then, when the electronic device starts up, if data or files are detected that meet certain characteristics, the data or files will be stored in the corresponding partition. For example, if the electronic device detects that the data or file is read-only and that the data or file is related to the application's business, it can store the data or file in the partition corresponding to the application's file system in the read-only area.

[0094] Alternatively, an additional partition corresponding to the root file system can be set in UFS, denoted as root file system B. The files in root file system B are the same as those in the original root file system (denoted as root file system A), thereby further ensuring the normal startup of electronic devices.

[0095] In this embodiment of the application, each sub-file system in the read-only region includes a first signature file representation, and each sub-file system in the read-only region is appended with the first signature file corresponding to that sub-file system. Figure 7 (b) shows a sub-filesystem with signed files. For example... Figure 7 As shown in (b), a first signature file corresponding to the sub-file system is appended to the end of the sub-file system. The sub-file system may include tags and data; the tags facilitate data retrieval. The first signature file includes signature information and an index; the index allows for easy retrieval of the signature information.

[0096] Because a corresponding first signature file is appended to the end of each sub-file system, the size of the partition corresponding to that sub-file system is larger than the size of the sub-file system itself. Typically, the header of a sub-file system stores file system format information (e.g., file allocation table (FAT), file directory table (FDT), global descriptor table (GDT), or partition size information). By appending a corresponding first signature file to the end of each sub-file system, compatibility with existing file system formats that cannot append a corresponding first signature file to the header of the sub-file system is ensured, thus avoiding corruption of the information stored in the file system format header.

[0097] Furthermore, while ensuring file system format compatibility, it also unifies the signing file and the signed file. In other words, the signing file can be stored jointly with the sub-file system (the signed file). This effectively improves usability and simplifies the process of distributing, managing, and verifying signed files.

[0098] In this embodiment, the sub-file system of the signature verification read-only area includes: generating a second signature file based on the data in the sub-file system, and comparing the second signature file with a first signature file appended to the end of the sub-file system. If the first signature file matches the second signature file, the signature verification is successful. If the first signature file does not match the second signature file, the signature verification is unsuccessful.

[0099] In some embodiments, after the second firmware file (e.g., UEFI) is loaded and run, the second firmware file can first verify the signature and load the trusted execution environment operating system (TEEOS), and then sequentially verify the signature and load the MDC dtb and MDC kernel stored in the original data storage area. The MDC kernel then further loads the root file system in the read-only area. Here, the MDC dtb is the device tree binary file of the MDC, used to describe information about the electronic device.

[0100] It should be noted that a Trusted Execution Environment (TEE) is a type of authorized security software that provides a secure execution environment, ensuring end-to-end security through the implementation of protection, confidentiality, integrity, and data access permissions. A TEE can be considered a secure area residing within the main processor of an electronic device, where various sensitive data are ensured to be stored, processed, and protected in a trusted environment. Therefore, in this embodiment, loading a TEE via signature verification ensures that the electronic device's boot process occurs within a secure and trusted environment.

[0101] In other embodiments, after the second firmware file (e.g., UEFI) is loaded and running, it can verify the root file system of the read-only region. After the root file system is verified, multiple underlying processes can be loaded, such as Identity and Access Management (IAM), Process Management (ProcMgr), and System Service (SS). Subsequently, specific files within the root file system (e.g., FileMgr) further verify the application file system and custom file systems.

[0102] It should be noted that since the amount of data in the file system is usually large, and the root file system, application file system and custom file system are all stored in the read-only area of ​​UFS, when verifying the application file system and custom file system with specific files in the root file system, it is not necessary to load them, that is, it is not necessary to read out the sub-file system in the read-only area to run.

[0103] It should also be noted that once the program file system is verified and mounted, the electronic device can initiate data plane and non-data plane processes that match the current system state, thereby completing the boot process of the electronic device.

[0104] 505. Verify the signature of the business files in the application file system and load the corresponding data or files in the read / write area.

[0105] The application file system includes multiple business files corresponding to various applications. These business files can be used to verify signatures and load corresponding data or files from the read / write area.

[0106] For example, if the business file is a map file, the map file is used for signature verification and the map data stored in the regional file system in the read-write zone is loaded. If the business file is a protected file, the protected file is used for signature verification and the user data stored in other read-write file systems in the read-write zone is loaded.

[0107] As described above, during the boot process of an electronic device, since read-only areas typically store files or data that are unlikely to change, full partition signature verification can be performed on the sub-file systems within the read-only area. This eliminates the need to verify each file individually within the read-only area, thus improving verification efficiency and speed. Furthermore, full partition signature verification allows for the verification of every file within the read-only area, enhancing verification completeness and preventing file omissions.

[0108] Furthermore, the above-mentioned multi-layered verification process ensures that there are no unsafe steps during the startup of electronic devices, thereby effectively improving the security of the startup process.

[0109] It is understood that, in order to achieve the above functions, the electronic device includes hardware and / or software modules that perform the respective functions. Based on the algorithmic steps of the examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is implemented in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application in conjunction with the embodiments, but such implementation should not be considered beyond the scope of this application.

[0110] This embodiment can divide the electronic device into functional modules according to the above method example. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing module. The integrated modules can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0111] For example, Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 8 As shown, this application provides an electronic device 800, including a startup unit 801, a signature verification unit 802, and a loading unit 803.

[0112] The startup unit 801 is used to power on or restart the electronic device.

[0113] The signature verification unit 802 is used to enable the startup program to verify the signature of the first firmware file, enable the first firmware file to verify the signature of the second firmware file, enable the second firmware file to verify the signature of the sub-file system in the read-only area, and enable the business files in the application file system to verify the signature of the corresponding data or files in the read-write area.

[0114] The loading unit 803 is used to enable the startup program to load the first firmware file, enable the first firmware file to load the second firmware file, and enable the business files in the application file system to load the corresponding data or files in the read / write area.

[0115] Embodiments of this application also provide a computer-readable storage medium storing a computer program. When the computer program is run on an electronic device, it causes the electronic device to execute the aforementioned method steps to implement the electronic device startup method in the above embodiments.

[0116] This application also provides a computer program product that, when run on an electronic device, causes the electronic device to perform the aforementioned related steps to implement the electronic device startup method executed by the electronic device in the above embodiments.

[0117] In addition, this application also provides an apparatus, which may specifically be a chip, component or module. The apparatus may include a connected processor and a memory. The memory is used to store computer execution instructions. When the apparatus is running, the processor may execute the computer execution instructions stored in the memory to cause the chip to execute the electronic device startup method executed by the electronic device in the above method embodiments.

[0118] The electronic devices, computer-readable storage media, computer program products, or chips provided in the embodiments of this application are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to in the beneficial effects of the corresponding methods provided above. Further details are omitted here.

[0119] From the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, the division of the above functional modules is only used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0120] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.

[0121] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0122] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0123] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially or in other words, the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0124] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A startup method, applied to an electronic device, characterized in that, The method includes: Load the startup program; One or more sub-file systems in the signature verification file system, wherein each sub-file system includes multiple files, and each sub-file system includes a first signature file; Each of the sub-file systems includes a first signature file, which is appended to the end of each of the sub-file systems.

2. The method according to claim 1, characterized in that, The file system includes a first region, which includes one or more partitions, and each partition corresponds to a sub-file system.

3. The method according to claim 1 or 2, characterized in that, The electronic device also includes a second region; The first region is a read-only region, and the second region is a read-write region.

4. The method according to claim 1 or 2, characterized in that, One or more sub-file systems in the signature verification file system include: Generate a second signature file for each of one or more sub-file systems in the file system; The first signature file and the second signature file of each sub-file system are compared to verify the signature.

5. The method according to claim 1 or 2, characterized in that, Prior to one or more partition file systems in the first verification zone, the method further includes: Verify the firmware file.

6. The method according to claim 1, characterized in that, The partitions include those corresponding to the root file system.

7. An electronic device, characterized in that, The electronic device includes a memory and one or more processors; the memory and the processors are coupled; the memory stores computer program code, which includes computer instructions that, when executed by the processor, cause the electronic device to perform: Load the startup program; One or more sub-file systems in the signature verification file system, wherein each sub-file system includes multiple files, and each sub-file system includes a first signature file; Each of the sub-file systems includes a first signature file, which is appended to the end of each of the sub-file systems.

8. The electronic device according to claim 7, characterized in that, The file system includes a first region, which includes one or more partitions, and each partition corresponds to a sub-file system.

9. The electronic device according to claim 7, characterized in that, The electronic device also includes a second region; The first region is a read-only region, and the second region is a read-write region.

10. The electronic device according to claim 7 or 8, characterized in that, One or more sub-file systems in the signature verification file system include: Generate a second signature file for each of one or more sub-file systems in the file system; The first signature file and the second signature file of each sub-file system are compared to verify the signature.

11. The electronic device according to claim 7 or 8, characterized in that, Prior to one or more partition file systems in the first verification area, the electronic device also performs: Verify the firmware file.

12. The electronic device according to claim 7, characterized in that, The partitions include those corresponding to the root file system.

13. A chip system, characterized in that, The chip system includes one or more interface circuits and one or more processors; the interface circuits and the processors are interconnected via lines; the interface circuits are used to receive signals from the memory of the electronic device and send the signals to the processors, the signals including computer instructions stored in the memory; when the processor executes the computer instructions, the electronic device performs the method as described in any one of claims 1-6.

14. A computer storage medium comprising computer instructions, characterized in that, When the computer instructions are executed on the electronic device, the electronic device causes the electronic device to perform the method as described in any one of claims 1-6.

15. A computer program product, characterized in that, When the computer program product is run on a computer, it causes the computer to perform the method as described in any one of claims 1-6.

Images