System startup methods, devices, electronic equipment and media

Abstract

This application provides a system startup method, apparatus, electronic device, and medium, relating to the field of computer technology. The method includes: determining the current startup state of a target system; the startup state indicating whether the target system is in the boot read-only memory stage, the boot loader stage, or the boot application stage; acquiring the input / output holding (IOHold) mechanism corresponding to the startup state, and controlling the input / output (I / O) interfaces of the target system based on the IOHold mechanism; the IOHold mechanism indicating I / O interfaces to be released in the current startup state. This method achieves the effect of flexible control of I / O interfaces during system startup.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a system startup method, apparatus, electronic device and medium. Background Technology

[0002] With the development of fields such as automotive, industrial control, and the Internet of Things, embedded systems are widely used in various mission-critical environments. These application scenarios place extremely high demands on the security of embedded systems, especially during the startup process. Ensuring that embedded systems can withstand potential attacks and prevent the execution of insecure code has become a significant technical challenge.

[0003] Currently, to ensure the security of embedded system startup, known technologies propose using an IOHold mechanism to keep all input / output I / O interfaces locked until the embedded system has finished booting, at which point they are unlocked.

[0004] The above process suffers from the drawback of being unable to flexibly manage I / O interfaces, which is detrimental to the timeliness of embedded systems. Summary of the Invention

[0005] This application provides an embedded system startup method, apparatus, electronic device, and medium to achieve flexible management of I / O interfaces during the embedded system startup process, thereby improving the timeliness of the embedded system.

[0006] In a first aspect, embodiments of this application provide an embedded system startup method, including:

[0007] Determine the current boot state of the target system; the boot state is used to indicate that the target system is in any one of the boot read-only memory stage, boot loader stage, or boot application stage.

[0008] The IOHold mechanism corresponding to the startup state is obtained, and the input / output I / O interface of the target system is controlled based on the IOHold mechanism; the IOHold mechanism is used to indicate the I / O interface to be released in the current startup state.

[0009] In one possible implementation, the IOHold mechanism corresponding to the boot read-only memory stage is used to instruct all I / O interfaces to remain in a locked state; the IOHold mechanism corresponding to the bootloader stage is used to instruct the release of at least some I / O interfaces; and the IOHold mechanism corresponding to the boot application stage is used to instruct the release of all I / O interfaces.

[0010] In one possible implementation, when the startup state indicates that the target system is in the bootloader stage, the control of the input / output I / O interface of the target system based on the IOHold mechanism includes:

[0011] Obtain the security level of the I / O interface; the security level is determined by security influencing factors, including at least one of access depth, potential attack vectors, and interface applications.

[0012] The I / O interface of the target system is controlled according to the security level and the IOHold mechanism.

[0013] In one possible implementation, controlling the I / O interface of the target system according to the security level and the IOHold mechanism includes:

[0014] If the security level of the I / O interface is low, then release the I / O interface; and / or,

[0015] If the security level of the I / O interface is medium security, then when the I / O interface meets the first preset condition, the I / O interface is released; when the I / O interface does not meet the first preset condition, the I / O interface is kept in a locked state; and / or,

[0016] If the security level of the I / O interface is high, then the I / O interface is released when the I / O interface meets the second preset condition; if the I / O interface does not meet the second preset condition, the I / O interface is kept in a locked state.

[0017] The first preset condition includes: the target system receives an access request for the I / O interface from an authorized external target system; the second preset condition includes: the target system enters a debug mode based on the I / O interface, or the target system executes a critical task based on the I / O interface.

[0018] In one possible implementation, determining the current startup state of the target system includes:

[0019] Before the target system is detected to be powered on and the boot read-only memory stage has ended, the startup state is determined to indicate that the target system is in the boot read-only memory stage;

[0020] Before the boot read-only memory phase ends, the loader passes verification, and the bootloader phase ends, the startup state is determined to indicate that the target system is in the bootloader phase;

[0021] When the bootloader phase is detected to have ended and the application has been verified, the startup state is determined to indicate that the target system is in the boot application phase.

[0022] In one possible implementation, when the target system is in any startup state, the method further includes:

[0023] Upon receiving an unauthorized access request to any target I / O interface, it is determined that the target system is abnormal;

[0024] The startup process is stopped and the system enters safe mode. When the target system is in safe mode, all I / O interfaces of the target system except for the debug interface are locked. The debug interface is used to implement the target system recovery operation.

[0025] In one possible implementation, the method further includes:

[0026] If the integrity of the boot firmware of the target system is defective, roll back to the target boot firmware; the boot firmware corresponds to the loader or application; the target boot firmware is a boot firmware that can boot successfully in a historical version;

[0027] If the rollback is successful, the target system will be started based on the target boot firmware;

[0028] Otherwise, the target system is controlled to enter a safe mode. When the target system is in safe mode, all I / O interfaces of the target system except for the debug interface are locked. The debug interface is used to implement the target system recovery operation.

[0029] Secondly, embodiments of this application provide an embedded system boot device, comprising:

[0030] A determination module is used to determine the current startup state of the target system; the startup state is used to indicate that the target system is in any one of the boot read-only memory stage, boot loader stage, or boot application stage.

[0031] The control module is used to obtain the input / output hold (IOHold) mechanism corresponding to the startup state, and control the input / output I / O interfaces of the target system based on the IOHold mechanism; the IOHold mechanism is used to indicate the I / O interfaces to be released in the current startup state.

[0032] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0033] The memory stores computer-executed instructions;

[0034] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0035] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0036] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0037] The embedded system startup method, apparatus, electronic device, and medium provided in this application achieve flexible management of the embedded system's I / O interface during startup by determining the corresponding I / O OHold mechanism based on the current startup state of the embedded system and controlling the embedded system's I / O interface through the corresponding I / O OHold mechanism. This improves the timeliness of the embedded system startup process while ensuring its security. Attached Figure Description

[0038] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0039] Figure 1 A schematic diagram illustrating a scenario for the system startup method provided in this application;

[0040] Figure 2 Flowchart of the system startup method provided in this application Figure 1 ;

[0041] Figure 3 Flowchart of the system startup method provided in this application Figure 2 ;

[0042] Figure 4 A complete process diagram of the system startup method provided in this application;

[0043] Figure 5 A schematic diagram of the system startup device provided in this application;

[0044] Figure 6 A schematic diagram of the structure of the electronic device provided in this application.

[0045] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0046] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0047] First, let me explain the terms used in this application:

[0048] An embedded system is a specialized computing system designed to perform specific tasks or functions. It is typically embedded within a larger device or system to provide specific control, monitoring, or processing capabilities.

[0049] Boot ROM (Read-Only Memory) Stage: This is the initial stage in the boot process of a computer system or embedded system. In this stage, the system executes the boot code stored in the read-only memory (ROM). The main purpose of this stage is to perform basic hardware initialization and prepare for the subsequent boot process.

[0050] The bootloader stage is a crucial phase in the startup process of a computer system or embedded system. During this stage, the system executes the bootloader's code. The bootloader is a small program responsible for further hardware initialization, loading the operating system or applications into memory, and transferring control to them.

[0051] The application boot phase is the final stage of the system startup process. During this phase, the system has completed all necessary initialization tasks and begins executing the main application code. This stage marks the transition of the system from the startup state to the normal operating state.

[0052] Input / output hold (IOHold) mechanism: During system startup, the timing requirements that the system's input / output (I / O) interfaces need to meet.

[0053] In addition to the terms mentioned above, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. In the following descriptions of embodiments, "a plurality of" means two or more, unless otherwise explicitly defined.

[0054] Currently, embedded systems are widely used in various industries, including consumer electronics, automobiles, industrial automation, medical devices, and communications. For example, smartphones, home appliances, in-vehicle navigation systems, and robots all rely on embedded systems to achieve specific functions and improve efficiency.

[0055] With the development of technology, embedded systems are increasingly being used in fields such as automotive, industrial control, and the Internet of Things. These fields typically involve mission-critical environments, which place extremely high demands on the security of embedded systems. In particular, ensuring that embedded systems can withstand potential attacks and prevent the execution of insecure code during system startup has become a significant technical challenge.

[0056] For example, during the startup process of an embedded system, the startup code (usually the bootloader) is responsible for downloading and initializing the system's critical functions and preparing for application execution. If the startup code is not effectively protected during this process, the following security issues may arise:

[0057] Bootloader tampering: Attackers may inject malicious code by modifying the bootloader or applications, thereby gaining control of the entire system.

[0058] External device interference: During the system startup phase, unlocked I / O interfaces may be maliciously exploited by external devices or attackers, leading to the leakage of sensitive information or unauthorized control of the device.

[0059] Firmware rollback attack: Attackers may roll back to an older version or a vulnerable firmware and exploit known security flaws to launch an attack.

[0060] To address these security threats, many embedded systems have introduced the concept of Secure Boot, a step-by-step boot process where each stage verifies the integrity of the previous stage, ensuring that only verified and trusted code can be executed.

[0061] Furthermore, in embedded systems, I / O interfaces (such as SPI, UART, and I2C) are used to communicate with external devices. However, embedded systems often haven't completed security verification during the boot phase. If I / O interfaces are exposed at this stage, attackers can maliciously interfere with the system or even tamper with the boot process, affecting the correctness of the system startup. On the other hand, the system may process sensitive data during boot; if the I / O interfaces are not effectively locked, external devices can steal this sensitive data through these interfaces, leading to information leakage.

[0062] Therefore, known technologies propose setting an IOHold mechanism to lock all I / O interfaces until the system completes the boot process, ensuring that external devices cannot interfere with the system through the I / O interfaces before the system is fully verified.

[0063] However, in the above process, some I / O interfaces need to be released in the later stages of startup, while others can be unlocked and used to communicate with external devices after the initial security verification is passed. Keeping all I / O interfaces locked during system startup at this time prevents flexible control of the I / O interfaces, thus hindering system timeliness.

[0064] For example, in an automotive embedded system, the system status needs to be reported via the CAN bus during startup. If the corresponding I / O interface remains locked during the startup of the automotive embedded system, the system will be unable to communicate with external devices in a timely manner, resulting in communication delay.

[0065] Therefore, this application proposes a system startup method, apparatus, electronic device, and medium to solve the above-mentioned problems. Specifically, in the system startup method of this application, the I / O interface of the system is controlled by adopting a corresponding IOHold mechanism when the system is in different startup states. This enables flexible control of the system I / O interface during the system startup process, thereby improving the flexibility of I / O interface management during system startup, effectively ensuring the timeliness of system startup, and also helping to ensure the security of the system during startup.

[0066] It is understood that the system startup method of this application can be executed by any electronic device, and the system startup method of this application is applicable to any scenario with extremely high security requirements, such as vehicle-mounted and industrial control systems. For example, Figure 1 A schematic diagram illustrating the system startup method provided in this application, such as... Figure 1 As shown, this application can be used in an in-vehicle embedded system. Specifically, the in-vehicle embedded system interacts with an electronic device configured with the system startup method of this application.

[0067] During the startup process of the vehicle-mounted embedded system, the electronic device determines the current startup state of the vehicle-mounted embedded system and further determines the IOHold mechanism corresponding to the current startup state. Based on the IOHold mechanism, it controls the I / O interface of the vehicle-mounted embedded system to maintain or unlock it.

[0068] Based on this setting, the vehicle-mounted embedded system can flexibly control the I / O interface during startup, releasing unlockable I / O interfaces when necessary, ensuring both startup security and timeliness of the vehicle-mounted embedded system.

[0069] It is understood that electronic devices can be integrated into in-vehicle embedded systems or interact with them as standalone devices; this embodiment does not limit this. When an electronic device interacts with an in-vehicle embedded system as a standalone device, the electronic device should be a trusted and authorized device.

[0070] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0071] Figure 2 Flowchart of the system startup method provided in this application Figure 1 ,like Figure 2 As shown, the method includes:

[0072] S201. Determine the current startup status of the target system.

[0073] Specifically, the startup status is used to indicate whether the target system is in the boot read-only memory stage, the boot loader stage, or the boot application stage;

[0074] In this embodiment, the startup process of the target system is divided into three stages: the BootROM stage, the Bootloader stage, and the boot application stage. The startup status is used to indicate the current stage of the target system.

[0075] It is understood that in this embodiment, the target system is specifically the embedded system mentioned above. In practical applications, the target system can also be any other system whose boot process includes three stages: BootROM stage, Bootloader stage, and boot application stage, such as general-purpose computer systems, mobile devices, network devices, server systems, etc. This embodiment does not limit this.

[0076] In this embodiment, the electronic device determines the startup state to indicate that the target system is in the BootROM stage before detecting that the chip containing the target system is powered on and before the boot read-only memory stage has ended.

[0077] Specifically, in this embodiment, the chip integrates a voltage monitoring circuit to detect whether the power supply voltage reaches a preset threshold. When the voltage stabilizes and exceeds the threshold, the voltage monitoring circuit generates a power-on signal and transmits it to the electronic device, enabling the electronic device to determine that the chip containing the target system is powered on, thereby determining that the target system has entered the BootROM stage. At this time, if the electronic device determines that the target system remains in the BootROM stage until the boot read-only memory stage has ended, it is incorrect.

[0078] It is understandable that in practical applications, if the chip is equipped with a power management circuit for detecting power supply stability, once the power supply reaches a stable state, the power management circuit generates a reset signal. The electronic device can then connect to this power management circuit and, by receiving the reset signal, determine whether the chip containing the target system is powered on, thereby determining whether the target system has entered the BootROM stage. Furthermore, the electronic device can also determine whether the chip containing the target system is powered on through other means; this embodiment does not limit this method.

[0079] It should be understood that the BootROM area itself is immutable. Therefore, the tasks of the target system at this stage include: loading and verifying the integrity of the loader, and initializing the lowest-level hardware modules. Specifically, at this stage, the target system also needs to ensure that the loader is read from an immutable storage area. More specifically, in this embodiment, the integrity of the loader is verified through signature verification based on the Hardware Root of Trust (HSM).

[0080] Furthermore, in this embodiment, after completing all its initialization tasks, the BootROM code sets a first flag or status register to indicate that the BootROM phase has successfully ended. The electronic device uses this first flag or status register to determine whether the end of the BootROM phase has been detected; if not, it determines that the target system is still in the BootROM phase.

[0081] In this embodiment, the electronic device determines the startup state to indicate that the target system is in the Bootloader stage before detecting the end of the BootROM stage, the successful verification of the loader, and the completion of the bootloader stage. Specifically, in this embodiment, the BootROM is provided with a second flag bit to indicate whether the loader has been verified. The electronic device uses this second flag bit to determine whether the integrity of the loader has been verified, and uses the aforementioned first flag bit to determine whether the end of the BootROM stage has been detected.

[0082] Once the BootROM detection phase ends and the loading program passes verification, the electronic device determines that the target system has entered the Bootloader phase. Before detecting the end of the Bootloader phase, the electronic device determines that the target system is still in the Bootloader phase.

[0083] Understandably, after the target system enters the Bootloader stage, the Bootloader, verified by the BootROM, begins execution. Its main responsibility is to load and verify the integrity of the application, and to initialize more external devices and system resources, such as storage and communication modules. Specifically, in this embodiment, the Bootloader stage uses a hardware root of trust to verify the digital signature of the application.

[0084] In this embodiment, the target system is provided with a third flag bit to indicate that the Bootloader stage has been successfully completed. The electronic device uses this third flag bit to determine whether the Bootloader stage has been detected as completed. If it has not been completed, it is determined that the target system is still in the Bootloader stage.

[0085] In this embodiment, when the electronic device detects the end of the bootloader phase and that the application has passed verification, it determines the startup state to indicate that the target system is in the application booting phase. Specifically, in this embodiment, the target system has a fourth flag bit used to indicate whether the application has passed verification; the electronic device determines whether the application has passed verification based on this fourth flag bit.

[0086] Specifically, after the application is verified by the bootloader, it is loaded and run, completing the final initialization of the target system and entering normal operation mode. In this embodiment, the bootstrap application stage is specifically responsible for the execution of business logic, such as the control logic of the Electronic Control Unit (ECU) in an in-vehicle system, and real-time control tasks in industrial control.

[0087] S202. Obtain the input / output holding IOHold mechanism corresponding to the startup state, and control the input / output I / O interface of the target system based on the IOHold mechanism.

[0088] The IOHold mechanism is used to indicate I / O interfaces that are to be released in the current startup state.

[0089] It should be understood that after the target system is powered on or reset, all its I / O interfaces should be in a locked state. At this time, any I / O request from an external device will be rejected to prevent unauthorized access before the target system has finished booting. Based on this, the IOHold mechanism is used to control the I / O interfaces of the target system, specifically by releasing the corresponding I / O interfaces or keeping the corresponding I / O interfaces in a locked state.

[0090] Since the security requirements of each startup state of the target system are inconsistent, in this embodiment, each startup state corresponds to an IOHold mechanism.

[0091] Specifically, when the target system's current boot state indicates it is in the BootROM stage, all I / O interfaces should be kept locked to prevent unauthorized access before booting is complete. When the target system's current boot state indicates it is in the Bootloader stage, corresponding I / O interfaces, such as simple control signal interfaces, can be released as needed. When the target system is in the application booting stage, after the application has finished loading and been successfully verified, its corresponding I / O interfaces are unlocked to allow timely interaction with external devices.

[0092] Therefore, in this embodiment, the IOHold mechanism corresponding to the boot read-only memory stage is used to instruct all I / O interfaces to remain in a locked state; the IOHold mechanism corresponding to the bootloader stage is used to instruct the release of at least some I / O interfaces; and the IOHold mechanism corresponding to the boot application stage is used to instruct the release of all I / O interfaces.

[0093] It should be understood that during the application boot process, the electronic device releases the corresponding I / O interface after the application has been verified. If the application corresponding to the I / O interface fails verification, it should remain locked until the application is verified.

[0094] The system startup method provided in this application improves the flexibility of I / O interface control while ensuring the security of the startup process by controlling the I / O interfaces of the target system based on the IOHold mechanism corresponding to each startup state indication stage, thereby helping to ensure the timeliness of the system.

[0095] As a preferred implementation, when the target system is in the BootROM stage or Bootloader stage, if it is necessary to release at least two I / O interfaces, the interface priorities of at least two I / O interfaces can be obtained, and the I / O interface with the higher interface priority can be released first.

[0096] The interface priority of at least two I / O interfaces can be determined by at least one of the following: the urgency of the application corresponding to the interface, the response time of the interface request, etc. For example, if the urgency of the application corresponding to one I / O interface is greater than that of another I / O interface, then the interface priority of the first I / O interface is higher than that of the second I / O interface. If the response time of the interface request corresponding to one I / O interface is shorter than that of another I / O interface, then the interface priority of the first I / O interface is higher than that of the second I / O interface.

[0097] It is understandable that in practical applications, the interface priority of at least two I / O interfaces is not limited to being determined by the aforementioned two items. For example, electronic devices can also determine their interface priority by combining the fault prediction results corresponding to the I / O interfaces.

[0098] Specifically, the electronic device collects and records various fault information that occurs during the historical startup process of the target system, including I / O interface faults and startup failures, and establishes a fault database. Using the fault information in this database, a predictive model (such as time series analysis or anomaly detection algorithms) is built to identify potential fault trends. Based on this, the electronic device can predict possible I / O interface faults before or during the startup of the target system using this predictive model, thereby obtaining fault prediction results for at least two I / O interfaces.

[0099] For I / O interfaces whose fault prediction results indicate that interface failure may occur, their interface priority can be appropriately lowered to adjust their release order later, thereby allowing time to start backup interfaces and perform other remedial measures.

[0100] Optionally, the electronic device may also determine the interface priority of at least two I / O interfaces by combining the power-on timing of external devices connected to the I / O interface. This embodiment does not limit this.

[0101] It is understandable that, in order to improve the startup efficiency and response speed of the target system, parallel computing technology can also be used in practical applications to release at least two I / O interfaces at the same time. This implementation does not limit this.

[0102] Based on the foregoing embodiments, this application also provides a method embodiment for further detailed explanation of the system startup method of this application. Specifically, this embodiment specifically describes the IOHold mechanism corresponding to the Bootloader stage.

[0103] Figure 3 Flowchart of the system startup method provided in this application Figure 2 ,like Figure 3 As shown, the method in this embodiment includes:

[0104] S301. When the current boot state of the target system indicates that the target system is in the bootloader stage, obtain the security level of the I / O interface.

[0105] The security level is determined by security influencing factors, which include at least one of the following: access depth, potential attack vectors, and interface applications.

[0106] In this embodiment, the electronic device classifies the I / O interface of the target system into three levels: low security level, medium security level, and high security level, according to security impact factors.

[0107] Specifically, in this embodiment, the security level of the I / O interface is determined based on the three security influencing factors mentioned above: access depth, potential attack vectors, and interface application. The specific determination process is as follows:

[0108] 1. If the access depth of the I / O interface indicates that it can directly access the critical areas of the target system (internal storage, firmware, memory, etc. of the target system).

[0109] And / or, the potential attack vectors of the I / O interface indicate that if it is attacked or abused, it may cause the target system to suffer any of the following: crash, data leakage, malicious code injection, etc.

[0110] If the application of the I / O interface indicates that it is primarily used for sensitive operations or for interacting with external devices (such as debugging tools, programmers, etc.) and may be used to access or control the target system, then the security level of the I / O interface is determined to be high security level.

[0111] For example, for debug interfaces such as JTAG and SWD, their application indicates that they are used for development and debugging, their access depth indicates that they can directly access the chip's internal memory and registers, and their potential attack vector indicates that if they are enabled during the boot phase, they could be exploited for deep system tampering. Therefore, the security level corresponding to such debug interfaces should be high.

[0112] For interfaces such as SPI and UART, which are commonly used for firmware updates, debugging, or data transfer, leaving these interfaces open may allow attackers to inject unauthorized code during the boot process. In other words, their potential attack vectors indicate that if attacked or misused, they could lead to malicious code injection into the target system. Therefore, these interfaces should also be assigned a high security level.

[0113] 2. If the access depth of the I / O interface indicates that it can only access a limited area or can only perform controlled operations;

[0114] And / or, the potential attack vectors of the I / O interface indicate that it may be used to obtain the target system status or network data, but will not cause the target system to suffer any of the following: crash, data leakage, malicious code injection, etc.

[0115] And / or, if the I / O interface is used to communicate or transmit data with external devices or modules during startup, but has limited direct control over the target system, then its corresponding security level is determined to be medium security level.

[0116] For example, interfaces such as CAN bus interfaces and LIN bus interfaces, which are used for communication protocols of the target system, are mainly used to transfer information between electronic control units (ECUs). Although these interfaces do not have the ability to directly control the system, they can expose system status information. Therefore, their corresponding security level is medium security.

[0117] Interfaces used for communication between devices, such as Ethernet interfaces, can be exploited by attackers to eavesdrop on or interfere with network communications if left uncontrolled. Therefore, their corresponding security level is medium security.

[0118] 3. If the access depth of the I / O interface indicates that its access capability is very limited, that is, it is usually only used to provide status information or implement simple control;

[0119] And / or, the potential attack vectors of the I / O interface indicate that even if they are exploited, they will not pose a substantial threat to the core functions or data of the target system;

[0120] If the application of the I / O interface indicates that it is only used for internal state transfer or simple signal control of the target system and does not involve bidirectional communication, then its corresponding security level is determined to be low security level.

[0121] For example, for interfaces like GPIO, the access depth indicates that they are used to provide simple input / output operations, such as controlling LEDs or buzzers, providing only system startup status or fault information, without involving any sensitive data or having data transmission capabilities. Therefore, their corresponding security level is low security.

[0122] Furthermore, in this embodiment, the electronic device controls the I / O interface of the target system according to the security level and the IOHold mechanism. The specific process is described in S302-S304 below.

[0123] S302. If the security level of the I / O interface is low, then release the I / O interface.

[0124] Understandably, low-security I / O interfaces generally do not involve the transmission of sensitive data, have limited access capabilities, and are used for simple status indications or user interactions. Even if they are completely released during the boot process, they will not pose a threat to the overall security of the target system. Therefore, these interfaces can be completely released during the bootloader phase.

