[go: up one dir, main page]

CN113553115B - Starting method based on heterogeneous multi-core chip and storage medium - Google Patents

Starting method based on heterogeneous multi-core chip and storage medium Download PDF

Info

Publication number
CN113553115B
CN113553115B CN202010326901.5A CN202010326901A CN113553115B CN 113553115 B CN113553115 B CN 113553115B CN 202010326901 A CN202010326901 A CN 202010326901A CN 113553115 B CN113553115 B CN 113553115B
Authority
CN
China
Prior art keywords
verified
file
content
core
merck tree
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202010326901.5A
Other languages
Chinese (zh)
Other versions
CN113553115A (en
Inventor
张金伟
董宗祥
牛建龙
李占坤
倪戎超
李明
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
SAIC General Motors Corp Ltd
Pan Asia Technical Automotive Center Co Ltd
Original Assignee
SAIC General Motors Corp Ltd
Pan Asia Technical Automotive Center Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by SAIC General Motors Corp Ltd, Pan Asia Technical Automotive Center Co Ltd filed Critical SAIC General Motors Corp Ltd
Priority to CN202010326901.5A priority Critical patent/CN113553115B/en
Publication of CN113553115A publication Critical patent/CN113553115A/en
Application granted granted Critical
Publication of CN113553115B publication Critical patent/CN113553115B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/445Program loading or initiating
    • G06F9/44505Configuring for program initiating, e.g. using registry, configuration files
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1446Point-in-time backing up or restoration of persistent data
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00Digital computers in general; Data processing equipment in general
    • G06F15/16Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G06F15/177Initialisation or configuration control
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/4401Bootstrapping

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Computer Security & Cryptography (AREA)
  • Stored Programmes (AREA)

Abstract

The application relates to a starting method based on heterogeneous multi-core chips, which comprises the following steps: bootRom is selected as a trusted root, and the boot module is verified through BootRom verification; and if the starting guide module passes the verification, selecting a core to be started in the heterogeneous multi-core chip according to the preset configuration.

Description

Starting method based on heterogeneous multi-core chip and storage medium
Technical Field
The invention relates to the field of embedded systems, in particular to a starting method based on heterogeneous multi-core chips and a computer readable storage medium.
Background
The development of technologies such as the internet of things and artificial intelligence has put more demands on embedded systems, and in some application occasions, the embedded systems are required to have higher real-time performance and stronger data processing capability. For example, in the automotive electronics field, the gateway needs to support the traditional CAN and LIN communications, so that a real-time operating system needs to be operated to achieve the purposes of fast response and avoiding frame loss of communications. Meanwhile, in order to support the functions of FOTA, big data, intrusion detection, etc., a processing core with a higher performance is required to run a more complex operating system. Therefore, the diversification needs in practice promote chip manufacturers to integrate a plurality of processing cores with different architectures in the embedded chip, so as to satisfy the abundant application scenarios.
Disclosure of Invention
The invention provides a system safety starting scheme based on heterogeneous multi-core chips. Specifically:
According to an aspect of the present invention, there is provided a heterogeneous multi-core chip-based starting method, including the steps of: selecting a BootROM as a trusted root, and checking a starting guide module through the BootROM; and if the starting guide module passes the verification, selecting a core to be started in the heterogeneous multi-core chip and the corresponding content to be verified according to the preset configuration.
Optionally, in some embodiments of the present invention, if the core to be started is selected as the controller core, the content to be verified includes a calibration file and an APP file, and the method further includes: and checking the calibration file and the APP file through the starting guide module, and releasing the controller core if the calibration is passed.
Optionally, in some embodiments of the present invention, if the core to be started is selected as a processor core, the content to be verified includes a uboot program, an environment variable, a kernel, a system service, a startup script, and an application program, and the method further includes: checking the uboot program through the starting guide module, and releasing the processor core if the checking is passed; executing the uboot program through the processor core, and checking the environment variable and the kernel in the uboot program; if the kernel passes the verification, copying the kernel into a file system and verifying system service and a starting script of the file system; and if the system service and the starting script pass the verification, executing the application program, and utilizing the starting guide module to verify the application program.
Optionally, in some embodiments of the present invention, if the size of the content to be verified is smaller than a predetermined value, the content to be verified includes a plurality of backups to form a set to be verified together, and the method further includes: if one item in the set to be verified does not pass the verification, recording the item, and utilizing the rest items in the set to be verified to carry out the verification: if all items in the set to be verified do not pass the verification, the verification of the content to be verified fails; and if any item in the set to be verified passes the verification, the content to be verified is successfully verified, and the recorded item is replaced by the verified item.
Optionally, in some embodiments of the present invention, if the size of the content to be verified is greater than or equal to a predetermined value, the content to be verified includes a backup file, and the method further includes: verifying the content to be verified by determining whether a merck tree set is legal, wherein the merck tree set comprises a master file merck tree and a backup file merck tree generated in the following way: dividing the content to be checked into a plurality of small files according to a preset rule and calculating a hash value for each small file to construct the master file merck tree; and dividing the backup file into a plurality of small files according to the preset rule and calculating a hash value for each small file to construct the backup file merck tree.
Optionally, in some embodiments of the present invention, the merck tree set further includes a plurality of backups of the master file merck tree, a plurality of backups of the backup file merck tree.
Optionally, in some embodiments of the present invention, if any one of the merck tree set is legal, constructing a merck tree of the current content to be verified according to the preset rule; comparing the merck tree of the current content to be verified with each node of any one of the merck tree sets: if each node of the merck tree of the current content to be checked is consistent with each node of any item, the current content to be checked passes the check; or if each node of the merck tree of the current content to be verified has a consistent node in any one of the merck tree sets, combining data blocks corresponding to the consistent nodes to replace the content to be verified, and verifying the replaced content.
Optionally, in some embodiments of the present invention, the start-up guidance module includes a plurality of backups, and the method includes the steps of: configuring a core to be started by the BootROM; and running the start-up boot module and the latest version in the backup thereof through the core.
Optionally, in some embodiments of the present invention, the content to be verified and the backup thereof are verified in the order of version from new to old.
According to another aspect of the present invention there is provided a computer readable storage medium having instructions stored therein, which when executed by a processor, cause the processor to perform any of the methods as described above.
Drawings
The above and other objects and advantages of the present invention will become more fully apparent from the following detailed description taken in conjunction with the accompanying drawings, in which identical or similar elements are designated by the same reference numerals.
FIG. 1 illustrates a heterogeneous multi-core chip based boot method according to one embodiment of the invention.
FIG. 2 illustrates a heterogeneous multi-core chip based boot method according to one embodiment of the invention.
FIG. 3 illustrates a heterogeneous multi-core chip based boot method according to one embodiment of the invention.
FIG. 4 illustrates a heterogeneous multi-core chip based boot method according to one embodiment of the invention.
FIG. 5 illustrates a heterogeneous multi-core chip based boot method according to one embodiment of the invention.
FIG. 6 illustrates a heterogeneous multi-core chip based boot method according to one embodiment of the invention.
FIG. 7 illustrates a heterogeneous multi-core chip based boot method according to one embodiment of the invention.
Detailed Description
Typically, the embedded system starts running from firmware boot in the chip and then jumps to a pre-configured user program address for execution, which configures the system clock, associated peripherals and runs the operating system. However, when the processor has multiple cores and the architecture and running operating system of each core are different, the alternative boot paths become numerous, and how to select the boot files during the boot process directly affects the correct running of the subsequent program.
In addition, as the concept of everything interconnection is becoming deeper, more and more embedded devices start to access to the network, and network security becomes an unavoidable problem. If the start-up procedure is unreliable, the security of the subsequent application is never ever the question. If the start-up scheme is configured by selecting only one trusted root and forming a trusted chain accordingly, the reliability of the selected trusted root is still to be further enhanced.
Finally, during the start-up process, the upper program checks the reliability and integrity of the lower program according to the running sequence of each program on the trusted chain, and if the check fails, the current practice is to give up the start-up, and the result is that if a certain file is destroyed or the file update fails, the normal execution of the system function will be seriously hindered, which will inevitably cause complaints of users. The measures that can be taken are to backup the files, and if one file fails to check, the backup files are automatically started. The problem is that a recovery mechanism after file damage is lacking, when two files are tampered at the same time or one of the two files fails to update, the other file is tampered, the system cannot be started, and how to improve the reliability of the starting process is also a problem to be solved.
In the context of the present application, if the verification is not passed, the boot fails unless otherwise specified. For brevity, some examples of the present application may only describe the flow direction through the verification in the verification process, but one skilled in the art will recognize after reading the present application that the processing should follow the normal process of the start-up failure, unless the present application is otherwise described in some examples.
The invention aims to design a secure starting scheme of an embedded system for heterogeneous multi-core chips so as to safely start the embedded chips with heterogeneous multi-core characteristics, thereby providing a trusted running environment for subsequent programs.
According to an aspect of the present invention, there is provided a heterogeneous multi-core chip-based starting method, as shown in fig. 7, the method including the steps of: selecting a BootROM as a trusted root, and checking a starting guide module through the BootROM; and if the boot module passes the verification, selecting a core to be started in the heterogeneous multi-core chip and the corresponding content to be verified according to the preset configuration.
In some examples of the invention, bootROM can be selected as a trusted root, a trusted chain is established by taking a designed start-up guide module as an intermediary according to the characteristics of heterogeneous multi-core chips, and several schemes for measuring the credibility are provided. The BootROM is a protected storage area inside the chip, and stores codes which are executed first after the chip is powered on, the codes are written in the chip before the chip leaves the factory, and the user cannot modify the chip after the chip leaves the factory, so that the BootROM is used as a safe root and is very reliable. At this point BootROM needs to support verification of the next level of program integrity and authenticity, and some chips (e.g. TC297, S32G) now support this functionality. Typically, these chips also provide a hardware security module to perform encryption and decryption calculations, and for the chip with the hardware security module, the BootROM needs to first verify the firmware of the hardware encryption module, then run the firmware, pass the program of the hardware encryption module or still verify the user program (e.g., start-up boot module) that is executed first by the BootROM.
In some embodiments of the present invention, if the core to be started is selected as the controller core, the content to be verified includes a calibration file and an APP file, and the method further includes: and (3) checking the calibration file and the APP file by starting the guide module, and releasing the controller core if the calibration is passed.
In some examples of the invention, after verification, the boot module is started to execute, and the module selects the core and its corresponding program to be started according to the configuration. If the controller core is needed to run the real-time operating system, the boot module is started to firstly verify the calibration file, then verify the APP file, and verify that the core is released, so that a trusted chain is formed, as shown in figure 1.
In some embodiments of the present invention, if the core to be started is selected as the processor core, the content to be verified includes a uboot program, an environment variable, a kernel, a system service, a startup script, and an application program, and the method further includes: checking the uboot program by starting the guide module, and releasing the processor core if the checking is passed; executing a uboot program through a processor core, and checking environment variables and kernels in the uboot program; if the kernel passes the verification, copying the kernel into a file system and verifying system service and a starting script of the file system; and if the system service and the starting script pass the verification, executing the application program, and verifying the application program by using the starting guide module.
In some examples of the invention, after verification, the boot module is started to execute, and the module selects the core and its corresponding program to be started according to the configuration. If the processor core is needed to run a Linux and other complex operating systems, the boot module is started to check the uboot first, the core is released after the verification is passed, the processor core executes the uboot program, the environment variable and the kernel are verified in the uboot program, the kernel copies into the file system after the verification and checks the system service and the starting script of the file system, after the verification is passed, the application program starts to execute, and meanwhile, the boot module is started to check the application program to be executed, so that a formed trusted chain is shown in fig. 2.
In some examples of the present invention, the verification of the program may be performed by selecting a digital signature, calculating a hash value for the program when the program is downloaded, encrypting the hash value with a private key of the manufacturer, storing the generated digital signature in a nonvolatile memory together with the program, storing a corresponding public key in a write-protected memory in the controller, verifying the signature before starting the program each time, calculating the hash value of the current program after verification, comparing the hash value with the value stored in the memory, and if the hash value is the same, proving that the program is complete and authentic. In addition, some authentication methods, such as HMAC, CMAC, GMAC, AES GCM, etc. may be used to authenticate the next level program, where the key used in the process is stored in the memory of the chip and protected by an encryption algorithm, and the key is decrypted and verified before use, and then the program is authenticated by using the decrypted key.
In some embodiments of the present invention, if the size of the content to be verified is less than a predetermined value (e.g., 50 kB), the content to be verified includes a plurality of backups to form a set to be verified together, the method further comprising: if one item in the set to be verified does not pass the verification, the item is recorded, and the remaining items in the set to be verified are utilized for verification: if all items in the set to be checked do not pass the check, the check of the content to be checked fails; and if any item in the set to be verified passes the verification, the verification of the content to be verified is successful, and the item passing the verification is used for replacing the recorded item.
In some examples of the invention, a mechanism for starting file recovery is designed to cope with the falsification, damage and failure of normal refreshing of the starting file, and the robustness of the starting process is improved. The files are divided into two types, for smaller files, the occupation of the memory is relatively small, a plurality of backups can be carried out on the smaller files, if the verification fails, the files are recorded, the verification of the backup program is started, and if all the backup programs fail to verify, the system is reset. If one of the backup programs passes the verification, the program is executed and the next program in the trust chain is verified. After the starting is completed, the starting guide module repairs the marked starting program which does not pass the verification, specifically, the program used in the normal starting is used for replacing the corresponding program which fails the verification, and the flow is shown in fig. 3.
In some embodiments of the present invention, if the size of the content to be verified is greater than or equal to a predetermined value (e.g., 50 kB), the content to be verified includes a backup file, and the method further includes: checking the content to be checked by determining whether a merck tree set is legal, wherein the merck tree set comprises a master file merck tree and a backup file merck tree generated in the following way: dividing the content to be checked into a plurality of small files according to a preset rule (for example, in a fixed size unit in fig. 5) and calculating a hash value for each small file to construct a master file merck tree; and dividing the backup file into a plurality of small files according to the preset rule and calculating a hash value for each small file to construct the backup file merck tree.
In some embodiments of the invention, the merck tree set further includes multiple copies of the master file merck tree and multiple copies of the backup file merck tree.
In some embodiments of the present invention, if any one of the merck tree sets is legal, constructing a merck tree of the current content to be verified according to a preset rule; comparing the current content to be verified with each node of any one of the merck tree set: if each node of the merck tree of the current content to be checked is consistent with each node of any one item, the current content to be checked passes the check; or if each node of the merck tree of the current content to be checked has a consistent node in any one of the merck tree sets, combining the data blocks corresponding to the consistent nodes to replace the content to be checked, and checking the replaced content.
In some examples of the present invention, for larger files, such as APP programs used in the controller core, bootloader programs involved in the processor core, kernel and file systems, if backed up multiple times, a large amount of memory consumption results, which is not applicable to embedded areas where memory resources are limited. These files can be backed up only once, hereinafter referred to as a master file and a backup file, and the two files are logically divided into a plurality of small files respectively, a hash value is calculated for each small file, and a merck tree is constructed, and since the merck tree is much smaller than the original file, the files can be backed up for multiple times by adopting the method to protect the files, and an authenticator is added or digitally signed and then stored in a memory, and a uboot is taken as an example, and the merck tree is shown in fig. 4.
The boot module is started to check the data of the tree structure first. If so, constructing the merck tree by the same logic division on the current file, comparing the root nodes, if the current file passes the verification, marking a modified logic block if the current file passes the verification, then authenticating the stored merck tree of the backup file, calculating the merck tree on the backup file after the verification passes, comparing the merck tree with a stored value, if the root nodes of the merck tree of the backup file are correct, starting the backup file, otherwise judging whether the root nodes of the merck tree stored by the main file and the backup file are consistent, if so, attempting to mutually repair by using the correct logic blocks in the main file and the backup file, if all the perfect data blocks can form the whole program, then successfully repairing, continuing to execute a starting process by using the combined file, otherwise, starting the backup file fails, resetting the system, and the flow is shown in a figure 5.
In some embodiments of the present invention, a boot module is initiated to include a plurality of backups, the method comprising the steps of: configuring a core to be started by the BootROM; and running the boot module and the latest version in the backup thereof through the core.
In some embodiments of the present invention, the content to be verified and its backup are verified in the order of version from new to old.
In some examples of the invention, aiming at the characteristics of complex running environment and more startup files on the heterogeneous multi-core embedded system, a guiding mechanism of the startup process is established by comprehensively considering factors such as startup time, file version and the like, so that the system selects an optimal startup path. For example, a BootROM boot core may be first configured, where the core is responsible for running the boot module and the other cores are responsible for running the application, so that the boot program does not affect the execution of the application, and when the boot module is verified and run, the module first compares and selects the latest version of the module with its unverified backup, and if the latest version of the program is currently running, continues. Otherwise, resetting the system and restarting the starting process. Thereafter, a corresponding trust chain is selected according to the core which is required to be started currently, and a next-stage bootstrap program (such as uboot and the like) in the trust chain is started.
In some examples of the present invention, the boot module first selects the latest version in the next level program in the trust chain, marks it as the main file, marks other files as backup files, the module checks the main file, if it passes, continues to run the boot process, if it does not pass, selects another backup file, compares the version number of the backup file with the version number of the previous level file, if it is compatible, checks the backup file, if it is successful, marks the current file as the main file, if all backup files fail to check, tries to recover, if it still fails, resets the system, when the number of resets exceeds the limit, the boot module starts the chip into the bootloader mode, in which the developer can burn the program protected by the digital signature into the chip RAM through various communication pins, directly start it by the RAM, and then load other files by the program, thereby starting normally. After the normal start is successful, the start-up guiding module covers the corresponding file which fails to verify in the start-up process with the file which is currently used, the working process of the start-up guiding module is shown in figure 6,
In order to further illustrate the present invention, a detailed description will be given below taking the start-up of the S32G chip as an example.
The S32G chip selected has 3 Cortex-M7 cores and 4 Cortex-A53 cores, and has a hardware security module HSE. When the boot-strap is started, a program in the BootROM starts to execute firstly, the program checks the functions of the registers, configures the peripheral equipment in the starting process, copies and checks the firmware of the hardware security module HSE from the external Flash, if the firmware passes the checking, the HSE firmware starts to execute, and jumps to a user file address in the starting vector table to start to execute.
In this example, the address corresponds to the program first address of the boot module, and is executed by a Cortex-M7 core, the HSE firmware authenticates the boot module by AES GCM, the authentication is executed by the HSE module, before the authentication, it is required to check whether the key used is trusted, then compare the current file version with the unverified backup file version, and if the current file is the latest version, continue to execute. Otherwise, the address of the backup file is written into the starting vector table, the chip is triggered to reset, and the starting program is restarted, and the setting can enable the chip to run the latest version of the perfect starting guide module program.
After the file version check is passed, according to the setting, the start-up guide module firstly needs to guide the core to run, the module copies the calibration and APP program to the SRAM according to the configuration, the calibration and the APP are respectively authenticated by the AES GCM, and once the authentication is passed, the module triggers the core to run the APP to reset and run. Because the calibration file in this example is smaller, it is backed up twice in the system, if calibration authentication fails, the file with authentication failure is recorded, the current calibration file is set as a backup file, another file in the system is set as a master file authentication, whether the version number is matched and authentication is performed is judged, if authentication is successful, the APP file is continuously authenticated, because the APP file is larger, only one backup is performed, firstly, the merck tree of the master file (three backup are provided for the merck tree of the master file backup file) is read, and AES GCM authentication is performed, if authentication fails, the backup merck tree is continuously read, authentication is performed until all the backups fail, and the current starting process is abandoned. If the authentication is successful, reading the APP file into the SRAM and calculating the merck tree thereof, comparing the value of the root node of the stored merck tree with the calculated root node value, and indicating that the current APP can be operated when the value is the same, otherwise, continuing to read the merck tree and the backup file of the backup file by the processing method of the master file, if the backup file is correct, starting the backup file, otherwise, judging the root nodes of the merck tree of the stored master file and the backup file, if the value is the same, selecting the correct program blocks in the master file and the backup file, attempting to form a complete program, if the value can be successfully formed into the complete program, starting the system can be continued, otherwise, resetting the system, and attempting to start the system again. If the above checks are all passed, the booted core is reset and allowed to start running.
After the program of the M7 core runs, the boot module starts to boot the program of the A53 core, and the bootloader used by the A53 core is uboot. The module copies the first part of code of uboot into Nor Flash to authenticate the code, and the code section contains copy and authentication of the rest uboot program. The first segment of code of uboot has a main file and two backups, the remaining code of uboot, and then the linux kernel and the file system occupy a larger memory, and only one backup is needed, but each file stores 3 corresponding merck trees. The authentication and recovery process of uboot residual code is consistent with APP described above. The second segment of uboot code contains authentication programs for environment variables and kernels, and the kernels can authenticate the starting script and system services after successful operation. In order to reduce the start-up time, the authentication of the application is performed by the core where the start-up boot program is located, and the standby application is started up once the authentication fails.
When all application programs pass the authentication, the starting guide module processes the files which fail the authentication, in particular to inquire the record in the starting process and cover the files which fail the authentication with the files of the same type used in the starting process, so that all the files including the main file and the backup file are in a complete and safe state when the system is started next time. If the system Reset times caused by authentication failure in the starting process exceeds a preset limit value, the bootstrap program is started to configure the chip to enter a serial boot mode of S32G after Reset, the bootstrap loader is directly written into the RAM to start running through communication modes such as CAN, UART, ethernet and the like, and the bootstrap loader is protected by using a digital signature or a message authentication code, so that a legal person CAN be ensured to start the chip in the mode. The new starting guide program, calibration used by the M7 core, uboot used by the APP and the A53 core, the kernel, the file system and the like are loaded by the program, and the situation that the chip cannot be used and only can be replaced after the file is attacked and cannot be recovered is avoided by the measure, so that the use cost of a user is reduced.
According to another aspect of the invention there is provided a computer readable storage medium having instructions stored therein, which when executed by a processor, cause the processor to perform any of the methods as described above. Computer-readable media, as referred to herein, include any type of computer storage media which can be accessed by a general purpose or special purpose computer. By way of example, a computer-readable medium may comprise RAM, ROM, EPROM, E 2 PROM, registers, hard disk, a removable disk, a CD-ROM or other optical disk storage, a magnetic disk storage or other magnetic storage device, or any other temporary or non-temporary medium that can be used to carry or store desired program code means in the form of instructions or data structures and that can be accessed by a general-purpose or special-purpose computer, or a general-purpose or special-purpose processor. As used herein, discs (disks) and disks include Compact Discs (CDs), laser discs, optical discs, digital Versatile Discs (DVDs), floppy disks, and blu-ray discs where disks usually reproduce data magnetically, while disks reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media. An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In the alternative, the processor and the storage medium may reside as discrete components in a user terminal.
In view of the above, it will be seen that some embodiments of the inventive arrangements have at least the following advantages over the prior art: (1) BootROM is selected as a trusted root, so that the safety is greatly enhanced; (2) According to possible application scenes of heterogeneous multi-core chips, a starting guide module is used for managing and maintaining a plurality of trusted chains, so that the safety and reliability of the whole starting process are ensured; (3) Different starting file security mechanisms are respectively formulated according to the sizes of the starting files, and the mechanism can recover the damaged starting files to a certain extent, and compared with the current method, the mechanism improves the capability of the system for resisting attacks, preventing risks such as refresh failures and the like; (4) The system comprises a system management module, a system management module and a system management module, wherein the system management module is used for managing a plurality of files in a heterogeneous multi-core system and selecting an optimal starting path from the files in the system, and the system management module is used for providing a system recovery mechanism when a fault is started, so that the safety of the system is ensured, the usability of the system is improved, and the user loss and complaints are reduced.
The above examples primarily illustrate the heterogeneous multi-core chip-based activation method and computer-readable storage medium of the present invention, and although only a few embodiments of the present invention have been described, those of ordinary skill in the art will appreciate that the present invention may be embodied in many other forms without departing from the spirit or scope thereof. Accordingly, the present examples and embodiments are to be considered as illustrative and not restrictive, and the invention is intended to cover various modifications and substitutions without departing from the spirit and scope of the invention as defined by the appended claims.

Claims (9)

1. The starting method based on the heterogeneous multi-core chip is characterized by comprising the following steps of:
Selecting a BootROM as a trusted root, and checking a starting guide module through the BootROM; and
If the starting guide module passes the verification, the core to be started in the heterogeneous multi-core chip and the corresponding content to be verified are selected according to the preset configuration,
If the core to be started is the controller core, the content to be checked comprises a calibration file and an APP file, and the method further comprises:
Checking the calibration file and the APP file through the starting guide module, releasing the controller core if the calibration is passed,
If the core to be started is a processor core, the content to be verified includes a uboot program, an environment variable, a kernel, a system service, a starting script and an application program, and the method further includes:
Checking the uboot program through the starting guide module, and releasing the processor core if the checking is passed;
Executing the uboot program through the processor core, and checking the environment variable and the kernel in the uboot program;
If the kernel passes the verification, copying the kernel into a file system and verifying system service and a starting script of the file system; and
And if the system service and the starting script pass the verification, executing the application program, and utilizing the starting guide module to verify the application program.
2. The method of claim 1, wherein if the size of the content to be verified is less than a predetermined value, the content to be verified includes a plurality of backups to together form a set to be verified, the method further comprising:
If one item in the set to be verified does not pass the verification, recording the item, and utilizing the rest items in the set to be verified to carry out the verification:
If all items in the set to be verified do not pass the verification, the verification of the content to be verified fails; and
And if any item in the set to be verified passes the verification, the content to be verified is successfully verified, and the recorded item is replaced by the verified item.
3. The method of claim 2, wherein if the size of the content to be verified is greater than or equal to a predetermined value, the content to be verified includes a backup file, the method further comprising: verifying the content to be verified by determining whether the merck tree set is legal, wherein
The merck tree set comprises a master file merck tree and a backup file merck tree generated in the following way:
Dividing the content to be checked into a plurality of small files according to a preset rule and calculating a hash value for each small file to construct the master file merck tree; and
Dividing the backup file into a plurality of small files according to the preset rule and calculating a hash value for each small file to construct the backup file merck tree.
4. The method of claim 3, wherein the merck tree set further comprises a plurality of backups of the master file merck tree, a plurality of backups of the backup file merck tree.
5. The method according to claim 4, wherein if any one of the merck tree sets is legal, constructing a merck tree of the current content to be verified according to the preset rule;
comparing the merck tree of the current content to be verified with each node of any one of the merck tree sets:
if each node of the merck tree of the current content to be checked is consistent with each node of any item, the current content to be checked passes the check; or alternatively
If each node of the merck tree of the current content to be verified has a consistent node in any one of the merck tree sets, combining data blocks corresponding to the consistent nodes to replace the content to be verified, and verifying the replaced content.
6. A method according to claim 2 or 3, wherein the boot module comprises a plurality of backups, the method comprising the steps of:
Configuring a core to be started by the BootROM; and
And running the start-up guide module and the latest version in the backup thereof through the core.
7. The method of claim 6, wherein the content to be verified and its backups are verified in version-from-new-to-old order.
8. A computer readable storage medium having stored therein a computer program/instructions which, when executed by a processor, cause the processor to perform the steps of the method according to any of claims 1-7.
9. A computer program product comprising computer programs/instructions which, when executed by a processor, cause the processor to perform the steps of the method of any of claims 1-7.
CN202010326901.5A 2020-04-23 2020-04-23 Starting method based on heterogeneous multi-core chip and storage medium Active CN113553115B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010326901.5A CN113553115B (en) 2020-04-23 2020-04-23 Starting method based on heterogeneous multi-core chip and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010326901.5A CN113553115B (en) 2020-04-23 2020-04-23 Starting method based on heterogeneous multi-core chip and storage medium

Publications (2)

Publication Number Publication Date
CN113553115A CN113553115A (en) 2021-10-26
CN113553115B true CN113553115B (en) 2024-09-10

Family

ID=78129361

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010326901.5A Active CN113553115B (en) 2020-04-23 2020-04-23 Starting method based on heterogeneous multi-core chip and storage medium

Country Status (1)

Country Link
CN (1) CN113553115B (en)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115130114B (en) * 2022-08-31 2022-12-23 杭州云动智能汽车技术有限公司 Gateway secure starting method and device, electronic equipment and storage medium
CN115421756B (en) * 2022-09-16 2023-07-18 杭州云动智能汽车技术有限公司 Service type gateway upgrading method
CN115629824B (en) * 2022-12-01 2023-08-15 摩尔线程智能科技(北京)有限责任公司 GPU startup method, device, device, storage medium and program product

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109800032A (en) * 2019-01-31 2019-05-24 深圳忆联信息系统有限公司 BOOTROM multicore loading method and device

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102008011925B4 (en) * 2008-02-29 2018-03-15 Globalfoundries Inc. Safe initialization of computer systems
WO2012149716A1 (en) * 2011-08-30 2012-11-08 华为技术有限公司 Bootrom backup method and apparatus
CN106407156B (en) * 2016-09-23 2018-11-23 深圳震有科技股份有限公司 The method and system of one BOOTROM guidance multi-core CPU starting
CN109542518B (en) * 2018-10-09 2020-12-22 华为技术有限公司 Chip and method for starting chip

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109800032A (en) * 2019-01-31 2019-05-24 深圳忆联信息系统有限公司 BOOTROM multicore loading method and device

Also Published As

Publication number Publication date
CN113553115A (en) 2021-10-26

Similar Documents

Publication Publication Date Title
JP4769608B2 (en) Information processing apparatus having start verification function
CN108399339B (en) Trusted starting method based on security chip
CN110990084B (en) Chip secure starting method and device, storage medium and terminal
CN113553115B (en) Starting method based on heterogeneous multi-core chip and storage medium
JP5582909B2 (en) Platform integrity verification system
US20090193211A1 (en) Software authentication for computer systems
US11163886B2 (en) Information handling system firmware bit error detection and correction
WO2021249359A1 (en) Data integrity protection method and apparatus
JP2014513348A (en) System and method for processing a request to change a system security database and firmware storage in an integrated extended firmware interface compliant computing device
CN113486360B (en) RISC-V based safe starting method and system
CN110363010B (en) System safety starting method based on MPSoC chip
CN112613011B (en) USB flash disk system authentication method and device, electronic equipment and storage medium
CN109445705B (en) Firmware authentication method and solid state disk
JP5076110B2 (en) System and method for guaranteeing data
CN112347518B (en) Storage device
TWI706274B (en) Computing device and non-transitory computer-readable storage medium enabling operating system repairs via recovery agents
CN111291381A (en) Method, equipment and medium for building trust chain based on TCM
CN114003915A (en) Chip-based secure startup method and device
US12155761B2 (en) Method and system for accelerating verification procedure for image file
CN113360914A (en) BIOS updating method, system, equipment and medium
CN115859310A (en) Method, device and equipment for integrating credibility measurement and business security
CN113505363B (en) Method and system for realizing memory space replay prevention through software mode
CN111814208B (en) Method for defending fault injection during secure start of soc national security chip
US11620385B2 (en) Vehicle control device, vehicle control device start-up method, and recording medium
JP5465738B2 (en) System firmware update method and computer

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant