A fault monitoring method of a control device and an electronic device

Abstract

This application discloses a fault monitoring method and electronic device for a control device, relating to the field of computer technology. The method includes: detecting fault information of a second processing unit of the control device, wherein the control device includes: a first processing unit, a second processing unit, and a reference storage unit, the reference storage unit being configured to be accessible only by the first processing unit, the second processing unit being used to control a connected server through one or more service programs, and the reference storage unit storing at least one target firmware data; initiating at least one reference service program by retrieving at least one reference firmware data from the reference storage unit based on the fault information; and restoring the operation of the second processing unit based on the fault information. This application solves the technical problem of low efficiency in monitoring and processing faults of control devices in related technologies, achieving the technical effect of improving the efficiency of fault monitoring and processing of control devices.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a fault monitoring method and electronic device for control equipment. Background Technology

[0002] As a core management component of the server, the control device has already implemented basic functions such as remote monitoring and firmware updates, and is being upgraded towards intelligent operation and maintenance and proactive immunity. The security of the control device plays a crucial role in the secure operation of the server, but related technologies suffer from low efficiency in monitoring and handling control device faults. Summary of the Invention

[0003] This application provides a fault monitoring method and electronic device for control equipment, so as to at least solve the problem of low efficiency in monitoring and processing faults of control equipment in related technologies.

[0004] This application provides a fault monitoring method for a control device, comprising: detecting fault information of a second processing unit of the control device, wherein the fault information is used to indicate an operational fault of the second processing unit; the control device includes: a first processing unit, a second processing unit, and a reference storage unit; the reference storage unit is configured to be accessible only by the first processing unit; the second processing unit is used to control a connected server through one or more service programs; the reference storage unit stores at least one target firmware data, the at least one target firmware data being used to start at least one target service program among one or more service programs; calling at least one reference firmware data from the at least one target firmware data in the reference storage unit according to the fault information to start at least one reference service program among at least one target service program; and restoring the operation of the second processing unit according to the fault information.

[0005] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the fault monitoring method of any of the above-described control devices.

[0006] According to this application, the first processing unit of the control device detects fault information of the second processing unit of the control device. The second processing unit is used to control the connected server through one or more service programs. The control device includes a reference storage unit that is configured to be accessible only by the first processing unit. The reference storage unit stores at least one target firmware data. The at least one target firmware data is used to start at least one target service program among one or more service programs. The first processing unit calls at least one reference firmware data from the at least one target firmware data in the reference storage unit according to the fault information to start at least one reference service program among at least one target service program, and restores the operation of the second processing unit according to the fault information. That is, in the event of a failure in the operation of the second processing unit, the first processing unit attempts to restore the operation of the second processing unit by using the data stored in the reference storage unit that is accessible only by the first processing unit, and also starts the reference service program on the first processing unit to ensure that the control device's control over the server is not interrupted. Therefore, the technical problem of low monitoring and processing efficiency of control device faults in related technologies can be solved, and the technical effect of improving the monitoring and processing efficiency of control device faults can be achieved. Attached Figure Description

[0007] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0008] Figure 1 This is a schematic diagram of a control device according to an embodiment of this application. Figure 1 ;

[0009] Figure 2 This is a schematic diagram of a control device according to an embodiment of this application. Figure 2 ;

[0010] Figure 3 This is a schematic diagram of a control device according to an embodiment of this application. Figure 3 ;

[0011] Figure 4 This is a schematic diagram of a control device according to an embodiment of this application. Figure 4 ;

[0012] Figure 5 This is an overall architecture diagram of a control device according to an embodiment of this application;

[0013] Figure 6 This is a hierarchical architecture diagram of a control device according to an embodiment of this application;

[0014] Figure 7 This is a diagram of a dual-system isolation architecture for a control device according to an embodiment of this application;

[0015] Figure 8 This is a flowchart of a method for starting the processing unit of a control device according to an embodiment of this application;

[0016] Figure 9 This is a flowchart of a BMC secure boot process according to an embodiment of this application;

[0017] Figure 10 This is a flowchart of a server control method according to an embodiment of this application;

[0018] Figure 11 This is a schematic diagram illustrating a process by which a security core provides security services to a business core according to an embodiment of this application;

[0019] Figure 12 This is a flowchart of a fault monitoring method for a control device according to an embodiment of this application;

[0020] Figure 13 This is a schematic diagram of a service core fault handling process according to an embodiment of this application;

[0021] Figure 14 This is a schematic diagram illustrating various upgrade methods for the service core according to embodiments of this application;

[0022] Figure 15 This is a structural block diagram of a fault monitoring device for a control device according to an embodiment of this application. Detailed Implementation

[0023] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0024] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0025] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0026] An embodiment of this application provides a control device. Figure 1 This is a schematic diagram of a control device according to an embodiment of this application. Figure 1 .like Figure 1 As shown, the control device includes: a first processing unit, a second processing unit, a reference storage unit, a first bus, and a second bus; wherein, the first processing unit is connected to both the first bus and the second bus, the second processing unit is connected to the second bus, and the reference storage unit is connected to the first bus.

[0027] Optionally, in this embodiment, the first processing unit may be configured to have access to the reference storage unit, and the second processing unit may be configured to not have access to the reference storage unit; the first processing unit may be configured to access the reference storage unit via a first bus and provide security functions to the second processing unit via a second bus; the second processing unit may be configured to run control services of the control device using the security functions provided by the first processing unit; and the reference storage unit may be configured to store data used by the security functions provided by the first processing unit.

[0028] The control device includes a first processing unit, a second processing unit, a reference storage unit, a first bus, and a second bus. The first processing unit is connected to both the first and second buses, the second processing unit is connected to the second bus, and the reference storage unit is connected to the first bus. The first processing unit is configured to have access to the reference storage unit, while the second processing unit is configured not to have access to the reference storage unit. The first processing unit accesses the reference storage unit via the first bus to store data used by the security functions provided by the first processing unit, and provides security functions to the second processing unit via the second bus. The second processing unit uses the security functions provided by the first processing unit to run the control operations of the control device. In other words, the control device includes not only the second processing unit that processes control operations but also the first processing unit that provides security functions to the second processing unit. The data used by the security functions provided by the first processing unit is stored in the reference storage unit, which the first processing unit has access to but the second processing unit does not. This ensures the secure and independent operation of the security functions, thereby ensuring the secure operation of the control operations. Therefore, the technical problem of low security in control devices can be solved, and the technical effect of improving the security of control devices can be achieved.

[0029] Optionally, in this embodiment, the control device may be used for server management and monitoring, and the control device may be, but is not limited to, an out-of-band system. Optionally, the control device may be, but is not limited to, a BMC (Baseboard Management Controller), etc.

[0030] Optionally, in this embodiment, the processing unit may refer to, but is not limited to, the core computing component inside the control device responsible for executing instructions, processing data, and controlling business processes. The processing unit may include, but is not limited to, a processor (e.g., a CPU (Central Processing Unit)) or a core (physical core). The processing unit may include, but is not limited to, a first processing unit and a second processing unit.

[0031] Optionally, in this embodiment, the first processing unit may, but is not limited to, run a lightweight operating system, and the second processing unit may, but is not limited to, run a complete business operating system.

[0032] Optionally, in this embodiment, the number of first processing units and second processing units included in the control device can be flexibly determined as needed, but is not limited to. For example, the control device may include, but is not limited to, one first processing unit and multiple second processing units, or the control device may include, but is not limited to, multiple first processing units and multiple second processing units, etc.

[0033] Optionally, in this embodiment, the reference storage unit may be, but is not limited to, a storage unit dedicated to security functions. The reference storage unit may be, but is not limited to, the root of trust carrier of the entire trusted computing architecture of the control device. The reference storage unit may, but is not limited to, allow access from the first processing unit used to provide security functions, but prohibit access from the second processing unit used to run control services. This prevents the second processing unit from being influenced by external devices / data after contacting them, thereby preventing unauthorized modification of the data used by the security functions and thus rendering the security functions ineffective.

[0034] Optionally, in this embodiment, the reference storage unit may include, but is not limited to, Secure OTP (Secure One-Time Programmable), ROM (Read-Only Memory), RAM (Random Access Memory), etc.

[0035] Optionally, in this embodiment, security functions may refer to, but are not limited to, underlying security services provided by the first processing unit to ensure the authenticity, confidentiality, integrity, and availability of the control device's identity. The second processing unit may use these functions through a secure channel without directly processing sensitive keys. Security functions may include, but are not limited to, encryption / decryption services (e.g., the first processing unit uses a hardware encryption engine to encrypt and decrypt data communicating between the control device and external terminals, while the second processing unit only forwards the ciphertext), signature verification services (e.g., the first processing unit verifies the digital signature of the business application or firmware upgrade package uploaded by the second processing unit to ensure that the code has not been tampered with), and trust measurement services (e.g., the first processing unit calculates the hash value of the running process in real time and compares it with a benchmark value to determine whether the control device is in a secure state), etc.

[0036] Optionally, in this embodiment, control services may refer to, but are not limited to, specific applications or service logic run by the second processing unit that directly manage and maintain server hardware. These services rely on underlying hardware resources but do not process underlying security keys themselves. For example, sensor monitoring services: reading server CPU temperature, voltage, and fan speed data and transmitting this data to the server's maintenance platform; power management services: controlling the switching on and off of PSUs (Power Supply Units); remote maintenance interaction services: handling SSH (Secure Shell) / HTTPS (Hypertext Transfer Protocol Secure) connections, receiving administrator commands, and performing operations such as restarting the server and setting BIOS (Basic Input / Output System) parameters.

[0037] Optionally, in this embodiment, the control services may also include, but are not limited to, starting up the control device and monitoring and recovering from the faults of the control device.

[0038] Optionally, in this embodiment, the second processing unit may, but is not limited to, use the security functions provided by the first processing unit to run the control services of the control device. For example, it may, but is not limited to, use the encryption / decryption service and signature verification service provided by the first processing unit to start the control device, etc.

[0039] Optionally, in this embodiment, the control device may, but is not limited to, include a first bus and a second bus. The buses, represented by the first and second buses, may, but are not limited to, communication channels connecting components such as processors, memory, and peripherals, used for transmitting data, addresses, and control signals. The buses may, but are not limited to, include various types such as SPI (Serial Peripheral Interface), I2C (Inter-Integrated Circuit), and AXI (Advanced eXtensible Interface).

[0040] Optionally, in this embodiment, different buses may, but are not limited to, carry communications with different security levels, and buses carrying communications with different security levels may, but are not limited to, be physically or logically isolated through isolators. Optionally, the security level of the communications carried by the first bus may, but is not limited to, be higher than the security level of the communications carried by the second bus.

[0041] Optionally, in this embodiment, the first processing unit and the reference storage unit may be connected via, but are not limited to, a first bus, which may be, but is not limited to, a security bus of the control device. Optionally, the second processing unit and the first processing unit may be connected via, but are not limited to, a second bus.

[0042] As an optional implementation method, Figure 2 This is a schematic diagram of a control device according to an embodiment of this application. Figure 2 ,like Figure 2 As shown, the first processing unit may include, but is not limited to, a first processor, a first register, and a first controller; wherein the first controller is connected to both the first processor and the first register, and is also connected to both the first bus and the second bus.

[0043] Optionally, in this embodiment, the first register may be used, but is not limited to, to store the first access permission of the first processor to the reference memory unit, wherein the first access permission is permitted; the first controller may be used, but is not limited to, to monitor the first processor's access to the reference memory unit according to the first access permission.

[0044] Optionally, in this embodiment, the first processor may refer to, but is not limited to, the core computing engine of the first processing unit, such as a processor or a core.

[0045] Optionally, in this embodiment, the access rights of the first processing unit to the storage unit within the control device, including the first access rights to the reference storage unit, can be recorded through the first register, but not limited to the first access rights.

[0046] Optionally, in this embodiment, the first controller may be, but is not limited to, the hardware monitoring and arbitration logic unit in the first processing unit. The first controller may, but is not limited to, intercept and check each memory access request of the first processor in real time according to the permissions stored in the first register.

[0047] Optionally, in this embodiment, the access permission of the first processor to the insecure storage unit can be set to prohibited through the first register to avoid insecure data affecting the normal operation of the first processing unit.

[0048] Optionally, in this embodiment, by coordinating the first register and the first controller to monitor the first processor's access to the reference memory unit, the first processing unit can be able to access the reference memory unit normally.

[0049] As an optional implementation, the second processing unit may include, but is not limited to, a second processor, a second register, and a second controller; wherein the second controller is connected to both the second processor and the second register, and the second controller is also connected to a second bus; wherein the second register may be used, but is not limited to, to store the second access permission of the second processor to the reference memory unit, wherein the second access permission is prohibited; the second controller may be used, but is not limited to, to monitor the access of the second processor to the reference memory unit according to the second access permission.

[0050] Optionally, in this embodiment, the components included in the second processing unit are similar to those included in the first processing unit, and will not be described again here.

[0051] Optionally, in this embodiment, the second processing unit may be prevented from accessing the reference storage unit by means of the cooperation of the second register and the second controller, so as to avoid the leakage or tampering of the data used by the security functions stored in the reference storage unit and ensure the normal operation of the security functions of the control device.

[0052] As an optional implementation, independent PMP (Page Memory Protection) registers (i.e., the aforementioned first register and second register) can be configured for the two CPUs (i.e., the first processor and the second processor mentioned above), and memory access permission tables can be defined (i.e., storing the first access permission and the second access permission). Unauthorized access triggers hardware exceptions and triggers security status verification of the dual processing units, so as to achieve access isolation between cores and devices.

[0053] As an optional implementation, the reference storage unit may be connected only to the first bus, and the control device may include, but is not limited to, a bus isolator; wherein the bus isolator is connected between the first bus and the second bus; wherein the bus isolator may be used, but is not limited to, to prevent the first operating device connected on the second bus from accessing the storage unit connected on the first bus.

[0054] Optionally, in this embodiment, a bus isolator may be used to prevent the first operating device from accessing the storage units connected to the first bus, i.e., the security bus, so as to prevent the data used by the security function and the data generated during the implementation of the security function from being stolen or tampered with by the first operating device.

[0055] Optionally, in this embodiment, the bus isolator may be, but is not limited to, a hardware security component deployed between system buses, and may be, but is not limited to, used to establish a physical or logical barrier between a high-security domain bus (first bus) and a low-security domain bus (second bus). The core function of the bus isolator may be, but is not limited to, blocking unauthorized data flow and preventing components in the low-security domain (such as a second processing unit or peripherals) from directly accessing or spying on sensitive resources in the high-security domain.

[0056] As an optional implementation, IOPMP (InstructionOpcode Memory Protection) can be deployed on the system bus to manage the access permissions of bus master devices (i.e., the aforementioned first running device) such as DMA (Direct Memory Access) and PCIe (Peripheral Component Interconnect Express) to prevent peripheral devices from attacking the security domain through the bus.

[0057] As an optional implementation, the control device may, but is not limited to, further include: a direct memory controller and a target interface; wherein both the target interface and the direct memory controller are connected to a second bus; the target interface may, but is not limited to, be used to connect a first external device, the first operating device including the first external device; the first external device is used to directly access the memory cells on the control device through the direct memory controller; wherein the bus isolator is used to prevent the first external device from directly accessing the reference memory cells through the direct memory controller.

[0058] Optionally, in this embodiment, a bus isolator can be used to prevent the first external device connected through the target interface from directly accessing the reference memory cell through the direct memory controller, thereby preventing the data stored in the reference memory cell from being stolen or tampered with.

[0059] As an optional implementation, the control device may, but is not limited to, include: a shared storage unit; wherein the shared storage unit is connected to a second bus; the first processing unit may, but is not limited to, be configured to have access to the shared storage unit; the access to the shared storage unit by the second processing unit may, but is not limited to, be set according to the storage address in the shared storage unit.

[0060] Optionally, in this embodiment, the control device may include, but is not limited to, a shared memory unit that can be accessed by both the first processing unit and the second processing unit. It should be noted that the second processing unit may, but is not limited to, always have access to certain memory addresses in the shared memory unit, and the access permissions of the second processing unit to certain memory addresses in the shared memory unit may, but are not limited to, be variable; that is, it may be accessible in some cases but not in others. Furthermore, some memory addresses in the shared memory unit may, but are not limited to, only be accessible to certain processes within the second processing unit.

[0061] Optionally, in this embodiment, since the second bus is connected to both the first processing unit and the second processing unit, a shared storage unit connected to the second bus is provided to provide temporary storage space for data transmitted between the first processing unit and the second processing unit.

[0062] As an optional implementation, the first storage address in the shared storage unit may, but is not limited to, be used to store alternative firmware data for the control device. The alternative firmware data may, but is not limited to, be used to start the kernel program of the second processing unit. The second processing unit may, but is not limited to, be configured to not have access to the first storage address if the security information of the alternative firmware data is not verified or if the security information of the alternative firmware data indicates that the alternative firmware data is insecure; and to have access to the first storage address if the security information of the alternative firmware data indicates that the alternative firmware data is secure.

[0063] Optionally, in this embodiment, the kernel program of the second processing unit may be, but is not limited to, the core part of the operating system of the second processing unit, such as the Zephyr Kernel or the Linux Kernel. The kernel program of the second processing unit may be, but is not limited to, a bridge connecting the hardware and the upper-level software, responsible for the lowest-level resource management.

[0064] Optionally, in this embodiment, alternative firmware data for starting the kernel program of the second processing unit can be stored at the first storage address of the shared storage unit, but is not limited to. The second processing unit can be configured, but is not limited to, not having access to the first storage address if the security information of the alternative firmware data is not verified or if the verification of the security information of the alternative firmware data fails (i.e., the security information of the alternative firmware data is used to indicate that the alternative firmware data is insecure), and only having access to the first storage address if the verification of the security information of the alternative firmware data passes (i.e., the security information of the alternative firmware data is used to indicate that the alternative firmware data is secure). With such a setting, the second processing unit can be prevented from using insecure firmware data to start the kernel program.

[0065] As an optional implementation, the second storage address of the shared storage unit may, but is not limited to, be used to store candidate firmware data of the control device, which is used to start the user service program of the second processing unit; the second processing unit is configured to not have access to the second storage address if the security information of the candidate firmware data is not verified or if the security information of the candidate firmware data indicates that the candidate firmware data is insecure; and to have access to the second storage address if the security information of the candidate firmware data indicates that the candidate firmware data is secure.

[0066] Optionally, in this embodiment, the second processing unit may require, but is not limited to, a user service program to be started in addition to the kernel program. Optionally, the user service program may be, but is not limited to, an application or service daemon running in User Space. The user service program may, but is not limited to, rely on the system call interface provided by the kernel to operate the hardware, but it does not directly operate the hardware registers itself.

[0067] Optionally, in this embodiment, candidate firmware data for starting the user service program of the second processing unit may be stored at the second storage address of the shared storage unit, but is not limited to. The second processing unit may be configured, but is not limited to, not have access to the second storage address if the security information of the candidate firmware data is not verified or if the verification of the security information of the candidate firmware data fails (i.e., the security information of the candidate firmware data is used to indicate that the candidate firmware data is insecure), and only have access to the second storage address if the verification of the security information of the candidate firmware data passes (i.e., the security information of the candidate firmware data is used to indicate that the candidate firmware data is secure). With such a setting, the second processing unit can be prevented from using insecure firmware data to start the user service program.

[0068] As an optional implementation, the third storage address of the shared storage unit may be used, but is not limited to, to store business data that has been processed by the first processing unit and is to be received by the second processing unit; the second processing unit may be configured, but is not limited to, having access to the third storage address for the target process of the second processing unit, wherein the target process is the process in the second processing unit that initiated the data processing request to the first processing unit.

[0069] Optionally, in this embodiment, when the second processing unit processes control services, it may, but is not limited to, require the first processing unit to perform preliminary processing on the data received by the second processing unit, or the second processing unit may require the first processing unit to perform further processing on the data before transmitting it to the outside of the control device. In these cases, the target process on the second processing unit will initiate a data processing request to the first processing unit. After the first processing unit responds to the data processing request and performs the data processing operation, it may, but is not limited to, store the processed data to be received by the second processing unit on a third storage address in the shared storage space. If the target process is set to have access to the third storage address, it can obtain the service data processed by the first processing unit from the third storage address.

[0070] Optionally, in this embodiment, the third storage address is open to the target process but not to other processes of the second processing unit, so that the business data can be processed normally while reducing the possibility of the business data being accessed, thereby reducing the possibility of the business data being illegally stolen and tampered with.

[0071] Optionally, in this embodiment, the first processing unit may, but is not limited to, implement fine-grained access control to the third storage address by configuring the PMP or MMU (Memory Management Unit). Specifically, the first processing unit may, but is not limited to, utilize the ASID (Address Space Identifier) ​​mechanism supported by the MMU to create an independent address space for the target process initiating the data processing request, and map the third storage address to the page table corresponding to the specific ASID, while setting the access permissions (such as read-write or read-only) for the address region. Through this ASID-based isolation mechanism, the hardware layer only allows the target process running under the corresponding ASID to access the third storage address; when other non-target processes attempt to access the address, due to the ASID mismatch, the MMU will directly trigger an access exception and intercept it, thereby ensuring at the hardware layer that only the target process can obtain the target data, effectively preventing unauthorized processes from bypassing access control through physical addresses.

[0072] Optionally, in this embodiment, data processing requirements may include, but are not limited to, the requirements for decrypting business data and the requirements for encrypting business data, etc.

[0073] As an optional implementation, the fourth storage address of the shared storage unit may, but is not limited to, be used to store the processing unit key of the second processing unit. The processing unit key may, but is not limited to, be used to encrypt and decrypt communication data between the first processing unit and the second processing unit. The second processing unit may, but is not limited to, be configured to have access to the fourth storage address.

[0074] Optionally, in this embodiment, the communication between the first processing unit and the second processing unit may be, but is not limited to, based on a processing unit key, which may be used, but is not limited to, for encrypting and decrypting communication data between the first and second processing units. The second processing unit is configured to have access to a fourth storage address, ensuring the normal operation of encrypted communication between the first and second processing units.

[0075] As an optional implementation, the control device may include, but is not limited to, a peripheral isolator; the shared storage unit may be connected to the second bus via the peripheral isolator; the peripheral isolator may be used to prevent a second operating device connected to the second bus from accessing the shared storage unit.

[0076] Optionally, in this embodiment, the peripheral isolator may be, but is not limited to, a hardware security component deployed between the shared storage unit and the peripheral bus (i.e., the second bus).

[0077] Optionally, in this embodiment, the memory access range of different peripherals can be isolated by an IOMMU (Input Output Memory Management Unit) (i.e., the aforementioned peripheral isolator) to prevent peripherals from accessing the shared storage unit.