[0125] S303. If the security level of the I / O interface is medium security level, then when the I / O interface meets the first preset condition, the I / O interface is released; when the I / O interface does not meet the first preset condition, the I / O interface is kept in a locked state.

[0126] The first preset condition includes: the target system receives an access request for the I / O interface from an authorized external system.

[0127] In this embodiment, when the target system is in the Bootloader stage, after the Bootloader passes the security verification, it selectively releases the I / O interfaces with a medium security level.

[0128] Specifically, if the I / O interface receives an access request from an authorized external system, the I / O interface can be released to allow the target system to report its startup status to external devices or systems or receive external control commands, facilitating external monitoring and rapid response. Otherwise, the I / O interface remains locked.

[0129] S304. If the security level of the I / O interface is high security level, the I / O interface is released when the second preset condition is met; if the I / O interface does not meet the second preset condition, the I / O interface is kept in a locked state.

[0130] The second preset condition includes: the target system entering a debug mode based on the I / O interface, or the target system executing a critical task based on the I / O interface.

[0131] Understandably, high-security I / O interfaces typically have the ability to access the target system's internal memory or controller. If released during the bootloader phase, they could be exploited to inject malicious code or interfere with the target system's startup. Therefore, these I / O interfaces should generally be kept locked to prevent unauthorized access, unless the target system is in debug mode or needs to perform critical tasks.

[0132] Specifically, when the target system is in the Bootloader stage, it listens for external access. When it detects access to I / O interfaces used for debugging or executing critical tasks, it determines that the target system is in debug mode or needs to execute a critical task. It can be understood that critical tasks could include firmware updates, etc.

[0133] In the method provided in this application embodiment, when the target system is in the Bootloader stage, the I / O interface of the target system is controlled by means of security level classification of the I / O interface, so as to achieve the effect of flexible control of the I / O interface of the target system. This ensures that the target system can respond in a timely manner while ensuring the security of the target system startup, thereby effectively avoiding the problem of communication delay.

[0134] In one possible implementation, during the startup process of the target system, the electronic device detects whether there are any abnormalities in the target system and takes appropriate action when abnormalities are found.

[0135] Specifically, if the target system receives an unauthorized access request to any target I / O interface while it is in any startup state, it will determine that an anomaly has occurred, stop the startup process, and enter safe mode.

[0136] When the target system is in safe mode, all I / O interfaces of the target system except for the debug interface are locked. The debug interface is used to implement the target system recovery operation.

[0137] In this embodiment, if the electronic device detects an unauthorized access request to an I / O interface when the target system is in any boot state, such as a forced access to an I / O interface that has not yet been unlocked, the target system immediately stops the boot process and triggers the IOHold locking mechanism to lock all I / O interfaces of the target system except for the debug interface. At this time, the target system is in a safe mode, in which the target system is only allowed to perform recovery operations through the restricted debug interface.

[0138] Furthermore, in this embodiment, in addition to identifying anomalies through external access requests, the electronic device can also identify anomalies by detecting hardware errors. Specifically, when the electronic device detects power fluctuations, external clock signals, or other hardware anomalies, it also determines that the target system is abnormal. At this time, it also needs to enter a safe mode to ensure that all non-critical functions are stopped in order to maintain a minimum system operating state.

[0139] With this setting, electronic devices can promptly detect anomalies during the target system's startup process and lock the corresponding I / O interfaces of the target system in a timely manner when anomalies occur, thereby ensuring the security of the target system.

[0140] In another possible implementation, the electronic device checks the integrity of the target system's boot firmware. If the integrity of the target system's boot firmware is defective, it rolls back to the target boot firmware. If the rollback is successful, the target system is started based on the target boot firmware. Otherwise, the target system is controlled to enter a safe mode.

[0141] Among them, the boot firmware corresponds to the loading program or application; when the target system is in safe mode, all I / O interfaces of the target system except for the debug interface are locked, and the debug interface is used to implement the target system recovery operation.

[0142] In this embodiment, the target boot firmware is specifically the version that was last successfully booted. Specifically, if the loader or application passes security verification, its integrity is determined to be without defects. Otherwise, its integrity is determined to be defective, and in this case, the system is rolled back to the target boot firmware, and a restart attempt is made based on that target boot firmware. If the rollback fails, the target system is put into safe mode.

[0143] With the above settings, on the one hand, if the rollback is successful, the startup stability of the target system can be guaranteed. On the other hand, if the rollback fails, the target system can be put into safe mode in a timely manner, ensuring the security of the target system.

[0144] Understandable Figure 4 A complete process diagram of the system startup method provided in this application is shown below. Figure 4 As shown, in the method of this embodiment, when the electronic device detects that the target system is powered on, it enters the BootROM stage. In this stage, the electronic device keeps all I / O interfaces of the target system locked, and the tasks of this stage are: loading and verifying the integrity of the loader, and initializing the lowest-level hardware modules. Furthermore, if the bootloader fails verification, it rolls back to the corresponding target boot firmware. If the rollback is successful, the target system is restarted; if the rollback fails, the target system enters safe mode.

