Trusted chain reconstruction method and related device
By running the detection component on the SoC, an abnormal system is detected and the restart information is passed to its previous node, and only part of the trusted chain is rebuilt, which solves the problem of long restart time caused by multiple system exceptions in the SoC, and achieves a fast and secure restart.
Patent Information
- Application Number
- CN202410047234.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-01-10
- Publication Date
- 2025-07-11
AI Technical Summary
In a system-on-chip (SoC), when multiple systems are running abnormally, the prior art needs to restart the trusted chain of the entire chip, resulting in a long restart time and affecting normal business operations.
By running the detection component on the SoC, after detecting a system that needs to be restarted, it passes restart information to its previous node, so that the previous node can re-execute the trusted startup process of the system, rebuild only part of the trusted chain, and avoid rebuilding the entire trusted chain.
Shorten the system restart time, reduce the impact on other systems, and ensure the safe restart of abnormal systems.
Smart Images

Figure CN120295831A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer security technologies, and in particular, to a method for rebuilding a trusted chain and related devices. Background Art
[0002] During the secure boot process of a chip, it usually starts to execute from the secure boot code in the read-only memory inside the chip, loads and verifies the next-level code through the previous-level code, and jumps to the next-level code for execution after successful verification until the system on the chip is successfully booted. In this way, during the chip boot process, the codes verified and executed in sequence can form a trusted chain. Since the next-level code in the trusted chain is only executed after being successfully verified by the previous-level code, the boot method based on the trusted chain can ensure the security of the entire boot process of the chip.
[0003] When an exception occurs during the operation of the system in the chip, such as the processor being unable to execute instructions normally or the security verification result being incorrect, etc., it is often necessary to restart the system in the chip and rebuild the trusted chain to ensure the security of the system restart process. Currently, in related technologies, the trusted chain for secure chip boot is usually rebuilt by stopping feeding the watchdog and causing the chip to reset due to the watchdog overflow, so as to achieve the restart of the entire chip.
[0004] However, in the case where the chip includes multiple systems, such as a System on Chip (SoC) including multiple physical subsystems or multiple operating systems, an exception in any one of the systems in the chip will cause the entire chip to restart (that is, the entire trusted chain needs to be rebuilt), resulting in a long chip restart time and easily affecting the normal operation of the services on the chip. Summary of the Invention
[0005] This application provides a method for rebuilding a trusted chain, which is applied to independently restart the system on the SoC, shorten the restart time of the system on the SoC, and reduce the impact area of the system restart on the SoC.
[0006] The first aspect of the present application provides a method for reconstructing a trusted chain, which is applied to an SoC. There are a detection component, a first component, and multiple systems running on the SoC. The specific execution process of the trusted chain reconstruction method includes: the detection component continuously detects the first system, and when the detection component detects that the first system needs to be restarted, the detection component transmits a restart message to the first component. Among them, the restart message is used to indicate the execution of the restart process for the first system. The first system is one of the multiple systems running on the SoC. The first component is the previous-level node of the first system in the trusted chain. That is, during the secure startup process of the SoC, the first component is responsible for verifying and loading the first system. Only when the code corresponding to the first system passes the verification, the first component will load the code corresponding to the first system and jump to execute the code corresponding to the first system, thereby realizing the startup of the first system.
[0007] Based on the restart message, the first component re-executes the trusted startup process of the first system. That is, the first component reloads and verifies the code of the first system, and jumps to execute the first system when the first system passes the verification.
[0008] In this solution, for an SoC including multiple systems, the detection component running on the SoC is used to detect the running status of the systems on the SoC. When the detection component detects that the first system on the SoC needs to be restarted, the detection component transmits a restart message to the previous-level node of the first system in the trusted chain (i.e., the first component) to indicate that the first component executes a restart for the first system. In this way, the first component can re-execute the trusted startup process of the first system to ensure that the first system can be safely restarted. Since only the previous-level node of the system executes the trusted startup process of the system in this solution, which is equivalent to reconstructing a part of the trusted chain of the SoC and does not require reconstructing the entire trusted chain of the SoC, it can shorten the restart time of the system and does not affect the normal operation of other systems on the SoC.
[0009] In a possible implementation manner, the multiple systems running on the SoC are all operating systems, and the first system is one of the multiple operating systems running on the SoC. That is, the system that needs to be restarted on the SoC is an operating system.
[0010] That is to say, in the case where the SoC runs multiple independent operating systems, when any one of the operating systems needs to be restarted, the previous-level node of the operating system in the trusted chain re-executes the trusted startup process of the current operating system, which can realize restarting only one of the operating systems and ensure that the other operating systems can run normally.
[0011] In a possible implementation manner, the detection component is an application program running on the second system, and the second system is one of the multiple operating systems. That is, the second system is another operating system other than the first system.
[0012] That is to say, when the first system is an operating system, the detection of the first system is implemented by another operating system or an application running on another operating system, so as to ensure that when the first system runs abnormally, the information that the first system needs to be restarted can be effectively transmitted to the first component.
[0013] In a possible implementation, the first component re-executes the trusted boot process of the first system, including: the first component loads the code of the first system into the running space of the first system and verifies the code of the first system; after the code of the first system passes the verification, the first component triggers the execution of the code of the first system.
[0014] In addition, before loading the code of the first system, the first component can first clear the running space of the first system; or the first component directly overwrites the code of the first system onto the current running space of the first system.
[0015] In a possible implementation, multiple systems running on the SoC are all processing systems, and each of the multiple systems includes an independent processor, and the first system is one of the multiple processing systems running on the SoC. That is, the system that needs to be restarted on the SoC is actually a physical subsystem.
[0016] In a possible implementation, the first component and the detection component run on the second system, and the first system and the second system belong to different processing systems among the multiple processing systems running on the SoC. That is, the first component and the detection component both run independently outside the first system, and the normal operation of the first component and the detection component will not be affected by the first system.
[0017] In a possible implementation, the first component re-executes the trusted boot process of the first system, including: the first component loads the corresponding boot firmware of the first system into the running space of the first system and verifies the boot firmware; after the boot firmware passes the verification, the first component triggers the execution of the boot firmware.
[0018] In a possible implementation, the detection component detects that the first system needs to be restarted, specifically including: the detection component receives a hardware signal sent by the first system, and the hardware signal is used to indicate restarting the first system.
[0019] That is to say, when the first system is a processing system running independently on the SoC, the first system can trigger its own restart by actively sending a hardware signal to the detection component, so as to meet the requirements in different scenarios.
[0020] In a possible implementation, the detection component detects that the first system needs to be restarted. Specifically, the detection component detects that the first system is in an abnormal operating state. For example, the first system exhibits phenomena such as unresponsiveness, crashing, or abnormal exit.
[0021] In this solution, the detection component is used to detect whether the first system is in an abnormal operating state to trigger an independent restart of the first system, which can ensure that the system will trigger a restart when operating abnormally and minimize the impact of the system restart as much as possible.
[0022] In a possible implementation, the first component is the Basic Input Output System (BIOS).
[0023] In a second aspect of the present application, there is provided a System on Chip (SoC). A detection component, a first component, and multiple systems are running on the SoC. The detection component is configured to, when detecting that the first system needs to be restarted, transmit restart information to the first component, where the restart information is used to indicate to perform a restart process on the first system. The first component is the previous-level node of the first system in the trust chain, and the first system is one of the multiple systems. The first component is configured to, based on the restart information, re-perform the trusted boot process of the first system.
[0024] In a possible implementation, the multiple systems are all operating systems, and the first system is one of the multiple operating systems running on the SoC.
[0025] In a possible implementation, the detection component is an application running on the second system, and the second system is one of the multiple operating systems.
[0026] In a possible implementation, the first component is specifically configured to: load the code of the first system into the running space of the first system and verify the code of the first system; after the code of the first system passes the verification, trigger the execution of the code of the first system.
[0027] In a possible implementation, the multiple systems are all processing systems, and the multiple systems each include an independent processor. The first system is one of the multiple processing systems running on the SoC.
[0028] In a possible implementation, the first component and the detection component run on the second system, and the second system is one of the multiple processing systems.
[0029] In a possible implementation, the first component is specifically configured to: load the startup firmware corresponding to the first system into the running space of the first system and verify the startup firmware; after the startup firmware passes the verification, trigger the execution of the startup firmware.
[0030] In a possible implementation, the detection component detects that the first system needs to be restarted, including: the detection component receives a hardware signal sent by the first system, and the hardware signal is used to indicate restarting the first system.
[0031] In a possible implementation, the detection component detects that the first system needs to be restarted, including: the detection component detects that the first system is in an abnormal operating state.
[0032] In a possible implementation, the first component is the BIOS.
[0033] The third aspect of this application provides a network device, including a processor and a memory; wherein, the memory is used to store program codes, and the processor is used to execute the method according to any one of the implementation manners of the first aspect.
[0034] The fourth aspect of this application provides a computer-readable storage medium, storing instructions, which when running on a computer, cause the computer to execute the method according to any one of the implementation manners of the first aspect.
[0035] The fifth aspect of this application provides a computer program product, which when running on a computer, causes the computer to execute the method according to any one of the implementation manners of the first aspect.
[0036] The sixth aspect of this application provides a chip, including one or more processors. Some or all of the processors are used to read and execute computer instructions stored in the memory to execute the method in any possible implementation manner of any of the above aspects. Optionally, the chip further includes a memory. Optionally, the chip further includes a communication interface, and the processor is connected to the communication interface. The communication interface is used to receive data and / or information that needs to be processed, the processor obtains the data and / or information from the communication interface, processes the data and / or information, and outputs the processing result through the communication interface. Optionally, the communication interface is an input / output interface or a bus interface. The method provided by this application is implemented by one chip or by multiple chips working together.
[0037] The solutions provided in the above third aspect to sixth aspect are used to implement or cooperate with the implementation of the method provided in the first aspect, so they can achieve the same or corresponding beneficial effects as the first aspect, and will not be elaborated here. Description of the Drawings
[0038] Figure 1 It is a schematic flowchart of the safe startup after the power-on of a chip provided in an embodiment of this application;
[0039] Figure 2 It is a schematic diagram of the system architecture to which a trusted chain reconstruction method provided in an embodiment of this application is applied;
[0040] Figure 3Schematic flowchart of a trusted chain reconstruction method provided by an embodiment of the present application;
[0041] Figure 4 Schematic flowchart of a process for starting multiple operating systems in a SoC provided by an embodiment of the present application;
[0042] Figure 5 Schematic diagram of a trusted chain provided by an embodiment of the present application;
[0043] Figure 6 Schematic diagram of another trusted chain provided by an embodiment of the present application;
[0044] Figure 7 Schematic diagram of the structure of a SoC provided by an embodiment of the present application;
[0045] Figure 8 Schematic diagram of the structure of a processing system provided by an embodiment of the present application;
[0046] Figure 9 Schematic flowchart of a process for starting multiple processing systems in a SoC provided by an embodiment of the present application;
[0047] Figure 10 Schematic diagram of a trusted chain provided by an embodiment of the present application;
[0048] Figure 11 Schematic diagram of another trusted chain provided by an embodiment of the present application;
[0049] Figure 12 Schematic diagram of the structure of a SoC provided by an embodiment of the present application. Detailed implementation manners
[0050] In order to make the objectives, technical solutions and advantages of the present application clearer and more understandable, the embodiments of the present application will be described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all of the embodiments. Those of ordinary skill in the art will know that with the emergence of new application scenarios, the technical solutions provided by the embodiments of the present application are equally applicable to similar technical problems.
[0051] The terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and do not have to be used to describe a specific order or sequence.
[0052] Currently, in the secure boot process of a chip, it usually starts to execute from the secure boot code in the read-only memory inside the chip, loads and verifies the next-level code through the previous-level code, and jumps to the next-level code for execution after successful verification until the system on the chip is successfully booted.
[0053] Please refer to Figure 1.Figure 1 This is a schematic diagram of the secure startup process after the chip is powered on provided by an embodiment of the present application. As Figure 1 shown, after the chip is powered on, it first loads the secure boot code from the read-only memory inside the chip and performs a security check on the off-chip secure boot code (i.e., the secure boot code located outside the chip) by executing the secure boot code. When the off-chip secure boot code passes the verification, the off-chip secure boot code loads and executes the off-chip secure boot code, thereby performing a security check on the Basic Input Output System (BIOS). When the BIOS passes the verification, the BIOS loads and executes the operating system, thereby performing a security check on the operating system. When the operating system passes the verification, the operating system can, according to the user's instructions, perform a security check on the application (APP) that the user needs to start and load and execute the APP when the APP passes the verification. In Figure 1 this process, the on-chip secure boot code, off-chip secure boot code, BIOS, operating system, and APP constitute a trusted chain. That is, the trusted chain is composed of multiple levels of nodes, and the code corresponding to the previous level of nodes is responsible for performing a security check on the code corresponding to the next level of nodes and loading and executing the code corresponding to the next level of nodes when the code corresponding to the next level of nodes passes the security check.
[0054] After the chip completes a secure startup, the system on the chip will monitor whether the system on the chip is running normally by feeding the watchdog. Among them, the watchdog is a relatively independent timer, and there are two signal lines connected to the timer. For the two signal lines connected to the timer, one signal line is used to receive the dog-feed signal sent by the system on the chip, and the dog-feed signal is used to indicate that the timer is cleared and starts counting again; the other signal line is used to send a reset signal. Specifically, if the system on the chip does not regularly send a dog-feed signal to the timer due to interference or other accidental failures, the timer count will overflow and generate a reset signal. In this way, when the chip receives the reset signal sent by the watchdog, it will reconstruct the trusted chain of the chip's secure startup, thereby realizing the restart of the entire chip.
[0055] However, in the case where the chip includes multiple systems, for example, an SoC includes multiple physical subsystems or multiple operating systems, any abnormal operation of a system in the chip will cause the entire chip to restart (i.e., the entire trusted chain needs to be reconstructed), resulting in a long chip restart time and easily affecting the normal operation of the services on the chip. Moreover, when only one system in the chip operates abnormally while other systems operate normally, the restart of the entire chip will affect other normally operating systems, resulting in too large an impact area and easily causing the interruption of the services executed on the chip.
[0056] In view of this, an embodiment of the present application provides a method for rebuilding a trusted chain. For a SoC including multiple systems, the running status of the systems on the SoC is detected by running a detection component on the SoC. When the detection component detects that the first system on the SoC needs to be restarted, the detection component transmits restart information to the previous-level node (i.e., the first component) of the first system on the trusted chain to instruct the first component to perform a restart on the first system. In this way, the first component can re-execute the trusted boot process of the first system, ensuring that the first system can be restarted safely. Since only the previous-level node of the system performs the trusted boot process of the system in this solution, which is equivalent to rebuilding a part of the trusted chain of the SoC and does not require rebuilding the entire trusted chain of the SoC, the restart time of the system can be shortened without affecting the normal operation of other systems on the SoC.
[0057] Please refer to Figure 2 , Figure 2 which is a schematic diagram of the system architecture to which the method for rebuilding a trusted chain provided by an embodiment of the present application is applied. As Figure 2 shown, the system architecture includes a first system, a detection component, and the previous-level node of the first system in the trusted chain. Among them, the detection component is responsible for detecting the running status of the first system to determine whether the first system needs to be restarted. When the detection component detects that the first system needs to be restarted (for example, the first system runs abnormally or the first system requests an independent restart), the detection component notifies the previous-level node of the first system in the trusted chain of the information that the first system needs to be restarted, so that the previous-level node of the first system in the trusted chain can re-execute the trusted boot process of the first system.
[0058] Please refer to Figure 3 , Figure 3 which is a schematic flowchart of the method for rebuilding a trusted chain provided by an embodiment of the present application. As Figure 3 shown, the method for rebuilding a trusted chain provided by an embodiment of the present application is applied to a SoC, on which a detection component, a first component, and multiple systems are running. And among the multiple systems running on the SoC, there is a first system.
[0059] Among them, the specific form of the SoC includes integrated circuit (IC), CPU, Network Processor (NP), Micro Processor (MP), MicroController Unit (MCU), application-specific integrated circuit (ASIC), or programmable logic device (PLD). This embodiment does not make specific limitations thereto. In addition, the PLD may specifically be any one or more of the following components: complex programmable logic device (CPLD), field-programmable gate array (FPGA), and generic array logic (GAL).
[0060] Specifically, the trusted chain reconstruction method provided by the embodiments of the present application includes the following steps 301-303.
[0061] Step 301, the detection component continuously detects whether the first system needs to be restarted.
[0062] In this embodiment, during the operation of the first system, the detection component continuously detects the first system to confirm whether the first system needs to be restarted.
[0063] Among them, there are various situations where the first system needs to be restarted.
[0064] In a possible situation, when the detection component detects that the first system is running abnormally, for example, the first system shows phenomena such as unresponsiveness, crashing, or abnormal exit, the detection component determines that the first system needs to be restarted.
[0065] In another possible situation, when the first system actively sends a restart notification to the detection component, the detection component can also determine that the first system needs to be restarted. For example, when the first system needs to update the firmware, the first system can actively send a restart notification to the detection component in the normal running state, so as to restart the first system based on the new firmware.
[0066] That is to say, there are two ways for the first system to trigger a restart. One is passive triggering (i.e., triggered by the detection component detecting the running state of the first system), and the other is active triggering (i.e., triggered by the first system actively notifying the detection component).
[0067] In addition, there are also various ways to implement the detection component. For example, the detection component is one of the multiple systems running on the SoC, that is, the detection component and the first system are different systems running on the SoC. Another example is that the detection component is a software module running on the SoC, and the detection component runs outside the first system, that is, the first system and the detection component run independently.
[0068] Step 302, when the detection component detects that the first system needs to be restarted, the detection component transmits a restart message to the first component, where the restart message is used to indicate to perform a restart process on the first system.
[0069] In this embodiment, the first component is the previous-level node of the first system in the trusted chain. For example, the first component is the BIOS. That is to say, in the secure boot process of the SoC, the first component is responsible for verifying and loading the first system. Only when the code corresponding to the first system passes the verification, the first component will load the code corresponding to the first system and jump to execute the code corresponding to the first system, thereby realizing the startup of the first system.
[0070] Since the first component can implement the verification and loading of the first system, when the detection component confirms that the first system needs to be restarted, it transmits a restart message to the first component to notify the first component to restart the first system.
[0071] Step 303, based on the restart message, the first component re-executes the trusted boot process of the first system.
[0072] After receiving the restart message transmitted by the detection component, the first component reloads and verifies the first system, thereby realizing re-executing the trusted boot process of the first system. Since the first component is the previous-level node of the first system in the trusted chain, when the first component restarts the first system, it can perform a security verification on the first system again to ensure the security of the restart process of the first system. Moreover, in this solution, only the first component re-executes the trusted boot process of the first system, which can avoid affecting other systems in the SoC and ensure that other systems in the SoC can run normally, minimizing the impact of the need to restart the first system.
[0073] The above describes the process of the detection component and the first component cooperating to restart the first system. For the convenience of understanding, the following will introduce in detail the process of restarting the first system in different scenarios with specific examples.
[0074] In a possible scenario, all the multiple systems running on the SoC are operating systems, and the first system described in the above embodiment is one of the multiple operating systems running on the SoC. That is, the system that needs to be restarted on the SoC is the operating system.
[0075] That is to say, when multiple independent operating systems are running on the SoC, when any one of the operating systems needs to be restarted, the previous-level node of the operating system in the trusted chain re-executes the trusted boot process of the current operating system, enabling only one of the operating systems to be restarted and ensuring that the other operating systems can run normally.
[0076] Optionally, the detection component is the second system or an application running on the second system. Here, the second system is one of the multiple operating systems, that is, the second system is another operating system other than the first system. That is to say, when the first system is an operating system, the detection of the first system is implemented through another operating system or an application running on another operating system, so as to ensure that in the case of abnormal operation of the first system, the information that the first system needs to be restarted can be effectively transmitted to the first component.
[0077] Exemplarily, please refer to Figure 4 , Figure 4 which is a schematic flowchart of starting multiple operating systems in an SoC provided by an embodiment of this application. As Figure 4 shown, when the SoC includes operating system 1 and operating system 2, the secure boot process of the SoC specifically includes the following processes.
[0078] (1) After the chip (i.e., the SoC) is powered on, start executing from the on-chip secure boot code located in the internal storage medium of the chip. The on-chip secure boot code loads the off-chip secure boot code located in the external storage medium of the chip into the memory and uses a public key cryptography algorithm to verify the digital signature of the off-chip secure boot code. After the off-chip secure boot code passes the verification, jump to execute the off-chip secure boot code.
[0079] (2) The off-chip secure boot code loads the BIOS code into the memory and uses a public key cryptography algorithm to verify the digital signature of the BIOS. After the BIOS passes the verification, jump to execute the BIOS.
[0080] (3) The BIOS includes component 1 and component 2. And the execution order of component 1 and component 2 can specifically be that component 1 executes first and component 2 executes later. The processor on the SoC supports multiple cores, for example, the processor supports dual cores. In this way, component 1 executes on one processor core and component 2 executes on another processor core. During the operation of the BIOS, component 1 loads the code of operating system 1 into the memory and uses a public key cryptography algorithm to verify the digital signature of operating system 1. After operating system 1 passes the verification, jump to execute operating system 1. In addition, component 2 loads the code of operating system 2 into the memory and uses a public key cryptography algorithm to verify the digital signature of operating system 2. After operating system 2 passes the verification, jump to execute operating system 2.
[0081] (4) The operating system 1 loads the code of Application 1 into memory and verifies the digital signature of Application 1 using a public-key cryptography algorithm. After Application 1 passes the verification, it jumps to execute Application 1.
[0082] (5) The operating system 2 loads the code of Application 2 into memory and verifies the digital signature of Application 2 using a public-key cryptography algorithm. After Application 2 passes the verification, it jumps to execute Application 2.
[0083] Based on Figure 4 the secure boot process shown, the boot process of the SoC actually has two trusted chains. Please refer to Figure 5 and Figure 6 , Figure 5 which is a schematic diagram of a trusted chain provided by an embodiment of the present application; Figure 6 and Figure 5 which is another schematic diagram of a trusted chain provided by an embodiment of the present application. As Figure 6 shown, one trusted chain corresponding to the boot process of the SoC is specifically: on-chip secure boot code → off-chip secure boot code → Component 1 in the BIOS → Operating system 1 → Application 1. As
[0084] shown, the other trusted chain corresponding to the boot process of the SoC is specifically: on-chip secure boot code → off-chip secure boot code → Component 2 in the BIOS → Operating system 2 → Application 2.
[0085] In addition, in this embodiment, the operating system 1 corresponds to the first system introduced in the above embodiment, that is, the operating system 1 is the target continuously detected by the detection component. Therefore, based on Figure 5 the trusted chain shown, Component 1 in the BIOS is the previous-level node of the operating system 1 in the trusted chain. The detection component is, for example, Application 2 or the operating system 2.
[0086] When the detection component is Application 2, the operating system 2 and Application 2 reside in memory, and Application 2 continuously detects the running status of the operating system 1. For example, Application 2 continuously detects the running status of the operating system 1 through methods such as heartbeat detection, process monitoring, log monitoring, port listening, and process status query. The specific method for Application 2 to detect the operating system 1 is not limited in this embodiment. Taking the example that Application 2 detects the operating system 1 through heartbeat detection, Application 2 and the operating system 1 agree to send a confirmation message to each other every 500 milliseconds. If Application 2 can receive the confirmation message sent by the operating system 1 every 500 milliseconds, it means that the operating system 1 is still running normally. If Application 2 has not received the confirmation message from the operating system 1 after a certain period (such as 1500 milliseconds), it can be determined that the operating system 1 is in an abnormal running state. For example, the operating system 1 may have crashed or exited abnormally.
[0087] After Application 2 determines that the operating system 1 is in an abnormal running state, Application 2 notifies Component 1 in the BIOS to restart the operating system 1. Specifically, Application 2 and Component 1 interact through command words, and different command words represent different working states of the operating system. In this way, Application 2 notifies Component 1 of the current running state of the operating system 1 by sending command words to the component, so as to instruct Component 1 to restart the operating system 1 when the operating system 1 runs abnormally. Exemplarily, the command words for the interaction between Application 2 and Component 1 are shown in Table 1.
[0088] Table 1
[0089] Command Word Meaning of Command Word 0x01 Operating System 1 is running normally 0x02 Operating System 1 is running abnormally
[0090] Taking the crash of the operating system 1 as an example, the process of Application 2 and Component 1 cooperating to restart the operating system 1 is introduced as follows.
[0091] Specifically, there is an illegal operation in the operating system 1 where the kernel mode directly accesses the user mode space, so the operating system 1 crashes. Application 2 interacts with the operating system 1 through heartbeat detection and does not receive the confirmation message sent by the operating system 1 within 1500 milliseconds, thus determining that the operating system 1 is in an abnormal running state. Then, Application 2 sends the command word 0x02 to Component 1 in the BIOS.
[0092] After Component 1 receives the command word sent by Application 2, it parses the command word and executes the processing flow with the command word 0x02. Specifically, the processing flow with the command word 0x02 includes the following 4 steps. Step 1, Component 1 clears the address space where Operating System 1 is located (i.e., clears the address space occupied by Operating System 1 in memory). Step 2, Component 1 loads the code of Operating System 1 from flash into memory, for example, the address space cleared by Component 1 in Step 1. Step 3, Component 1 uses a public-key cryptography algorithm to verify the digital signature of the code of Operating System 1. Step 4, after Operating System 1 passes the verification, it jumps to the entry address of Operating System 1, and Operating System 1 starts to execute.
[0093] In this way, after Operating System 1 is successfully started, the functions of Operating System 1 are restored, and Trusted Chain 1 is successfully rebuilt. From the above introduction, it can be seen that during the reconstruction of Trusted Chain 1, it actually starts from the node where Operating System 1 is located, and the nodes before Operating System 1 in the trusted chain do not need to be rebuilt, thus greatly improving the reconstruction speed of the trusted chain.
[0094] In another possible scenario, multiple systems running on the SoC are all processing systems, and each of the multiple systems includes an independent processor. The first system introduced in the above embodiment is one of the multiple processing systems running on the SoC. That is, the system that needs to be restarted on the SoC is actually a physical subsystem.
[0095] Exemplarily, please refer to Figure 7 , Figure 7 which is a schematic structural diagram of an SoC provided by an embodiment of the present application. As Figure 7 shown, the SoC includes a first system and a second system, and both the first system and the second system are processing systems including independent processors and can operate independently. In addition, the first system and the second system are connected by an on-chip bus to realize the interaction between the two systems.
[0096] Please refer to Figure 8 , Figure 8 which is a schematic structural diagram of a processing system provided by an embodiment of the present application. Since both the first system and the second system are processing systems, the structures of the first system and the second system are, for example, Figure 8 as shown in the structural diagram of the processing system. As Figure 8As shown, the processing system is actually composed of a processor, which includes physical cores, internal memory (such as internal static random-access memory (SRAM)), and a communication interface. The physical cores, internal memory, and communication interface are connected to each other through a bus. Based on the physical cores and internal memory, the processing system can independently run application programs and communicate with other processing systems through the communication interface.
[0097] Optionally, when both the first system and the second system on the SoC are processing systems, the first component and the detection component run on the second system. That is, the first component and the detection component both run independently outside the first system, and the normal operation of the first component and the detection component will not be affected by the first system.
[0098] In addition, since the detection component is located on another processing system outside the first system, the interaction between the detection component and the first system needs to be implemented by hardware, such as the on-chip bus connected between the first system and the second system. In this way, the way for the detection component to detect that the first system needs to be restarted is, for example, that the detection component detects a hardware signal sent by the first system, and this hardware signal is used to indicate restarting the first system. That is, the first system can trigger its own restart by actively sending a hardware signal to the detection component.
[0099] Exemplarily, please refer to Figure 9 , Figure 9 which is a schematic flowchart of starting multiple processing systems in an SoC provided by an embodiment of the present application. As Figure 9 shown, when there are two processing systems, namely the first system and the second system, in the SoC, the secure boot process of the SoC specifically includes the following processes.
[0100] 1. After the chip is powered on, it first starts to execute the secure boot code from the read-only storage medium inside the first system. After the secure boot code starts to execute, it loads and verifies the BIOS code. After the BIOS verification passes, it jumps to execute the BIOS.
[0101] 2. The BIOS includes component 1 and component 2. Component 1 executes first, and component 2 executes later. Specifically, component 1 in the BIOS loads and verifies the operating system, and after the operating system verification passes, it jumps to execute the operating system.
[0102] 3. Component 2 in the BIOS loads and verifies the startup firmware of the second system. After the startup firmware of the second system is verified successfully, the BIOS configures the starting running address of the second system and de-resets the second system, so that the second system starts to power on and run the startup firmware.
[0103] 4. The operating system in the first system loads and verifies the code of the application program, and after the code of the application program passes the verification, it jumps to execute the application program.
[0104] 5. After the startup firmware of the second system runs successfully, it enters the running state and can provide runtime services.
[0105] Based on Figure 9 the secure startup process shown, the startup process of the SoC actually has two trusted chains. Please refer to Figure 10 and Figure 11 , Figure 10 which is a schematic diagram of a trusted chain provided by an embodiment of the present application; Figure 11 which is another schematic diagram of a trusted chain provided by an embodiment of the present application. As Figure 10 shown, one of the trusted chains corresponding to the startup process of the SoC is specifically: Secure Boot Code → Component 1 in BIOS → Operating System → Application Program. As Figure 11 shown, the other trusted chain corresponding to the startup process of the SoC is specifically: Secure Boot Code → Component 2 in BIOS → Startup Firmware of the Second System.
[0106] When the second system needs to restart independently, for example, when the second system needs to update the firmware, the second system can send a hardware signal to the first system, thereby triggering the independent restart of the second system.
[0107] First, configure the runtime service configuration register of the second system, thereby triggering the sending of a hardware signal to the first system. For example, the second system and the first system are connected by a signal line, and the level of the signal line always remains high. After the second system configures the register, the level of the signal line is changed to low, thereby enabling the second system to send a hardware signal to the first system.
[0108] After the first system receives the hardware signal sent by the second system, it enters Application 1 for interrupt processing. Application 1 sends a command word to Component 2 in BIOS, thereby notifying Component 2 of the second system's request for independent restart.
[0109] The component 2 in the BIOS controls the restart of the second system. For example, the firmware in component 2 resets the second system by configuring the reset register of the second system. During the process of component restarting the second system, component 2 first performs necessary initialization on the second system, such as clearing the storage space in the second system where the boot firmware is stored. Then, component 2 reads the boot firmware of the second system (such as the updated boot firmware of the second system) from an external storage medium, such as off-chip flash, into the code running space in the second system. Secondly, component 2 uses a public key cryptography algorithm to verify the digital signature of the boot firmware of the second system. After the boot firmware of the second system passes the verification, component 2 configures the starting execution address of the second system and releases the reset of the second system by configuring the de-reset register of the second system.
[0110] Finally, the second system is powered on and starts to execute from the starting position of the boot firmware until it boots into the running state.
[0111] Generally, when updating the firmware in the processing system of the SoC, the entire SoC system needs to be reset. In this embodiment, by the way of independently restarting the second system, the boot firmware in the second system is updated, the trusted chain corresponding to the second system is rebuilt, the restart of the first system is avoided, the influence surface is reduced, the impact on the service is minimized, and the reliability of the platform is improved.
[0112] The above introduces the trusted chain reconstruction method provided by the embodiments of the present application. The following will introduce the device for executing the above trusted chain reconstruction method.
[0113] Please refer to Figure 12 , Figure 12 which is a schematic structural diagram of an SoC provided by an embodiment of the present application. As Figure 12 shown, a detection component 1201, a first component 1202 and multiple systems are running on the SoC; the detection component 1201 is used to transmit restart information to the first component 1202 when it detects that the first system 1203 needs to be restarted, where the restart information is used to indicate the execution of the restart process for the first system 1203, the first component 1202 is the previous-level node of the first system 1203 in the trusted chain, and the first system 1203 is one of the multiple systems; the first component 1202 is used to re-execute the trusted boot process of the first system 1203 based on the restart information.
[0114] In a possible implementation manner, the multiple systems are all operating systems, and the first system 1203 is one of the multiple operating systems running on the SoC.
[0115] In a possible implementation manner, the detection component 1201 is an application program running on the second system, and the second system is one of the multiple operating systems.
[0116] In a possible implementation, the first component 1202 is specifically configured to: load the code of the first system 1203 into the running space of the first system 1203 and verify the code of the first system 1203; after the code of the first system 1203 passes the verification, trigger the execution of the code of the first system 1203.
[0117] In a possible implementation, multiple systems are all processing systems, and each of the multiple systems includes an independent processor. The first system 1203 is one of the multiple processing systems running on the SoC.
[0118] In a possible implementation, the first component 1202 and the detection component 1201 run on the second system, and the second system is one of the multiple processing systems.
[0119] In a possible implementation, the first component 1202 is specifically configured to: load the startup firmware corresponding to the first system 1203 into the running space of the first system 1203 and verify the startup firmware; after the startup firmware passes the verification, trigger the execution of the startup firmware.
[0120] In a possible implementation, the detection component 1201 detects that the first system 1203 needs to be restarted, including: the detection component 1201 receives a hardware signal sent by the first system 1203, and the hardware signal is used to indicate restarting the first system 1203.
[0121] In a possible implementation, the detection component 1201 detects that the first system 1203 needs to be restarted, including: the detection component 1201 detects that the first system 1203 is in an abnormal running state.
[0122] In a possible implementation, the first component 1202 is the BIOS.
[0123] Each embodiment in this specification is described in a progressive manner. The same or similar parts among the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments.
[0124] A refers to B, which means that A is the same as B or A is a simple deformation of B.
[0125] The terms "first" and "second" in the description and claims of the embodiments of this application are used to distinguish different objects, rather than to describe a specific order of the objects, nor can they be understood as indicating or implying relative importance. For example, the first speed limit channel and the second speed limit channel are used to distinguish different speed limit channels, rather than to describe a specific order of the speed limit channels, nor can it be understood that the first speed limit channel is more important than the second speed limit channel.
[0126] In the embodiments of the present application, unless otherwise specified, "at least one" means one or more, and "a plurality" means two or more.
[0127] The above embodiments can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present application are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by wire (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that the computer can access or a data storage device such as a server or data center that includes one or more integrated available media. The available medium can be a magnetic medium (such as a floppy disk, hard disk, magnetic tape), an optical medium (such as a DVD), or a semiconductor medium (such as a solid-state disk (SSD)).
[0128] The above embodiments are only used to illustrate the technical solutions of the present application, not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments or equivalently replace some of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.
Claims
1. A trusted chain reconstruction method, characterized in that, The method is applied to a system on chip (SoC), on which a detection component, a first component, and multiple systems are running. The method includes: When the detection component detects that the first system needs to be restarted, the detection component transfers a restart message to the first component, where the restart message is used to indicate to perform a restart process on the first system. The first component is the previous-level node of the first system in the trusted chain, and the first system is one of the multiple systems. Based on the restart message, the first component re-executes the trusted boot process of the first system.
2. The method according to claim 1, characterized in that, The multiple systems are all operating systems, and the first system is one of the multiple operating systems running on the SoC.
3. The method according to claim 2, characterized in that, The detection component is an application running on the second system, and the second system is one of the multiple operating systems.
4. The method according to claim 2 or 3, characterized in that, The first component re-executing the trusted boot process of the first system includes: The first component loads the code of the first system into the running space of the first system and verifies the code of the first system. After the code of the first system passes the verification, the first component triggers the execution of the code of the first system.
5. The method according to claim 1, wherein The multiple systems are all processing systems, and the multiple systems all include independent processors. The first system is one of the multiple processing systems running on the SoC.
6. The method according to claim 5, wherein The first component and the detection component run on the second system, and the second system is one of the multiple processing systems.
7. The method according to claim 5 or 6, characterized in that, The first component re-executing the trusted boot process of the first system includes: The first component loads the startup firmware corresponding to the first system into the running space of the first system and verifies the startup firmware. After the startup firmware passes the verification, the first component triggers the execution of the startup firmware.
8. The method according to any one of claims 5-7, characterized in that The detection component detecting that the first system needs to be restarted includes: The detection component receives a hardware signal sent by the first system, and the hardware signal is used to indicate restarting the first system.
9. The method according to any one of claims 1-7, characterized in that The detection component detecting that the first system needs to be restarted includes: The detection component detects that the first system is in an abnormal running state.
10. The method according to any one of claims 1-9, characterized in that, The first component is a basic input / output system (BIOS).
11. A SoC, characterized in that, On the SoC, a detection component, a first component, and multiple systems are running; The detection component is used to transfer a restart message to the first component when detecting that the first system needs to be restarted, where the restart message is used to indicate to perform a restart process on the first system. The first component is the previous-level node of the first system in the trusted chain, and the first system is one of the multiple systems. The first component is used to re-execute the trusted boot process of the first system based on the restart message.
12. The SoC according to claim 11, wherein The multiple systems are all operating systems, and the first system is one of the multiple operating systems running on the SoC.
13. The SoC according to claim 12, wherein The detection component is an application running on the second system, and the second system is one of the multiple operating systems.
14. The SoC according to claim 12 or 13, characterized in that, The first component is specifically used for: Load the code of the first system into the running space of the first system and verify the code of the first system; After the code of the first system passes the verification, trigger the execution of the code of the first system.
15. The SoC according to claim 11, wherein, The multiple systems are all processing systems, and each of the multiple systems includes an independent processor. The first system is one of the multiple processing systems running on the SoC.
16. The SoC according to claim 15, characterized in that, The first component and the detection component run on the second system, and the second system is one of the multiple processing systems.
17. The SoC according to claim 15 or 16, characterized in that, The first component is specifically configured to: Load the startup firmware corresponding to the first system into the running space of the first system and verify the startup firmware; After the startup firmware passes the verification, trigger the execution of the startup firmware.
18. The SoC according to any one of claims 15-17, characterized in that, The detection component detects that the first system needs to be restarted, including: The detection component receives a hardware signal sent by the first system, and the hardware signal is used to indicate restarting the first system.
19. The SoC according to any one of claims 11-17, characterized in that, The detection component detects that the first system needs to be restarted, including: The detection component detects that the first system is in an abnormal operating state.
20. A network device, comprising a processor and a memory, the memory is used to store program code, and the processor is used to execute the method according to any one of claims 1-10.
Citation Information
Cited By
Double-trigger independent restarting method, device and equipment for SoC (System on Chip) chip domain of in-vehicle infotainment system
CN122044951A