[0078] Optionally, in this embodiment, one or more IOMMU page tables may be maintained internally by the peripheral isolator, and the mapping of the IOVA (I / O Virtual Address) of the second running device to the physical address of the shared memory unit may not be created in the IOMMU page table, but is not limited to. When the second running device initiates a shared memory unit access request, the peripheral isolator searches the IOMMU page table. If no mapping entry is found, or the permission bit of the found mapping entry is set to 0 (i.e., the mapping entry is invalid), the peripheral isolator refuses to respond to the access request, triggering a hardware exception. Alternatively, when the second running device triggers unauthorized access to the shared memory unit, the peripheral isolator can directly disconnect the bus connection of the second running device without affecting the normal operation of other second running devices.

[0079] By using an external isolator installed between the second bus and the shared storage unit, precise control over access permissions to the shared storage unit is achieved, preventing insecure access to the shared storage unit by a second operating device connected on the second bus and ensuring the data security of the shared storage unit.

[0080] As an optional implementation, the control device further includes: a direct memory controller and a target interface; both the target interface and the direct memory controller are connected to a second bus; the target interface is used to connect a second external device, and the second operating device includes the second external device; the second external device is used to directly access the storage unit on the control device through the direct memory controller; wherein, a peripheral isolator is used to prevent the second external device from directly accessing the shared storage unit through the direct memory controller.

[0081] Optionally, in this embodiment, a peripheral isolator can be used to prevent a second external device connected through the target interface from directly accessing the shared storage unit through the direct storage controller, thereby preventing the data stored in the shared storage unit from being stolen or tampered with by external devices.

[0082] As an optional implementation, the control device may, but is not limited to, include: an encryption acceleration engine; the encryption acceleration engine is only connected to the first bus; and the first processing unit is further configured to control the encryption acceleration engine to perform cryptographic operations using the data stored in the reference storage unit.

[0083] Optionally, in this embodiment, the encryption acceleration engine may be connected to, but is not limited to, only the first bus, so that the encryption acceleration engine can only be used by the first processing unit, ensuring the security of the encryption acceleration engine, and further ensuring the security of the security functions implemented using the encryption acceleration engine.

[0084] As an optional implementation, the control device also includes: a management interface, a third bus, and a bus bridge. Figure 3This is a schematic diagram of a control device according to an embodiment of this application. Figure 3 .like Figure 3 As shown, the management interface is connected to both the first bus and the third bus, and the bus bridge is connected between the second bus and the third bus. The control permissions of the management interface can be set to allow control only by one of the processing units, the first processing unit and the second processing unit. The management interface is used to connect to the operation and maintenance terminal of the control device.

[0085] Optionally, in this embodiment, different buses may also carry communication at different speed levels (such as the aforementioned second bus and the aforementioned third bus), and buses carrying different speed levels may be connected, but not limited to, via a bus bridge. Optionally, a bus bridge may be, but is not limited to, a hardware interface circuit or logic module that connects two different bus domains.

[0086] Optionally, in this embodiment, the control device may include, but is not limited to, a management interface for connecting to an external control device's maintenance terminal. The maintenance terminal may be used, but is not limited to, for monitoring the operation of the control device and restoring the normal operation of the control device in the event of a control device failure.

[0087] Optionally, in this embodiment, the control permissions of the management interface can be set to allow only one of the first and second processing units to control it. This avoids the control failure caused by two processing units controlling the management interface at the same time, and also ensures that the first processing unit will not be affected by the second processing unit with poor security when using the management interface to implement security functions, thus ensuring the security of the security functions.

[0088] As an optional implementation method, Figure 4 This is a schematic diagram of a control device according to an embodiment of this application. Figure 4 .like Figure 4As shown, the control device may include, but is not limited to, APP_AHB_BUS (i.e., the second bus), SEC_AHB_BUS (i.e., the first bus), APB_BUS (i.e., the third bus), CPU1 (i.e., the second processing unit), and CPU0 (i.e., the first processing unit). An IOPMP (i.e., a bus isolator) is configured between APP_AHB_BUS and SEC_AHB_BUS of the control device. The control device's APP_AHB_BUS also connects to DMA (Direct Memory Access) (i.e., direct memory controller), RGMII (Reduced Gigabit Media Independent Interface, an interface between Ethernet media access control layer physical layer devices) / RMII (Reduced Media Independent Interface, an interface between Ethernet media access control layer physical layer devices), USB (Universal Serial Bus) 1.1, USB 2.0, and QSPI (Quad Serial Peripheral Interface), LPC (Low Pin Count Bus), and eSPI (Enhanced Serial Peripheral Interface). It can connect external devices through, but is not limited to, these interfaces such as RGMII / RMII, USB 1.1, USB 2.0, QSPI, LPC, and eSPI. The control device also includes SRAM (Static Random-Access Memory) and PSRAM (Pseudo Static Random-Access Memory) as shared storage units. It also includes OTBN (Operand-Testable Big Number) and SM2 (a hash algorithm) / SM3 (a hash algorithm) / SM4 (a hash algorithm) encryption acceleration engines. The control device's management interface, UART (Universal Asynchronous Receiver / Transmitter), is connected to APB_BUS, and an AHB2APB bridge (i.e., a bus bridge) is also established between APB_BUS and APP_AHB_BUS.

[0089] As an optional implementation, the reference storage unit may, but is not limited to, store the identity key information, startup key information, and communication key information of the control device; wherein, the first processing unit may, but is not limited to, be used for: starting the control device according to the startup key information; verifying the security of the target terminal to be connected to the second processing unit according to the identity key information; and responding to the data processing request initiated by the second processing unit according to the communication key information.

[0090] Optionally, in this embodiment, the data used by the security functions stored in the reference storage unit may include, but is not limited to, various types of data: startup key information corresponding to secure boot, identity key information and communication key information corresponding to secure communication, etc.

[0091] As an optional implementation, the identity key information may include, but is not limited to, a device key for the control device and a root certificate for the control device; wherein, the reference storage unit may include, but is not limited to, a first non-volatile memory and a second non-volatile memory; the first non-volatile memory may store, but is not limited to, the device key; and the second non-volatile memory may store, but is not limited to, the root certificate.

[0092] Optionally, in this embodiment, the device key may be used, but is not limited to, to identify the control device. The device key may be, but is not limited to, unique identification information of the control device. The device key may include, but is not limited to, a unique identifier, such as an EK (Enrollment Key). The device key may be, but is not limited to, burned into the control device at the factory, that is, stored in the first non-volatile memory at the factory, cannot be tampered with, and is hardware locked, allowing only internal operations.

[0093] Optionally, in this embodiment, the first non-volatile memory may be, but is not limited to, an immutable storage medium inside the control device, such as Secure OTP (Secure One-Time Programmable Memory).

[0094] Optionally, in this embodiment, the root certificate may be, but is not limited to, the starting point of the public key infrastructure trust chain, and may include, but is not limited to, a public key and corresponding identity information (such as the issuing authority name, validity period, etc.). The root certificate of the control device may, but is not limited to, refer to the vendor's root certificate or the platform's root certificate. Optionally, the legitimacy of all other certificates (such as intermediate certificates, device certificates) may, but is not limited to, ultimately trace back to the root certificate, that is, the root certificate may, but is not limited to, be used to verify the legitimacy of other certificates.

[0095] Optionally, in this embodiment, the root certificate may, but is not limited to, be stored on an immutable storage medium inside the control device, that is, the second non-volatile memory may, but is not limited to, include ROM (Read-Only Memory).

[0096] Optionally, in this embodiment, the device key and root certificate of the control device are stored on a first non-volatile memory and a second non-volatile memory, respectively. This separate storage strategy achieves physical and logical isolation between core confidential data and the public trust anchor. This prevents the second processing unit from simultaneously stealing the device key and tampering with the trust benchmark through a single storage area vulnerability, and ensures that even if part of the storage medium is damaged, the authentication capability or firmware verification capability of the control device can still exist independently. Physical isolation enhances the security of the key and the root of trust, and improves the ability to resist single points of failure and coordinated attacks.

[0097] As an optional implementation, the startup key information may include, but is not limited to,: the root key of the control device, and, corresponding firmware data identifiers and standard results; wherein, the reference storage unit includes: a first non-volatile memory and a second non-volatile memory; the root key is stored in the first non-volatile memory; and the corresponding firmware data identifiers and standard results are stored in the second non-volatile memory.

[0098] Optionally, in this embodiment, the root key may be, but is not limited to, the highest-level key in the control device security architecture, and the root key may be, but is not limited to, stored in an immutable storage medium.

[0099] Optionally, in this embodiment, the firmware data identifier may be used, but is not limited to, to identify each firmware data, and each firmware data may be used, but is not limited to, to start each part of each processing unit of the control device. For example, each firmware data may include, but is not limited to, first firmware data and second firmware data for starting the bootloader of the first processing unit, etc.

[0100] Optionally, in this embodiment, the standard result may be, but is not limited to, obtained by performing cryptographic operations on the firmware data identified by the firmware data identifier. It may be, but is not limited to, performing cryptographic operations (e.g., hash operations) on the firmware data when it is determined that the firmware data is secure and usable, and storing the cryptographic operation result as the standard result in the second non-volatile memory. When it is necessary to start each part of the processing unit with the firmware data, the standard result is used to perform security verification on the firmware data first.

[0101] Optionally, in this embodiment, the root key and the corresponding firmware data identifier and standard result are stored in the first non-volatile memory and the second non-volatile memory respectively. This separate storage strategy realizes the physical and logical isolation of the two types of security data, reducing the risk of the two types of security data being stolen or tampered with at the same time.

[0102] As an optional implementation, the boot key information may include, but is not limited to, a firmware data identifier and a verification key with a corresponding relationship; the reference storage unit may also include a target volatile memory; wherein the target volatile memory stores the firmware data identifier and the verification key with a corresponding relationship.

[0103] Optionally, in this embodiment, the boot key information may include, but is not limited to, a corresponding firmware data identifier and a standard result for verifying whether the firmware data has been tampered with, a corresponding firmware data identifier and a verification key for verifying whether the data source of the firmware data is reliable.

[0104] As an optional implementation, the control device may, but is not limited to, include: a third non-volatile memory; wherein the third non-volatile memory is connected to the second bus; wherein the third non-volatile memory stores a key packet of the control device and a corresponding firmware data identifier and an encrypted firmware data packet, the key packet being an encrypted firmware data identifier and a decryption key, the encrypted firmware data packet being firmware data identified by the encrypted firmware data identifier, and the firmware data being used to start the control device.

[0105] Optionally, in this embodiment, the firmware data identifier and encrypted firmware data packet with corresponding relationship, as well as the encrypted firmware data identifier and decryption key with corresponding relationship, can be stored on a third non-volatile memory. This allows for convenient acquisition of the firmware data and decryption data required for startup while avoiding direct acquisition of plaintext firmware data, thereby improving the security of the startup process.

[0106] As an optional implementation, the communication key information may include, but is not limited to, target credential information, and a corresponding processing identifier and terminal session key. The target credential information may include, but is not limited to, target credential parameters used to indicate the target credential authorized by the first processing unit to the second processing unit. The terminal session key may include, but is not limited to, encrypting and decrypting data to be processed, which is data transmitted between the second processing unit and a target terminal connected to the second processing unit. The reference storage unit may include, but is not limited to, a target volatile memory. The target volatile memory may store, but is not limited to, the target credential information and the corresponding processing identifier and terminal session key.

[0107] Optionally, in this embodiment, when the control device includes multiple second processing units, the security functions provided by the first processing unit may be available to, but are not limited to, all second processing units. In this case, the first processing unit may, but is not limited to, issue target credentials to second processing units that are able to use the security functions provided by the first processing unit.

[0108] Optionally, in this embodiment, the security functions provided by the first processing unit may or may not be available for all business needs of the second processing unit. In this case, the first processing unit may or may not issue target credentials to the second processing unit corresponding to the business needs that can use the security functions.

[0109] Optionally, in this embodiment, different credentials may have, but are not limited to, different credential parameters, and the target credential parameters may be used to verify whether the credential provided by the second processing unit is the target credential authorized and issued by the first processing unit.

[0110] Optionally, in this embodiment, such as Figure 4 As shown, the SEC_AHB_BUS of the control device is also connected to secureOTP (Secure One-Time Programmable) (i.e., the first non-volatile memory), BROM (Boot ROM) (i.e., the second non-volatile memory), and SRAM (i.e., the target volatile memory). The control device also includes eMMC (Embedded MultiMediaCard) (i.e., the third non-volatile memory), which is connected to APP_AHB_BUS.

[0111] As an optional implementation, the reference storage unit may, but is not limited to, store target key information of the control device. The target key information may, but is not limited to, include: key parameters of the second processing unit in various operating states; the first processing unit may, but is not limited to, be used to: detect the target operating state of the second processing unit in the various operating states via the second bus; and access the reference storage unit via the first bus to control the operation of the second processing unit according to the target key parameters corresponding to the target operating state in the target key information.

[0112] As an optional implementation, the target key information may include, but is not limited to, a root key, and may also include, but is not limited to, a firmware data identifier and a standard result with a corresponding relationship, and / or, a firmware data identifier and a verification key with a corresponding relationship; wherein, the first processing unit may be used for, but is not limited to, decrypting the encrypted firmware data packet of the control device according to the root key to obtain at least one firmware data, wherein the at least one firmware data is used to start the control device; and, according to the firmware data identifier and the standard result with a corresponding relationship, and / or, the firmware data identifier and the verification key with a corresponding relationship, detecting the security information of the at least one firmware data, wherein the security information is used to indicate the security of the at least one firmware data.

[0113] Optionally, in this embodiment, decrypting the encrypted firmware data packet of the control device according to the root key may include, but is not limited to: directly decrypting the encrypted firmware data packet using the root key to obtain at least one firmware data, or decrypting the encrypted firmware data identifier and decryption key with a corresponding relationship using the root key to obtain the firmware data identifier and decryption key with a corresponding relationship, and then decrypting the encrypted firmware data packet using the firmware data identifier and decryption key with a corresponding relationship to obtain at least one firmware data.

[0114] Optionally, in this embodiment, the security of firmware data can be detected by using, but is not limited to, a firmware data identifier and a verification key with a corresponding relationship, or by using, but is not limited to, a firmware data identifier and a verification key with a corresponding relationship together.

[0115] As an optional implementation, the reference storage unit may include, but is not limited to, a target volatile memory and a first non-volatile memory; the target volatile memory stores a firmware data identifier and a verification key with a corresponding relationship, and the first non-volatile memory stores a root key; the first processing unit is further configured to: read the root key from the first non-volatile memory when the first processing unit starts up to the target stage; generate a firmware data identifier and a verification key with a corresponding relationship based on the root key; and write the firmware data identifier and the verification key with a corresponding relationship into the target volatile memory.

[0116] Optionally, in this embodiment, the corresponding firmware data identifier and verification key may be generated by the first processing unit using the root key stored in the first non-volatile memory and stored in the target volatile memory. Storing the verification key in the volatile memory ensures that the key only exists during the operation of the control device. Once the power is cut off or restarted, the key is immediately destroyed, which fundamentally prevents the key from being physically extracted from the storage medium or stolen for a long time.

[0117] Optionally, in this embodiment, the method for generating the corresponding firmware data identifier and verification key based on the root key may be, but is not limited to, a fixed method; that is, the method for deriving the verification key from the root key may be, but is not limited to, a fixed method. The method for generating the corresponding firmware data identifier and verification key stored in the target volatile memory for detecting the security of firmware data based on the root key may be, but is not limited to, the same as the method for generating the corresponding firmware data identifier and verification key for signing firmware data based on the root key.

[0118] Optionally, in this embodiment, the target stage may refer to any stage preceding the stage where security checks on the firmware data are required. When the first processing unit starts up to the target stage, a verification key is needed to check the security of the firmware data.

[0119] As an optional implementation, the control device may, but is not limited to, further include: a third non-volatile memory; wherein the third non-volatile memory may, but is not limited to, store a key packet and corresponding firmware data identifiers and encrypted firmware data packets, wherein the key packet is an encrypted firmware data identifier and a decryption key, and the encrypted firmware data packet is firmware data identified by the encrypted firmware data identifier, and the firmware data is used to start the control device; wherein the first processing unit is further configured to read a root key from a reference storage unit; decrypt the key packet using the root key to obtain a corresponding firmware data identifier and a decryption key; and decrypt the encrypted firmware data packet using the corresponding firmware data identifier and the decryption key to obtain at least one piece of firmware data.

[0120] Optionally, in this embodiment, the first processing unit may, but is not limited to, read the root key from the reference storage unit via the first bus, and obtain the key packet and encrypted firmware data packet from the third non-volatile memory via the second bus. The first processing unit may then use the root key to decrypt the key packet to obtain a firmware data identifier and decryption key with a corresponding relationship. Finally, the first processing unit may use the firmware data identifier and decryption key with a corresponding relationship to decrypt the encrypted firmware data packet to obtain at least one firmware data.

[0121] As an optional implementation, the control device may, but is not limited to, further include: a shared storage unit; the first storage address in the shared storage unit may, but is not limited to, be set to allow only the first processing unit to access it if the security information of the alternative firmware data is not verified or if the security information of the alternative firmware data is used to indicate that the alternative firmware data is insecure, the alternative firmware data being used to start the kernel program of the second processing unit; the first processing unit may, but is not limited to, further be used to: store the alternative firmware data to the first storage address when the alternative firmware data is obtained.

[0122] Optionally, in this embodiment, after the first processing unit obtains the alternative firmware data through bus access and decryption operations, the first processing unit may, but is not limited to, store the obtained alternative firmware data in the first storage address.

[0123] As an optional implementation, the second storage address in the shared storage unit may, but is not limited to, be configured to allow only the first processing unit to access the candidate firmware data if the security information of the candidate firmware data is not verified or if the security information of the candidate firmware data is used to indicate that the candidate firmware data is insecure. The candidate firmware data is used to start the user service program of the second processing unit. The first processing unit may, but is not limited to, also store the candidate firmware data in the second storage address when it obtains the candidate firmware data.

[0124] Optionally, in this embodiment, after the first processing unit obtains the candidate firmware data through bus access and decryption operations, the first processing unit may, but is not limited to, store the obtained candidate firmware data in the second storage address.

[0125] As an optional implementation, the target key information may include, but is not limited to: target credential information, and a corresponding processing identifier and a terminal session key, wherein the processing identifier is used to identify the communication connection between the terminal and the second processing unit, the target credential information is used to indicate the target credential parameters of the target credential authorized by the first processing unit to the second processing unit, and the terminal session key is used to encrypt and decrypt the data to be processed, which is data transmitted between the second processing unit and the target terminal connected to the second processing unit; wherein the first processing unit is used to perform cryptographic operations on the data to be processed transmitted by the second processing unit according to the target credential information and the corresponding processing identifier and terminal session key to obtain the target data.

[0126] Optionally, in this embodiment, the control device may, but is not limited to, be connected to the terminal through the second processing unit, and the terminal connected to the control device may, but is not limited to, manage and control the server connected to the control device through the control device.

[0127] Optionally, in this embodiment, the connection between the second processing unit and different terminals may, but is not limited to, require the use of different terminal session keys. Using different terminal session keys achieves session-level key isolation, ensuring that even if the session key of a terminal is leaked, the security of communication with other terminals will not be compromised, effectively preventing lateral attacks caused by key leakage.

[0128] As an optional implementation, the target key information may include, but is not limited to, the root certificate of the control device and the device key of the control device; the first processing unit may be used for, but is not limited to, verifying the security of the target terminal to be connected to the second processing unit based on the root certificate and the device key; if the target terminal is found to be secure, generating target credential information and a target terminal session key for the target connection between the target terminal and the second processing unit; and writing the target credential information, as well as the processing identifier of the corresponding target connection and the target terminal session key, into the reference storage unit.

[0129] Optionally, in this embodiment, the first processing unit may establish a connection between the second processing unit and the target terminal only after verifying the security of the target terminal to be connected to the second processing unit by combining the root certificate and the device key, and determining that the target terminal is secure. This generates connection interaction preparation information (i.e., the aforementioned target credential information and target terminal session key) for the target connection between the target terminal and the second processing unit, in order to avoid the second processing unit establishing a connection with an insecure terminal and to prevent insecure terminals from affecting the secure operation of the control device.

[0130] Optionally, in this embodiment, the generated target credential information, as well as the corresponding target connection processing identifier and target terminal session key, can be written into a secure reference storage unit to prepare for the secure use of the target credential information and the corresponding target connection processing identifier and target terminal session key.

[0131] As an optional implementation, the control device may, but is not limited to, include: a shared storage unit; the third storage address in the shared storage unit may, but is not limited to, be set to allow access only by the target process of the second processing unit and the first processing unit, wherein the target process is the process in the second processing unit that initiated a data processing request to the first processing unit; wherein the first processing unit may, but is not limited to, also store the target data in the third storage address when it acquires the target data.

[0132] Optionally, in this embodiment, the first processing unit may, but is not limited to, store the target data obtained after performing cryptographic operations on the data to be processed into a third storage address of a shared storage unit accessible to the target process of the second processing unit. This ensures that the target process can successfully obtain the target data and also prevents other unrelated processes from stealing the target data or affecting the target data.

[0133] As an optional implementation, the control device may include, but is not limited to, a shared storage unit; the fourth storage address in the shared storage unit may be, but is not limited to, set to allow access only by the first processing unit and the second processing unit; wherein the first processing unit is further configured to generate a processing unit key for the second processing unit, the processing unit key being used to encrypt and decrypt communication data between the first processing unit and the second processing unit; and to store the processing unit key in the fourth storage address.

[0134] Optionally, in this embodiment, the fourth storage address in the shared storage unit may, but is not limited to, be set to allow only the first processing unit and the second processing unit to access it, thereby ensuring the security of the processing unit key stored at the fourth storage address.

[0135] As an optional implementation method, Figure 5 This is an overall architecture diagram of a control device according to an embodiment of this application. Figure 6 This is a hierarchical architecture diagram of a control device according to an embodiment of this application. Figure 7 This is a dual-system isolation architecture diagram of a control device according to an embodiment of this application. Figure 5 As shown, the architecture of the control device provided in this application can be, but is not limited to, based on hardware isolation, centered on end-to-end measurement, and supported by trusted interaction. It employs a dual-system architecture of BMC chips to construct a dual-architecture isolation system encompassing the security domain and the business domain, covering the entire lifecycle of trusted protection for the BMC from power-on startup and operational management to security protection. Optionally, the overall architecture can be, but is not limited to, divided into four layers: a hardware root layer, an isolation execution layer, an end-to-end trusted function layer, and a device layer. For example... Figure 6 As shown, authorized access can be achieved through a security bus, but is not limited to this; unauthorized cross-layer interactions are directly intercepted by the hardware. The hardware root layer (root of trust and isolation foundation) serves as the trust foundation of the architecture, providing hardware-level isolation, secure storage, and encrypted computing capabilities. All components are immutable hardware units. The specific composition of the hardware root layer may include, but is not limited to:

[0136] 1. Dual-system architecture CPU unit (core isolated component): such as Figure 7As shown, physical-level isolation can be achieved using two independent CPUs built into the BMC, but not limited to: CPU0 (Security Core) (i.e., the first processing unit): a dedicated security execution core, which can run a TEE (Trusted Execution Environment) built on Zephyr OS (Operating System) (a type of RTOS (Real-Time Operating System)), handling only security-related operations (signature verification, key management, security protection, end-to-end measurement), without any non-security function redundancy; CPU1 (Service Core) (i.e., the second processing unit): a functional execution core, running a complete operating system to implement routine management functions (sensor monitoring, log management, remote operation and maintenance interaction), without security key access permissions. The service core can, but is not limited to, have ROM and RAM accessible to the service core, as well as an ADC (Analog-to-Digital Converter) and accelerator to enable the service core to perform normal management services to the server. The service core can also, but is not limited to, have various interfaces (SPI (Serial Peripheral Interface), UART, I2C (Inter-Integrated Interface)). Circuit (inter-integrated circuit bus), I3C (Improved Inter-Integrated Circuit); Inter-core communication components: can, but are not limited to, integrate Mailbox secure channels (hardware level), support authorized command interaction between dual cores, communication data can, but are not limited to, use AES-256 (an encryption algorithm), and unauthorized commands (such as business cores directly requesting keys) are intercepted and logged when they are securely verified.

[0137] 2. Secure Storage Unit: Designed according to the principles of isolated storage and hierarchical access: ROM0 (Secure Core Dedicated Read-Only Storage) (i.e., the second non-volatile memory): Contains the secure core First Stage Bootloader (initial boot program) (i.e., the first firmware data), end-to-end metric benchmark values ​​(hash digests) (i.e., firmware data identifiers and standard results with corresponding relationships), and the root key public key. ROM0 can be accessed by, but is not limited to, only the secure core, physically isolating the service core; Secure SRAM (Security Core Dedicated Random Access Memory) (i.e., Target Volatile Memory): Can be used, but is not limited to, to store runtime keys (i.e., firmware data identifiers and verification keys with corresponding relationships), measurement results, and fault logs. Data is lost upon power failure to prevent key leakage. Shared ROM / RAM (Hierarchical Access) (i.e., Shared Storage Unit): Can be used, but is not limited to, to store the basic firmware of the business core (i.e., fourth and fifth firmware data), with access domains divided by PMP or IOMMU. eMMC (Encrypted Storage) (i.e., Third Non-Volatile Memory): Can be used, but is not limited to, to store the encrypted business core firmware image (i.e., firmware data identifiers and encrypted firmware data packets with corresponding relationships). Supports segment-by-segment online encryption and decryption. Only the security core can perform decryption operations. The storage space of eMMC can be divided by hardware partitions, including: Business Core Firmware Area (stores encrypted firmware images), Security Core Backup Area (accessible only by the security core, used for version backup and rollback before security core firmware upgrades), and Security Data Area (used for long-term backup of audit logs, etc.). All partitions are protected by hardware isolation components, prohibiting unauthorized cross-partition access.

[0138] 3. Hardware Isolation Components: Implement access isolation between cores and devices: PMP (Intra-core Memory Isolation): Can, but is not limited to, configure independent PMP registers (i.e., first register and second register) for two CPUs (i.e., the first processing unit and the second processing unit), define memory access permission tables (e.g., the secure core ROM0 area is only allowed to be read by CPU0), and unauthorized access triggers hardware exceptions; IOPMP (Bus-level Isolation) (i.e., bus isolator): Deployed on the system bus, it manages the access permissions of bus master devices such as DMA and PCIe, preventing peripherals from attacking the security domain through the bus; IOMMU (Device Memory Isolation) (i.e., peripheral isolator): Isolates the memory access range of different peripherals (such as network cards and sensors) to prevent malicious data tampering by peripherals.

[0139] Optionally, in this embodiment, independent PMP registers can be deployed for the security core (CPU0) and the service core (CPU1) respectively, with the permission table strongly bound to the hierarchical security storage, achieving strict isolation of the dual-core physical memory. The security core ROM0 area is configured as read-only throughout, allowing the security core to read only the initial boot program, root key public key, and other trusted root data, without any write permission opening mechanism; security core firmware updates are performed through the security core's dedicated writable partition in the eMMC. Hardware anomalies triggered by unauthorized access will not only interrupt the current core operation but also simultaneously notify the BMC trusted monitoring module, triggering dual-system security status verification, rather than being handled solely within the core.

[0140] Optionally, in this embodiment, IOPMP can be deployed on the system bus, but is not limited to, to perform permission checks on transactions of BusMaster devices (bus master devices) such as DMA and PCIe. Access control is implemented based on the SID (Device Permission ID), MD (Memory Domain), and IOPMPEntry (Record) rule tables, with the core objective of preventing peripheral devices from accessing memory without authorization.

[0141] Optionally, in this embodiment, before a bus master device such as DMA or PCIe initiates access, IOPMP may, but is not limited to, request real-time metric verification of the target memory region from the BMC trusted root (security core). (The metric is stored in SecureSRAM and compared with a preset baseline value in ROM0). Only after successful verification will the bus master device be checked for access to the storage region. If the verification is successful, the transmission is allowed. A three-level bus access system may be implemented for BMC-specific peripherals, with the access scope and priority of different peripherals bound to their trust levels. Out-of-band management network cards have higher access rights than ordinary sensors, and a unified access control logic is used in general solutions. An audit register may, but is not limited to, be built into IOPMP to record the initiating device, target address, and access result of all cross-domain bus accesses. Logs are encrypted and transmitted via the security bus to the SecureSRAM of the security core for temporary storage, and periodically synchronized to the secure data area of ​​the eMMC for long-term backup. Once written, logs can only be read by the security core and cannot be tampered with or deleted.

[0142] Optionally, in this embodiment, the IOMMU may, but is not limited to, not only isolating the memory access ranges of different peripherals, but also explicitly dividing four independent address spaces: the security core memory domain, the service core memory domain, the BMC shared memory domain, and the peripheral shared memory domain. Peripherals can only access the peripheral shared domain and are prohibited from directly accessing the private memory domain of the dual-core system. The memory-mapped page tables of the IOMMU may, but are not limited to, be generated and signed by the security core, and must be loaded after signature verification by the BMC root of trust at startup. When a peripheral triggers an unauthorized memory access, the IOMMU may, but is not limited to, directly disconnect the bus connection of that peripheral without affecting the normal operation of other peripherals.

[0143] 4. Key and Encryption Unit: Provides encryption computing capabilities and key storage security: Secure OTP (One-Time Programmable Storage): Stores the Root Key, Device ID, and EK Key (Endorsement Key), which cannot be tampered with after being burned and can only be read by the security core; Encryption Acceleration Engine: Supports multiple encryption algorithms at the hardware level, realizing hardware acceleration of SSL / TLS (Secure Sockets Layer / Transport Layer Security) negotiation, firmware image encryption and decryption, and digital signature verification, improving security processing efficiency.

[0144] Optionally, in this embodiment, the isolated execution layer can, but is not limited to, be based on the hardware root layer, constructing two independent execution environments, clearly defining permission boundaries, and ensuring the isolated operation of the security domain and the functional domain:

[0145] 1. Secure Core TEE Environment: The secure core can, but is not limited to, run a TEE (Trusted Execution Environment) built on Zephyr OS, with all non-secure functions removed, retaining only core security services such as key management, signature verification, and measurement auditing; it can, but is not limited to, deploy TAs (TEE APPs, TEE security applications) on the secure core, including measurement TAs, key management TAs, and fault control TAs. All TAs are verified by the signature of the initial program of the secure core to prevent malicious TA injection; it can, but is not limited to, only allow access to the secure storage unit and encryption unit at the hardware root level, and prohibit direct access to peripherals of the business core (such as network cards and serial ports).

[0146] 2. Business Core Functional Environment: It may, but is not limited to, run business firmware based on the Zephyr kernel service program, and deploy conventional business applications such as sensor monitoring, PSU (Power Supply Unit) management, and remote operation and maintenance; it may, but is not limited to, only allow access to shared storage and device-level peripherals, and prohibit access to the security core's dedicated storage and the key storage area of ​​the encryption unit. All security-related operations must initiate an authorization request to the security core through Mailbox.

[0147] Optionally, in this embodiment, trusted functional modules covering the entire lifecycle of BMC can be deployed to form a full-link trusted functional layer. All modules can be implemented with "a secure core as the root of trust and hardware isolation as a guarantee". Table 1 is a modular example table of a full-link trusted functional layer. As shown in Table 1, the full-link trusted functional layer can include, but is not limited to, five core modules.

[0148] Table 1

[0149]

[0150] Optionally, in this embodiment, the device layer may be used, but is not limited to, to enable the connection between the BMC and external components. All interface accesses must be authorized by the security kernel. External components may include, but are not limited to: server core components: Host CPU, CPLD (Complex Programmable Logic Device), PSU, fan / temperature / voltage sensors; maintenance interfaces: Ethernet interface, UART serial port, USB interface, etc.

[0151] Optionally, in this embodiment, authorization can be tiered according to the trust level of peripheral devices, with out-of-band management network cards having higher permissions than ordinary sensors; core components such as PSUs and fans are controlled by the service core by default. When the service core fails, the security core obtains the minimum operating permissions through resource takeover mode, and transfers control after the fault is recovered.

[0152] As an optional implementation, the first processing unit may, but is not limited to, controlling the second processing unit to start by accessing the reference storage unit according to the first key parameter corresponding to the first running state in the target key information when the target running state is the first running state, wherein the first running state is used to indicate that the control device has been triggered to start.

[0153] This embodiment provides a method for starting the processing unit of a control device. Figure 8 This is a flowchart of a method for starting the processing unit of a control device according to an embodiment of this application, such as... Figure 8 As shown, the method includes the following steps:

[0154] Step S802: When the control device is triggered to start, the first firmware data is run to start the target program. The control device includes a first processing unit and a second processing unit. The bootloader of the first processing unit includes a target program and a reference program.

[0155] Step S804: The target program calls the second firmware data startup reference program based on the first security information of the first firmware data and the second security information of the second firmware data. The first security information is used to indicate the security of the first firmware data, and the second security information is used to indicate the security of the second firmware data.

[0156] In step S806, the reference program calls the third firmware data based on the third security information to start the operating system for the first processing unit. The third security information is used to indicate the security of the third firmware data of the operating system, and the operating system is used to start the second processing unit.

[0157] Based on the above, and through this application, when the control device is triggered to start, the first firmware data starts the target program. The target program then calls the second firmware data to start the reference program based on the first security information of the first firmware data and the second security information of the second firmware data, thereby improving the security of the startup operation of the reference program. The reference program then calls the third firmware data to start the operating system of the first processing unit based on the third security information, further improving the security of the startup operation of the operating system of the first processing unit. The operating system of the first processing unit is used to start the second processing unit. Using the secure boot operating system to start the second processing unit improves the security of the startup operation of the second processing unit. Therefore, this application solves the technical problem of low security in the startup process of the control device's processing unit in related technologies, achieving the technical effect of improving the security of the startup process of the control device's processing unit.

[0158] Optionally, in this embodiment, the startup process of the first processing unit may, but is not limited to, be divided into the startup of the target program, the startup of the reference program, and the startup of the operating system. This division operation may, but is not limited to, reduce the attack surface of the startup process and improve the startup security of the first processing unit. Furthermore, using the more secure operating system of the first processing unit to start the second processing unit also improves the startup security of the second processing unit.

[0159] Optionally, in this embodiment, the method for starting a processing unit of a control device provided in this application may be applied to, but is not limited to, the first processing unit of the control device.

[0160] In the embodiment provided in step S802, the control device is triggered to start, which may refer to the control device entering initialization and loading firmware program from a power-off, reset or hibernation state to start running.

[0161] Optionally, in this embodiment, the control device can be started by means of power-on triggering, hard reset triggering, software command triggering, etc.

[0162] Optionally, in this embodiment, the bootloader of the first processing unit may include, but is not limited to, a target program and a reference program. The target program may be, but is not limited to, a first-stage bootloader, i.e., an FSB (First Stage Bootloader). The reference program may be, but is not limited to, the remaining part of the bootloader excluding the target program, such as a second-stage bootloader.

[0163] In the embodiment provided in step S804, after the target program is started by running the first firmware data, the target program may, but is not limited to, combine the security information of the first firmware data used to start itself (i.e., the first security information) and the security information of the second firmware data used to start the reference program to comprehensively determine whether to continue starting the control device, i.e., whether to start the reference program.

[0164] Optionally, in this embodiment, the target program may report a startup failure when the first security information indicates that the first firmware data is insecure, and / or the second security information indicates that the second firmware data is insecure. In this case, the startup process of the control device will not continue to be executed, that is, the startup reference program for the second firmware data will not be called.

[0165] In the embodiment provided in step S806, the started reference program may determine, but is not limited to, whether to call the third firmware data to start the operating system for the first processing unit based on the security of the third firmware data used to start the operating system.

[0166] Optionally, in this embodiment, if the third security information indicates that the third firmware data is insecure, the reference program may report a startup failure and stop the continued execution of the startup process of the control device.

[0167] As an optional implementation, the target program can initiate the reference program by calling the second firmware data based on the first security information of the first firmware data and the second security information of the second firmware data, but not limited to the following methods: the target program obtains target key information from the reference storage unit via a first bus, wherein the control device further includes: a reference storage unit and a first bus, a first processing unit connected to the first bus, the reference storage unit being configured to allow only the first processing unit to access the reference storage unit, and the reference storage unit storing the target key information and the second firmware data of the control device; the target program detects the first security information of the first firmware data based on the target key information; if the first security information indicates that the first firmware data is secure, the target program obtains the second firmware data from the reference storage unit via the first bus; the target program detects the second security information of the second firmware data based on the target key information; if the second security information indicates that the second firmware data is secure, the target program uses the second firmware data to initiate the reference program.

[0168] Optionally, in this embodiment, the first key parameter may include, but is not limited to, target key information.

[0169] Optionally, in this embodiment, if it is determined that the first security information is used to indicate the security of the first firmware data, the target program may obtain the second firmware data from the reference storage unit through the first bus to avoid insecure target program accessing the reference storage unit.

[0170] As an optional implementation, the detection of first security information of the first firmware data by the target program based on the target key information can be achieved in the following ways, but not limited to: the target program obtains the first firmware data stored in the reference storage unit through the first bus, and obtains the first standard result corresponding to the first firmware data identifier of the first firmware data from the firmware data identifier and standard result with corresponding relationship, wherein the target key information includes: firmware data identifier and standard result with corresponding relationship; the target program performs a first cryptographic operation on the first firmware data to obtain a first operation result; and the target program determines the first security information based on the first standard result and the first operation result.

[0171] Optionally, in this embodiment, the first firmware data may be, but is not limited to, stored in the reference storage unit.

[0172] Optionally, in this embodiment, the first cryptographic operation may be, but is not limited to, a hash operation.

[0173] Optionally, in this embodiment, the determination of the first security information by the target program based on the first standard result and the first calculation result may include, but is not limited to: the target program comparing the first standard result and the first calculation result; if the comparison of the first standard result and the first calculation result is consistent, determining the first security information to indicate that the first firmware data is secure; if the comparison of the first standard result and the first calculation result is inconsistent, determining the first security information to indicate that the first firmware data is insecure.

[0174] As an optional implementation, the acquisition of second firmware data from the reference storage unit by the target program via the first bus can be achieved in the following ways, but not limited to: the target program sending a first read request carrying first security information to the reference storage unit via the first bus, wherein the first read request is used to request the reading of second firmware data; the reference storage unit responding to the first read request sending the second firmware data to the target program via the first bus, wherein the reference storage unit is configured to only allow responding to read requests carrying first security information for requesting the reading of second firmware data; and the target program receiving the second firmware data.

[0175] Optionally, in this embodiment, the second firmware data may, but is not limited to, also be stored in the reference storage unit.

[0176] Optionally, in this embodiment, when the target program needs to read the second firmware data, the target program may actively send a first read request carrying the first security information to the reference storage unit. The reference storage unit may, but is not limited to, directly respond to the first read request carrying the first security information and return the second firmware data to the target program. This reduces the number of interactions between the target program and the reference storage unit and improves the startup speed of the control device.

[0177] As an optional implementation, the target program may obtain target key information from the reference storage unit via the first bus in the following ways, but not limited to: the target program sending a second read request to the reference storage unit via the first bus, wherein the second read request is used to request the reading of second firmware data; the reference storage unit responding to the second read request sending feedback information to the target program via the first bus, wherein the feedback information is used to instruct the reference storage unit to provide feedback on the security of the first firmware data; and the target program responding to the feedback information obtaining target key information from the reference storage unit via the first bus.

[0178] Optionally, in this embodiment, the process of the target program obtaining the second firmware data from the reference storage unit via the first bus may include, but is not limited to: the target program sending a third read request carrying first security information to the reference storage unit via the first bus, wherein the third read request is used to request the reading of the second firmware data; the reference storage unit responding to the third read request by sending the second firmware data to the target program via the first bus, wherein the reference storage unit is configured to only allow responding to read requests carrying security information indicating the security of the first firmware data for requesting the reading of the second firmware data; and the target program receiving the second firmware data.

[0179] Optionally, in this embodiment, the reference storage unit may, but is not limited to, require verification of the security of the first firmware data when the target program interacts with the reference storage unit for the first time. Only when the target program is started with verified secure firmware data will the reference storage unit provide data (including second firmware data, etc.), which ensures the security of data related to security functions.

[0180] Optionally, in this embodiment, after the security of the first firmware data is verified in the first interaction, the security of the first firmware data may not be verified again in subsequent interactions, or the security of the first firmware data may be verified in every interaction.

[0181] Optionally, in this embodiment, the target program may, but is not limited to, actively send a read request carrying the first security information to the reference storage unit during subsequent interactions with the reference storage unit after receiving feedback information from the reference storage unit, thereby avoiding repeated interaction processes for obtaining the first security information and reducing resource waste.

[0182] As an optional implementation, before the target program obtains the second firmware data from the reference storage unit via the first bus, the second firmware data can be written to the target volatile memory in the following ways, but not limited to: the target program obtains the firmware data packet corresponding to the second firmware data identifier from the firmware data identifiers and firmware data packets with corresponding relationships stored in the third non-volatile memory via the second bus, and obtains the target decryption key corresponding to the second firmware data identifier from the firmware data identifiers and decryption keys with corresponding relationships stored in the target volatile memory via the first bus. The control device further includes: a second bus and a target storage unit, the target storage unit including: a third non-volatile memory, the reference storage unit including: the target volatile memory, and the second bus connected to both the first processing unit and the target storage unit; the target program uses the target decryption key to decrypt the firmware data packet corresponding to the second firmware data identifier to obtain the second firmware data; and the target program writes the second firmware data to the target volatile memory via the first bus.

[0183] Optionally, in this embodiment, the second firmware data may, but is not limited to, not always stored in the reference storage unit, but is written by the target program into the target volatile memory included in the reference storage unit during the startup process of the control device.

[0184] Optionally, in this embodiment, the reference storage unit may include, but is not limited to, a second non-volatile memory, and the first firmware data may be stored, but is not limited to, in the second non-volatile memory.

[0185] As an optional implementation, before the target program obtains the target decryption key corresponding to the second firmware data identifier from the corresponding firmware data identifier and decryption key stored in the target volatile memory via the first bus, the corresponding firmware data identifier and decryption key can be written into the target volatile memory in the following ways, but not limited to: the target program obtains a key packet from the third non-volatile memory via the second bus, and the target program obtains the root key of the control device from the first non-volatile memory via the first bus, wherein the reference storage unit further includes: the first non-volatile memory; the target program uses the root key to decrypt the key packet to obtain the corresponding firmware data identifier and decryption key; the target program writes the corresponding firmware data identifier and decryption key into the target volatile memory via the first bus.

[0186] Optionally, in this embodiment, the firmware data identifier and decryption key with corresponding relationship may, but are not limited to, be stored in the reference storage unit all the time, but are written by the target program into the target volatile memory included in the reference storage unit during the startup process of the control device.

[0187] As an optional implementation, the second security information of the second firmware data detected by the target program based on the target key information can be implemented in the following ways, but not limited to: the target program obtains the second standard result corresponding to the second firmware data identifier of the second firmware data from the corresponding firmware data identifiers and standard results, and obtains the target verification key corresponding to the second firmware data identifier of the second firmware data from the corresponding firmware data identifiers and verification keys, wherein the target key information includes: the corresponding firmware data identifiers and standard results, and the corresponding firmware data identifiers and verification keys; the target program detects the second target information of the second firmware data based on the second standard result, and the target program detects the second reference information of the second firmware data based on the target verification key, wherein the second target information is used to indicate the possibility that the second firmware data has been tampered with, and the second reference information is used to indicate the reliability of the source of the second firmware data; the target program detects the second security information based on the second target information and the second reference information.

[0188] Optionally, in this embodiment, cryptographic operations can be performed on the second firmware data to obtain the operation result. The operation result is compared with the second standard result. If the operation result is consistent with the second standard result, the second target information is determined to indicate that the possibility of the second firmware data being tampered with is less than or equal to the possibility threshold. If the operation result is inconsistent with the second standard result, the second target information is determined to indicate that the possibility of the second firmware data being tampered with is greater than the possibility threshold.

[0189] Optionally, in this embodiment, the accompanying digital signature can be extracted from the second firmware data, but is not limited to, and the signature can be verified using the target verification key. If the signature verification passes, the second reference information can be determined to indicate that the reliability of the source of the second firmware data is greater than or equal to a reliability threshold; if the signature verification fails, the second reference information can be determined to indicate that the reliability of the source of the second firmware data is less than a reliability threshold.

[0190] Optionally, in this embodiment, the second security information can be detected comprehensively by combining the second target information and the second reference information, which improves the accuracy of the detected second security information.

[0191] Optionally, in this embodiment, the detection of the second security information by the target program based on the second target information and the second reference information may include, but is not limited to, the following: when the second target information indicates that the probability of the second firmware data being tampered with is less than or equal to a probability threshold, and the second reference information indicates that the reliability of the source of the second firmware data is greater than or equal to a reliability threshold, the target program determines that the second security information indicates that the second firmware data is secure; when the second target information indicates that the probability of the second firmware data being tampered with is greater than a probability threshold, and / or when the second reference information indicates that the reliability of the source of the second firmware data is less than a reliability threshold, the target program determines that the second security information indicates that the second firmware data is insecure.

[0192] As an optional implementation, the operating system for the first processing unit can be started by the reference program calling the third firmware data based on the third security information in the following manner: the target program detects the third target information of the third firmware data, wherein the third target information is used to indicate the possibility that the third firmware data has been tampered with; if the possibility indicated by the third target information satisfies the target possibility condition, the reference program detects the third reference information of the third firmware data, wherein the third reference information is used to indicate the reliability of the source of the third firmware data; the reference program determines the third security information based on the third reference information; if the third security information indicates that the third firmware data is secure, the reference program uses the third firmware data to start the operating system for the first processing unit.