[0145] When the electronic device detects the end of the BootROM phase and that the Bootloader has passed verification, it enters the Bootloader phase. While the target system is in the Bootloader phase, the electronic device releases at least some I / O interfaces based on the corresponding IOHold mechanism. The tasks of this phase are: loading and verifying the integrity of the application, and initializing more external devices and system resources. Furthermore, if the application fails verification, it rolls back to the corresponding target boot firmware. If the rollback is successful, the target system restarts; if the rollback fails, the target system enters safe mode.

[0146] Once the electronic device detects the end of the Bootloader phase and that the application verification has passed, it enters the bootloader phase. When the target system is in the application boot phase, the electronic device releases all I / O interfaces based on the IOHold mechanism corresponding to the application boot phase.

[0147] This application also provides an embodiment of a system startup device. Figure 5 A schematic diagram of the system startup device provided in this application is shown below. Figure 5 As shown, the system startup device provided in this embodiment includes:

[0148] The determination module 51 is used to determine the current boot state of the target system; the boot state is used to indicate that the target system is in any one of the boot read-only memory stage, boot loader stage, or boot application stage.

[0149] The control module 52 is used to obtain the input / output hold IOHold mechanism corresponding to the startup state, and control the input / output I / O interface of the target system based on the IOHold mechanism; the IOHold mechanism is used to indicate the I / O interface to be released in the current startup state.

[0150] In one possible implementation, the IOHold mechanism corresponding to the boot read-only memory stage is used to instruct all I / O interfaces to remain locked; the IOHold mechanism corresponding to the bootloader stage is used to instruct the release of at least some I / O interfaces; and the IOHold mechanism corresponding to the boot application stage is used to instruct the release of all I / O interfaces.

[0151] In one possible implementation, when the startup status indicates that the target system is in the bootloader stage, the control module 52 is specifically used for:

[0152] Obtain the security level of the I / O interface; the security level is determined by security influencing factors, which include access depth, potential attack vectors, and at least one of the interface applications.

[0153] Control the I / O interfaces of the target system based on security level and IOHold mechanism.

[0154] In one possible implementation, the control module 52 is specifically used for:

[0155] If the I / O interface has a low security level, then release the I / O interface; and / or,

[0156] If the security level of the I / O interface is medium security, then when the I / O interface meets the first preset condition, the I / O interface is released; when the I / O interface does not meet the first preset condition, the I / O interface is kept in a locked state; and / or,

[0157] If the security level of the I / O interface is high, the I / O interface will be released when the second preset condition is met; if the I / O interface does not meet the second preset condition, the I / O interface will be kept in a locked state.

[0158] The first preset condition includes: the target system receives an access request for the I / O interface from an authorized external target system; the second preset condition includes: the target system enters a debug mode based on the I / O interface, or the target system executes a critical task based on the I / O interface.

[0159] In one possible implementation, the determining module 51 is specifically used for:

[0160] Before the target system is detected to be powered on and the boot read-only memory stage has ended, the boot status is determined to indicate that the target system is in the boot read-only memory stage;

[0161] Before the boot read-only memory stage is detected to have ended, the loader has passed verification, and the bootloader stage has not ended, the startup status is determined to indicate that the target system is in the bootloader stage;

[0162] When the bootloader phase is detected to have ended and the application has been verified, the startup status is determined to indicate that the target system is in the application boot phase.

[0163] In one possible implementation, the control module 52 is also used for:

[0164] When the target system is in any startup state, if an unauthorized access request is received on any target I / O interface, it is determined that the target system is abnormal;

[0165] The startup process is stopped and the system enters safe mode. When the target system is in safe mode, all I / O interfaces of the target system except for the debug interface are locked. The debug interface is used to implement the target system recovery operation.

[0166] In one possible implementation, the control module 52 is also used for:

[0167] If the integrity of the target system's boot firmware is flawed, roll back to the target boot firmware; the boot firmware corresponds to the loader or application; the target boot firmware is a boot firmware that can boot successfully in a previous version;

[0168] If the rollback is successful, the target system will be booted based on the target boot firmware;

[0169] Otherwise, the target system is controlled to enter safe mode. When the target system is in safe mode, all I / O interfaces of the target system except for the debug interface are locked. The debug interface is used to implement the target system recovery operation.

[0170] The system startup device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0171] This application also provides an electronic device, Figure 6 A schematic diagram of the structure of the electronic device provided in this application. Figure 6 As shown, the electronic device provided in this embodiment includes a processor 61 and a memory 62. The processor 61 and the memory 62 are connected, for example, via a bus 63. Optionally, the electronic device may also include a transceiver 64. It should be noted that in practical applications, the transceiver 64 is not limited to one, and the structure of this electronic device does not constitute a limitation on the embodiments of this application.

[0172] Processor 61 may be a central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 61 may also be a combination that implements computational functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc.

