System starting method and device, electronic equipment and medium

Abstract

The embodiment of the invention provides a system starting method and device, electronic equipment and a medium, and relates to the technical field of computers. The method comprises the steps of determining a current starting state of a target system; the starting state is used for indicating that the target system is in any one of a read-only memory guiding stage, a loading program guiding stage and an application program guiding stage; obtaining an input / output holding (IOHOld mechanism corresponding to the starting state, and controlling an input / output (I / O) interface of the target system based on the IOHOld mechanism; the IOold mechanism is used for indicating the I / O interface to be released in the current starting state. The method is used for achieving the effect of flexibly controlling the I / O interface in the system starting process.

Description

Technical Field

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

[0002] With the development of automobiles, 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. How to ensure that embedded systems can resist potential attacks and avoid unsafe code execution has become an important technical problem.

[0003] At present, in order to ensure the security of the embedded system during startup, the known technology proposes to adopt an input / output hold IOHold mechanism to lock all input / output I / O interfaces until the embedded system completes startup and then is unlocked uniformly.

[0004] In the above process, there is a defect that the I / O interface cannot be flexibly managed, which is not conducive to the timeliness of the embedded system. Summary of the invention

[0005] The embodiments of the present application provide an embedded system startup method, device, electronic device and medium, which are used to achieve the effect of flexibly managing I / O interfaces during the startup process of the embedded system, thereby facilitating improving the timeliness of the embedded system.

[0006] In a first aspect, an embodiment of the present application provides an embedded system startup method, comprising:

[0007] 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 booting read-only memory stage, the boot loader stage, and the booting application stage;

[0008] An input / output holding 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 indicate that all I / O interfaces remain in a locked state; the IOHold mechanism corresponding to the boot loader stage is used to indicate the release of at least some I / O interfaces; and the IOHold mechanism corresponding to the boot application stage is used to indicate the release of all I / O interfaces.

[0010] In a possible implementation, when the startup status indicates that the target system is in the boot loader stage, controlling the input / output I / O interface of the target system based on the IOHold mechanism includes:

[0011] Obtaining a security level of the I / O interface; the security level is determined by security influencing factors, the 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 a possible implementation manner, 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 a low security level, releasing the I / O interface; and / or,

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

[0016] If the security level of the I / O interface is a high security level, releasing the I / O interface when the I / O interface meets a second preset condition; and maintaining the I / O interface in a locked state when the I / O interface does not meet the second preset condition;

[0017] Among them, 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 debugging mode based on the I / O interface, or the target system executes a key task based on the I / O interface.

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

[0019] Upon detecting that the target system is powered on and before the booting read-only memory stage is completed, determining that the startup state is used to indicate that the target system is in the booting read-only memory stage;

[0020] Before detecting that the boot read-only memory stage ends, the loader passes verification, and the boot loader stage has not ended, determining that the startup state is used to indicate that the target system is in the boot loader stage;

[0021] When it is detected that the boot loader stage ends and the application passes verification, the startup state is determined to indicate that the target system is in the boot application stage.

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

[0023] When receiving an unauthorized access request to any target I / O interface, determining that an abnormality exists in the target system;

[0024] Stop the startup process and enter the safe mode; when the target system is in the safe mode, all I / O interfaces of the target system except the debug interface are in a locked state, and the debug interface is used to implement the target system recovery operation.

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

[0026] When there is a defect in the integrity of the boot firmware of the target system, roll back to the target boot firmware; the boot firmware corresponds to a loader or an application; the target boot firmware is a boot firmware that can be successfully started in a historical version;

[0027] If the rollback is successful, starting the target system based on the target startup firmware;

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

[0029] In a second aspect, an embodiment of the present application provides an embedded system startup device, comprising:

[0030] A determination module, used for determining a current startup state of the target system; the startup state is used for indicating that the target system is in any one of a booting read-only memory stage, a booting loader stage, and a booting application stage;

[0031] The control module is used to 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; the IOHold mechanism is used to indicate the I / O interface to be released in the current startup state.

[0032] In a third aspect, an embodiment of the present application provides an electronic device, including: a memory, a processor;

[0033] The memory stores computer-executable instructions;

[0034] The processor executes the computer-executable instructions stored in the memory, so that the processor executes the above first aspect and / or various possible implementations of the first aspect.

[0035] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement the first aspect above and / or various possible implementations of the first aspect.

[0036] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the above first aspect and / or various possible implementation methods of the first aspect.

[0037] The embedded system startup method, device, electronic device and medium provided in the embodiments of the present application achieve the effect of flexibly managing the I / O interface of the embedded system during the startup process of the embedded system by determining the corresponding I / O old mechanism according to the current startup state of the embedded system during the startup process of the embedded system, and controlling the I / O interface of the embedded system through the corresponding I / O old mechanism. While improving the timeliness of the startup process of the embedded system, the security of the startup process of the embedded system can be guaranteed at the same time. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

[0041] Figure 3 Schematic diagram 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 structure 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 above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0046] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0047] First, the terms involved in this application are explained:

[0048] Embedded system: is a special-purpose computing system designed to perform a specific task or function. It is often embedded in a larger device or system to provide specific control, monitoring or processing functions.

[0049] Boot ROM stage: It is the initial stage of the computer system or embedded system startup process. In this stage, the system executes the startup 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 startup process.

[0050] Bootloader stage: It is a key stage in the startup process of a computer system or embedded system. At this stage, the system executes the code of the Bootloader. The Bootloader is a small program that is responsible for further hardware initialization, loading the operating system or application into memory, and handing control to them.

[0051] Boot application phase: It is the final phase of the system startup process. In this phase, the system has completed all necessary initialization work and begins to execute the main application code. This phase marks the transition of the system from the startup state to the normal operation state.

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

[0053] In addition to the above terms, the terms "first", "second", etc. are used for descriptive purposes only and are not to be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. In the description of the following embodiments, the meaning of "multiple" is more than two, unless otherwise clearly and specifically defined.

[0054] Currently, embedded systems are widely used in various industries, including consumer electronics, automobiles, industrial automation, medical equipment and communications. Smart phones, home appliances, car navigation systems, robots, etc. all rely on embedded systems to achieve specific functions and improve efficiency.

[0055] With the development of technology, embedded systems are increasingly used in the fields of automobiles, industrial control, and the Internet of Things. These fields usually involve mission-critical environments, which place extremely high demands on the security of embedded systems. Especially during the system startup process, how to ensure that embedded systems can resist potential attacks and avoid the execution of unsafe code has become an important technical problem.

[0056] For example, during the startup process of an embedded system, the startup code (usually the Bootloader) is responsible for downloading and initializing key functions of the system and preparing for the execution of the application. During this process, if the startup code is not effectively protected, the following security issues may occur:

[0057] Boot code tampering: An attacker may modify the Bootloader or application to implant malicious code and control 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, resulting in sensitive information leakage or illegal 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 attacks.

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

[0061] In addition, in embedded systems, I / O interfaces (such as SPI, UART, I2C, etc.) are used to communicate with external devices. However, embedded systems in the startup phase often have not completed security verification. If the I / O interfaces are open to the outside at this stage, on the one hand, attackers can maliciously interfere with the system through these interfaces, or even tamper with the startup process, affecting the correctness of the system startup. On the other hand, the system may process some sensitive data during the startup process. If the I / O interfaces are not effectively locked, external devices can steal sensitive data through these I / O interfaces, resulting in information leakage.

[0062] Therefore, the known technology proposes to lock all I / O interfaces by setting an IOHold mechanism until the system completes the startup 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 stage of startup, while some I / O interfaces can be unlocked after passing the preliminary security verification and used to communicate with external devices. At this time, keeping all I / O interfaces locked during the system startup process cannot achieve the control flexibility of the I / O interfaces, which is not conducive to the timeliness of the system.

[0064] For example, for an in-vehicle embedded system, it needs to report the system status through the CAN bus during the startup process. If the corresponding I / O interface remains locked during the startup process of the in-vehicle embedded system, the in-vehicle embedded system will not be able to perform necessary communications with external devices in a timely manner, thereby causing communication delays.