[0193] Optionally, in this embodiment, the target program may first detect the third target information in the third firmware data. Only if the probability indicated by the third target information meets the target probability condition will the reference program continue to detect the third reference information in the third firmware data. If the probability indicated by the third target information does not meet the target probability condition, the startup process of the control device will be stopped. This design avoids the execution of invalid third reference information detection operations and saves operational resources.

[0194] Optionally, in this embodiment, the target probability condition may include, but is not limited to, the indicated probability being less than or equal to a probability threshold.

[0195] Optionally, in this embodiment, after the target program obtains each firmware data (including the second firmware data, the third firmware data, the fourth firmware data, and the fifth firmware data), the target program can detect the target information of each firmware data. If the target information of the firmware data used to indicate the possibility that the firmware data has been tampered with does not meet the corresponding possibility conditions, the startup process of the control device can be terminated.

[0196] Optionally, in this embodiment, the reference program determining the third security information based on the third reference information may include, but is not limited to: when the third reference information indicates that the reliability of the source of the third firmware data is greater than or equal to a reliability threshold, the reference program determines that the third security information is used to indicate that the third firmware data is secure; when the third reference information indicates that the reliability of the source of the third firmware data is less than a reliability threshold, the reference program determines that the third security information is used to indicate that the third firmware data is insecure.

[0197] As an optional implementation, the third target information for detecting the third firmware data by the target program can be achieved, but is not limited to, through the following methods: the target program obtains the third firmware data from the reference storage unit via the first bus, and obtains the third standard result corresponding to the third firmware data identifier from the firmware data identifier and standard result with corresponding relationship via the first bus. The control device further includes: a reference storage unit and a first bus, the first bus being connected to both the reference storage unit and the first processing unit. The reference storage unit is configured to allow access only by the first processing unit. The reference storage unit stores the target key information and the third firmware data of the control device. The target key information includes: firmware data identifier and standard result with corresponding relationship; the third target information for detecting the third firmware data by the target program based on the third standard result.

[0198] Optionally, in this embodiment, similar to the previous one, the third firmware data and the second firmware data may, but are not limited to, always be stored in the reference storage unit, but are written into the reference storage unit by the target program during the startup process of the control device. The specific writing process steps are similar to the process steps of writing the second firmware data into the target volatile memory, and will not be described again here.

[0199] Optionally, in this embodiment, the method of detecting the third target information by combining the third standard result is similar to the aforementioned method of detecting the second target information of the second firmware data by combining the second standard result, and will not be described again here.

[0200] As an optional implementation, the third reference information for detecting the third firmware data can be implemented by the reference program in the following manner, but not limited to: the reference program obtains the reference verification key corresponding to the third firmware data identifier of the third firmware data from the firmware data identifier and verification key with a corresponding relationship through the first bus, wherein the control device further includes: the first bus and the reference storage unit, the first bus is connected to both the reference storage unit and the first processing unit, the reference storage unit is configured to allow only the first processing unit to access it, the reference storage unit stores the target key information of the control device, the target key information includes: the firmware data identifier and verification key with a corresponding relationship; the reference program detects the third reference information of the third firmware data according to the reference verification key.

[0201] Optionally, in this embodiment, the method of detecting the third reference information in conjunction with the reference verification key is similar to the aforementioned method of detecting the second reference information of the second firmware data in conjunction with the target verification key, and will not be described again here.

[0202] As an optional implementation, after the reference program starts the operating system for the first processing unit by calling the third firmware data based on the third security information, the second processing unit may be started in the following ways, but not limited to: the operating system starts the kernel program for the second processing unit by calling the fourth firmware data based on the fourth security information, wherein the fourth security information is used to indicate the security of the fourth firmware data; the operating system starts the user service program for the second processing unit by calling the fifth firmware data based on the fifth security information, wherein the fifth security information is used to indicate the security of the fifth firmware data, and both the kernel program and the user service program are used to control the operation of the server to which the second processing unit is connected.

[0203] Optionally, in this embodiment, after the first processing unit is safely started, the second processing unit may be started by the first processing unit, but is not limited to being controlled by the first processing unit.

[0204] Optionally, in this embodiment, the aforementioned alternative firmware data may include, but is not limited to, fourth firmware data, and the aforementioned candidate firmware data may include, but is not limited to, fifth firmware data.

[0205] As an optional implementation, the operating system can, but is not limited to, use the following method to enable the operating system to call the fourth firmware data based on the fourth security information to start the kernel program for the second processing unit: the target program detects the fourth target information of the fourth firmware data, wherein the fourth target information is used to indicate the possibility that the fourth firmware data has been tampered with; if the possibility indicated by the fourth target information satisfies the reference possibility condition, the operating system detects the fourth reference information of the fourth firmware data, wherein the fourth reference information is used to indicate the reliability of the source of the fourth firmware data; the operating system determines the fourth security information based on the fourth reference information; if the fourth security information indicates that the fourth firmware data is secure, the operating system uses the fourth firmware data to start the kernel program for the second processing unit.

[0206] Optionally, in this embodiment, the target program may first detect the fourth target information of the fourth firmware data. Only if the probability indicated by the fourth target information meets the reference probability condition will the operating system continue to detect the fourth reference information of the fourth firmware data. If the probability indicated by the fourth target information does not meet the reference probability condition, the startup process of the control device will be stopped. This design avoids the execution of invalid fourth reference information detection operations and saves operating resources.

[0207] Optionally, in this embodiment, the reference probability condition may include, but is not limited to, the indicated probability being less than or equal to the probability threshold.

[0208] As an optional implementation, the fourth target information for detecting the fourth firmware data by the target program can be achieved, but is not limited to, through the following methods: the target program obtains the fourth firmware data from a first storage address in the shared storage unit via a second bus, and obtains the fourth standard result corresponding to the fourth firmware data identifier from firmware data identifiers and standard results with corresponding relationships via the first bus. The control device further includes: a first bus, a second bus, a reference storage unit, and a shared storage unit. The first bus is connected to both the first processing unit and the reference storage unit, and the second bus is connected to both the first processing unit and the shared storage unit. The reference storage unit is configured to allow access only by the first processing unit. The reference storage unit stores the target key information of the control device, which includes: firmware data identifiers and standard results with corresponding relationships. The first storage address is configured to allow access only by the first processing unit when the security information of the fourth firmware data is not verified or when the security information of the fourth firmware data indicates that the fourth firmware data is insecure. The target program detects the fourth target information of the fourth firmware data based on the fourth standard result.

[0209] As an optional implementation, before the target program retrieves the fourth firmware data from the first storage address in the shared storage unit via the second bus, the fourth firmware data can be written to the shared storage unit in the following ways, but not limited to: the target program retrieves the firmware data packet corresponding to the fourth firmware data from the firmware data identifiers and firmware data packets with corresponding relationships stored in the third non-volatile memory via the second bus, and the target program retrieves the fourth decryption key corresponding to the fourth firmware data from the firmware data identifiers and decryption keys with corresponding relationships stored in the target volatile memory via the first bus, wherein the control device further includes... The system includes: a third non-volatile memory; a reference memory unit including a target volatile memory; a shared memory unit including a reference volatile memory; a second bus also connected to the third non-volatile memory; the target volatile memory is configured to allow only the first processing unit to access it; the reference volatile memory is configured to allow only the first processing unit to access it if the security information of the fourth firmware data is not verified or if the security information of the fourth firmware data is used to indicate that the fourth firmware data is insecure; the target program uses the fourth decryption key to decrypt the firmware data packet corresponding to the fourth firmware data identifier to obtain the fourth firmware data; the target program writes the fourth firmware data to the reference volatile memory via the second bus.

[0210] Optionally, in this embodiment, the fourth firmware data may, but is not limited to, always be stored in the shared storage unit, but may be written into the shared storage unit (refer to volatile memory) by the target program during the startup process of the control device.

[0211] Optionally, in this embodiment, the reference volatile memory storing the fourth firmware data may, but is not limited to, be configured to allow the first processing unit to access it if the security information of the fourth firmware data is not verified or if the security information of the fourth firmware data is used to indicate that the fourth firmware data is insecure. That is, the second processing unit can only allow the fourth firmware data to start the kernel program if the target program detects the fourth firmware data and detects that the fourth firmware data is secure. This avoids using insecure firmware data to start the kernel program and improves the security of controlling the device startup.

[0212] As an optional implementation, the fourth reference information for detecting the fourth firmware data can be implemented by the operating system in the following manner, but not limited to: the operating system obtains the alternative verification key corresponding to the fourth firmware data identifier from the firmware data identifier and verification key with a corresponding relationship, wherein the control device further includes: a reference storage unit, the reference storage unit is configured to be accessible only by the first processing unit, the reference storage unit stores the target key information of the control device, the target key information includes: a firmware data identifier and verification key with a corresponding relationship; the operating system detects the fourth reference information of the fourth firmware data according to the alternative verification key.

[0213] As an optional implementation, the operating system can use the fourth firmware data to start the kernel program for the second processing unit in the following ways, but not limited to: the operating system sets a first storage address in the shared storage unit to allow the second processing unit to access it, wherein the control device further includes: a shared storage unit and a second bus, the second bus being connected to both the first and second processing units, the shared storage unit being connected to the second bus, and the first storage address being set to allow only the first processing unit to access it if the security information of the fourth firmware data is not verified or if the security information of the fourth firmware data indicates that the fourth firmware data is insecure; the operating system sends a first authorization instruction to the second processing unit through the second bus, wherein the first authorization instruction is used to instruct the second processing unit to authorize the second processing unit to use the fourth firmware data stored in the first storage address; the second processing unit obtains the fourth firmware data from the first storage address through the second bus and uses the fourth firmware data to start the kernel program.

[0214] Optionally, in this embodiment, the first storage address in the shared storage unit can be set to allow the second processing unit to access it by modifying the IOMMU page table, but not limited to creating an address mapping from the IOVA of the second processing unit to the first storage address in the IOMMU page table.

[0215] As an optional implementation, the user service program for the second processing unit can be started by the operating system calling the fifth firmware data based on the fifth security information in the following manner: the target program detects the fifth target information of the fifth firmware data, wherein the fifth target information is used to indicate the possibility that the fifth firmware data has been tampered with; if the possibility indicated by the fifth target information satisfies the candidate possibility condition, the operating system detects the fifth reference information of the fifth firmware data, wherein the fifth reference information is used to indicate the reliability of the source of the fifth firmware data; the operating system determines the fifth security information based on the fifth reference information; if the fifth security information indicates that the fifth firmware data is secure, the operating system uses the fifth firmware data to start the user service program for the second processing unit.

[0216] Optionally, in this embodiment, similar to the previous one, the target program can first detect the fifth target information of the fifth firmware data. Only when the possibility indicated by the fifth target information meets the candidate possibility condition will the operating system continue to detect the fifth reference information of the fifth firmware data. With this design, the execution of invalid fifth reference information detection operations can be avoided, saving operating resources.

[0217] Optionally, in this embodiment, the candidate probability condition may include, but is not limited to, the indicated probability being less than or equal to the probability threshold.

[0218] As an optional implementation, the fifth target information of the fifth firmware data can be detected by the target program in the following ways, but not limited to: the target program obtains the fifth firmware data from the second storage address in the shared storage unit via the second bus, and obtains the fifth standard result corresponding to the fifth firmware data identifier from the firmware data identifier and standard result with corresponding relationship via the first bus. The control device further includes: a first bus, a second bus, a reference storage unit, and a shared storage unit. The first bus is connected to both the first processing unit and the reference storage unit, and the second bus is connected to both the shared storage unit and the first processing unit. The reference storage unit is configured to allow only the first processing unit to access it. The reference storage unit stores the target key information of the control device, which includes: a firmware data identifier and standard result with corresponding relationship. The second storage address is configured to allow only the first processing unit to access it if the security information of the fifth firmware data is not verified or if the security information of the fifth firmware data indicates that the fifth firmware data is insecure. The target program detects the fifth target information of the fifth firmware data based on the fifth standard result.

[0219] Optionally, in this embodiment, the fifth firmware data may, but is not limited to, always be stored in the shared storage unit, but may be written to the shared storage unit (second storage address) by the target program during the startup process of the control device. The specific writing process steps for writing the fifth firmware data to the shared storage unit are similar to those for writing the fourth firmware data to the shared storage unit, and will not be described again here.

[0220] As an optional implementation, the fifth reference information for detecting the fifth firmware data can be implemented by the operating system in the following way: the operating system obtains the candidate verification key corresponding to the fifth firmware data identifier from the corresponding firmware data identifier and verification key through a first bus. The control device further includes a first bus and a reference storage unit. The first bus is connected to both the first processing unit and the reference storage unit. The reference storage unit is configured to be accessible only by the first processing unit. The reference storage unit stores the target key information of the control device, which includes a corresponding firmware data identifier and verification key. The operating system detects the fifth reference information of the fifth firmware data based on the candidate verification key.

[0221] As an optional implementation, the user service program for the second processing unit can be started by the operating system using the fifth firmware data in the following manner, but not limited to: the operating system sets the second storage address in the shared storage unit to allow the second processing unit to access it. The control device further includes: a shared storage unit, a reference storage unit, and a second bus. The second bus is connected to both the second processing unit and the shared storage unit, and is also connected to the first processing unit. The reference storage unit is set to allow only the first processing unit to access it. The reference storage unit stores the target key information of the control device. The target key information includes: a firmware data identifier with a corresponding relationship and a standard result. The second storage address is set to allow only the first processing unit to access it if the security information of the fifth firmware data is not verified or if the security information of the fifth firmware data indicates that the fifth firmware data is insecure. The kernel program retrieves the fifth firmware data stored at the second memory address via the second bus; the kernel program performs a second cryptographic operation on the fifth firmware data to obtain the second operation result; the operating system retrieves the second operation result, and obtains the fifth standard result corresponding to the fifth firmware data identifier from the corresponding firmware data identifier and standard result; the operating system detects the secondary target information of the fifth firmware data based on the fifth standard result, wherein the secondary target information is used to indicate the possibility that the fifth firmware data has been tampered with; if the possibility indicated by the secondary target information meets the alternative possibility conditions, the operating system sends a second authorization instruction to the kernel program via the second bus, wherein the second authorization instruction is used to instruct the kernel program to use the fifth firmware data stored at the second memory address; the kernel program uses the fifth firmware data to start the user service program.

[0222] Optionally, in this embodiment, the second storage address in the shared storage unit can be set to allow the second processing unit to access it by modifying the IOMMU page table, but not limited to creating an address mapping from the IOVA of the second processing unit to the second storage address in the IOMMU page table.

[0223] Optionally, in this embodiment, if the second processing unit can access the second storage address (i.e., obtain the fifth firmware data), the kernel program and operating system can cooperate to re-verify whether the possibility of the fifth firmware data being tampered with meets the candidate possibility conditions. This further improves the security of user service program startup.

[0224] Optionally, in this embodiment, since the fifth standard result is stored in a reference storage unit accessible only to the first processing unit, the second operation result can be passed to the operating system after the kernel program performs the second cryptographic operation to obtain the second operation result. The operating system, which can access the reference storage unit and thus obtain the fifth standard result, can then detect the secondary target information of the fifth firmware data. This design, which separates the cryptographic operation and the comparison of the operation result, further improves the security of the user service program startup.

[0225] Optionally, in this embodiment, the alternative possibility conditions may be consistent with, but are not limited to, the aforementioned candidate possibility conditions, or they may be more stringent than the aforementioned candidate possibility conditions.

[0226] As an optional implementation method, Figure 9 This is a flowchart illustrating a BMC secure boot process according to an embodiment of this application. For example... Figure 9 As shown, the secure boot of the BMC may include, but is not limited to, four phases:

[0227] Phase 1: Security Core Initial Start-up and Self-Test: Phase 1 can be triggered when the BMC (i.e., control device) is powered on and the hardware reset signal is released. The BMC prioritizes CPU0 (the secure core). The secure core reads the initial boot program (i.e., the first firmware data) from ROM0 (the second non-volatile memory). It first initializes the encryption acceleration engine to complete the basic configuration of the hardware encryption module. The secure core then uses the initialized encryption acceleration engine to calculate the SHA-256 hash value of the initial boot program firmware data and compares it with the base hash value (the standard result) built into ROM0 to verify the integrity of the initial boot program firmware data. If the comparison matches, the secure core reads the Root Key from the Secure OTP (the first non-volatile memory) and derives a temporary key to encrypt and protect sensitive data written to the Secure RAM during subsequent runtime. Simultaneously, it initializes the Mailbox secure channel, configures PMP / IOPMP isolation rules, and completes the initialization of the secure domain environment. If the comparison does not match, the secure core immediately triggers a hardware-level lock (cutting off power to all peripherals and prohibiting external output), writes a "failed to verify the integrity of the initial boot program firmware data" fault code to the Secure OTP fault log area, and terminates the boot process.

[0228] Phase 2: Firmware Image Decryption: The security core, through the encryption acceleration engine, uses the Root Key in Secure OTP to execute the key derivation function through the hardware encryption engine, decrypting the pre-stored encryption key package (i.e., key packet) in the EMMC Flash (i.e., the third non-volatile memory), obtaining the exclusive decryption keys (KEY_Bootloader, KEY_Zephyr, KEY_BMC) for each image segment; the security core, through the Flash controller, reads the encrypted image in the following order: Bootloader (i.e., reference program) → Security Core ZephyrOS (i.e., the operating system of the first processing unit) → Service Core Zephyr Kernel (i.e., the kernel program of the second processing unit) → User Service Program, calling the On-the-fly AES Decryption Engine to perform segment-by-segment online decryption, which can, but is not limited to, using KEY_Bootloader to decrypt the Bootloader segment, and writes the decrypted data into Secure SRAM (i.e., the target volatile memory) accessible only to the security core; it uses KEY_Zephyr to decrypt the Security Core Zephyr OS segment, and writes the decrypted data into Secure SRAM. SRAM; the service core Zephyr Kernel segment is decrypted using the service core-specific key derived from KEY_Zephyr, and the decrypted data is written to the service core isolation partition (i.e., the first storage address) of the shared RAM (i.e., the shared storage unit); the user service program segment is decrypted using KEY_BMC, and the decrypted data is written to another isolation partition (i.e., the second storage address) of the shared RAM; after each segment is decrypted, the security core calculates the SHA-256 hash value of each image through the encryption acceleration engine, and compares it one by one with the corresponding segment base value built into ROM0 (i.e., the second non-volatile memory); if any segment comparison fails, the exception handling operation of stage 3 is executed.

[0229] Phase 3: Step-by-Step Signature Verification: The secure kernel verifies the Bootloader signature: It may, but is not limited to, using the Bootloader signature public key (i.e., verification key) stored in SecureOTP to verify the RSA-2048 signature of the Bootloader in Secure SRAM through the encryption acceleration engine; after successful verification, the Bootloader is loaded into the secure kernel execution memory area; The Bootloader (i.e., the reference program) verifies the secure kernel Zephyr OS signature: The Bootloader reads the secure kernel Zephyr OS image from Secure SRAM and verifies its signature using the OS signature public key (i.e., verification key) issued by the secure kernel; after successful verification, the secure kernel Zephyr OS is loaded, and simultaneously, the signature public key of the business kernel Zephyr Kernel stored in Secure SRAM is written to the shared RAM secure partition; The secure kernel Zephyr OS (i.e., the operating system of the first processing unit) verifies the business kernel ZephyrKernel (i.e., the kernel program of the second processing unit) signature: It reads the business kernel Zephyr from the shared RAM... The kernel image (i.e., the fourth firmware data) is signed using the corresponding public key. Upon successful verification, the shared RAM partition containing the image is made visible to the service core. The service core, Zephyr Kernel (i.e., the kernel program of the second processing unit), verifies the user service program signature: the security core distributes the BMC signing public key via Mailbox, the service core Zephyr Kernel reads the user service program image, calculates the hash value, and reports it to the security core; after the security core verifies that the hash value matches the baseline value, it authorizes the service core to load the user service program. In cases where the signature / hash comparison fails at any stage, the security core may perform an exception handling operation: the security core immediately cuts off the power to the service core, sends an alarm message including "failure stage + error code" via UART, and simultaneously locks the write / erase permissions of the eMMCFlash.

[0230] Phase 4: Business Core Startup Authorization: The security core sends a startup authorization command (including the security core's RSA-2048 signature and the business core's permission configuration table) to the business core via the Mailbox secure channel; the business core uses the security core's public key to verify the command signature, and upon successful verification, loads the permission configuration table to specify the peripherals / storage areas that the business core can access, linking with PMP / IOPMP rules; the business core Zephyr Kernel starts the user service program and business applications; the security core continuously monitors the business core's running status via Mailbox (e.g., periodically verifying the runtime hash value of the user service program).

[0231] As an optional implementation, the first processing unit may, but is not limited to, controlling the data transmitted between the second processing unit and the connected server by accessing the reference storage unit according to the second key parameter corresponding to the second running state in the target key information when the target running state is the second running state. The second processing unit is used to control the server, and the second running state is used to indicate that the second processing unit is running.

[0232] This embodiment provides a server control method. Figure 10 This is a flowchart of a server control method according to an embodiment of this application, such as... Figure 10 As shown, the method includes the following steps:

[0233] Step S1002: Obtain data processing information of the second processing unit. The control device includes: a first processing unit, a second processing unit, and a reference storage unit. The reference storage unit is configured to allow only the first processing unit to access it. The reference storage unit stores the target key information of the control device. The target key information includes: key parameters and target credential information. The target credential information is used to indicate the target credential parameters of the target credential authorized by the first processing unit to the second processing unit. The second processing unit is connected to the server. The data processing information is used to indicate the data processing requirements of the second processing unit. The data processing information carries the index information of the reference credential and the data to be processed. The index information is used to indicate the reference credential.

[0234] Step S1004: Verify the reference voucher according to the target voucher parameters to obtain the voucher verification result, wherein the voucher verification result is used to indicate the matching degree between the reference voucher and the target voucher;

[0235] Step S1006: Perform cryptographic operations on the data to be processed based on the credential verification result and key parameters to obtain the target data;

[0236] Step S1008: Transmit target data to the second processing unit, wherein the second processing unit is used to control the server according to the target data.

[0237] Through the above, the first processing unit of the server's control device obtains data processing information from the second processing unit. The reference storage unit in the control device is set to be accessible only to the first processing unit. The reference storage unit stores the target key information of the control device. The target key information includes key parameters and target credential parameters indicating the target credential authorized by the first processing unit to the second processing unit. The reference credential indicated by the index information carried in the data processing information is verified according to the target credential parameters to obtain a credential verification result indicating the matching degree between the reference credential and the target credential. Cryptographic operations are performed on the data to be processed based on the credential verification result and the key parameters to obtain the target data, which is then transmitted to the second processing unit. The second processing unit is connected to the server and is used to control the server according to the target data. That is, the control of the server by the second processing unit in the control device is carried out under the monitoring of the first processing unit. The first processing unit processes the data used by the second processing unit when controlling the server, in conjunction with the data stored in the reference storage unit that is accessible only to the first processing unit. This avoids the second processing unit from completely independently controlling the server. Therefore, it can solve the technical problem of low security in the control process of the control device over the server in related technologies and achieve the technical effect of improving the security of the control process of the control device over the server.