[0173] Bus 63 may include a pathway for transmitting information between the aforementioned components. Bus 63 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Bus 63 may be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 6 The bus 63 is represented by only one thick line, but this does not mean that there is only one bus 63 or one type of bus 63.

[0174] The memory 62 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto.

[0175] The memory 62 is used to store application code that executes the solution of this application, and its execution is controlled by the processor 61. The processor 61 is used to execute the application code stored in the memory 62 to implement the content shown in the foregoing method embodiments.

[0176] This application also provides a computer-readable storage medium, which may include various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk. Specifically, the computer-readable storage medium stores program instructions, which are used to implement the methods in the above embodiments.

[0177] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the technical solution of the above method embodiments. Its implementation principle and technical effects are similar, and will not be repeated here.

[0178] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the claims.

[0179] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A system startup method, characterized in that, include: Determine the current boot state of the target system; the boot state is used to indicate that the target system is in any one of the boot read-only memory stage, boot loader stage, or boot application stage. The IOHold mechanism corresponding to the startup state is obtained, and the input / output I / O interface of the target system is controlled based on the IOHold mechanism; the IOHold mechanism is used to indicate the I / O interface to be released in the current startup state; The IOHold mechanism corresponding to the boot read-only memory stage instructs all I / O interfaces to remain locked, the IOHold mechanism corresponding to the bootloader stage instructs at least some I / O interfaces to be released based on the security level of the I / O interfaces, and the IOHold mechanism corresponding to the boot application stage instructs all I / O interfaces to be released; the security level is determined by access depth, potential attack vectors, and at least one security influencing factor in the interface application.

2. The method according to claim 1, characterized in that, When the startup state indicates that the target system is in the bootloader stage, the control of the input / output I / O interface of the target system based on the IOHold mechanism includes: Obtain the security level of the I / O interface; The I / O interface of the target system is controlled according to the security level and the IOHold mechanism.

3. The method according to claim 2, characterized in that, The step of controlling the I / O interface of the target system according to the security level and the IOHold mechanism includes: If the security level of the I / O interface is low, then release the I / O interface; and / or, If the security level of the I / O interface is medium security, then when the I / O interface meets the first preset condition, the I / O interface is released; when the I / O interface does not meet the first preset condition, the I / O interface is kept in a locked state; and / or, If the security level of the I / O interface is high, then the I / O interface is released when the I / O interface meets the second preset condition; if the I / O interface does not meet the second preset condition, the I / O interface is kept in a locked state. The first preset condition includes: the target system receives an access request for the I / O interface from an authorized external target system; the second preset condition includes: the target system enters a debug mode based on the I / O interface, or the target system executes a critical task based on the I / O interface.

4. The method according to claim 1, characterized in that, Determining the current startup status of the target system includes: Before the target system is detected to be powered on and the boot read-only memory stage has ended, the startup state is determined to indicate that the target system is in the boot read-only memory stage; Before the boot read-only memory phase ends, the loader passes verification, and the bootloader phase ends, the startup state is determined to indicate that the target system is in the bootloader phase; When the bootloader phase is detected to have ended and the application has been verified, the startup state is determined to indicate that the target system is in the boot application phase.

5. The method according to claim 1, characterized in that, When the target system is in any startup state, the method further includes: Upon receiving an unauthorized access request to any target I / O interface, it is determined that the target system is abnormal; The startup process is stopped and the system enters safe mode. When the target system is in safe mode, all I / O interfaces of the target system except for the debug interface are locked. The debug interface is used to implement the target system recovery operation.

6. The method according to claim 1, characterized in that, The method further includes: If the integrity of the boot firmware of the target system is defective, roll back to the target boot firmware; the boot firmware corresponds to the loader or application; the target boot firmware is a boot firmware that can boot successfully in a historical version; If the rollback is successful, the target system will be started based on the target boot firmware; Otherwise, the target system is controlled to enter a safe mode. When the target system is in safe mode, all I / O interfaces of the target system except for the debug interface are locked. The debug interface is used to implement the target system recovery operation.

7. A system startup device, characterized in that, include: A determination module is used to determine the current startup state of the target system; the startup state is used to indicate that the target system is in any one of the boot read-only memory stage, boot loader stage, or boot application stage. The control module is used to acquire the input / output hold (IOHold) mechanism corresponding to the startup state, and control the input / output I / O interfaces of the target system based on the IOHold mechanism; the IOHold mechanism is used to indicate the I / O interfaces to be released in the current startup state; Specifically, the IOHold mechanism corresponding to the boot read-only memory stage instructs all I / O interfaces to remain locked, the IOHold mechanism corresponding to the bootloader stage instructs at least some I / O interfaces to be released based on the security level of the I / O interfaces, and the IOHold mechanism corresponding to the boot application stage instructs all I / O interfaces to be released; the security level is determined by access depth, potential attack vectors, and at least one security influencing factor in the interface application.

8. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-6.

10. A computer program product comprising a computer program that, when executed by a processor, implements the method of any one of claims 1-6.

Images