[0065] Therefore, the present application proposes a system startup method, device, electronic device and medium to solve the above problems. Specifically, in the system startup method of the present application, by using the corresponding IOHold mechanism to control the I / O interface of the system when the system is in different startup states, flexible control of the system I / O interface during the system startup process is achieved, thereby improving the flexibility of I / O interface management during the system startup process, which can effectively ensure the timeliness of the system during the startup process, and on the other hand, it is also conducive to ensuring the safety of the system during the startup process.

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

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

[0068] Based on this setting, during the startup process of the vehicle embedded system, the I / O interface of the vehicle embedded system can be flexibly controlled to release the unlocked I / O interface when necessary, thereby ensuring the startup security of the vehicle embedded system and the timeliness of the vehicle embedded system.

[0069] It is understandable that the electronic device can be integrated into the vehicle embedded system or can interact with the vehicle embedded system as an independent device, which is not limited in this embodiment. When the electronic device interacts with the vehicle embedded system as an independent device, the electronic device should be a trusted and authorized device.

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

[0071] Figure 2 Schematic diagram 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 state is used to indicate that the target system is in any one of a booting read-only memory stage, a booting loader stage, and a booting application stage;

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

[0075] It is understandable that in this embodiment, the target system is specifically the embedded system in the foregoing content. In practical applications, the target system can also be any other system whose startup process includes three stages: BootROM stage, Bootloader stage and boot application stage, such as a general computer system, a mobile device, a network device, a server system, etc., which is not limited in this embodiment.