[0238] Optionally, in this embodiment, the server control method provided in this application may be applied to, but is not limited to, the first processing unit of the control device.

[0239] In the embodiment provided in step S1002, the data processing information may be used, but is not limited to, to indicate the data processing requirements of the second processing unit. The data processing requirements may include, but are not limited to, data encryption requirements and data decryption requirements, etc.

[0240] Optionally, in this embodiment, the second key parameter may include, but is not limited to, target key information.

[0241] Optionally, in this embodiment, the data processing information may include, but is not limited to, index information of the reference voucher and the data to be processed. The reference voucher may be, but is not limited to, the voucher stored by the second processing unit. The first processing unit may, but is not limited to, first verify whether the data processing request of the second processing unit is qualified to be processed by the first processing unit through the index information. If it is determined that the data processing request is qualified to be processed by the first processing unit, the data to be processed is processed according to the data processing request.

[0242] Optionally, in this embodiment, the key parameters can be used, but are not limited to, to perform cryptographic operations on the data to be processed, such as using the key parameters to decrypt the data to be processed, or using the key parameters to encrypt the data to be processed.

[0243] Optionally, in this embodiment, different target credential information and key parameters may be set for different data processing needs, and correspondingly, different reference credentials may be stored on the second processing unit; or, the same target credential information and key parameters may be set for different data processing needs, and correspondingly, a unique reference credential may be stored on the second processing unit. The former method is more secure, while the latter method can save storage resources and operational resources when performing verification operations.

[0244] Optionally, in this embodiment, the index information of the reference certificate and the data to be processed carried in the data processing information can be obtained by the first processing unit in the same way, but not limited to. For example, the index information of the reference certificate and the data to be processed can be sent to the first processing unit by the second processing unit through the second bus.

[0245] Optionally, in this embodiment, the index information of the reference credential and the data to be processed carried in the data processing information can also be obtained by the first processing unit in different ways, but not limited to. For example, the second processing unit can store the data to be processed in the shared storage address of the shared storage unit through the second bus. The shared storage address can be set to allow access by both the first and second processing units. Then, the second processing unit sends the index information of the reference credential to the first processing unit through the second bus. The first processing unit can verify the reference credential. If the reference credential is verified, the first processing unit obtains the data to be processed from the shared storage address through the second bus.

[0246] Optionally, in this embodiment, after a process of the second processing unit writes data to be processed into the shared storage address, the access permissions of the shared storage address can be modified, that is, the shared storage address can be set to allow the process in the second processing unit that writes the data to be processed into the shared storage address and the first processing unit to access it. After the first processing unit processes the data to be processed and obtains the target data, it can directly store the target data into the shared storage address. The second processing unit can directly obtain the processed target data from the storage address where the data to be processed was written.

[0247] In the embodiment provided in step S1004, the reference credential provided by the second processing unit may be verified using the standard target credential parameters stored in the first processing unit, but is not limited to, whether the credential authorized by the first processing unit to the second processing unit for requesting the first processing unit to respond to the data processing requirement.

[0248] Optionally, in this embodiment, verifying the reference voucher based on the target voucher parameters may include, but is not limited to, comparing each target voucher parameter with the reference voucher parameters of the corresponding reference voucher, and determining the voucher verification result based on the number of mutually matching target voucher parameters and corresponding reference voucher parameters and the voucher parameter threshold.

[0249] In the embodiment provided in step S1006, it is possible, but not limited to, to determine whether to process the data to be processed, i.e., whether to perform cryptographic operations on the data to be processed, based on the matching degree between the reference credential and the target credential. If it is determined that cryptographic operations need to be performed on the data to be processed, the key parameters may be used to perform cryptographic operations on the data to be processed; if it is determined that cryptographic operations cannot be performed on the data to be processed, a hardware failure may be triggered and a failure log may be saved, prohibiting the second processing unit from continuing to control the server.

[0250] In the embodiment provided in step S1008, after obtaining the target data, the target data can be transmitted to the second processing unit in various ways, but not limited to. For example, the target data can be sent from the first processing unit to the second processing unit via the second bus, or the target data can be stored in the third storage address of the shared storage unit via the second bus by the first processing unit, and the target process that initiated the data processing request can be notified to retrieve the target data from the third storage address.

[0251] As an optional implementation, the verification of the reference credential based on the target credential parameters and the resulting credential verification can be achieved, but is not limited to, by the following method: accessing the reference storage unit via a first bus to obtain the target credential parameters, wherein the control device further includes: a first bus and an encryption acceleration engine, the first bus being connected to both the first processing unit and the reference storage unit, the first bus being connected to the encryption acceleration engine, and the encryption acceleration engine being configured to be controlled only by the first processing unit; controlling the encryption acceleration engine to verify the reference credential based on the target credential parameters and obtaining the credential verification result.

[0252] Optionally, in this embodiment, the target credential parameters can be used to verify the reference credential using the encryption acceleration engine, but not limited to this. Since both the encryption acceleration engine and the reference storage unit storing the target credential parameters are connected to the first bus but not to the second bus, and the encryption acceleration engine is set to be controlled only by the first processing unit and the reference storage unit is set to be accessed only by the first processing unit, the verification process of the reference credential can be completely controlled within a secure range, avoiding the verification process from being affected and causing incorrect verification, which in turn leads to an insecure control of the server by the control device.

[0253] As an optional implementation, the target credential parameters can be obtained by accessing the reference storage unit via the first bus in the following manner, but not limited to: obtaining the target credential key of the control device from the reference storage unit via the first bus, wherein the target credential parameters include the target credential key.

[0254] Optionally, in this embodiment, controlling the encryption acceleration engine to verify the reference credential based on the target credential parameters to obtain the credential verification result may include, but is not limited to, transmitting the target credential key and the reference credential to the encryption acceleration engine via a first bus, wherein the encryption acceleration engine is used to: use the target credential key to detect the credential verification information of the reference credential, the credential verification information being used to indicate the source of the reference credential; transmit the credential verification information to the first processing unit via the first bus; receive the credential verification information; and determine the credential verification result based on the credential verification information.

[0255] Optionally, in this embodiment, the target credential information may include, but is not limited to, the target credential key.

[0256] Optionally, in this embodiment, the source of the reference credential can be detected using the target credential key, but is not limited to. For example, the credential signature of the reference credential can be verified using the target credential key, and if the signature verification passes, it is determined that the reference credential originates from the first processing unit.

[0257] Optionally, in this embodiment, when the source of the reference voucher is received as the first processing unit, the voucher verification result may be determined to indicate that the matching degree between the reference voucher and the target voucher is greater than or equal to the voucher matching degree threshold; when the source of the reference voucher is received as the first processing unit, the voucher verification result may be determined to indicate that the matching degree between the reference voucher and the target voucher is less than the voucher matching degree threshold.

[0258] As an optional implementation, the target data can be obtained by performing cryptographic operations on the data to be processed based on the credential verification result and key parameters in the following manner: when the matching degree between the reference credential indicated by the credential verification result and the target credential is greater than or equal to the credential matching degree threshold, the reference storage unit is accessed through the first bus to obtain the key parameters. The control device further includes: a first bus and an encryption acceleration engine. The first bus is connected to both the first processing unit and the reference storage unit, and the encryption acceleration engine is set to be controlled only by the first processing unit. The encryption acceleration engine is controlled to perform cryptographic operations on the data to be processed based on the key parameters to obtain the target data.

[0259] Optionally, in this embodiment, the key parameters may be accessed only when the matching degree between the reference credential indicated by the credential verification result and the target credential is greater than or equal to the credential matching degree threshold, in order to avoid unnecessary key parameter acquisition operations and reduce the risk of key parameter leakage.

[0260] As an optional implementation, the key parameters can be obtained by accessing the reference storage unit via the first bus in the following manner, but not limited to: sending a key read request to the reference storage unit via the first bus, wherein the key read request is used to request the read of key parameters, and the reference storage unit is used to: respond to the key read request, obtain the target terminal session key corresponding to the data processing identifier from the corresponding processing identifier and terminal session key, and send the target terminal session key to the first processing unit via the first bus, wherein the key parameters include the target terminal session key, the data processing identifier is used to identify the communication connection between the target terminal and the second processing unit, and the target terminal is used to control the server through the second processing unit; and receive the target terminal session key returned by the reference storage unit in response to the key read request.

[0261] Optionally, in this embodiment, the first processing unit may request the reference storage unit to obtain the target terminal session key corresponding to the data processing identifier of the data processing information, in order to prevent the first processing unit from obtaining all the corresponding processing identifiers and terminal session keys stored in the reference storage unit, thereby improving data security.

[0262] Optionally, in this embodiment, the target terminal session key may be, but is not limited to, a key agreed upon in advance by the first processing unit and the target terminal. The first processing unit may, but is not limited to, use the target terminal session key to decrypt the encrypted data provided by the target terminal through the second processing unit and to encrypt the data before providing it to the target terminal. The target terminal may, but is not limited to, use the target terminal session key to decrypt the encrypted data provided by the second processing unit after being encrypted by the first processing unit and to encrypt the data before providing it to the first processing unit.

[0263] Optionally, in this embodiment, the target terminal may, but is not limited to, control the server through the second processing unit. For example, the target terminal may, but is not limited to, send an encrypted temperature acquisition request from the server to the second processing unit. The second processing unit may, but is not limited to, provide the encrypted temperature acquisition request to the first processing unit for decryption processing to obtain the temperature acquisition request. The second processing unit may, but is not limited to, respond to the temperature acquisition request by detecting the temperature of the server through a sensor to obtain temperature data and provide the temperature data to the first processing unit. The first processing unit encrypts the temperature data, and the second processing unit transmits the encrypted temperature data to the target terminal.

[0264] As an optional implementation, the encryption acceleration engine can be controlled to perform cryptographic operations on the data to be processed based on the key parameters to obtain the target data in the following ways: controlling the encryption acceleration engine to perform cryptographic operations of the target operation type on the data to be processed using the target terminal session key to obtain the target data.

[0265] Optionally, in this embodiment, the target operation type may include, but is not limited to, encryption and decryption operations.

[0266] As an optional implementation, the encryption acceleration engine can be controlled to perform cryptographic operations on the data to be processed based on key parameters to obtain target data in the following manner: The target terminal session key corresponding to the data processing identifier is obtained from the corresponding processing identifier and terminal session key, wherein the data processing identifier is used to identify the communication connection between the target terminal and the second processing unit, the target terminal is used to control the server through the second processing unit, and the key parameters include the corresponding processing identifier and terminal session key; the encryption acceleration engine is controlled to perform cryptographic operations of the target operation type on the data to be processed using the target terminal session key to obtain the target data.

[0267] Optionally, in this embodiment, in addition to obtaining the target terminal session key corresponding to the data processing identifier of the data processing information only from the reference storage unit, the first processing unit may also obtain the corresponding processing identifier and terminal session key from the reference storage unit. If it is necessary to find the terminal session key corresponding to other data processing requirements in the future, it can be completed directly in the internal memory through fast search without accessing the reference storage unit again.

[0268] As an optional implementation, the control of the encryption acceleration engine to perform cryptographic operations of the target operation type on the data to be processed using the target terminal session key can be achieved through, but is not limited to, the following methods: detecting the target information type of the index information, wherein the information type of the index information includes an identifier type and a credential type; when the target information type is a credential type, sending a reference control instruction to the encryption acceleration engine through a first bus, wherein the reference control instruction is used to instruct the decryption of the data to be processed using the target terminal session key; receiving the target data returned by the encryption acceleration engine; when the target information type is an identifier type, sending a candidate control instruction to the encryption acceleration engine through the first bus, wherein the candidate control instruction is used to instruct the encryption of the data to be processed using the target terminal session key; and receiving the target data returned by the encryption acceleration engine.

[0269] Optionally, in this embodiment, the verification operation of the credential may not be performed every time the second processing unit generates a data processing request. It may be performed only when the data processing request is to process data received by the second processing unit and awaiting the response of the second processing unit to control the server. In this case, the reference credential of the second processing unit is verified. If the reference credential is verified successfully, a verification pass identifier is issued to the second processing unit. The verification pass identifier is the index information of the identifier type. After the second processing unit responds to the received control request and obtains the control request response result, the verification pass identifier can be carried in the data processing information. When the first processing unit obtains the verification pass identifier in the data processing information, it may, but is not limited to, not repeat the verification of the reference credential of the second processing unit to save operating resources and perform encryption operations on the data to be processed (i.e., the control request response result).

[0270] Optionally, in this embodiment, the reference credential may be, but is not limited to, index information of the credential type.

[0271] Optionally, in this embodiment, the decryption or encryption operation is dynamically selected by detecting the type of index information (credential type or identifier type), realizing adaptive processing logic based on business scenarios. This eliminates the need for pre-coding the calculation direction, improving the flexibility and applicability of the control method. In particular, by introducing an identifier type as a marker for successful verification, the first processing unit can skip duplicate credential verification in the subsequent response stage and directly perform the encryption operation, thereby significantly reducing operational overhead and improving response speed.

[0272] As an optional implementation, the control of the encryption acceleration engine to perform cryptographic operations of the target operation type on the data to be processed using the target terminal session key can also be achieved through the following methods, but not limited to: extracting operation type information from the data processing information, wherein the data processing information also carries operation type information, which is used to indicate the target operation type; generating a target control instruction carrying the operation type information, the target terminal session key, and the data to be processed, wherein the target control instruction is used to instruct the use of the target terminal session key to perform cryptographic operations of the target operation type on the data to be processed; sending the target control instruction to the encryption acceleration engine through the first bus; and receiving the target data returned by the encryption acceleration engine.

[0273] Optionally, in this embodiment, the data processing information may also include, but is not limited to, operation type information indicating the target operation type. The operation type information may be extracted from the data processing information, and the target control command carrying the operation type information, the target terminal session key, and the data to be processed may be sent to the encryption acceleration engine. The encryption acceleration engine may, but is not limited to, perform cryptographic operations on the data to be processed according to the target terminal session key, indicating the target operation type, to obtain the target data.

[0274] Optionally, in this embodiment, by allowing the direct inclusion of operation type information in the data processing information, the first processing unit can dynamically generate target control instructions including operation instructions, keys, and data. This achieves flexible configuration and decoupling of cryptographic operation types, enhancing support for different encryption / decryption algorithm extensions. This mechanism also avoids the need to modify the hardware instruction set or firmware code due to changes in operation types, improving the versatility of the encryption / decryption engine.

[0275] As an optional implementation, the target data can be transmitted to the second processing unit in the following manner, but not limited to: storing the target data in a third storage address in the shared storage unit via a second bus, wherein the control device further includes: a second bus and a shared storage unit, the second bus being connected to both the first processing unit and the shared storage unit, the second bus also being connected to the second processing unit, the third storage address being configured to allow access only by the target processes of the first and second processing units, the target process being the process that initiated the data processing request; controlling the target process to retrieve the target data from the third storage address via the second bus.

[0276] Optionally, in this embodiment, the processed target data may be stored in a third storage address in the second processing unit that is only accessible to the target process, in order to prevent the target data from being exposed to other processes and improve the security of the target data.

[0277] As an optional implementation, the control of the target process to retrieve target data from the third storage address via the second bus can be achieved by, but is not limited to, sending a process instruction to the target process of the second processing unit via the second bus, wherein the process instruction is used to instruct the target process to use the target data stored in the third storage address, and the target process is used to retrieve the target data from the third storage address in response to the process instruction.

[0278] As an optional implementation, before acquiring the data processing information of the second processing unit, a secure connection between the second processing unit and the target terminal can be achieved, but is not limited to, through the following methods: receiving external connection information from the second processing unit, wherein the external connection information is used to indicate the connection requirements between the target terminal and the second processing unit, and the target terminal is used to control the server by controlling the second processing unit; detecting the terminal security information of the target terminal, wherein the terminal security information is used to indicate the security of the target terminal; and controlling the connection between the second processing unit and the target terminal based on the terminal security information.

[0279] Optionally, in this embodiment, the terminal security information of the target terminal may be detected first, and the connection between the second processing unit and the target terminal may be controlled according to the terminal security information to avoid the connection between an insecure terminal and the second processing unit.

[0280] Optionally, in this embodiment, the external connection information may include, but is not limited to, the request frame in the terminal connection request sent by the target terminal to the second processing unit.

[0281] As an optional implementation, the detection of terminal security information of the target terminal can be achieved, but is not limited to, through the following methods: accessing the reference storage unit via a first bus to obtain the device key and root certificate of the control device, wherein the target key information further includes: the device key and the root certificate, and the control device further includes: the first bus, which is connected to both the first processing unit and the reference storage unit; generating a controller certificate for the control device based on the device key; transmitting the controller certificate to the target terminal via the second processing unit based on the terminal address information of the target terminal carried in the external connection information, wherein the target terminal is further used to: verify the controller certificate, and if the controller certificate verification is successful, send the target terminal's terminal certificate to the second processing unit; receive the terminal certificate forwarded by the second processing unit; and verify the terminal certificate based on the root certificate to obtain terminal security information.

[0282] Optionally, in this embodiment, the device key may be, but is not limited to, a pre-programmed and tamper-proof hardware root of trust used to identify the unique identity of the control device.

[0283] Optionally, in this embodiment, generating a controller certificate for the control device based on the device key may include, but is not limited to, the following: a first processing unit constructs certificate request data, which may include, but is not limited to, at least the unique ID (Identifier) ​​of the control device and the certificate validity period. Then, the first processing unit may, but is not limited to, invoke a hardware encryption acceleration engine to perform a digital signature operation on the constructed certificate request data using the aforementioned device key. After signing, the original certificate request data is combined with the generated digital signature to form a complete controller certificate. This controller certificate is publicly available, and the digital signature proves the integrity and authenticity of the certificate content. When a remote terminal receives this certificate, it can use a pre-set root certificate to verify the signature, thereby confirming the legitimacy of the control device and achieving server-side identity trust in two-way authentication.

[0284] Optionally, in this embodiment, transmitting the controller certificate to the target terminal through the second processing unit based on the terminal address information of the target terminal carried in the external connection information may include, but is not limited to: extracting the terminal address information; sending the terminal address information and the controller certificate to the second processing unit, wherein the second processing unit is used to send the controller certificate to the target terminal based on the terminal address information.

[0285] As an optional implementation, terminal security information can be obtained by verifying the terminal certificate based on the root certificate in the following ways, but not limited to: sending alternative control instructions to the encryption acceleration engine via a first bus, wherein the control device further includes: the encryption acceleration engine, which is configured to be controlled only by the first processing unit, and the first bus is also connected to the encryption acceleration engine; the alternative control instructions are used to instruct the use of the root certificate to verify the terminal certificate; receiving the certificate verification result returned by the encryption acceleration engine, wherein the certificate verification result is used to indicate the security of the terminal certificate; when the certificate verification result indicates that the terminal certificate is secure, obtaining the terminal address information corresponding to the data processing identifier of the external connection information from the corresponding processing identifier and address information, wherein the data processing identifier is used to identify the communication connection between the target terminal and the second processing unit; detecting the address matching degree between the terminal address information and the certificate address information carried in the terminal certificate; and determining that the terminal security information is used to indicate the security of the target terminal when the address matching degree is greater than or equal to the address matching degree threshold.

[0286] Optionally, in this embodiment, the terminal certificate can be verified by the encryption acceleration engine to confirm the legitimacy of the terminal device and realize the trustworthiness of the demand side identity in two-way identity authentication.

[0287] Optionally, in this embodiment, after determining the legitimacy of the target terminal's terminal certificate, it is possible, but not limited to, verifying whether the terminal certificate is the terminal certificate of the target terminal that initiated the connection request, to avoid insecure connections caused by impersonation of terminal certificates.

[0288] Optionally, in this embodiment, the corresponding processing identifier and address information may be stored, but is not limited to, in a storage unit that the first processing unit can read and write. In order to improve the security of the corresponding processing identifier and address information, it may be stored, but is not limited to, in a reference storage unit to avoid access to the data by other processing units with relatively lower security.

[0289] As an optional implementation, the connection between the second processing unit and the target terminal can be controlled according to the terminal security information in the following ways, but not limited to: when the terminal security information is used to indicate the security of the target terminal, the second processing unit is controlled to establish a target connection with the target terminal and generate a target terminal session key for the target connection; a target credential is generated according to the target terminal session key, and the target credential information is obtained; the target credential is sent to the second processing unit through the second bus, and the target credential information and the target terminal session key are stored in the reference storage unit through the first bus, wherein the control device further includes: a first bus and a second bus, the first bus being connected to both the first processing unit and the reference storage unit, and the second bus being connected to both the first processing unit and the second processing unit.

[0290] Optionally, in this embodiment, when the terminal security information is used to indicate that the target terminal is insecure, the second processing unit may be prohibited from establishing a target connection with the target terminal and the insecurity of the target terminal may be reported.

[0291] Optionally, in this embodiment, generating a target terminal session key for the target connection may include, but is not limited to, pre-storing terminal session keys corresponding to each terminal in the first processing unit, and after establishing the target connection, searching for the target terminal session key corresponding to the terminal identifier of the target terminal from the terminal identifiers and terminal session keys with corresponding relationships.

[0292] Optionally, in this embodiment, the target terminal session key may be generated in real time, but is not limited to that generated in real time. In this case, the target terminal session key may be generated through negotiation between the first processing unit and the target terminal. The first processing unit may, but is not limited to, conduct SSL / TLS handshake negotiation with the target terminal through the second processing unit, wherein the second processing unit is only responsible for transmitting the handshake message without parsing the protocol content. During the handshake process, after verifying the controller certificate issued by the first processing unit, the target terminal uses the public key in the certificate to encrypt the pre-master key or negotiates a shared key through the ECDHE (Elliptic Curve Diffie-Hellman Ephemerals) algorithm and securely transmits it to the first processing unit. Subsequently, the first processing unit and the target terminal independently calculate the same target terminal session key using a pseudo-random function based on the random number exchanged during the handshake and their respective secret information, thereby ensuring that the key is never transmitted in plaintext form in the network and guaranteeing the security of the target terminal session key.

[0293] Optionally, in this embodiment, generating the target credential based on the target terminal session key may include, but is not limited to, deriving the target credential using the target terminal session key. It may also include, but is not limited to, extracting attribute parameters of the target credential to obtain target credential information, or obtaining data that uniquely corresponds to the target credential but does not correspond to other credentials to obtain target credential information.

[0294] Optionally, in this embodiment, the target credential information and the target terminal session key may be stored in the reference storage unit at the same time as the target credential is sent to the second processing unit, in preparation for subsequent verification of the credential provided by the second processing unit.

[0295] As an optional implementation, after the target credential is sent to the second processing unit via the second bus and the target credential information is stored in the reference storage unit via the first bus, the target credential can be disabled in the following ways, but not limited to: detecting the connection information of the target connection, wherein the connection information is used to indicate the connection status of the target connection; when the connection information indicates that the target connection has been interrupted, deleting the target terminal session key and the master control key corresponding to the target terminal session key from the reference storage unit via the first bus; and controlling the second processing unit to disable the target credential.

[0296] Optionally, in this embodiment, the master control key can be used, but is not limited to, to indicate the availability status of the target terminal session key. The target terminal session key is only available when the master control key is still stored in the reference storage unit. Even if the target terminal session key can be obtained from the reference storage unit, it remains unavailable if the master control key is not present in the reference storage unit. By introducing the master control key as an enable switch for the target terminal session key, a dependency-based secondary access control mechanism is constructed. This ensures that the session key is logically invalidated only when the first processing unit actively destroys the master control key, thereby preventing inconsistencies in security status or key residue risks caused by asynchronous key cleanup between the second processing unit's credential invalidation and the first processing unit's key cleanup.

[0297] Optionally, in this embodiment, after storing the target credential information in the reference storage unit, it is possible, but not limited to, monitoring whether the target connection is continuously connected. If the connection is interrupted, the target terminal session key and the master control key corresponding to the target terminal session key are deleted from the reference storage unit to prevent the target terminal session key from being impersonated by other connections.

[0298] Optionally, in this embodiment, by monitoring the connection status in real time and simultaneously cleaning up the session key, master key, and credentials, automatic recycling of session resources and closed-loop management of security status are achieved, effectively preventing security risks caused by key retention due to abnormal connection interruptions. At the same time, forcibly disabling the target credentials ensures that the session key cannot be reused after a disconnection, completely blocking potential replay attacks or illegal reconnection risks.

[0299] As an optional implementation, the control of the second processing unit to disable the target credential can be achieved by, but is not limited to, sending an invalidation command carrying deletion information to the second processing unit via a second bus, wherein the deletion information is used to indicate that the master control key has been deleted from the reference storage unit, and the invalidation command is used to instruct the second processing unit to delete the target credential. The second processing unit is used to: receive the invalidation command, detect the information carried in the invalidation command, and respond to the invalidation command to disable the target credential if the deletion information is detected.

[0300] Optionally, in this embodiment, the second processing unit may, but is not limited to, respond to the invalidation instruction to deactivate the target credential upon receiving an invalidation instruction carrying deletion information indicating that the master control key has been deleted from the reference storage unit. This avoids the second processing unit from mistakenly deleting credentials that should not be deleted, and ensures the mandatory and consistent nature of key lifecycle management.

[0301] As an optional implementation method, Figure 11 This is a schematic diagram illustrating a process by which a security core provides security services to a business core according to an embodiment of this application. Figure 11 As shown, when the business core requests security services from the security core (such as obtaining a trusted state or requesting a signature), the security core (CPU0) divides the Mailbox into three independent hardware channels (corresponding to different security services, such as "trusted state query," "signature request," and "key request"). Each channel is bound to a unique SourceID (SOID), and a unique mapping relationship between the channel, SOID, and security service is configured through the PMP register, prohibiting cross-channel access. The business core (CPU1) encapsulates the request data according to the agreed protocol. The encapsulated request data includes the request type (such as a signature), business parameters, business core identifier (CPU1 device ID), timestamp, etc. It calls the hardware encryption engine to generate a hash value for the request data, and then uses the business core's temporary key (a key issued by the security core through the Mailbox during startup, derived from the Secure OTP RootKey, and updated periodically) to encrypt the request data + hash value using AES-256, and sends it to the security core through the Mailbox channel corresponding to the SOID. The security core performs multi-factor authentication on received security service requests: 1) Channel legitimacy verification: The security core verifies whether the SOID of the Mailbox channel matches the request type; if they do not match, the request is discarded. 2) Identity verification: The security core reads the business core identifier and compares it with the list of authorized business cores pre-stored in Secure OTP. Simultaneously, it calls OTBN to verify the hash value of the business core identifier. 3) Data integrity verification: The security core decrypts the request data using the business core's temporary key, recalculates the hash value, and compares it with the encapsulated hash value. If they do not match, a data tampering log is recorded in Secure SRAM. After all multi-factor authentications pass, the security core executes the corresponding security service; it calls the encryption acceleration engine, and based on Secure OTP's Root Key + current channel ID + timestamp, derives a session dynamic key in real time. The security core uses the business core's exclusive key (derived from the Root Key during startup) to encrypt the session dynamic key using AES-256, packages the encrypted session dynamic key + encrypted response data + response signature, and returns it through the original Mailbox channel. Simultaneously, it writes the communication log to the hardware audit partition of Secure SRAM. The log is readable only by the security core and cannot be tampered with. After receiving the response, the business core calls the hardware encryption engine to decrypt the data using the business core's exclusive key and the session dynamic key; it then verifies the integrity of the response signature through the encryption acceleration engine. If the signature is correct, the business control logic is executed. If the verification fails, a hardware interrupt is triggered, suspending the security service request.

[0302] As an optional implementation, the interaction between the BMC and the remote maintenance terminal (i.e., the target terminal) may include, but is not limited to, the following steps: Step a, Terminal connection request forwarding: The remote maintenance terminal initiates a connection request (i.e., external connection information). The service core receives the request frame (only extracting the terminal IP (Internet Protocol) and the request type of the connection request, without parsing application layer data), and forwards the request frame to the security core through the Mailbox's external communication dedicated channel (independent of the inter-core service channel). Step b, SSL / TLS initialization and two-way authentication: 1) The security core calls the encryption acceleration engine to initialize the SSL / TLS environment, reads the EK key in Secure OTP, and generates a device certificate (i.e., controller certificate) (containing the BMC device's unique ID, certificate validity period, and signed with the SM2 national cryptographic algorithm); 2) The security core sends the device certificate to the service core through the Mailbox, and the service core forwards it to the maintenance terminal; 3) The terminal returns the terminal certificate to the BMC, and the service core forwards it to the security core; The security core calls the encryption acceleration engine to verify the terminal certificate chain in conjunction with the root certificate. If the verification passes, two-way authentication is completed; if it fails, the connection is rejected. Step c, Session Key Generation and Business Core Permission Allocation: 1) The security core and the operations and maintenance terminal negotiate to generate a session key (SK), and derive two components based on the SK: Security Core Master Control Key (SK_M): Reserved for key lifecycle management (such as updates and destruction), stored in Secure SRAM; Business Core Decryption Token (SK_T) (i.e., target credential): Includes business core ID, token validity period, and permission mask, without plaintext SK; 2) The security core encrypts the SK_T using the business core's exclusive key and sends it to the business core via Mailbox; 3) The security core writes the binding relationship of SK-terminal IP-session ID (i.e., the corresponding processing identifier and terminal session key) into the key partition of Secure SRAM, accessible only to the hardware encryption engine. The hardware encryption engine has a built-in permission verification module that only accepts the SK_T signed by the security core and denies the business core direct access to the key storage area. Step d, the business core receives terminal data and performs hardware decryption: 1) The maintenance terminal encrypts business data (such as sensor monitoring instructions and upgrade package requests) using SK and sends it to the BMC; the business core receives the encrypted data, does not parse the plaintext, and transmits it to the security core. The security core calls the hardware encryption engine and passes in SK_T + encrypted data; 2) The hardware encryption engine verifies the validity of SK_T. After it passes, the security core reads SK from the Secure SRAM and provides it to the encryption acceleration engine to decrypt the encrypted data. The plaintext obtained after decryption is temporarily stored in the business core's secure buffer (i.e., the third storage address of the shared storage unit); 3) The business core reads the plaintext data from the secure buffer and performs regular business processing.Step e, Business Core Data Return and Encryption: 1) The business core writes the processed response data into the business core's secure buffer and initiates a security service request to the security core. The security core calls the hardware encryption engine and passes in SK_T + response data; 2) The hardware encryption engine verifies SK_T. After successful verification, the security core provides SK to the encryption engine. The encryption engine uses SK to encrypt the response data, generates an encrypted data stream, and stores it in the business core's secure buffer to return to the business core; 3) The business core forwards the encrypted data stream to the operation and maintenance terminal without ever touching the plaintext SK or the plaintext data.

[0303] Optionally, this embodiment also involves the maintenance and destruction of session keys: During the session, the security core may, but is not limited to, issue an SK_T update token (derived from SK, the old token immediately becomes invalid) to the service core through Mailbox at regular intervals to prevent security risks caused by token leakage; when the terminal actively disconnects or the session times out, the security core destroys SK and SK_M, the hardware encryption engine disables the SK_T, and sends an SK_T invalidation instruction to the service core, so that the service core no longer decrypts data using the token.

[0304] As an optional implementation, this application also provides a method for upgrading a security kernel. As the root of trust for the entire system, the security kernel's upgrade must meet the principles of "least privilege, dual authentication, seamless rollback, and no business interruption." The upgrade process is executed independently throughout, without relying on the business kernel, and the upgrade package is only allowed to be transmitted through an offline secure channel to avoid the risk of remote attacks.

[0305] Optionally, in this embodiment, the security kernel firmware security upgrade process may include, but is not limited to, the following:

[0306] Upgrade prerequisites: The security core can, but is not limited to, supporting offline UART serial port-triggered upgrades. Operation and maintenance personnel can, but are not limited to, initiate the process through a preset security core upgrade-specific trigger signal. The operation and maintenance terminal sending the upgrade trigger signal and the upgrade data packet must carry the upgrade authorization certificate pre-stored in the security core's Secure OTP. The security core verifies the certificate chain, and only authorized terminals can initiate the upgrade. Before the security core starts the upgrade, it first verifies its own running status (i.e., verifies the integrity of the core security service and the availability of the encryption engine) and the status of the service core (if the service core is normal, its running status is temporarily stored in shared RAM; if the service core has failed, it directly enters the upgrade process).