[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 where the target system is located is powered on and the boot ROM stage is not finished.

[0077] Specifically, in this embodiment, the chip is integrated with a voltage monitoring circuit for detecting whether the power supply voltage reaches a preset threshold value. When the voltage is stable and exceeds the threshold value, the voltage monitoring circuit generates a power-on signal and transmits it to the electronic device, so that the electronic device determines that the chip where the target system is located is powered on, thereby determining that the target system enters the BootROM stage. At this time, if the electronic device does not end the boot read-only memory stage, it is determined that the target system has been in the BootROM stage.

[0078] It is understandable that, in practical applications, if the chip is equipped with a power management circuit for detecting the stability of the power supply, once the power supply reaches a stable state, the power management circuit generates a reset signal, and the electronic device can also be connected to the power management circuit to determine whether the chip where the target system is located is powered on by receiving the reset signal, thereby determining whether the target system enters the BootROM stage. In addition, the electronic device can also determine whether the chip where the target system is located is powered on by other means, which is not limited in this embodiment.

[0079] It should be understood that the BootROM area itself is unmodifiable, so the tasks of the target system at this stage include: loading and verifying the integrity of the loader, and initializing the lowest level hardware module. Among them, when the target system is at this stage, it is also necessary to ensure that the loader is read from the storage area that cannot be tampered with. More specifically, in this embodiment, the integrity of the loader is verified by a signature based on the hardware root of trust (HSM).

[0080] In addition, in this embodiment, after completing all its initialization tasks, the BootROM code will set a first flag bit or status register to indicate that the BootROM stage has been successfully completed. The electronic device determines whether the BootROM stage is detected to be completed through the first flag bit or status register. If not, it determines that the target system is still in the BootROM stage.

[0081] In this embodiment, the electronic device determines the startup state to indicate that the target system is in the Bootloader stage before detecting that the BootROM stage ends, the loader passes verification, and the bootloader stage has not ended. Specifically, in this embodiment, the BootROM is provided with a second flag bit to indicate whether the loader has passed verification, and the electronic device determines whether it has detected that the integrity of the loader has passed verification through the second flag bit, and determines whether it has detected that the BootROM stage ends through the aforementioned first flag bit.

[0082] The electronic device determines that the target system enters the Bootloader stage after detecting that the BootROM stage is finished and the loader passes the verification. Before the electronic device detects that the Bootloader stage is finished, it determines that the target system is still in the Bootloader stage.

[0083] It is understandable that after the target system enters the Bootloader stage, the Bootloader verified by the BootROM begins to execute, which is mainly responsible for loading and verifying the integrity of the application, and initializing more external devices and system resources, such as storage, communication modules, etc. Specifically, in this embodiment, the Bootloader stage uses the hardware trust root to verify the digital signature of the application.

[0084] In this embodiment, the target system is provided with a third flag bit for indicating that the Bootloader stage has been successfully ended. The electronic device determines whether the Bootloader stage has been detected to have ended through the third flag bit. If not, it determines that the target system is still in the Bootloader stage.

[0085] In this embodiment, when the electronic device detects that the boot loader stage is finished and the application is verified, the electronic device determines the startup state to indicate that the target system is in the boot application stage. In this embodiment, the target system is provided with a fourth flag to indicate whether the application is verified, and the electronic device determines whether the application is verified based on the fourth flag.

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

[0087] S202: Acquire an 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.

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

[0089] It should be understood that after the target system is powered on or reset, all I / O interfaces it contains 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 is started. Based on this, the I / O interface of the target system is controlled based on the IOHold mechanism, specifically, the corresponding I / O interface is released based on the IOHold mechanism, or the corresponding I / O interface is maintained 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 current startup state of the target system indicates that the target system is in the BootROM stage, in order to prevent the target system from being accessed without authorization before the startup is completed, all I / O interfaces should be kept in a locked state. When the current startup state of the target system indicates that the target system is in the Bootloader stage, the corresponding I / O interfaces can be released according to system requirements, such as some simple control signal interfaces. When the target system is in the application booting stage, after the application is loaded and verified successfully, its corresponding I / O interface enters an unlocked state to interact with external devices in a timely manner.

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

[0093] It should be understood that, in the application booting stage, the electronic device releases the corresponding I / O interface after the corresponding application passes verification. If the application corresponding to the I / O interface fails to pass verification, it should be maintained in a locked state until the application passes verification.

[0094] The system startup method provided in the embodiment of the present application achieves the effect of improving the flexibility of I / O interface control while ensuring the security of the startup process by controlling the I / O interface included in the target system based on the IOHold mechanism corresponding to the stage at each startup status indication of the target system, thereby facilitating the timeliness of the system.

[0095] As a preferred implementation, when the target system is in the BootROM stage or the Bootloader stage, if at least two I / O interfaces need to be released, the interface priorities of at least two I / O interfaces can be obtained, and the I / O interface with a 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 urgency of the interface application, the response time of the interface requirement, etc. Exemplarily, if the urgency of the interface application corresponding to the I / O interface is more urgent than that of another I / O interface, the interface priority of the I / O interface is higher than that of the other I / O interface. If the response time of the interface requirement corresponding to the I / O interface is shorter than that of another I / O interface, the interface priority of the I / O interface is higher than that of the other 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. Exemplarily, the electronic device may also determine its interface priority in combination with 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, startup failures, etc., and establishes a fault database. Through the fault information in the fault database, a prediction model (such as time series analysis, anomaly detection algorithm) is established to identify potential fault trends. Based on this, the electronic device can predict possible I / O interface faults through the prediction model before or during the startup of the target system, thereby obtaining fault prediction results for at least two I / O interfaces.

[0099] For I / O interfaces that may have interface failures as indicated by the fault prediction results, their interface priorities can be appropriately lowered to adjust their release order backwards, thereby leaving time for executing other remedial measures such as starting a backup interface.

[0100] Optionally, the electronic device may also determine the interface priorities of at least two I / O interfaces in combination with the power-on sequence of external devices connected to the I / O interfaces, which is not limited in this embodiment.

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

[0102] Based on the above embodiments, the present application also provides a method embodiment for further describing the system startup method of the present application in detail. Specifically, the present embodiment describes the IOHold mechanism corresponding to the Bootloader stage.

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

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

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

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

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

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

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

[0110] And / or, the interface application of the I / O interface indicates that it is mainly 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 a high security level.

[0111] For example, for debugging interfaces such as JTAG interface and SWD interface, their interface application indicates that they are used for development and debugging, their access depth indicates that they can directly access the memory and registers inside the chip, and their potential attack vectors indicate that if they are opened during the startup phase, they may be exploited to perform deep system tampering. Therefore, the security level corresponding to such debugging interfaces should be high security level.

[0112] For interfaces such as SPI and UART that are commonly used for firmware updates, debugging, or data transmission, opening these interfaces may give attackers the opportunity to inject unauthorized code during the boot process, that is, their corresponding potential attack vectors indicate that once they are attacked or abused, they may cause malicious code injection into the target system. Therefore, the security level corresponding to these interfaces should also be high.

[0113] 2. If the access depth of the I / O interface indicates that it can only access restricted areas 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 crash, leak data, or inject malicious code;

[0115] And / or, the interface application of the I / O interface indicates that it must be used for communication or data transmission with an external device or module during the startup process, but the direct control capability of the target system is limited, then its corresponding security level is determined to be a medium security level.

[0116] For example, interfaces such as CAN bus interface and LIN bus interface used for target system communication protocol are mainly used to transmit 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 level.

[0117] For interfaces such as Ethernet interfaces used for communication between devices, if they are not controlled, they may be used by attackers to eavesdrop or interfere with network communications. Therefore, their corresponding security level is also medium security level.

[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 it is exploited, it will not pose a substantial threat to the core functions or data of the target system;

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

[0121] For example, for an interface such as a GPIO interface, its access depth indicates that it is used to provide simple input / output operations, such as controlling an LED or a buzzer, and only provides system startup status or fault information, does not involve any sensitive data, and does not have data transmission capabilities. Therefore, its corresponding security level is a low security level.

[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. For the specific process, please refer to the contents shown in S302-S304 below.

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

[0124] It is understandable that low-security-level I / O interfaces generally do not involve the transmission of sensitive data, have limited access capabilities and single purposes, and are usually used for simple status indication or user interaction. Even if they are fully released during the boot process, they will not pose a threat to the overall security of the target system. Therefore, these interfaces can be fully released at the Bootloader stage.

[0125] S303: If the security level of the I / O interface is a medium security level, then when the I / O interface meets a 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 maintained 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, the I / O interface with a medium security level is selectively released.

[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 the startup status to an external device or system or receive an external control command through the I / O interface, which is convenient for external monitoring and rapid response. Otherwise, the I / O interface is maintained in a locked state.

[0129] S304: If the security level of the I / O interface is a high security level, releasing the I / O interface when the I / O interface meets a second preset condition; and maintaining the I / O interface in a locked state when the I / O interface does not meet the second preset condition.

[0130] The second preset condition includes: the target system enters a debugging mode based on the I / O interface implementation, or the target system executes a key task based on the I / O interface implementation.

[0131] It is understandable that I / O interfaces with a high security level usually have the ability to access the internal memory or controller of the target system. If released at the Bootloader stage, they may be used to inject malicious code or interfere with the startup of the target system. Therefore, in general, these I / O interfaces should be kept in a locked state to avoid 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, external access is monitored, and when access to the corresponding I / O interface for debugging or for executing critical tasks is monitored, it is determined that the target system is in debugging mode or needs to execute critical tasks. It can be understood that the critical task can be firmware update, etc.

[0133] In the method provided in the embodiment of the present application, when the target system is in the Bootloader stage, the I / O interface of the target system is controlled based on the 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, thereby ensuring that the target system can respond in a timely manner while ensuring the security of the startup of the target system, so as to effectively avoid the problem of communication delay.

[0134] In a possible implementation, during the startup of the target system, the electronic device detects whether there is any abnormality in the target system, and takes corresponding measures in a timely manner if there is any abnormality.

[0135] Specifically, when the target system is in any startup state, if an unauthorized access request is received from any target I / O interface, it is determined that an abnormality exists, the startup process is stopped, and the safe mode is entered.

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

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

[0138] In addition, 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, and at this time it also needs to enter the safe mode to ensure that all non-critical functions are stopped to maintain the minimum system operation state.

[0139] Through this setting, during the startup process of the target system, the electronic device can detect abnormalities in time, and when abnormalities exist in the target system, lock the corresponding I / O interface of the target system in time to ensure the security of the target system.

[0140] In another possible implementation, the electronic device detects the integrity of the target system's boot firmware, and rolls back to the target boot firmware when there are defects in the integrity of the target system's 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 startup firmware corresponds to a loader or application; when the target system is in a safe mode, all I / O interfaces of the target system except the debug interface are in a locked state, 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 successfully booted last time. Specifically, if the loader or application passes the security verification, it is determined that there is no defect in its integrity. Otherwise, it is determined that there is a defect in its integrity. At this time, roll back to the target boot firmware and retry booting based on the target boot firmware. When the rollback fails, the target system enters the safe mode.

[0143] Through 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 time to ensure the security of the target system.

[0144] Understandably, Figure 4 A complete process diagram of the system startup method provided in this application, such as 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 in a locked state, and the tasks of this stage are: loading and verifying the integrity of the loader, and initializing the lowest level hardware module. In addition, if the Bootloader fails to pass the verification, it rolls back to the corresponding target startup firmware, restarts the target system when the rollback is successful, and puts the target system into safe mode when the rollback fails.

[0145] When the electronic device detects that the BootROM stage is over and the Bootloader passes verification, it enters the Bootloader stage. When the target system is in the Bootloader stage, the electronic device releases at least some I / O interfaces based on the IOHold mechanism corresponding to the Bootloader stage, and the tasks of this stage are: loading and verifying the integrity of the application, and initializing more external devices and system resources. In addition, if the application fails to pass verification, it rolls back to the corresponding target boot firmware, restarts the target system if the rollback is successful, and puts the target system into safe mode if the rollback fails.

[0146] When the electronic device detects that the Bootloader stage is finished and the application is verified, it enters the bootloader stage. When the target system is in the boot application stage, the electronic device releases all I / O interfaces based on the IOHold mechanism corresponding to the boot application stage.

[0147] The present application also provides an embodiment of a system startup device, Figure 5 A schematic diagram of the structure of the system startup device provided in this application, such as Figure 5 As shown, the system startup device provided in this embodiment includes:

[0148] The determination module 51 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 booting read-only memory stage, the booting loader stage, and the booting application stage;

[0149] The control module 52 is used to 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; 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 indicate that all I / O interfaces remain in a locked state; the IOHold mechanism corresponding to the boot loader stage is used to indicate the release of at least some I / O interfaces; and the IOHold mechanism corresponding to the boot application stage is used to indicate the release of all I / O interfaces.

[0151] In a possible implementation, when the startup status indicates that the target system is in the boot loader stage, the control module 52 is specifically configured to:

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

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

[0154] In a possible implementation, the control module 52 is specifically configured to:

[0155] If the security level of the I / O interface is a low security level, releasing the I / O interface; and / or,

[0156] If the security level of the I / O interface is a medium security level, when the I / O interface meets a 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 maintained in a locked state; and / or,

[0157] If the security level of the I / O interface is a high security level, releasing the I / O interface when the I / O interface meets a second preset condition; and maintaining the I / O interface in a locked state when the I / O interface does not meet the second preset condition;

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

[0159] In a possible implementation, the determination module 51 is specifically configured to:

[0160] Before detecting that the target system is powered on and the booting read-only memory stage is not finished, determining the startup state is used to indicate that the target system is in the booting read-only memory stage;

[0161] Before detecting that the boot ROM stage ends, the loader passes verification, and the boot loader stage has not ended, determining that the boot state is used to indicate that the target system is in the boot loader stage;

[0162] When the end of the bootloader stage is detected and the application passes verification, a boot state is determined to indicate that the target system is in the booting application stage.

[0163] In a possible implementation, the control module 52 is further configured to:

[0164] When the target system is in any startup state, upon receiving an unauthorized access request to any target I / O interface, determining that the target system has an abnormality;

[0165] Stop the boot process and enter the safe mode; when the target system is in the safe mode, all I / O interfaces of the target system except the debug interface are in a locked state. The debug interface is used to implement the target system recovery operation.

[0166] In a possible implementation, the control module 52 is further configured to:

[0167] When there is a defect in the integrity of the boot firmware of the target system, roll back to the target boot firmware; the boot firmware corresponds to a loader or an application; the target boot firmware is the boot firmware that can be successfully started in the historical version;

[0168] If the rollback is successful, the target system is started based on the target startup firmware;

[0169] Otherwise, the target system is controlled to enter the safe mode. When the target system is in the safe mode, all I / O interfaces of the target system except the debug interface are in a locked state. 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 this embodiment will not be described in detail here.

[0171] The present application also provides an electronic device, Figure 6 This is 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, such as through a bus 63. Optionally, the electronic device may further include a transceiver 64. It should be noted that in actual applications, the transceiver 64 is not limited to one, and the structure of the electronic device does not constitute a limitation on the embodiments of the present application.

[0172] The processor 61 may be a central processing unit (CPU), a general 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 various exemplary logic blocks, modules and circuits described in conjunction with the disclosure of this application. The processor 61 may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc.

[0173] The bus 63 may include a path to transmit information between the above components. The bus 63 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. The bus 63 may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 6 Although only one thick line is used in the figure, it does not mean that there is only one bus 63 or only one type of bus 63.

[0174] The memory 62 may be a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM) or other types of dynamic storage devices that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited to these.

[0175] The memory 62 is used to store the application code for executing the solution of the present application, and the 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 above method embodiment.

[0176] The present application also provides a computer-readable storage medium, which may include: a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk, and other media that can store program codes. Specifically, the computer-readable storage medium stores program instructions, and the program instructions are used to implement the methods in the above-mentioned embodiments.

[0177] A computer program product is also provided in an embodiment of the present application, including a computer program. When the computer program is executed by a processor, the technical solution of the above-mentioned method embodiment is implemented. The implementation principle and technical effect are similar and will not be repeated here.

[0178] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention disclosed herein. The present application is intended to cover any modification, use or adaptation of the present application, which follows the general principles of the present application and includes common knowledge or customary techniques in the art that are not disclosed in the present application. The specification and examples are intended to be exemplary only, and the true scope and spirit of the present application are indicated by the claims.

[0179] It should be understood that the present application is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A system startup method, characterized in that: include: 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 booting read-only memory stage, the boot loader stage, and the booting application stage; An input / output holding 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.

2. The method according to claim 1, characterized in that The IOHold mechanism corresponding to the boot read-only memory stage is used to indicate that all I / O interfaces remain in a locked state; the IOHold mechanism corresponding to the boot loader stage is used to indicate the release of at least part of the I / O interfaces; and the IOHold mechanism corresponding to the boot application stage is used to indicate the release of all I / O interfaces.

3. The method according to claim 1 or 2, characterized in that: When the startup state indicates that the target system is in the boot loader stage, controlling the input / output I / O interface of the target system based on the IOHold mechanism includes: Obtaining a security level of the I / O interface; the security level is determined by security influencing factors, the security influencing factors including at least one of access depth, potential attack vectors, and interface applications; The I / O interface of the target system is controlled according to the security level and the IOHold mechanism.

4. The method according to claim 3, characterized in that The 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 a low security level, releasing the I / O interface; and / or, If the security level of the I / O interface is a medium security level, when the I / O interface meets a first preset condition, releasing the I / O interface; when the I / O interface does not meet the first preset condition, maintaining the I / O interface in a locked state; and / or, If the security level of the I / O interface is a high security level, releasing the I / O interface when the I / O interface meets a second preset condition; and maintaining the I / O interface in a locked state when the I / O interface does not meet the second preset condition; Among them, 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 debugging mode based on the I / O interface, or the target system executes a key task based on the I / O interface.

5. The method according to claim 1 or 2, characterized in that: Determining the current startup state of the target system includes: Upon detecting that the target system is powered on and before the booting read-only memory stage is completed, determining that the startup state is used to indicate that the target system is in the booting read-only memory stage; Before detecting that the boot read-only memory stage ends, the loader passes verification, and the boot loader stage has not ended, determining that the startup state is used to indicate that the target system is in the boot loader stage; When it is detected that the boot loader stage ends and the application passes verification, the startup state is determined to indicate that the target system is in the boot application stage.

6. The method according to claim 1 or 2, characterized in that: When the target system is in any startup state, the method further includes: When receiving an unauthorized access request to any target I / O interface, determining that an abnormality exists in the target system; Stop the startup process and enter the safe mode; when the target system is in the safe mode, all I / O interfaces of the target system except the debug interface are in a locked state, and the debug interface is used to implement the target system recovery operation.

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

8. A system startup device, characterized in that: include: A determination module, used for determining a current startup state of the target system; the startup state is used for indicating that the target system is in any one of a booting read-only memory stage, a booting loader stage, and a booting application stage; The control module is used to 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; the IOHold mechanism is used to indicate the I / O interface to be released in the current startup state.

9. An electronic device, characterized in that: include: Memory, processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory, so that the processor performs the method according to any one of claims 1 to 7.

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

11. A computer program product, comprising a computer program, wherein when the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

Images