[0307] The upgrade process includes: the maintenance terminal sends an encrypted full upgrade package for the security kernel via the UART serial port. This upgrade package is encrypted using a temporary session key derived from the unique device ID and root key in Secure OTP. Upon receiving the package, the security kernel first decrypts the session key using its own securely stored key material, and then decrypts the upgrade package. Subsequently, it performs dual verification: legitimacy verification: using the public key of the upgrade package distribution root certificate pre-installed in ROM0 or Secure OTP to verify the signature file and confirm its legitimacy; integrity verification: calling the encryption acceleration engine to calculate the image hash value and comparing it with the base value built into the upgrade package; if verification fails, a failure code is immediately sent back to the maintenance terminal, the upgrade is terminated, and the current security kernel operating state is maintained. After successful verification, the security core encrypts and backs up the currently running old version of the security core firmware to the security core backup partition in eMMC (this partition is accessible only to the security core and is hardware-isolated). After the backup is complete, the security core independently performs the old version image erasure operation (erasing only the security core's dedicated storage area, the eMMC security core writable partition). Following the order of TEE environment kernel → security TA → core security service configuration, the new image is written segment by segment to the security core's dedicated storage area. The hash value is verified in real time after each segment is written to ensure no data loss / tampering. After the image is written, the security core triggers its own restart, performing a full-link trusted verification startup according to the aforementioned security core initial startup process. The security core completes the upgrade and restores the core security service operation. If the business core was normal before the upgrade, it restores its running state from shared RAM. If any verification fails during the upgrade and restart process, a rollback mechanism is immediately triggered, loading the old version image from the security core backup partition. After restarting, the state before the upgrade is restored, and a rollback alarm message is sent via UART.

[0308] As an optional implementation, this application also provides various upgrade methods for service cores, which may include, but are not limited to, online partial upgrades, online full erase upgrades, and offline UART upgrades. Online partial upgrades may be applicable to updates of some user applications in the user service program, online full erase upgrades may be applicable to updates of the user service program, and offline UART upgrades may be more applicable to service core failures.

[0309] Optionally, in this embodiment, the online partial upgrade operation process may include, but is not limited to, the following steps: Step a, Upgrade package reception and forwarding: The remote operation and maintenance terminal sends an upgrade package (including the updated business application image, digital signature, and the SHA-256 base hash value built into the image) to the BMC. After receiving the package, the business core only performs a forwarding operation, without parsing the upgrade package content or touching any sensitive verification information, thus avoiding security leakage at the business core level while ensuring the originality of the upgrade package is transmitted to the security core. Step b, Security verification before writing: The security core performs layered differentiated verification operations: ① Legality verification: An asymmetric encryption verification mechanism is adopted, using the public key pre-stored by the upgrade package issuer in the security core Secure OTP to verify the digital signature attached to the upgrade package, confirming that the upgrade package origin is legitimate and has not been illegally forged; ② Integrity verification: A hash verification mechanism is adopted, calling the hardware encryption engine to calculate the actual hash value of the business application image in the upgrade package, and comparing it byte by byte with the base hash value built into the upgrade package to confirm that the upgrade package has not been tampered with or that no data is missing during transmission. Only after both verifications pass can the next step be performed. If either verification fails, the upgrade package is discarded and an illegal upgrade log is recorded in Secure SRAM. Step c, Incremental Write and Real-time Verification: After successful verification, the security core calls the Flash API (Flash Application Programming Interface) to perform an incremental write operation on the partition corresponding to the business application in the eMMC (only overwriting the updated part, reducing write time and storage usage). During the write process, the security core simultaneously performs real-time integrity verification. After each data segment is written, the encryption acceleration engine is immediately called to calculate the hash value of the data segment and compare it with the hash value of the corresponding segment in the upgrade package to promptly detect data errors and tampering issues during the write process and avoid invalid writes. Step d, Post-Write Security Verification: The security core performs targeted validity verification operations: ① Full Hash Verification: Calls the Flash API to read the complete image of the business application partition already written to the eMMC, and recalculates the hash value of the full image through the hardware encryption engine; ② Bidirectional Comparison Verification: The recalculated full hash value is bidirectionally compared with the base hash value built into the upgrade package and the actual hash value of the image calculated before writing, doubly confirming that the writing result has not been tampered with, has no missing parts, and is completely consistent with the legitimate upgrade package. After successful verification, the security core sends an upgrade completion command to the business core, and the business core restarts the corresponding business application to make the upgrade effective; if the verification fails, the security core immediately triggers the version rollback mechanism, calls the pre-stored original version image, overwrites the currently written abnormal partition, restores the system to normal operation, and records the upgrade failure log to Secure SRAM to ensure that the upgrade process is traceable and the fault is recoverable.

[0310] Optionally, in this embodiment, the online full erase upgrade process may include, but is not limited to, the following steps: Step a, the service core receives the full upgrade package and forwards it to the security core for dual verification (including upgrade package signature verification and hash value verification); after the security core completes the verification and confirms that the upgrade package is legal and valid, the security core sends a service pause command to the service core. After receiving the command, the service core pauses all running service processes and saves its current running status (including register status, service context, process running parameters, etc.) completely to the preset shared RAM area. After saving, it sends a status save ready signal back to the security core. Step b, after receiving the status save ready signal from the service core, the security core independently performs a full erase operation on the eMMC storage medium to completely remove the old version user service program data and related residual files in the storage medium, avoiding old data from interfering with the operation of the new system; after the erase operation is completed and verified to be correct, the security core decrypts the new user service program image according to the preset segmentation rules. After decryption, it writes the image segment by segment to the eMMC storage medium. During the writing process, the integrity of each segment of the image is verified in real time to ensure that the written data is not lost or erroneous. Step c: After the new system image is fully written, the security core initiates the end-to-end signature verification process, sequentially verifying the signatures of all critical components in the startup chain. The verification process strictly matches the preset trusted signature rules. If the end-to-end signature verification passes, the security core triggers a BMC restart command. After the BMC restarts, it starts the second processing unit according to the aforementioned second processing unit startup process. If the end-to-end signature verification fails, the system rollback mechanism is immediately triggered. The security core loads the original version image from the preset backup area, restoring the system to its state before the upgrade, and simultaneously notifies the business core to resume the original business operation. Step d: After a successful restart, the system first completes its own initialization, including core service startup, hardware adaptation verification, and security policy loading. After confirming that the new system is running stably and without anomalies, the security core reads the business core's running status data stored in the shared RAM area. During the reading process, the security core performs integrity verification (verification hash value) and legality verification (verification that the data has not been tampered with) on the status data. After successful verification, the security core restores the status data segment by segment to the registers and storage areas corresponding to the business core, and simultaneously sends a business recovery command to the business core. After receiving the instruction, the business core gradually restores all suspended business processes based on the restored operating status. Once the restoration is complete, it sends a business recovery ready signal back to the security core, thus completing the entire online full wipe and upgrade process.

[0311] As an optional implementation, the reference storage unit may, but is not limited to, also store at least one target firmware data. The at least one target firmware data may, but is not limited to, be used to start at least one target service program among one or more service programs. The second processing unit is used to control the connected server through one or more service programs. The first processing unit may, but is not limited to, also be used to: when the target running state is a second running state, perform fault monitoring on the second processing unit according to the fault information of the second processing unit and at least one target firmware data, wherein the second running state is used to indicate that the second processing unit is running, and the fault information is used to indicate the running failure of the second processing unit.

[0312] This embodiment provides a method for monitoring faults in control equipment. Figure 12 This is a flowchart of a fault monitoring method for a control device according to an embodiment of this application, such as... Figure 12 As shown, the method includes the following steps:

[0313] Step S1202: Detect fault information of the second processing unit of the control device, wherein the fault information is used to indicate the operational failure of the second processing unit. The control device includes: a first processing unit, a second processing unit, and a reference storage unit. The reference storage unit is configured to allow only the first processing unit to access it. The second processing unit is used to control the connected server through one or more service programs. The reference storage unit stores at least one target firmware data. The at least one target firmware data is used to start at least one target service program among one or more service programs.

[0314] Step S1204: Based on the fault information, at least one reference firmware data from at least one target firmware data in the reference storage unit is retrieved to start at least one reference service program from at least one target service program, and the operation of the second processing unit is restored based on the fault information.

[0315] Based on the above, the first processing unit of the control device detects fault information of the second processing unit of the control device. The second processing unit is used to control the connected server through one or more service programs. The control device includes a reference storage unit that is configured to be accessible only by the first processing unit. The reference storage unit stores at least one target firmware data. The at least one target firmware data is used to start at least one target service program among one or more service programs. The first processing unit calls at least one reference firmware data from the at least one target firmware data in the reference storage unit according to the fault information to start at least one reference service program among at least one target service program, and restores the operation of the second processing unit according to the fault information. That is, in the event of a failure in the operation of the second processing unit, the first processing unit attempts to restore the operation of the second processing unit by using the data stored in the reference storage unit that is accessible only by the first processing unit, and also starts the reference service program on the first processing unit to ensure that the control device's control over the server is not interrupted. Therefore, the technical problem of low monitoring and processing efficiency of control device faults in related technologies can be solved, and the technical effect of improving the monitoring and processing efficiency of control device faults can be achieved.

[0316] Optionally, in this embodiment, the fault monitoring method for the control device provided in this application may be applied to, but is not limited to, the first processing unit of the control device.

[0317] In the embodiment provided in step S1202, the fault information may be used, but is not limited to, to indicate that the operation of the second processing unit has failed, or the fault information may be used, but is not limited to, to indicate a specific fault that has occurred in the operation of the second processing unit.

[0318] Optionally, in this embodiment, the second processing unit may be used, but is not limited to, to control the connected server through one or more service programs. For example, the second processing unit may be used, but is not limited to, to collect temperature and voltage data inside the server chassis in real time by running a sensor monitoring service program, or to control the fan speed and power switch status of the server by running a power supply unit management service program.

[0319] Optionally, in this embodiment, the reference storage unit, which is only accessible to the first processing unit, may, but is not limited to, store at least one target firmware data. The at least one target firmware data may, but is not limited to, be used to start at least one target service program among one or more service programs used to implement control over the server. Since the at least one target firmware data is stored in the reference storage unit, it is less likely to be tampered with and has higher security. Therefore, it may, but is not limited to, be used to recover the system in the event of a failure in the operation of the second processing unit.

[0320] In the embodiment provided in step S1204, at least one reference firmware data in at least one target firmware data can be invoked based on the fault information to start at least one reference service program in at least one target service program, so as to temporarily take over the control business of the control device in the event of a failure of the second processing unit, thereby avoiding the interruption of the control device's control over the server.

[0321] Optionally, in this embodiment, restoring the operation of the second processing unit based on fault information may include, but is not limited to: determining the recoverability of the second processing unit through fault sub-information, where fault sub-information may, but is not limited to, indicating the proportion of successful recovery of the operational fault of the second processing unit within a historical time period prior to the current moment; recoverability may, but is not limited to, indicating the recovery probability of the second processing unit being successfully recovered; and fault information may, but is not limited to, including fault sub-information; and restarting the second processing unit when the recovery probability indicated by the recoverability meets a recovery probability condition. Here, the recovery probability condition may, but is not limited to, include a recovery probability greater than or equal to a recovery probability threshold.

[0322] As an optional implementation, the startup of at least one reference service program from at least one target firmware data in the reference storage unit based on fault information can be achieved by, but is not limited to, by: filtering reference firmware data from at least one target firmware data according to the target fault type of the operational fault that occurred in the second processing unit; and starting the reference service program using the reference firmware data.

[0323] Optionally, in this embodiment, the fault information may include, but is not limited to, the target fault type of the operational fault that occurred in the second processing unit.

[0324] Optionally, in this embodiment, the target fault type may include, but is not limited to, the complete shutdown of the second processing unit, the failure of some service programs in the second processing unit, etc.

[0325] Optionally, in this embodiment, the service program that needs to be temporarily started on the first processing unit can be determined by combining the target fault type of the specific second processing unit fault, and reference firmware data for starting these service programs can be obtained. The reference firmware data is used to start the reference service program on the first processing unit. The control business originally undertaken by the service program that failed on the second processing unit can be taken over by the reference service program that was temporarily started on the first processing unit, thus accurately avoiding the interruption of the control business of the control device to the server.

[0326] As an optional implementation, the selection of reference firmware data from at least one target firmware data based on the target fault type of the operational fault occurring in the second processing unit can be achieved in the following manner, but not limited to: sending a fourth read request to a reference storage unit via a first bus, wherein the control device further includes: a first bus connected to both the first processing unit and the reference storage unit; the fourth read request is used to request the reading of target firmware data corresponding to the target fault type; the reference storage unit is used to: respond to the fourth read request, search for reference firmware data corresponding to the target fault type from the fault types and target firmware data with corresponding relationships, and send the reference firmware data to the first processing unit via the first bus; and receive the reference firmware data sent by the first processing unit.

[0327] Optionally, in this embodiment, the corresponding fault types and target firmware data may include, but are not limited to, the following: a first fault type and a first target firmware data, a second fault type and a second target firmware data, a third fault type and a third target firmware data, etc., wherein the first fault type may refer to, but is not limited to, a complete shutdown of the second processing unit; the first target firmware data may refer to, but is not limited to, the target firmware data used to start multiple service programs started on the second processing unit; the second fault type may refer to, but is not limited to, indicating a fault in the sensor monitoring service program on the second processing unit; the second target firmware data may refer to, but is not limited to, the target firmware data used to start the sensor monitoring service program; the third fault type may refer to, but is not limited to, indicating a fault in the operating power supply unit management service program on the second processing unit; and the third target firmware data may refer to, but is not limited to, the target firmware data used to start the operating power supply unit management service program.

[0328] Optionally, in this embodiment, whether the second processing unit has fallen into a complete shutdown state can be detected by periodic heartbeat detection between the first processing unit and the second processing unit.

[0329] Optionally, in this embodiment, when acquiring reference firmware data, the first processing unit may send a fourth read request to the reference storage unit to request the reading of target firmware data corresponding to the target fault type. The reference storage unit may search for reference firmware data corresponding to the target fault type in the stored fault types and target firmware data with corresponding relationships, and return the found reference firmware data to the first processing unit. The lookup logic of the mapping relationship is pushed down to the reference storage unit, which reduces the amount of bus data transmission between the first processing unit and the reference storage unit (only specific firmware data needs to be transmitted instead of the full mapping table), thereby reducing communication overhead and improving the real-time performance of fault response.

[0330] As an optional implementation, the acquisition of reference firmware data from the reference storage unit based on the target fault type of the operational fault occurring in the second processing unit can be achieved in the following manner, but is not limited to: sending a fifth read request to the reference storage unit via a first bus, wherein the control device further includes: a first bus, the first bus being connected to both the first processing unit and the reference storage unit; the fifth read request being used to request the reading of fault types and target firmware data with corresponding relationships; the reference storage unit being used to respond to the fifth read request by sending the fault types and target firmware data with corresponding relationships to the first processing unit via the first bus; receiving the fault types and target firmware data with corresponding relationships; and searching for reference firmware data corresponding to the target fault type from the fault types and target firmware data with corresponding relationships.

[0331] Optionally, in this embodiment, the first processing unit may obtain complete fault types and target firmware data with corresponding relationships. The search logic is set in the first processing unit, which gives the first processing unit greater configuration flexibility. This makes the reference storage unit not need to have complex query logic, which facilitates unified management and batch updates of firmware versions.

[0332] As an optional implementation, the reference service program can be started using reference firmware data in the following ways, but not limited to: creating a second process independent of the first process for the reference service program, and allocating a second memory space independent of the first memory space for the reference service program, wherein the first process is used to run the security service program of the first processing unit, and the first memory space is the memory space used by the first process; loading reference firmware data into the second memory space; and controlling the second process to start the reference service program according to the reference firmware data stored in the second memory space.

[0333] Optionally, in this embodiment, a second process independent of the first process used to run the security service program of the first processing unit may be created for the reference service program, and a second memory space independent of the first memory space used by the first process may be allocated for the reference service program. That is, the security service program started on the first processing unit and the business service program temporarily started on the first processing unit are separated to avoid the business service program with lower security that needs to interact with the outside of the control device from affecting the operation of the security service program, thereby ensuring the security of the security functions provided by the control device.

[0334] Optionally, in this embodiment, the security service program may be used, but is not limited to, to implement the security functions provided by the first processing unit.

[0335] As an optional implementation, the recovery of the second processing unit based on the fault information can be achieved, but is not limited to, by the following means: detecting the target recovery information of the second processing unit according to the target fault type of the operational fault that occurred in the second processing unit, wherein the target recovery information is used to indicate the recovery method for restoring the operation of the second processing unit; and restoring the operation of the second processing unit based on the target recovery information.

[0336] Optionally, in this embodiment, different fault types may correspond to different operation recovery methods, and the target recovery information of the second processing unit may be detected according to the target fault type.

[0337] As an optional implementation, the target recovery information of the second processing unit can be detected based on the target fault type of the operational fault that occurred in the second processing unit in the following ways: if the target fault type is a stop-operation type, the target recovery information is determined to instruct the restart of the second processing unit; if the target fault type is a fault type other than the stop-operation type, the reference service program corresponding to the target fault type is obtained from the fault types and service programs with corresponding relationships; and the target recovery information is determined to instruct the resumption of the operation of the reference service program in the second processing unit.

[0338] Optionally, in this embodiment, the fault type of stopping operation may refer to, but is not limited to, the complete shutdown of the second processing unit.

[0339] Optionally, in this embodiment, when the target fault type is a fault type other than the stop-run type, the target fault type may be, but is not limited to, used to indicate that the target business service has failed, and the service program that corresponds to the target fault type may be, but is not limited to, a service program used to implement the target business service.

[0340] Optionally, in this embodiment, it is possible, but not limited to, first determining whether the second processing unit has completely crashed and stopped running. If it has completely stopped running, the recovery method is determined to be restarting the second processing unit. If it has not completely stopped running, the recovery method is determined to be restoring the corresponding service program that failed to run. Different fault recovery methods are set for different fault situations, which improves the flexibility of fault recovery.

[0341] As an optional implementation, the operation of the second processing unit can be restored according to the target recovery information in the following manner, but not limited to: when the target recovery information is used to indicate the restart of the second processing unit, a reset command is sent to the reset controller of the second processing unit, wherein the reset command is used to indicate the restart of the second processing unit, and the control device further includes: a reset controller, which is configured to respond only to the command sent by the first processing unit, and the reset controller is used to control the restart of the second processing unit in response to the reset command.

[0342] Optionally, in this embodiment, the reset controller may be, but is not limited to, a hardware module in the control device responsible for managing the reset state of the processing unit. The reset controller may, but is not limited to, receiving a reset command from the first processing unit and generating a hardware reset pulse to send to the second processing unit to control the second processing unit to restart.

[0343] Optionally, in this embodiment, hardware-level permission isolation is configured to ensure that only the first processing unit can initiate a reset, preventing the second processing unit from getting stuck in an infinite loop of restarting or failure in a deadlock or controlled state, thus ensuring the effectiveness of the reset. Simultaneously, the setting that the reset controller only responds to instructions sent by the first processing unit also blocks malicious code from interfering with the recovery process or stealing privileges through self-reset, achieving secure exclusive control over fault handling.

[0344] As an optional implementation, the restoration of the second processing unit's operation based on the target restoration information can be achieved, but is not limited to, by the following means: when the target restoration information is used to instruct the restoration of the reference service program in the second processing unit, reference firmware data for starting the reference service program is obtained from the reference storage unit via a first bus, wherein the control device further includes: a first bus and a second bus, the first bus being connected to both the first processing unit and the reference storage unit, and the second bus being connected to both the first processing unit and the second processing unit; a restoration command is sent to the second processing unit via the second bus, wherein the restoration command carries the reference firmware data, and the restoration command is used to instruct the second processing unit to restore the operation of the reference service program using the reference firmware data, and the second processing unit is used to: respond to the restoration command by using the reference firmware data to restore the operation of the reference service program on the second processing unit.

[0345] Optionally, in this embodiment, when the target recovery information is used to instruct the recovery of the reference service program in the second processing unit, the first processing unit may, but is not limited to, obtain reference firmware data from the reference storage unit and send it to the second processing unit so that the second processing unit can attempt to start the reference service program on the second processing unit using the reference firmware data, and ultimately realize the recovery of the reference service program running on the second processing unit.

[0346] Optionally, in this embodiment, in addition to sending the reference firmware data to the second processing unit through communication between processing units, the first processing unit may also store the reference firmware data in a shared storage unit at a storage address that can be accessed by the first processing unit and is accessible by the second processing unit, and the second processing unit reads the reference firmware data from this storage address.

[0347] As an optional implementation, the following methods can be used, but are not limited to, to start at least one reference service program from at least one target firmware data in the reference storage unit based on fault information, and to restore the operation of the second processing unit based on fault information: starting at least one reference service program from at least one reference firmware data in the reference storage unit based on the target fault type of the operational fault that occurred in the second processing unit, wherein the fault information includes the target fault type; and restoring the operation of the second processing unit based on the target fault type.

[0348] Optionally, in this embodiment, it is possible, but not limited to, temporarily starting the control services undertaken by the service program that took over the fault on the first processing unit before attempting to restore the operation of the second processing unit, so as to avoid a stage in which the server cannot be managed and controlled during the process of attempting to restore the operation of the second processing unit.

[0349] As an optional implementation, fault information of the second processing unit of the detection control device can be achieved, but is not limited to, by the following methods: obtaining the processing unit key of the second processing unit from a fourth storage address in the shared storage unit via a second bus, wherein the control device further includes: a shared storage unit and a second bus, the second bus being connected to both the first processing unit and the shared storage unit, the second processing unit being connected to the second bus, and the fourth storage address being set to allow access only by the first and second processing units; sending an encrypted heartbeat command to the second processing unit via the second bus, wherein the encrypted heartbeat command is a heartbeat request command encrypted using the processing unit key, and the heartbeat request command is used to instruct the second processing unit to send its processing operation information to the first processing unit, the processing operation information being... The second processing unit is used to indicate the operating status of each service on the second processing unit. The second processing unit is configured to: receive an encrypted heartbeat command; obtain a processing unit key from a fourth storage address via a second bus; decrypt the encrypted heartbeat command using the processing unit key to obtain a heartbeat request command; and generate response information based on the heartbeat request command, wherein the response information includes the target processing operating information of the second processing unit; encrypt the response information using the processing unit key to obtain encrypted response information; send the encrypted response information to the first processing unit via the second bus; receive the encrypted response information; decrypt the encrypted response information using the processing unit key to obtain the response information; and determine that fault information has been detected if no response information is obtained, or if the operating status of the target service indicated by the response information is a fault state.

[0350] Optionally, in this embodiment, the processing operation information may be used, but is not limited to, to indicate the operating status of each business service on the second processing unit, that is, to indicate whether the operation of each service program on the second processing unit has failed.

[0351] Optionally, in this embodiment, it is possible, but not limited to, to determine that a fault information of the type of stop operation has been detected when no response information is obtained; it is possible, but not limited to, to determine that fault information of other types of faults has been detected when the target service indicated by the response information is in a fault state. The specific fault type is the fault type used to indicate that the target service has failed.

[0352] As an optional implementation, after starting at least one reference service program from at least one target firmware data in the reference storage unit based on the fault information, and restoring the operation of the second processing unit based on the fault information, the control device can be updated in the following ways, but not limited to: detecting the recovery result of the second processing unit, wherein the recovery result is used to indicate the recovery status of the operation of the second processing unit; and updating the control device through the maintenance terminal connected to the management interface of the control device when the recovery result indicates that the operation of the second processing unit has not been restored.

[0353] Optionally, in this embodiment, after avoiding control interruption of the server by starting at least one reference service program on the first processing unit and attempting to restore the operation of the second processing unit based on the fault information, the recovery status of the recovery measures taken on the operation of the second processing unit can be detected. In cases where the recovery status is poor, i.e. the recovery result indicates that the operation of the second processing unit has not been restored, the control device can be updated through the operation and maintenance terminal connected to the management interface of the control device to restore the normal operation of the second processing unit from another perspective.

[0354] As an optional implementation, the update of the control device by the maintenance terminal connected through the management interface of the control device can be achieved in the following ways, but not limited to: taking over the control permissions of the management interface, wherein the control permissions of the management interface are set to be controlled only by one of the first processing unit and the second processing unit; sending alarm information to the maintenance terminal through the management interface, wherein the alarm information is used to indicate that the control device needs to be updated; receiving the update data packet of the control device returned by the maintenance terminal in response to the alarm information through the management interface; and updating the control device using the update data packet.

[0355] Optionally, in this embodiment, the aforementioned target terminal may be, but is not limited to, the same terminal as the operation and maintenance terminal, or they may be, but are not limited to, different terminals (for example, the level of the operation and maintenance terminal may be, but is not limited to, higher than that of the target terminal; the target terminal can only perform out-of-band management of the server through the control device, but the operation and maintenance terminal can realize fault management and upgrade of the control device).

[0356] Optionally, in this embodiment, when the management interface has control permissions in the second processing unit, the management interface may be used, but is not limited to, to perform routine out-of-band management tasks, such as log output.

[0357] Optionally, in this embodiment, after receiving alarm information, the operation and maintenance terminal may, but is not limited to, automatically or manually send an update data packet to the control device through the management interface.

[0358] As an optional implementation, the control permissions of the management interface can be taken over in the following way, but not limited to: by adjusting the system permission configuration table of the control device to allow only the first processing unit to control it, wherein the system permission configuration table is used to configure the control permissions of each interface of the control device.

[0359] Optionally, in this embodiment, the control permissions of the management interface can be taken over by the first processing unit by adjusting the system permission configuration table, but not limited to this method.

[0360] Optionally, in this embodiment, the system permission configuration table may be, but is not limited to, a data structure used to define and restrict the hardware resources, memory regions, and peripheral interfaces that the processing unit is allowed to access during startup or operation.

[0361] As an optional implementation, updating the control device using the update data packet can be achieved, but is not limited to, by the following means: obtaining target key information from a reference storage unit via a first bus, wherein the control device further includes: a first bus connected to both a first processing unit and a reference storage unit, the reference storage unit storing the target key information of the control device; detecting data packet security information of the update data packet based on the target key information, wherein the data packet security information is used to indicate the security of the update data packet; when the data packet security information indicates the security of the update data packet, updating the fourth firmware data using the sixth firmware data in the update data packet, and updating the fifth firmware data using the seventh firmware data in the update data packet, wherein the fourth firmware data and the fifth firmware data are used to start the second processing unit; starting the second processing unit using the sixth firmware data and the seventh firmware data.

[0362] Optionally, in this embodiment, after receiving the update data packet, the security of the update data packet can be detected using, but is not limited to, the target key information stored in the reference storage unit. If the update data packet is secure, the firmware data in the update data packet is used to update the firmware data stored in the control device for starting the second processing unit, thereby avoiding the use of insecure firmware data to start the second processing unit.

[0363] Optionally, in this embodiment, the update data packet may include, but is not limited to, the sixth firmware data used to update the fourth firmware data and the seventh firmware data used to update the fifth firmware data, as well as the eighth firmware data used to update the second firmware data and the ninth firmware data used to update the third firmware data. It may be possible to update the fourth firmware data using the sixth firmware data in the update data packet, update the fifth firmware data using the seventh firmware data in the update data packet, update the second firmware data using the eighth firmware data in the update data packet, and update the third firmware data using the ninth firmware data in the update data packet.

[0364] As an optional implementation, updating the fourth firmware data using the sixth firmware data in the update data package and updating the fifth firmware data using the seventh firmware data in the update data package can be implemented in the following ways, but not limited to: deleting the fourth firmware data from the first storage address in the shared storage unit via the second bus, writing the sixth firmware data to the first storage address via the second bus, deleting the fifth firmware data from the second storage address in the shared storage unit via the second bus, and writing the seventh firmware data to the second storage address via the second bus. The control device further includes: a shared storage unit and a second bus, the second bus being connected to both the first processing unit and the shared storage unit. The shared storage unit is configured to allow only the first processing unit to access the data if the security information of the stored firmware data is not verified or if the security information of the stored firmware data indicates that the firmware data is insecure.

[0365] Optionally, in this embodiment, after updating the fourth firmware data using the sixth firmware data and updating the fifth firmware data using the seventh firmware data, the startup process of starting the second processing unit using the sixth firmware data and the seventh firmware data can be, but is not limited to, similar to the aforementioned startup process of starting the second processing unit using the fourth firmware data and the fifth firmware data, and will not be described again here.

[0366] As an optional implementation, after detecting the recovery result of the second processing unit, the reference service program temporarily started on the first processing unit may be unloaded in the following ways, but not limited to: if the recovery result indicates that the operation of the second processing unit has been restored, the operation of the second process of the first processing unit is terminated, and the second memory space is released, wherein the second process is used to run the reference service program, and the second memory space is the memory space used by the second process.

[0367] Optionally, in this embodiment, if the operation of the second processing unit is restored, that is, if the second processing unit is able to normally operate the control services of the control device, the reference service program can be unloaded from the first processing unit to avoid the operation of the reference service program affecting the security functions provided by the first processing unit.

[0368] As an optional implementation method, Figure 13 This is a schematic diagram of a service core fault handling process according to an embodiment of this application. For example... Figure 13 As shown, the security core can, but is not limited to, send periodic heartbeat requests to the service core via Mailbox for periodic security core checks. The service core must return a response within a certain time. If no response is received for three consecutive times, or if the response data integrity verification fails, the security core determines that the service core is faulty and records the fault time and service core status to SecureSRAM.

[0369] Optionally, in this embodiment, a Mailbox communication channel may be used to establish a dedicated two-way communication link between the security core and the business core, prohibiting third-party components from accessing the system. The communication data is encrypted using a preset symmetric encryption algorithm and supplemented with a CRC-32 cyclic redundancy check code to prevent the communication data from being tampered with, stolen, or forged, and to ensure the confidentiality, integrity, and legality of monitoring commands and response data.

[0370] Optionally, in this embodiment, the security core side may, but is not limited to, a preset Secure SRAM dedicated storage area for storing monitoring configuration parameters, monitoring logs, service core fault information, and service core security baseline data. This area adopts a hardware-level permission isolation mechanism, which can only be accessed by the security core, effectively preventing data from being illegally tampered with and ensuring the authenticity and traceability of the data.

[0371] Optionally, in this embodiment, the monitoring process may, but is not limited to, adopt a combination of periodic heartbeat interaction and real-time security verification, with the security core as the monitoring subject and the business core as the monitored subject. The specific steps of fault monitoring are as follows:

[0372] Step a, Monitoring Initialization Configuration: After the system starts, the security core completes the initialization of the monitoring module and loads the preset monitoring configuration parameters and business core security baseline data, which specifically include: heartbeat parameters (heartbeat request sending cycle, business core response timeout threshold, continuous timeout judgment threshold), security baseline data (signature hash value of the business core process, preset running permission range (such as memory access address range, peripheral operation permission), default configuration value of core register, hash value of key business configuration parameters), and security verification rules (format specification of business core response data, security verification items and verification failure judgment criteria).

[0373] Step b, Periodic Heartbeat Interaction and Liveness Monitoring: The security core sends encrypted heartbeat request commands to the business core via Mailbox at fixed intervals. This command includes a command identifier, the current timestamp, and a random checksum. The random checksum is dynamically generated for each transmission to prevent heartbeat requests from being forged and to improve monitoring security. Upon receiving the heartbeat request command, the business core first decrypts and performs a CRC-32 check. After confirming the command's validity, it generates response data. The response data includes its own liveness identifier and a random checksum receipt (which perfectly matches the random checksum in the request command). After encrypting the response data and attaching the checksum, it sends it back to the security core via Mailbox. After receiving response data from the business core, the security core first completes decryption and verification of the checksum, and then determines its liveness status: If a valid response is received within a fixed waiting time threshold, the business core is determined to be currently alive, the monitoring log is updated, and the next heartbeat cycle begins; if no response data is received after the fixed threshold is exceeded, a timeout is recorded, and the number of timeouts is accumulated; if the accumulated number of timeouts reaches 3, the business core is directly determined to have failed; if response data is received, but decryption fails, the checksum does not match, or the response data format does not conform to the preset specifications, it is determined to be an invalid response, and timeouts are processed, accumulating the number of timeouts until 3 times are reached, at which point the business core is determined to have failed.

[0374] Optionally, in this embodiment, the security core may, but is not limited to, immediately perform the following operations after determining that a failure has occurred in the service core, forming a closed loop for fault handling:

[0375] Operation 1, Fault Recording: Immediately write the fault information to the Secure SRAM dedicated storage area (including the fault occurrence time, fault type), fault judgment basis, and the operating status of the business core at the time of the fault, forming an unalterable fault monitoring log for easy subsequent fault investigation and auditing;

[0376] Operation 2, Fault Isolation: The security core immediately restricts the bus access permission, memory access permission, and peripheral operation permission of the service core through hardware-level permission control, and prohibits the service core from performing critical operations (such as modifying system configuration or sending abnormal commands).

[0377] Operation 3, Fault Trigger Handling: The security core directly resets the service core. If the service core reset and recovery fails, a fault trigger handling is generated, which directly triggers the offline UART upgrade process.

[0378] As an optional implementation method, such as Figure 13 As shown, in the event of a business core failure, a core resource takeover operation can be performed, but is not limited to, to prevent the BMC from interrupting its monitoring and management of the server.

[0379] Optionally, in this embodiment, the security core may, but is not limited to, adopt a dual-mode adaptive switching logic of security standby mode + resource takeover mode, strictly following the principle of only running core security services when the business core is normal and taking over necessary business services as needed when the business core fails, thus ensuring both the simplicity and security of the security core itself, and achieving controllability of core resources in fault scenarios.

[0380] Optionally, in this embodiment, the operating mode of the security core may include, but is not limited to, a security standby mode (applicable when the service core is running normally) and a resource takeover mode (applicable when the service core fails).

[0381] Optionally, in this embodiment, after the BMC starts up, the security core completes initialization, completes a normal handshake with the service core through Mailbox, and after three consecutive rounds of heartbeat interaction, the service core is detected to be in a live + secure operation state, and the secure standby mode is automatically activated. In this mode, the security core only runs preset core security services and does not participate in any business-level resource control or service operation. Its core operation is to provide security services (i.e., security functions) for the business core, specifically including: key management service (responsible for key generation, storage, update, and encryption / decryption calls, running entirely in the Secure SRAM exclusive area, without exposing key information to the outside world, ensuring key security), signature verification and measurement audit service (responsible for signature verification and hash measurement of upgrade packages, business core response data, and core configuration parameters, ensuring data legality and integrity), business core fault monitoring service (monitoring the survival status and security operation status of the business core through a periodic heartbeat interaction mechanism, only performing monitoring and judgment, without interfering with the normal operation of the business core), and permission isolation and control (maintaining hardware-level permission isolation, prohibiting the business core from accessing the security core's exclusive resources, while not actively accessing the core components controlled by the business core itself, avoiding resource conflicts and security risks), etc.

[0382] Optionally, in this embodiment, in the safe standby mode, the safe core occupies very little system resources and monitors the operating status of the service core throughout the process. Once a visible or hidden fault is detected in the service core, the mode switching process is immediately triggered.

[0383] Optionally, in this embodiment, if the security kernel determines that the business kernel is faulty, the resource takeover mode can be activated immediately. The activation process does not affect the normal operation of the security kernel's core security services, ensuring the security of the takeover process.

[0384] Optionally, in this embodiment, the resource takeover mode may, but is not limited to, adopting the principle of prioritizing security services and taking over services with the least privilege. Optionally, when the security kernel is in resource takeover mode, it may, but is not limited to, ensuring the continuous operation of core security services and ensuring the security and traceability of the takeover process; the security kernel may, but is not limited to, only obtain the minimum operating privileges of core components, and the takeover privileges are only valid during fault handling to reduce security risks; the takeover service and the core security service adopt a resource isolation mechanism (independent memory address segments, independent process spaces) to prevent abnormalities in the takeover service (such as crashes or attacks) from affecting the operation of the core security service and improve the stability of the security kernel.

[0385] Optionally, in this embodiment, after the business core fault handling is completed (such as successful offline upgrade, successful security reset, etc.), and the security core verification confirms that the business core has recovered to the live + secure operation state, the core component operation permissions are released, the system switches back to the secure standby mode, and restores the state of only running core security services, forming a closed loop of mode switching.

[0386] Optionally, in this embodiment, the core resource takeover process may, but is not limited to, be executed only when the security core is in resource takeover mode. The core resource takeover process may, but is not limited to, be completed independently by the security core without relying on any service from the business core. The specific execution process of the core resource takeover may include, but is not limited to: writing fault information into the Secure SRAM dedicated storage area to form an immutable fault log; the security core starting the takeover service process and simultaneously obtaining operation permissions for core components such as the PSU, fan, and temperature sensor, entering the resource takeover execution phase; the security core directly taking over core components such as the PSU, fan, and temperature sensor; during security verification, reading temperature sensor data and comparing it with a preset security threshold, and promptly implementing heat dissipation control when the threshold is exceeded. While performing anomaly handling, the security core generates standardized fault alarm information, specifically including: fault type, fault judgment basis, fault occurrence time, current operating status of each core component, executed handling operations, fault log summary, etc.

[0387] Optionally, in this embodiment, when the fault handling of the service core is completed (such as successful offline upgrade or successful security reset), the service core may, but is not limited to, send a recovery ready signal to the security core; the security core performs a comprehensive verification of the service core, and after the verification is passed, it confirms that the service core can operate normally; the security core immediately releases the operation permissions of core components such as PSU, fan, and temperature sensor, and returns the control of the core components to the service core; after the takeover by the security core terminates, the security core automatically switches from the resource takeover mode back to the security standby mode, stops all takeover-related operations, retains only the core security service and the service core fault monitoring function, updates the monitoring log and the takeover log, and completes the entire core resource takeover closed loop.

[0388] As an optional implementation method, Figure 14 This is a schematic diagram illustrating various upgrade methods for the service core according to embodiments of this application. For example... Figure 14 As shown, the upgrade of the service core may include, but is not limited to, offline upgrades via the UART management interface. In the event of a service core failure, an attempt may be made to restore the normal operation of the service core through an offline upgrade.

[0389] Optionally, in this embodiment, the operation and maintenance personnel may send an offline upgrade trigger signal to the BMC via the UART serial port, but not limited to this. The trigger signal is a preset specific instruction combination (including instruction header, check code, and instruction tail), which is unique and unforgeable. It is used to clearly distinguish between regular serial communication instructions and offline upgrade trigger instructions, avoid accidental triggering of the offline upgrade mode, and ensure the stability of system operation.

[0390] Optionally, in this embodiment, the security core may, but is not limited to, monitoring the communication data of the UART serial port in real time. When an offline upgrade trigger signal that meets the preset rules is detected, the offline upgrade mode is immediately started and the UART serial port control transfer process is executed.

[0391] Optionally, in this embodiment, the service core may, but is not limited to, sending heartbeat packets to the security core at fixed intervals. The heartbeat packets may, but are not limited to, include two types of core information: ① Status information: the service core's own operating status and the UART serial port controller's working status; ② Data information: real-time data segments received by the UART serial port. The security core maintains the service core jump ledger and uses heartbeat packets to achieve real-time monitoring of the service core's status and UART serial port communication data. When parsing the serial port data segments in the heartbeat packets, the security core compares the characteristics of the offline upgrade trigger signal (completeness and correctness of the instruction header, checksum, and instruction tail) in real time. If a complete and valid trigger signal is detected, it immediately determines that the offline upgrade mode needs to be initiated. Simultaneously, it combines the service core status information in the heartbeat packets to determine whether the service core is faulty (the determination criteria may include, but are not limited to: heartbeat timeout / status field abnormality, indicating a service core fault; heartbeat normal / status field normal, indicating no service core fault).

[0392] Optionally, in this embodiment, the UART serial port control transfer process may, but is not limited to, be executed according to different scenarios. The UART serial port control transfer process may, but is not limited to, include: Step 1: The security core executes differentiated takeover instructions based on the business core jump status: ① Scenario 1 (heartbeat normal, business core no fault): The security core sends a serial port control transfer instruction to the business core, along with a successful trigger signal verification certificate (ensuring the legality of the instruction); ② Scenario 2 (heartbeat timeout / abnormal, business core fault): The security core directly marks the business core as faulty, skips the transfer instruction, and executes a forced serial port takeover to avoid the faulty business core interfering with the takeover process; Step 2 (executed only in scenario 1): After receiving the transfer instruction, the business core immediately performs the following operations to ensure the safe release of serial port control: suspend all UART serial port communication processes and prohibit new serial port data transmission and reception; clear the serial port receive / transmit buffer and reset the serial port related register configuration to the initial state; send a control release ready signal back to the security core, which includes verification information that the buffer clearing is complete and the register reset is successful; after the security core verifies that the control release is normal, it proceeds to Step 3. Step 3 (executed in both Scenario 1 and Scenario 2): The security core modifies the system permission configuration table, granting access to UART serial port related registers and buffers only to the security core process, prohibiting any other process from accessing them. In Scenario 2, the security core uses the system exception handling mechanism to forcibly terminate all UART serial port-related processes in the service core, releasing serial port resources and avoiding resource conflicts. After taking over the serial port, the security core takes over the serial port data reporting of the service core, directly reads UART serial port data, and responds to maintenance terminal commands, achieving independent control of the upgrade process. Step 4: The security core continuously monitors the service core's hop status, maintaining the service core's access to the serial port blocked in the permission configuration table throughout the offline upgrade process. Even if the service core's hop returns to normal later, the security core must actively unblock the access after the upgrade is complete to restore the service core's control over the serial port, preventing the service core from interfering with serial communication during the upgrade process.

[0393] Optionally, in this embodiment, the security core may, but is not limited to, setting up three protection measures after taking over the core resources: ① Access control isolation: After taking over the serial port, the security core activates the access control isolation mechanism to strictly limit the data interaction range of serial communication. It only allows receiving encrypted upgrade packages and upgrade-related control commands sent by the maintenance terminal, prohibits receiving any illegal commands, and directly discards and logs illegal commands; ② Communication encryption: All UART serial communication data between the maintenance terminal and the security core is encrypted using the AES-256 encryption algorithm and a verification code is added. After receiving the data, the security core decrypts it and then verifies it to ensure that the data is not tampered with or stolen during the data transmission process; ③ Anomaly monitoring: The security core monitors its own serial communication module and operating status during verification. If an anomaly is detected in the serial communication, the serial communication is immediately suspended, and an anomaly log is retained for subsequent troubleshooting.

[0394] Optionally, in this embodiment, after the security core completes the takeover of control of the UART serial port, it may, but is not limited to, send a takeover ready signal to the operation and maintenance terminal. After receiving the signal, the operation and maintenance terminal sends an encrypted full upgrade package of the service core system to the security core through the UART serial port. After receiving the upgrade package, the security core first uses a preset decryption algorithm to completely decrypt the upgrade package, and then executes a dual verification process (upgrade package digital signature verification and upgrade package hash value verification) to verify the legality and integrity of the upgrade package. After confirming that it has not been tampered with or damaged, it proceeds to the subsequent upgrade steps. If the verification fails, the security core may, but is not limited to, send a clear verification failure message to the operation and maintenance terminal through the UART serial port, maintain the serial port takeover state, and directly terminate the upgrade process to prevent unauthorized upgrade packages from being written.

[0395] Optionally, in this embodiment, after the upgrade package is verified, the security core can, but is not limited to, independently perform a full erase operation on the storage medium to completely erase the old version of the business core system data (i.e., the fourth firmware data and the fifth firmware data) in the storage medium. After erasure, the security core will write the decrypted new business core system image (i.e., the sixth firmware data and the seventh firmware data) into the storage medium segment by segment according to the preset segmentation rules. During the writing process, the hash value of each image segment is verified in real time and compared with the segmentation benchmark value built into the upgrade package to ensure that the written data is not lost, erroneous, or tampered with. After all images are written, the security core starts the full-link signature verification process and performs signature verification on all key components in the startup link in sequence. The verification standard is consistent with the online full erase upgrade.

[0396] Optionally, in this embodiment, if the end-to-end signature verification passes, the security core triggers a BMC restart command, simultaneously removing the UART serial port control shield and releasing UART serial port control. After the BMC restarts, it starts a new service core system according to the end-to-end trusted startup process, and the system resumes normal operation and maintenance after successful startup. If the end-to-end signature verification fails, the security core immediately triggers a system rollback mechanism, loading the original version of the service core system image from a preset backup area, overwriting the currently written abnormal image, and restoring the system to its state before the upgrade; simultaneously, it removes the UART serial port control shield and releases UART serial port control to the service core.

[0397] As an optional implementation method, this application may provide, but is not limited to, a method for measuring and auditing the entire BMC operation process, which may, but is not limited to, rely on the dual-mode operation mechanism of the security kernel and divide the measurement points according to the startup phase and the operation phase.

[0398] Optionally, in this embodiment, the Bootloader, OS (operating system), and user service program images can be measured during the startup phase; and the memory image of the business core process (such as the sensor monitoring process) can be measured every 5 seconds during the runtime phase.

[0399] Optionally, in this embodiment, the measurement data may be calculated using a cryptographic acceleration engine to obtain a hash value, compared with a benchmark value, and the result recorded in the measurement log of Secure SRAM (including measurement time, component name, comparison result, etc.).

[0400] Optionally, in this embodiment, the operation and maintenance terminal may, but is not limited to, request a trusted report through a remote connection. The security kernel reads the measurement log from the Secure SRAM, generates a structured report, signs it with the EK key, and then distributes it. The operation and maintenance terminal may, but is not limited to, verify the report signature, confirm the trusted status of the BMC, and realize audit traceability.

[0401] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0402] Embodiments of this application also provide a fault monitoring device for control equipment. Figure 15 This is a structural block diagram of a fault monitoring device for a control equipment according to an embodiment of this application, such as... Figure 15 As shown, the device includes:

[0403] The first detection module 1502 is used to detect fault information of the second processing unit of the control device. The fault information is used to indicate the operational failure of the second processing unit. The control device includes: a first processing unit, a second processing unit, and a reference storage unit. The reference storage unit is configured to allow only the first processing unit to access it. The second processing unit is used to control the connected server through one or more service programs. The reference storage unit stores at least one target firmware data. The at least one target firmware data is used to start at least one target service program among one or more service programs.

[0404] The startup module 1504 is used to start at least one reference service program from at least one target firmware data in at least one target firmware data in the reference storage unit according to the fault information, and to restore the operation of the second processing unit according to the fault information.

[0405] Through the above device, the first processing unit of the control device detects the fault information of the second processing unit of the control device. The second processing unit is used to control the connected server through one or more service programs. The control device includes a reference storage unit that is set to be accessible only by the first processing unit. The reference storage unit stores at least one target firmware data. The at least one target firmware data is used to start at least one target service program among one or more service programs. The first processing unit calls at least one reference firmware data from the at least one target firmware data in the reference storage unit according to the fault information to start at least one reference service program among at least one target service program, and restores the operation of the second processing unit according to the fault information. That is, in the event of a failure in the operation of the second processing unit, the first processing unit attempts to restore the operation of the second processing unit by using the data stored in the reference storage unit that is accessible only by the first processing unit, and also starts the reference service program on the first processing unit to ensure that the control device's control over the server is not interrupted. Therefore, the technical problem of low monitoring and processing efficiency of control device faults in related technologies can be solved, and the technical effect of improving the monitoring and processing efficiency of control device faults can be achieved.

[0406] The fault monitoring device for control equipment provided in the embodiments of this application is also configured to execute the steps in any of the above embodiments of the fault monitoring method for control equipment, which will not be described in detail here.

[0407] For a description of the features in the embodiment corresponding to the fault monitoring device of the control equipment, please refer to the relevant description of the embodiment corresponding to the fault monitoring method of the control equipment, which will not be repeated here.

[0408] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above-described embodiments of the fault monitoring method for control devices.

[0409] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described embodiments of the fault monitoring method for control devices when it is run.

[0410] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0411] The embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described embodiments of the fault monitoring method for control devices.

[0412] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described embodiments of the fault monitoring method for control devices.

[0413] Any of the components, modules, units, parts, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Alternatively or additionally, any functionality described herein can be executed at least in part by one or more hardware logic components, such as, but not limited to, a central processing unit (CPU), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), an application-specific standard product (ASSP), a system-on-a-chip (SoC), a complex programmable logic device (CPLD), a microprocessor (MCU), etc. The terms "system," "computing device," or "apparatus" as used herein encompass various means, devices, and machines for processing data, including, for example, one or more programmable processors, computers, SoCs, or combinations thereof. The apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or one or more combinations thereof. The aforementioned computer program (also known as a program, software, software application, app, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for a computing environment.

[0414] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0415] The foregoing has provided a detailed description of a fault monitoring method and electronic device for a control device provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for fault monitoring of control equipment, characterized in that, The method, applied to a first processing unit of a control device, includes: The control device detects fault information of the second processing unit, wherein the fault information is used to indicate an operational failure of the second processing unit. The control device includes: a first processing unit, a second processing unit, and a reference storage unit. The reference storage unit is configured to allow only the first processing unit to access it. The second processing unit is used to control a connected server through one or more service programs. The reference storage unit stores at least one target firmware data, and the at least one target firmware data is used to start at least one target service program among the one or more service programs. Based on the fault information, at least one reference firmware data from the at least one target firmware data is retrieved from the reference storage unit to start at least one reference service program from the at least one target service program, and the operation of the second processing unit is restored based on the fault information.

2. The fault monitoring method according to claim 1, characterized in that, The step of starting at least one reference service program among the at least one target service program by retrieving at least one reference firmware data from the at least one target firmware data from the reference storage unit based on the fault information includes: The reference firmware data is filtered from the at least one target firmware data according to the target fault type of the operational fault that occurred in the second processing unit; The reference service program is started using the reference firmware data.

3. The fault monitoring method according to claim 2, characterized in that, The step of filtering the reference firmware data from the at least one target firmware data according to the target fault type of the operational fault that occurred in the second processing unit includes: A fourth read request is sent to the reference storage unit via a first bus. The control device further includes: the first bus, which is connected to both the first processing unit and the reference storage unit. The fourth read request is used to request the reading of target firmware data corresponding to the target fault type. The reference storage unit is used to: respond to the fourth read request, search for the reference firmware data corresponding to the target fault type from the fault types and target firmware data with corresponding relationships, and send the reference firmware data to the first processing unit via the first bus. Receive the reference firmware data sent by the first processing unit.

4. The fault monitoring method according to claim 2, characterized in that, The step of obtaining the reference firmware data from the reference storage unit according to the target fault type of the operational fault occurring in the second processing unit includes: A fifth read request is sent to the reference storage unit via a first bus. The control device further includes: the first bus, which is connected to both the first processing unit and the reference storage unit. The fifth read request is used to request the reading of corresponding fault types and target firmware data. The reference storage unit is used to respond to the fifth read request by sending the corresponding fault types and target firmware data to the first processing unit via the first bus. Receive the corresponding fault types and target firmware data; Search for the reference firmware data corresponding to the target fault type from the corresponding fault types and target firmware data.

5. The fault monitoring method according to claim 2, characterized in that, The step of starting the reference service program using the reference firmware data includes: A second process independent of the first process is created for the reference service program, and a second memory space independent of the first memory space is allocated for the reference service program, wherein the first process is used to run the security service program of the first processing unit, and the first memory space is the memory space used by the first process; Load the reference firmware data into the second memory space; The second process is controlled to start the reference service program based on the reference firmware data stored in the second memory space.

6. The fault monitoring method according to claim 1, characterized in that, The step of restoring the operation of the second processing unit based on the fault information includes: The target recovery information of the second processing unit is detected based on the target fault type of the operational fault that occurred in the second processing unit, wherein the target recovery information is used to indicate the recovery method for restoring the operation of the second processing unit; The operation of the second processing unit is resumed based on the target recovery information.

7. The fault monitoring method according to claim 6, characterized in that, The step of detecting the target recovery information of the second processing unit based on the target fault type of the operational fault that occurred in the second processing unit includes: If the target fault type is a stop-operation type, the target recovery information is determined to instruct the restart of the second processing unit; If the target fault type is a fault type other than the one that stops running, the reference service program corresponding to the target fault type is obtained from the fault types and service programs with corresponding relationships; the target recovery information is determined to instruct the recovery of the operation of the reference service program in the second processing unit.

8. The fault monitoring method according to claim 6, characterized in that, The step of restoring the operation of the second processing unit based on the target recovery information includes: When the target recovery information is used to indicate the restart of the second processing unit, a reset command is sent to the reset controller of the second processing unit, wherein the reset command is used to indicate the restart of the second processing unit, and the control device further includes: the reset controller, which is configured to respond only to the command sent by the first processing unit, and the reset controller is used to control the restart of the second processing unit in response to the reset command.

9. The fault monitoring method according to claim 6, characterized in that, The step of restoring the operation of the second processing unit based on the target recovery information includes: When the target recovery information is used to instruct the resumption of the reference service program in the second processing unit, the reference firmware data for starting the reference service program is obtained from the reference storage unit via the first bus. The control device further includes: the first bus and the second bus, wherein the first bus is connected to both the first processing unit and the reference storage unit, and the second bus is connected to both the first processing unit and the second processing unit. A recovery command is sent to the second processing unit via the second bus, wherein the recovery command carries the reference firmware data and is used to instruct the second processing unit to use the reference firmware data to restore the operation of the reference service program. The second processing unit is used to: respond to the recovery command by using the reference firmware data to restore the operation of the reference service program on the second processing unit.

10. The fault monitoring method according to claim 1, characterized in that, The step of calling at least one reference firmware data from the at least one target firmware data in the at least one target firmware data in the reference storage unit to start at least one reference service program in the at least one target service program according to the fault information, and restoring the operation of the second processing unit according to the fault information, includes: Based on the target fault type of the operational fault that occurred in the second processing unit, the at least one reference firmware data is retrieved from the reference storage unit to start the at least one reference service program, wherein the fault information includes the target fault type; Restore the operation of the second processing unit according to the target fault type.

11. The fault monitoring method according to claim 1, characterized in that, The fault information detected by the second processing unit of the control device includes: The control device further includes the shared storage unit and the second bus, wherein the second bus is connected to both the first processing unit and the shared storage unit, the second processing unit is connected to the second bus, and the fourth storage address is set to allow only the first processing unit and the second processing unit to access it. The second processing unit sends an encrypted heartbeat command to the second processing unit via the second bus. The encrypted heartbeat command is a heartbeat request command encrypted using the processing unit key. The heartbeat request command instructs the second processing unit to send its processing operation information to the first processing unit. This processing operation information indicates the operating status of each service on the second processing unit. The second processing unit is configured to: receive the encrypted heartbeat command; obtain the processing unit key from the fourth storage address via the second bus; decrypt the encrypted heartbeat command using the processing unit key to obtain the heartbeat request command; and generate response information based on the heartbeat request command, wherein the response information includes the target processing operation information of the second processing unit; encrypt the response information using the processing unit key to obtain encrypted response information; and send the encrypted response information to the first processing unit via the second bus. Receive the encrypted response information; The encrypted response information is decrypted using the processing unit key to obtain the response information; If the response information is not obtained, or if the target service indicated by the response information is in a fault state, it is determined that the fault information has been detected.

12. The fault monitoring method according to claim 1, characterized in that, After invoking at least one reference firmware data from the at least one target firmware data in the reference storage unit according to the fault information to start at least one reference service program in the at least one target service program, and resuming the operation of the second processing unit according to the fault information, the method further includes: The recovery result of the second processing unit is detected, wherein the recovery result is used to indicate the recovery status of the operation of the second processing unit; If the recovery result indicates that the operation of the second processing unit has not been restored, the control device is updated through the maintenance terminal connected to the management interface of the control device.

13. The fault monitoring method according to claim 12, characterized in that, The updating of the control device via the maintenance terminal connected through the management interface of the control device includes: Take over the control permissions of the management interface, wherein the control permissions of the management interface are set to allow only one of the processing units, the first processing unit and the second processing unit, to control it; The alarm information is sent to the operation and maintenance terminal through the management interface, wherein the alarm information is used to indicate that the control device needs to be updated; The management interface receives the update data packet of the control device returned by the operation and maintenance terminal in response to the alarm information; The control device is updated using the update data package.

14. The fault monitoring method according to claim 13, characterized in that, The control permissions to take over the management interface include: The control permissions of the management interface are adjusted by modifying the system permission configuration table of the control device so that only the first processing unit can control it. The system permission configuration table is used to configure the control permissions of each interface of the control device.

15. The fault monitoring method according to claim 13, characterized in that, Updating the control device using the update data packet includes: The target key information is obtained from the reference storage unit via a first bus, wherein the control device further includes: the first bus, which is connected to both the first processing unit and the reference storage unit, and the reference storage unit also stores the target key information of the control device; The data packet security information of the update data packet is detected based on the target key information, wherein the data packet security information is used to indicate the security of the update data packet; When the data packet security information is used to indicate that the update data packet is secure, the fourth firmware data is updated using the sixth firmware data in the update data packet, and the fifth firmware data is updated using the seventh firmware data in the update data packet, wherein the fourth firmware data and the fifth firmware data are used to start the second processing unit; The second processing unit is started using the sixth firmware data and the seventh firmware data.

16. The fault monitoring method according to claim 15, characterized in that, The step of updating the fourth firmware data using the sixth firmware data in the update data package, and updating the fifth firmware data using the seventh firmware data in the update data package, includes: The control device further includes the shared storage unit and the second bus. The second bus is connected to both the first processing unit and the shared storage unit. The shared storage unit is configured to allow only the first processing unit to access the data if the security information of the stored firmware data is not verified or if the security information of the stored firmware data indicates that the firmware data is insecure.

17. The fault monitoring method according to claim 12, characterized in that, After detecting the recovery result of the second processing unit, the method further includes: If the recovery result indicates that the operation of the second processing unit has been restored, the operation of the second process of the first processing unit is terminated, and the second memory space is released, wherein the second process is used to run the reference service program, and the second memory space is the memory space used by the second process.

18. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the fault monitoring method as described in any one of claims 1 to 17 when executing the computer program.

Images