Management controller and server

Abstract

The application discloses a kind of management controller and server, it is related to server technical field, including main processor, first security processor and second security processor.The abnormal event generated in the running process of main processor is monitored by first security processor and monitoring report is obtained, and the execution information of first security processor is verified based on monitoring report by the second security processor of the second security processor that prohibits external device to initiate active access to identify its working state, and according to the abnormal level and verification result determines which security processor handles abnormal event, so that the second security processor can reliably verify first security processor under isolation protection, and take over abnormal event processing or directly process high-level abnormal events when first security processor is attacked or fails, solve the problem that security processor is vulnerable to attack in related art, leading to insufficient safety of abnormal event processing, improve the safety and reliability of abnormal event processing.

Description

Technical Field

[0001] This application relates to the field of server technology, and in particular to management controllers and servers. Background Technology

[0002] As a core management component of the server, the Baseboard Management Controller (BMC) needs to continuously monitor the operating system's running status to ensure system security. In relevant security monitoring solutions, the BMC's processor typically monitors and handles abnormal events that occur during operation.

[0003] However, in related technologies, security processors are vulnerable to attacks during the monitoring and handling of abnormal events, resulting in insufficient security in abnormal event handling. Summary of the Invention

[0004] This application provides a management controller, a server, a security monitoring method for the management controller, an electronic device, a computer-readable storage medium, and a program product to at least address the problem in the related art that security processors are vulnerable to attacks during the monitoring and processing of abnormal events, resulting in insufficient security in abnormal event handling.

[0005] This application provides a management controller, comprising: a main processor, located within the management controller, for executing hardware management functions of the management controller; a first security processor, communicatively connected to the main processor, for monitoring abnormal events generated during the operation of the main processor and outputting monitoring reports; and a second security processor, which prevents external devices from initiating active access, and is communicatively connected to both the first security processor and the main processor, for verifying the working status of the first security processor based on the monitoring reports and outputting verification results; the first security processor is further configured to handle corresponding abnormal events when the abnormality level corresponding to the monitoring report exceeds a first warning threshold; the second security processor is further configured to handle corresponding abnormal events when the abnormality level corresponding to the monitoring report exceeds a second warning threshold, or when the verification result is a verification failure; wherein the value of the second warning threshold is greater than the first warning threshold.

[0006] This application provides a server, including: a firmware storage unit; a secure storage device; and the aforementioned management controller.

[0007] This application provides a security monitoring method for a management controller, applied to the aforementioned management controller, which includes a main processor, a first security processor, and a second security processor. The security monitoring method includes: executing hardware management services of the management controller through the main processor; monitoring abnormal events generated during the operation of the main processor through the first security processor and outputting monitoring reports; verifying the working status of the first security processor based on the monitoring reports through the second security processor and outputting verification results; processing the corresponding abnormal event through the first security processor when the abnormality level corresponding to the monitoring report exceeds a first warning threshold; and processing the corresponding abnormal event through the second security processor when the abnormality level corresponding to the monitoring report exceeds a second warning threshold, or when the verification result is a verification failure; wherein the value of the second warning threshold is greater than the first warning threshold.

[0008] 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 steps of any of the above-described security monitoring methods for a management controller.

[0009] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of any of the above-described security monitoring methods for a management controller.

[0010] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described security monitoring methods for a management controller.

[0011] This application addresses the issue of insufficient security in anomaly handling by incorporating a second security processor that prevents external devices from initiating active access. This second processor is less susceptible to external attacks and can identify whether the first security processor has malfunctioned or been attacked based on the verification results. When the verification fails, the second security processor takes over the handling of the abnormal event. Furthermore, by setting a second warning threshold higher than the first warning threshold, lower-level anomalies are handled by the first security processor, while higher-level anomalies are handled by the isolated and protected second security processor. Even if the first security processor is attacked or malfunctions during anomaly monitoring and handling, the second security processor can still detect the problem based on the verification results and take over the handling, or directly handle high-level anomalies. Therefore, this invention solves the technical problem in related technologies where security processors are easily attacked or malfunction during anomaly monitoring and handling, leading to insufficient security in anomaly handling, thus improving the security of anomaly handling. Attached Figure Description

[0012] 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.

[0013] Figure 1 This is one of the schematic diagrams of the management controller in an embodiment of this application.

[0014] Figure 2 This is a second schematic diagram of the management controller according to an embodiment of this application.

[0015] Figure 3 This is an interactive schematic diagram of an abnormal event handling method in a management controller provided in an embodiment of this application.

[0016] Figure 4 This is a schematic diagram of a secure storage device provided in an embodiment of this application.

[0017] Figure 5 This is a schematic diagram of a server provided in an embodiment of this application.

[0018] Figure 6 This is one of the flowcharts illustrating a security monitoring method for a management controller provided in an embodiment of this application.

[0019] Figure 7 This is a second flowchart illustrating a security monitoring method for a management controller provided in an embodiment of this application. Detailed Implementation

[0020] 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.

[0021] 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.

[0022] 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.

[0023] The Baseboard Management Controller (BMC) is a core management component in a server, typically integrated on the server motherboard, used to implement out-of-band management functions for the server hardware. Through an independent power supply and network interface, the BMC can continue to operate even when the main server system is shut down or malfunctions, enabling functions such as remote monitoring, fault diagnosis, and system maintenance.

[0024] In some related technologies, BMC security verification mainly focuses on the system startup phase. The system typically performs a one-time signature verification or integrity check on the firmware image only upon power-up. This single-verification mode has significant shortcomings. The verification process can only confirm that the firmware image state at startup has not been tampered with, and cannot address dynamic threats that may arise during system operation. Attackers can compromise the system's security state after startup through memory injection, runtime code tampering, and other means. Due to the lack of continuous security monitoring, the system cannot detect these runtime attacks in a timely manner, leaving the server at a long-term potential security risk.

[0025] In some related technologies, even if a BMC (Backend Management System) possesses runtime monitoring capabilities, it can only detect single types of abnormal events. The system lacks the ability to quantitatively assess the overall security status. During operation, a BMC may simultaneously experience multiple types of abnormal events, such as illegal memory access, abnormal process crashes, and cryptographic verification failures. The severity of these events varies, and the impact of historical abnormal events gradually diminishes over time. However, the monitoring methods in these technologies cannot comprehensively consider the cumulative effect and time decay characteristics of several abnormal events, making it difficult for the system to accurately determine the current security risk level.

[0026] In some related technologies, BMC (Browser Control Management) lacks the ability to handle anomalies in a tiered manner. The systems typically employ a uniform processing strategy or a simple threshold-based triggering method. When an anomaly is detected, the BMC systems in these technologies either execute fixed logging and alarm procedures or directly trigger aggressive measures such as system restarts, failing to achieve fine-grained tiered processing.

[0027] In some related technologies, BMC's security monitoring function relies entirely on the execution results of a single security processor. The system lacks reliable verification of the security processor's own operational status. The processor responsible for security monitoring itself can become a target for attack. Attackers can use targeted hardware attacks to tamper with the security processor's firmware image, disrupt its operational status, or falsify monitoring results. Because there is no independent security domain to verify the monitoring processor, the system cannot detect when the security processor itself has been compromised.

[0028] To address the aforementioned technical problems, this application provides a management controller. The management controller of this application will now be described in detail with reference to the accompanying drawings.

[0029] Figure 1 This is one of the schematic diagrams of the management controller in an embodiment of this application.

[0030] like Figure 1 As shown, the management controller 100 in this embodiment includes: a main processor 10, a first security processor 20, and a second security processor 30.

[0031] The main processor 10 is located inside the management controller 100 and can be used to execute the hardware management business of the management controller 100.

[0032] For example, the main processor 10 may refer to the processing unit in the management controller responsible for performing the main management tasks. The main processor 10 may run a main operating system to handle the routine management functions of the management controller. The main operating system may be Linux, an embedded real-time operating system, or other operating systems suitable for the BMC.

[0033] For example, the main processor 10 may include, but is not limited to, an Advanced RISC Machine (ARM) processor, a Reduced Instruction Set Computer (RISC) processor, or other embedded processors.

[0034] In one feasible implementation, the hardware management services of the main processor 10 may include server hardware monitoring tasks, sensor data acquisition tasks, fan control tasks, power management tasks, etc. The main processor 10 may also provide external management interfaces, such as the Intelligent Platform Management Interface (IPMI), to respond to control commands from remote management terminals.

[0035] The first security processor 20 is connected to the main processor 10 and can be used to monitor abnormal events generated during the operation of the main processor 10 and output monitoring reports.

[0036] For example, the first security processor 20 may refer to a processing unit in the management controller specifically responsible for security monitoring. The first security processor 20 operates independently of the main processor 10 and is capable of continuously monitoring the behavior and state of the main processor 10 during operation.

[0037] For example, the first security processor 20 may include, but is not limited to, a RISC architecture processor core, an ARM Cortex series processor core, or other low-power embedded processor core.

[0038] In one feasible implementation, the first security processor 20 can access the operating status information of the main processor 10 via the system bus or a dedicated monitoring interface. The first security processor 20 acquires information such as memory access records, process running status, and system call sequences of the main processor 10. The first security processor 20 can compare this information with preset security rules to identify potential abnormal events.

[0039] In another feasible implementation, after detecting an abnormal event, the first security processor 20 can record information such as the type, time of occurrence, and severity of the abnormal event. Based on this information, the first security processor 20 generates a monitoring report. The monitoring report may include a detailed description of the abnormal event and an anomaly level obtained from a comprehensive assessment.

[0040] It should be noted that the anomaly level in the monitoring report is used to characterize the degree of risk of the current system security status. The anomaly level can be obtained through quantitative calculation; the higher the value, the greater the security risk faced by the system.

[0041] The second security processor 30 prohibits external devices from initiating active access. It is communicatively connected to both the first security processor 20 and the main processor 10. It can be used to check the working status of the first security processor 20 based on monitoring reports and output the check results. The check results characterize the working status of the first security processor 20.

[0042] For example, the second security processor 30 can be a processing unit in the management controller responsible for supervising and verifying the first security processor 20. Unlike the first security processor 20, the second security processor 30 prohibits external devices from initiating active access. The second security processor 30 acts as an independent root of trust, providing trusted verification of the monitoring work of the first security processor 20.

[0043] For example, the second security processor 30's prohibition of active access by external devices means that the second security processor 30 is isolated from other processors and external communication interfaces at both the physical and logical levels. At the physical level, the second security processor 30 exchanges limited data with other components through a separate hardware bus. External devices cannot directly access the internal resources of the second security processor 30. At the logical level, the firmware image program running on the second security processor 30 undergoes rigorous security auditing, performs only predefined security verification tasks, and does not respond to dynamic instruction requests from external sources.

[0044] For example, the second security processor 30 may include, but is not limited to, a dedicated security processor core, a processor core integrated with a Trusted Platform Module (TPM), or other processor cores with hardware isolation capabilities.

[0045] In one feasible implementation, the second security processor 30 can receive the monitoring report generated by the first security processor 20 via a unidirectional data path. Upon receiving the monitoring report, the second security processor 30 acquires the execution information of the first security processor 20. This execution information characterizes the working state of the first security processor 20, including its operating parameters, calculation results, and status indicators during the monitoring process. The second security processor 30 can verify the execution information to confirm whether the first security processor 20 is operating normally during the monitoring process, whether the monitoring steps are executed in a preset order, and whether the calculation results are reliable.

[0046] In one implementation, the second security processor 30 can verify the calculation results in the execution information. For example, the second security processor 30 can recalculate the anomaly level value in the monitoring report and compare it with the anomaly level recorded in the monitoring report, thereby verifying whether the data provided by the first security processor 20 is accurate. The second security processor 30 can also sample and verify the abnormal events recorded in the monitoring report to confirm that these abnormal events did indeed occur in the main processor 10.

[0047] In another implementation, the second security processor 30 can analyze the status identifiers in the execution information. The second security processor 30 determines whether the first security processor 20 has encountered any abnormal states during the monitoring process. For example, whether the first security processor 20 has restarted, triggered any error interrupts, attempted unauthorized access, or whether the firmware metric values ​​are consistent with the expected values.

[0048] It should be noted that the second security processor 30 obtains the inspection result based on the verification of the execution information. The inspection result indicates whether the first security processor 20 is operating normally and whether the monitoring report is reliable. If the inspection result indicates that the inspection has failed, it means that the first security processor 20 may have been compromised or is malfunctioning, in which case the second security processor 30 needs to intervene to handle the abnormal event.

[0049] The first security processor 20 can also be used to: process the abnormal event corresponding to the monitoring report in response to the anomaly level of the monitoring report exceeding the first warning threshold.

[0050] The second security processor 30 can also be used to: process the abnormal event corresponding to the monitoring report in response to the anomaly level of the monitoring report exceeding the second warning threshold, or the inspection result indicating inspection failure. The value of the second warning threshold is greater than the value of the first warning threshold.

[0051] In one feasible implementation, after generating a monitoring report, the first security processor 20 can obtain the anomaly level recorded in the monitoring report. The first security processor 20 compares the anomaly level with a first warning threshold. When the anomaly level exceeds the first warning threshold, the first security processor 20 determines that the current system security status has exceeded the normal range and that the abnormal event needs to be handled. The first security processor 20 can determine the specific abnormal event that needs to be handled based on the abnormal event information recorded in the monitoring report.

[0052] For example, the first warning threshold can be a pre-set value used to characterize the initial risk boundary of the system's security status. The setting of the first warning threshold can comprehensively consider the operating environment and security requirements of the management controller.

[0053] In one feasible implementation, after completing the operational status check of the first security processor 20, the second security processor 30 can determine whether intervention is necessary based on two conditions. The first condition is that the anomaly level corresponding to the monitoring report exceeds a second warning threshold. When this condition is met, it indicates that the system faces a serious security risk. The second condition is that the inspection result indicates inspection failure. When this condition is met, it indicates that the first security processor 20 may have malfunctioned during monitoring, and its monitoring report may be unreliable. When either of these two conditions is met, the second security processor 30 needs to process the abnormal event corresponding to the monitoring report.

[0054] For example, the second warning threshold can be a pre-set value used to characterize the severe risk boundary of the system's security status.

[0055] Optionally, the second warning threshold may be greater than the first warning threshold. The difference between the two warning thresholds can be adjusted according to actual needs.

[0056] It should be noted that by setting two different warning thresholds, the management controller 100 implements a tiered response to abnormal events. When the anomaly level is between the first and second warning thresholds, it is handled by the first security processor 20. When the anomaly level exceeds the second warning threshold, or when there is a problem with the operation of the first security processor 20 itself, it is handled by the second security processor 30. The above-mentioned tiered response method can take different intensities of handling measures according to the severity of the security risk.

[0057] Optionally, the specific values ​​of the first and second warning thresholds can be configured according to the application scenario of the management controller. In scenarios with high security requirements, such as data centers, lower warning thresholds can be set. In scenarios with high availability requirements, such as edge computing, higher warning thresholds can be set.

[0058] By adopting the technical solution of the above embodiments, the second security processor prohibits external devices from initiating active access, thus avoiding the impact of external attacks on the second security processor. The second security processor can check the working status of the first security processor 20 and determine whether the first security processor is working properly based on the check result. When the check result indicates a failure, it means that the first security processor may have been attacked or malfunctioned. At this time, the second security processor can take over the handling of abnormal events.

[0059] Meanwhile, by setting a second warning threshold higher than the first warning threshold, a tiered handling system for abnormal events is implemented. When the anomaly level exceeds the first warning threshold but not the second warning threshold, the first security processor handles the abnormal event. When the anomaly level exceeds the second warning threshold, the second security processor handles the abnormal event. This tiered handling method ensures that lower-level anomalies are handled by the first security processor, while higher-level anomalies are handled by the isolated and protected second security processor.

[0060] Even if the first security processor is attacked or malfunctions during the monitoring and handling of abnormal events, the second security processor can still detect the abnormal state of the first security processor 20 by checking its working status and take over the handling of abnormal events. For serious abnormal events whose abnormality level exceeds the second warning threshold, the second security processor can handle them directly, avoiding the situation where serious abnormal events cannot be handled in a timely manner due to the malfunction of the first security processor.

[0061] The above embodiments illustrate the overall architecture of the management controller and the collaborative relationships between the various processors. The following section details the process by which the first security processor monitors abnormal events during the operation of the main processor and generates monitoring reports.

[0062] Based on the above embodiments, as an optional embodiment, the first security processor 20 is also used to monitor several abnormal events generated during the operation of the main processor 10.

[0063] The first security processor 20 can determine the severity information of each abnormal event among several abnormal events based on the event type of the abnormal events.

[0064] The first security processor 20 can perform a weighted summation of the severity information of several abnormal events to obtain the abnormality level of the several abnormal events. Based on the several abnormal events and their abnormality levels, the first security processor 20 outputs a monitoring report.

[0065] In one implementation, the first security processor 20 can continuously collect system behavior data during the operation of the main processor 10. The first security processor 20 acquires operational information such as memory access operations, process scheduling records, and system call requests of the main processor 10. The first security processor 20 compares and analyzes the above operational information with a preset security rule base, identifies events that deviate from normal behavior patterns, and treats the identified events as abnormal events.

[0066] The first security processor 20 can look up a preset severity mapping table based on the event type of each abnormal event. The severity mapping table stores the mapping relationship between different event types and corresponding severity information. The first security processor 20 retrieves the severity information corresponding to each abnormal event from the severity mapping table based on the event type of each abnormal event.

[0067] For example, severity information can be a quantified numerical value. The severity information for an illegal memory access attempt can be 5, the severity information for an unexpected crash of a critical process can be 20, and the severity information for a failed cryptographic verification can be 50. The severity information for different event types reflects the degree of impact of that type of anomalous event on system security.

[0068] The first security processor 20 can assign a weight coefficient to each abnormal event and calculate the severity information of several abnormal events by weighted summation to obtain the abnormality level of several abnormal events.

[0069] Optionally, the severity mapping table can be configured according to the actual application scenario of the management controller. For example, in application scenarios with high security requirements, higher severity information can be set for various abnormal events. In application scenarios with high availability requirements, lower severity information can be set for various abnormal events.

[0070] By adopting the technical solution of the above embodiments, the first security processor can continuously monitor several abnormal events that occur during the operation of the main processor, and determine quantified severity information for each abnormal event according to the event type. The first security processor calculates the severity information of several abnormal events by weighted summation to obtain an anomaly level reflecting the overall security status of the system. The above method can comprehensively consider the cumulative impact of several abnormal events, avoiding misjudgments that may be caused by isolated judgment of a single abnormal event.

[0071] To avoid the problem of local severe anomalies caused by a single anomaly level being diluted overall or several minor anomalies being simply amplified by accumulation, as an optional embodiment based on the above embodiments, the first security processor 20 can also be used to classify several abnormal events according to the abnormal objects corresponding to each abnormal event in several abnormal events, to obtain an abnormal event set corresponding to at least one abnormal object.

[0072] The first security processor 20 can determine the local anomaly level of each anomaly object and the global anomaly level of the main processor based on the severity information of the anomaly events in each set of anomalies.

[0073] The first security processor 20 can generate monitoring reports based on the local and global anomaly levels of each abnormal object.

[0074] In one feasible implementation, the first security processor 20 can extract the anomaly object identifiers recorded in each anomaly event and group anomaly events with the same anomaly object into the same anomaly event set. Anomaly objects may include specific processes, threads, files, or network connections, etc. Through classification processing, the first security processor 20 can obtain the anomaly event set corresponding to each anomaly object.

[0075] The first security processor 20 can analyze various sets of abnormal events. The first security processor 20 can read the severity information of each abnormal event from the abnormal event set, and calculate the local anomaly level of the abnormal object based on the value of the severity information, the number of abnormal events, and the frequency of occurrence of the abnormal events.

[0076] The first security processor 20 can comprehensively consider the local anomaly levels of various abnormal objects to determine the global anomaly level of the main processor 10.

[0077] In one implementation, the first security processor 20 can count the number of abnormal objects with a high local anomaly level. If the number of high-level abnormal objects exceeds a first threshold, the first security processor 20 can determine that the global anomaly level is high. If the number of high-level abnormal objects does not exceed the first threshold but the number of medium-level abnormal objects exceeds a second threshold, the first security processor 20 can determine that the global anomaly level is medium. The global anomaly level is used to characterize the degree of anomaly in the overall operating state of the main processor 10.

[0078] The first security processor 20 can write the identifiers of each abnormal object, the corresponding local anomaly levels, detailed information of each abnormal event set, and the global anomaly level of the main processor 10 into a monitoring report. The monitoring report can be sent to the second security processor 30 for verification, and the second security processor 30 will execute the corresponding anomaly handling process accordingly.

[0079] It should be noted that by introducing both local and global anomaly levels, the monitoring report can reflect both the severe anomalies of individual abnormal objects and the degree of anomalies in the overall operating status of the main processor 10.

[0080] Optionally, the second security processor 30 can verify the local anomaly level and the global anomaly level based on the monitoring report. The second security processor 30 can verify whether the local judgment results of the first security processor 20 for each anomaly object are accurate, and whether the comprehensive judgment result for the overall anomaly state of the main processor is reliable. If the verification passes, the second security processor 30 can trigger the corresponding anomaly handling process according to the local anomaly level and the global anomaly level.

[0081] By adopting the technical solution of the above embodiments, and dividing the anomaly level into local anomaly level and global anomaly level, it is possible to accurately identify the serious anomalies of individual anomaly objects and accurately assess the overall anomaly state of the main processor, thereby improving the accuracy of subsequent hierarchical processing.

[0082] To more accurately reflect the actual impact of abnormal events on the system's security status and to avoid historical abnormal events occupying long-term evaluation weights and affecting the judgment of the current security status.

[0083] Based on the above embodiments, as an optional embodiment, the first security processor 20 can also be used to obtain the duration of each abnormal event among several abnormal events.

[0084] The first security processor 20 can determine the attenuation coefficient of each abnormal event based on its duration. The attenuation coefficient of an abnormal event is negatively correlated with its duration.

[0085] The first security processor 20 can perform a weighted summation of the severity information of each abnormal event and the corresponding attenuation coefficient to obtain the abnormality level of several abnormal events.

[0086] In one implementation, when a monitoring report needs to be generated, the first security processor 20 can obtain the timestamp of the current moment. The first security processor 20 iterates through each abnormal event in the event log table. The first security processor 20 reads the occurrence time corresponding to each abnormal event. The first security processor 20 compares the current moment with the occurrence time of each abnormal event, calculates the time difference between the two, and obtains the duration of each abnormal event.

[0087] For example, the duration can be the time interval from the moment the abnormal event occurred to the current moment.

[0088] It should be noted that duration measures the length of time since the occurrence of the anomaly. A longer duration indicates that the anomaly occurred further back in time, while a shorter duration indicates that the anomaly occurred more recently.

[0089] In one feasible implementation, the first security processor 20 can calculate the attenuation coefficient of each abnormal event according to a preset attenuation function. The first security processor 20 takes the duration of each abnormal event as an input parameter and substitutes it into the attenuation function to obtain the corresponding attenuation coefficient as the output result.

[0090] For example, the decay function can be an exponential decay function. The exponential decay function can simulate the natural decay of the impact of an abnormal event over time. The mathematical expression for the exponential decay function can be... , where e is the natural constant, λ is the decay parameter, and Δt is the duration.

[0091] In one implementation, the first security processor 20 can read the value of the attenuation parameter λ from preset configuration parameters. The attenuation parameter λ is a positive number greater than 0. The attenuation parameter λ controls the rate attenuation coefficient changes with the duration. The first security processor 20 calculates the attenuation coefficient of the abnormal event based on the attenuation function, the duration, and the attenuation parameter.

[0092] It should be noted that the decay coefficient of an anomaly is negatively correlated with its duration. The longer the duration, the smaller the decay coefficient. The shorter the duration, the larger the decay coefficient. Anomalies that occur over a longer period of time have a larger duration and correspondingly a smaller decay coefficient.

[0093] It should be noted that the aforementioned negative correlation allows recently occurring anomalies to have a higher weight in the anomaly level calculation, while the impact of earlier anomalies gradually decreases over time. This design aligns with the needs of practical security assessments. The current security status of the system is primarily influenced by recent anomalies. While historical anomalies may have existed, their impact on the current system status should gradually weaken over time.

[0094] In one implementation, the first security processor 20 can multiply the severity information of each abnormal event by the corresponding attenuation coefficient to obtain the weighted severity of each abnormal event. The first security processor 20 then sums up the weighted severity of all abnormal events to obtain the abnormality level of several abnormal events.

[0095] Optionally, the attenuation parameter can be configured according to the application scenario of the management controller. In application scenarios requiring rapid response, a larger attenuation parameter can be set to allow the impact of historical anomalies to decay quickly. In application scenarios requiring long-term tracking, a smaller attenuation parameter can be set to allow the impact of historical anomalies to persist for a longer period.

[0096] By employing the technical solution of the above embodiments, the first security processor determines the attenuation coefficient based on the duration of the abnormal event, and calculates the anomaly level by weighted summation of the attenuation coefficient and severity information. Since the attenuation coefficient is negatively correlated with the duration, recently occurring abnormal events have a higher weight in the anomaly level calculation, while the impact of earlier occurring abnormal events gradually decreases over time. This method can more accurately reflect the current security status of the system and avoid excessive influence of historical abnormal events on the assessment of the current security status.

[0097] The following describes the process by which the second security processor verifies the operating status of the first security processor.

[0098] As an optional embodiment, the second security processor 30 can also be used to determine the target severity information of at least one target anomaly in the monitoring report based on the event type of at least one target anomaly in the monitoring report.

[0099] The second security processor 30 can compare the target severity information of at least one target abnormal event with the severity information of the corresponding abnormal event in the monitoring report to obtain the data verification result of the monitoring report.

[0100] The second security processor 30 can obtain the operating status parameters of the first security processor 20 from the monitoring report. The operating status parameters include at least one of firmware metric values, operating status register values, and abnormal event identifiers.

[0101] The second security processor 30 can compare the operating status parameters with preset status parameters to obtain the status verification results of the monitoring report.

[0102] The second security processor 30 determines that the inspection result is passed only when both the data inspection result and the status inspection result are passed.

[0103] For example, the inspection of the first security processor 20 by the second security processor 30 can be divided into two dimensions: data inspection and status inspection. Data inspection is used to verify whether the monitoring data provided by the first security processor 20 is accurate and reliable. Status inspection is used to verify whether the first security processor 20 itself is in normal working condition.

[0104] In one implementation, the second security processor 30 can receive monitoring reports via an inter-core private communication interface, and identify and extract the event type of at least one target anomaly event. The second security processor 30 queries a locally stored severity mapping table based on the event type to obtain the target severity information corresponding to each target anomaly event in the at least one target anomaly event, and compares it with the severity information of the corresponding anomaly events recorded in the monitoring report. If the target severity information of at least one target anomaly event is equal to the corresponding severity information, the second security processor 30 determines that the data verification result characterization verification has passed.

[0105] It should be noted that the failure of the data verification result characterization test may indicate that the first security processor 20 made a calculation error when determining the severity information of the abnormal event, or that the severity mapping table has been tampered with.

[0106] In one implementation, the second security processor 30 can extract the operating status parameters of the first security processor 20 from the monitoring report and read preset status parameters from the local security memory for comparison.

[0107] For example, the firmware metric can be the cryptographic hash of the second type of secure firmware image currently running on the first security processor 20. The second security processor 30 can compare the firmware metric with a pre-stored trusted firmware image baseline hash to verify whether the firmware image has been tampered with.

[0108] For example, the runtime status register value can be the current value of a critical status register of the first security processor 20. The runtime status register may include a program counter, a stack pointer, a status flag register, etc. The second security processor 30 can check whether the program counter value is within the legal code segment address range and whether the status flag register displays an abnormal interruption or error status.

[0109] For example, the abnormal event identifier can be a record identifier of an internal abnormal event encountered by the first security processor 20 during the execution of a monitoring task, and may include an illegal access attempt identifier, a watchdog timeout identifier, an internal error interruption identifier, etc.

[0110] It should be noted that when all comparison results of the operating status parameters are normal, the second security processor 30 determines that the status verification result characterization test has passed. When at least one operating status parameter shows an abnormal comparison result, the second security processor 30 determines that the status verification result characterization test has failed.

[0111] If both the data verification result characterization test and the state verification result characterization test pass, the second security processor 30 determines that the verification result is passed. If either the data verification result characterization test or the state verification result characterization test fails, the second security processor 30 determines that the verification result is failed.

[0112] By employing the technical solution described in the above embodiments, the second security processor verifies the monitoring report of the first security processor through two dimensions: data verification and status verification. Data verification involves recalculating the severity information of at least one target anomaly and comparing it with the severity information of the corresponding anomaly in the monitoring report. This process can detect whether there are calculation errors or data tampering in the monitoring data provided by the first security processor. Status verification involves acquiring and analyzing the first security processor's firmware metrics, runtime register values, and anomaly event identifiers, etc., to determine whether the first security processor itself is functioning normally. When both data verification and status verification pass, the second security processor can determine that the monitoring report is credible. This dual verification method effectively prevents the risk of the first security processor providing false monitoring reports after being compromised independently.

[0113] The following sections describe the handling process of abnormal events by the first security processor and the second security processor, respectively.

[0114] Based on the above embodiments, as an optional embodiment, when the anomaly level corresponding to the monitoring report exceeds the first warning threshold, the first security processor 20 can also be used to generate maintenance instructions based on the abnormal events in the monitoring report.

[0115] The main processor 10 can also be used to receive maintenance instructions and handle corresponding abnormal events using non-interrupt maintenance.

[0116] For example, non-disruptive maintenance processing can handle abnormal events through software policy adjustments, resource restrictions, logging, etc., without interrupting the normal operation of the main processor 10. Non-disruptive maintenance processing is suitable for abnormal events with relatively low abnormality levels that do not pose a serious threat to system security.

[0117] In one implementation, after generating a monitoring report, the first security processor 20 compares the anomaly level corresponding to the monitoring report with a first warning threshold. When the anomaly level exceeds the first warning threshold but does not exceed a second warning threshold, the first security processor 20 determines that the current anomaly is a minor anomaly, which can be processed by the main processor 10 at the software level. The first security processor 20 generates maintenance instructions based on the anomaly event information recorded in the monitoring report.

[0118] After receiving a maintenance instruction, the main processor 10 can parse the abnormal event information and suggested handling measures in the maintenance instruction and take corresponding maintenance operations.

[0119] In one implementation, the main processor 10 can impose resource restrictions on suspicious processes corresponding to maintenance instructions. For example, the main operating system can reduce the CPU usage priority of suspicious processes, limit the memory allocation of suspicious processes, or restrict the network access permissions of suspicious processes.

[0120] In another implementation, the main processor 10 can enhance monitoring of specific system resources. For example, when the exception event corresponding to a maintenance instruction is an illegal memory access attempt, the main operating system can enable stricter access control policies for the relevant memory region, or increase the logging frequency of access operations to that memory region.

[0121] By adopting the technical solution of the above embodiments, the first security processor generates maintenance instructions for minor abnormal events whose anomaly level in the monitoring report exceeds the first warning threshold. The main processor then performs non-interrupted maintenance processing on the corresponding abnormal events according to the maintenance instructions. Since non-interrupted maintenance processing is executed in the background and does not forcibly terminate running tasks or services, it can maintain the normal operation of the management controller while handling abnormal events in a timely manner, avoiding the system availability degradation problem that may result from using interrupted processing for all abnormal events.

[0122] Based on the above embodiments, as an optional embodiment, when the anomaly level corresponding to the monitoring report exceeds the second warning threshold, or the inspection result is an inspection failure, the second security processor 30 can also be used to generate an interrupt instruction based on the abnormal event in the monitoring report.

[0123] The main processor 10 can also be used to receive interrupt instructions, terminate the running task corresponding to the abnormal event, and send a warning prompt to the user.

[0124] For example, interrupt handling can refer to emergency handling of serious abnormal events by forcibly terminating suspicious tasks, isolating affected components, or triggering system alarms. Interruption handling is suitable for abnormal events with a high anomaly level that may pose a serious threat to system security.

[0125] In one feasible implementation, the second security processor 30 can determine whether interruption processing is required after verifying the monitoring report. When the anomaly level corresponding to the monitoring report exceeds the second warning threshold, the second security processor 30 determines that the current abnormal event is a serious anomaly and requires interruption processing. When the verification result is a failure, it indicates that the first security processor 20 may have been compromised or malfunctioned, and the second security processor 30 also needs to perform interruption processing. The second security processor 30 generates an interrupt command based on the abnormal event information recorded in the monitoring report.

[0126] For example, the interrupt instruction may include information such as the task identifier that needs to be terminated, the process identifier that needs to be isolated, and the content of the warning message. The interrupt instruction generated by the second security processor 30 has the highest priority, and the main processor 10 should execute it immediately after receiving the interrupt instruction.

[0127] In one feasible implementation, after receiving an interrupt instruction, the main processor 10 can parse the task identifier or process identifier in the interrupt instruction and forcibly terminate the running task corresponding to the abnormal event. The main operating system can send a termination signal to the task or process, reclaim the system resources it occupies, and record the relevant information of the task or process in the security event log.

[0128] For example, early warning prompts can use different alarm levels. For severe anomalies where the anomaly level exceeds the second early warning threshold, the highest alarm level can be used. For cases where the verification result is a failure, the early warning prompt can clearly indicate that the security monitoring component may have been compromised, and recommend that the user immediately conduct manual intervention for investigation.

[0129] It should be noted that interruption processing will impact the normal operation of the system. A terminated task will be unable to continue execution, and other services that depend on that task may be affected. Therefore, interruption processing will only be triggered when the anomaly level exceeds the second warning threshold or when the security monitoring component itself malfunctions, ensuring that the strength of the handling measures matches the threat level.

[0130] Alternatively, the main processor 10 may attempt to start a standby task or switch to safe mode after terminating the running task.

[0131] By employing the technical solution of the above embodiments, the second security processor generates an interrupt instruction for serious abnormal events where the anomaly level corresponding to the monitoring report exceeds the second warning threshold, or when the verification result is a failure. The main processor then executes interrupt-driven processing based on the interrupt instruction. Because the second security processor is isolated from external environment access, even if the first security processor has been compromised or malfunctions, the second security processor can still independently determine the anomaly level and generate an interrupt instruction, ensuring that serious security threats are dealt with promptly. Interruption-driven processing, by forcibly terminating suspicious tasks and sending warning prompts to the user, can quickly block the potential security impact of serious abnormal events.

[0132] To ensure accurate decision-making in handling serious abnormal events and avoid unnecessary system interruptions due to misjudgment, as an optional embodiment based on the above embodiments, when the abnormality level corresponding to the monitoring report exceeds the second warning threshold, the second security processor 30 can also be used to determine the target severity information of each abnormal event among several abnormal events in the monitoring report.

[0133] The second security processor 30 can compare the target severity information of each abnormal event with the severity information of the corresponding abnormal event in the monitoring report to obtain the comparison result.

[0134] When the comparison results indicate that the target severity information of each abnormal event is the same as the corresponding severity information, the second security processor 30 can generate an interrupt instruction based on the abnormal event in the monitoring report.

[0135] For example, when the anomaly level exceeds the second warning threshold, it indicates that a serious anomaly event exists, requiring interruption processing. Since interruption processing forcibly terminates running tasks, significantly impacting the normal operation of the system, the second security processor 30 needs to fully review all anomalies in the monitoring report before generating the interrupt instruction to ensure data accuracy.

[0136] It should be noted that the comprehensive review method described above differs from the data verification method in the aforementioned embodiments. In the aforementioned embodiments, when the second security processor 30 performs data verification on the monitoring report, it can use a sampling verification method, that is, select at least one target abnormal event from several abnormal events in the monitoring report for verification. However, in the current embodiment, since the abnormality level has exceeded the second warning threshold, generating an interrupt command will have a significant impact on the system. Therefore, the second security processor 30 needs to review all abnormal events in the monitoring report one by one.

[0137] In one feasible implementation, the second security processor 30, upon receiving a monitoring report, can determine whether the anomaly level corresponding to the monitoring report exceeds a second warning threshold. When the anomaly level exceeds the second warning threshold, the second security processor 30 initiates a comprehensive review process, extracts a list of several abnormal events from the monitoring report, and iterates through the list of abnormal events to read the event type of each abnormal event.

[0138] In one feasible implementation, the second security processor 30 can query the corresponding target severity information from the locally stored severity mapping table according to the event type of each abnormal event, and compare the target severity information of each abnormal event with the severity information of the corresponding abnormal event record in the monitoring report one by one.

[0139] It should be noted that when the comparison results are inconsistent, it indicates that the severity information of at least one abnormal event in the monitoring report is incorrectly calculated or has been tampered with. In this case, the second security processor 30 may consider the data in the monitoring report unreliable, refuse to generate an interrupt instruction, and instead generate a fault instruction for the first security processor 20, requiring the first security processor 20 to be restarted or reinitialized.

[0140] By adopting the technical solution of the above embodiments, when the anomaly level corresponding to the monitoring report exceeds the second warning threshold, the second security processor performs a comprehensive review of all abnormal events in the monitoring report to ensure that the severity information of each abnormal event is independently verified. Since interrupted processing can significantly impact the normal operation of the system, comprehensive review can effectively avoid misjudgments caused by individual data errors or partial functional abnormalities of the first security processor, ensuring the accuracy and reliability of the interrupt instruction generation decision. The comprehensive review mechanism complements the sampling inspection method in the aforementioned embodiments. Sampling inspection improves efficiency in minor anomaly scenarios, while comprehensive review ensures accuracy in severe anomaly scenarios, achieving a balance between inspection efficiency and decision reliability.

[0141] Please refer to Figure 2 , Figure 2 This is a second schematic diagram of the management controller according to an embodiment of this application.

[0142] like Figure 2 As shown, the management controller 100 may also include several subprocessors 60 and neural network processors 70.

[0143] For example, the main processor 10 may include a plurality of main processors, such as main processor 1, main processor 2 to main processor n, where n is an integer greater than or equal to 1. The plurality of main processors are used to handle the main management tasks of the management controller 100.

[0144] For example, the subprocessor 60 may include several subprocessors, such as subprocessor 1, subprocessor 2 to subprocessor n, where n is an integer greater than or equal to 1. Different subprocessors can perform different specialized tasks, such as sensor data acquisition, fan control, power management, etc.

[0145] Several firmware images required by the main operating system running on the main processor 10 are stored in the firmware storage unit. The firmware storage unit includes main memory 40 and backup main memory 50. Main memory 40 is used to store the firmware image currently in operation; backup main memory 50 is used to store at least one of the backup firmware image and the firmware image to be upgraded.

[0146] For example, the neural network processor 70 can be used to perform neural network-based intelligent analysis tasks. For instance, the neural network processor 70 can run artificial intelligence algorithms such as anomaly detection models and fault prediction models to intelligently analyze system operation data. The neural network processor 70 runs a neural network inference engine and microcode to achieve efficient neural network inference computation.

[0147] In one feasible implementation, both the main memory 40 and the spare main memory 50 include several storage regions. The identifiers of the several storage regions correspond one-to-one with different types of processors.

[0148] For example, the main memory 40 may include a main processor firmware image storage area, a secondary processor firmware image storage area, and a neural network processor firmware image storage area. The main processor firmware image storage area is used to store the firmware image currently running on the main processor 10. The secondary processor firmware image storage area is used to store the secondary operating system firmware image currently running on the secondary processor 60. The neural network processor firmware image storage area is used to store the neural network inference engine firmware image and microcode firmware image currently running on the neural network processor 70.

[0149] For example, the storage area division of the backup main memory 50 can be consistent with that of the main memory 40. The backup main memory 50 also includes a main processor firmware image storage area, a secondary processor firmware image storage area, and a neural network processor firmware image storage area. Each storage area of ​​the backup main memory 50 is used to store at least one of the backup firmware image and the firmware image to be upgraded for the corresponding processor.

[0150] It should be noted that by dividing the main memory 40 and the backup main memory 50 into storage areas corresponding to different types of processors, unified management and classified storage of firmware images for multiple types of processors can be achieved. When the firmware image of a certain processor needs to be upgraded, the first security processor 20 only needs to store the new version firmware image in the corresponding storage area of ​​the backup main memory 50, and switch the boot selection flag during the next restart to complete the firmware image upgrade for that processor without affecting the normal operation of other processors.

[0151] By adopting the technical solution of the above embodiments, the management controller, through the introduction of several main processors, several sub-processors, and a neural network processor, achieves parallel processing, division of labor and cooperation, and intelligent enhancement of management tasks. The main memory stores the running firmware image, while the backup main memory stores at least one of the backup firmware image and the firmware image to be upgraded. The main memory and backup main memory are divided into several storage areas, and the identifiers of each storage area correspond one-to-one with different types of processors, achieving unified management and classified storage of firmware images for multiple types of processors. The first security processor stores different types of firmware images in the corresponding identified storage areas according to the firmware image type information. Each processor loads its own firmware image from the corresponding storage area according to the boot selection identifier, supporting firmware image upgrades for multiple types of processors and improving the flexibility and scalability of the management controller's firmware image upgrades.

[0152] Based on the above embodiments, as an optional embodiment, please refer to... Figure 3 , Figure 3 This is an interactive schematic diagram of an abnormal event handling method in a management controller provided in an embodiment of this application.

[0153] like Figure 3 As shown, the management controller may also include several sub-processors, which are used to perform auxiliary computing tasks. In the event of a serious abnormal event during the operation of a sub-processor, to ensure the continuity of management functions and avoid service interruption due to direct task termination, a task switching method can be used to migrate the abnormal task from the first sub-processor to a second sub-processor with the same processing capabilities for execution. This process may specifically include the following steps.

[0154] Step S301: The first subprocessor runs the first auxiliary computing task.

[0155] In step S302, the second subprocessor runs the second auxiliary computing task.

[0156] It should be noted that the execution order of steps S301 and S302 is not important. The first and second subprocessors among the several subprocessors can run their respective auxiliary computing tasks simultaneously.

[0157] In step S303, the first security processor monitors abnormal events generated during the operation of several sub-processors and generates a monitoring report for the sub-processors.

[0158] In one implementation, the first security processor 20 can monitor the operation of several sub-processors in real time. The first security processor 20 monitors the operational status of each sub-processor, including system calls, process behavior, and resource access. When the first security processor 20 detects an abnormal event during the operation of a sub-processor, it records relevant information about the abnormal event. The first security processor 20 generates a monitoring report for the sub-processors based on the detected abnormal events.

[0159] In step S304, the first security processor 20 outputs the monitoring report of the sub-processor to the second security processor 30.

[0160] In step S305, when the anomaly level in the monitoring report of the sub-processor is greater than the second warning threshold, the second security processor generates a switching instruction based on the anomaly event in the monitoring report of the sub-processor.

[0161] In one implementation, the second security processor 30, upon receiving a monitoring report from the subprocessor, can obtain the anomaly level represented by the monitoring report. The second security processor 30 compares this anomaly level with a second warning threshold. If the anomaly level in the subprocessor's monitoring report is greater than the second warning threshold, the second security processor 30 determines that the current anomaly is a serious anomaly, requiring a task switch to be performed on the subprocessor running the anomaly task.

[0162] In one implementation, the second security processor 30 generates a switching instruction based on abnormal events reported in the monitoring report of the sub-processor. The switching instruction may include information such as the identifier of the sub-processor whose task needs to be terminated, the identifier of the sub-processor whose task needs to be taken over, and the task identifier.

[0163] For example, the second security processor 30 can select a second subprocessor with the same processing capabilities as the first subprocessor from among several subprocessors as the target processor for task takeover. The second security processor 30 specifies in the switching instruction that the first subprocessor terminates the currently running abnormal task and that the second subprocessor takes over the execution of the task.

[0164] In step S306, the second security processor 30 sends a switching instruction to the first and second sub-processors.

[0165] In step S307, the first secondary processor receives a switching instruction and terminates the running task corresponding to the abnormal event.

[0166] In one implementation, upon receiving a switching instruction, the first secondary processor responds to it. The first secondary processor parses the task identifier in the switching instruction to determine the running task corresponding to the abnormal event. The first secondary processor locates the running task through its corresponding secondary operating system. The secondary operating system corresponding to the first secondary processor sends a termination signal to the running task, terminating its execution. The secondary operating system corresponding to the first secondary processor reclaims the system resources occupied by the running task, including memory space and network connections.

[0167] In step S308, the second subprocessor receives the switching instruction and executes the running task corresponding to the abnormal event.

[0168] In one implementation, a second subprocessor among several subprocessors responds to a switching instruction upon receiving it. The second subprocessor has the same processing capabilities as the first subprocessor. The second subprocessor parses the task identifier in the switching instruction to determine the running task corresponding to the abnormal event. The second subprocessor creates a process for the running task through its corresponding sub-operating system. The sub-operating system corresponding to the second subprocessor allocates necessary system resources for the running task. The sub-operating system corresponding to the second subprocessor starts the execution of the running task, taking over the management functions originally performed by the first subprocessor.

[0169] It should be noted that the execution order of steps S307 and S308 is not important. The first and second subprocessors can execute their respective operations simultaneously after receiving the switching instruction. The termination of the running task corresponding to the abnormal event by the first subprocessor and the execution of the running task by the second subprocessor can be performed in parallel.

[0170] It should be noted that, since the second subprocessor has the same processing power as the first subprocessor, the second subprocessor can execute the tasks that the first subprocessor was originally executing, ensuring the continuity of function after task switching.

[0171] Optionally, the second security processor 30 can simultaneously send the context information of the running task when generating the switching instruction. The context information of the running task may include the task's execution parameters, processed data, and the queue of tasks to be processed. The second sub-processor can restore the execution state of the running task based on the context information to achieve task switching.

[0172] By employing the technical solution of the above embodiments, the first security processor monitors abnormal events generated in the secondary operating system running on several secondary processors and outputs monitoring reports for the secondary processors. When the abnormality level in the monitoring report of a secondary processor exceeds a second warning threshold, the second security processor generates a switching instruction. The first secondary processor receives the switching instruction and terminates the running task corresponding to the abnormal event, while the second secondary processor receives the switching instruction and takes over the task. Since the second secondary processor has the same processing power as the first secondary processor, it can quickly restore service when a serious abnormality occurs on a secondary processor, avoiding interruption of management functions.

[0173] Figure 4 This is a schematic diagram of a secure storage device provided in an embodiment of this application.

[0174] like Figure 4 As shown, based on the above embodiments, as an optional embodiment, the second security processor 30 runs the first security firmware image; the first security processor 20 runs the second security firmware image. The first security firmware image and the second security firmware image are stored in different storage areas of the security memory 80. The security memory 80 is the memory in the firmware storage unit 200.

[0175] For example, the secure storage 80 can be a separate storage area within the management controller 100 specifically for storing secure firmware images. The secure storage 80 is physically or logically isolated from the firmware storage unit to ensure the storage security of the secure firmware images.

[0176] For example, the first secure firmware image can be a firmware image program executed by the second secure processor 30. The first secure firmware image may include, but is not limited to, functional modules such as secure boot code, hardware root of trust verification module, and cryptographic algorithm library. The second secure firmware image can be a firmware image program executed by the first secure processor 20. The second secure firmware image may include, but is not limited to, functional modules such as firmware image integrity verification module, dynamic measurement calculation engine, abnormal event monitoring module, and monitoring report generation module.

[0177] In one feasible implementation, the different storage areas of the secure memory 80 can be divided into a first secure firmware image storage area and a second secure firmware image storage area. The first secure firmware image storage area is used to store the first secure firmware image running by the second secure processor 30. The second secure firmware image storage area is used to store the second secure firmware image running by the first secure processor 20.

[0178] In one feasible implementation, the second security processor 30 can load and run the first security firmware image from the first security firmware image storage area after power-on reset. The first security processor 20 can load and run the second security firmware image from the second security firmware image storage area after receiving a boot command from the second security processor 30.

[0179] Optionally, the secure storage 80 may include a primary secure storage space and a backup secure storage space. The primary secure storage space is used to store the currently running first and second secure firmware images. The backup secure storage space is used to store the secure firmware image to be upgraded or a backup copy of the secure firmware image. When the secure firmware image needs to be upgraded, the new version of the secure firmware image is first written to the backup secure storage space, verified by the second secure processor 30, and then switched to the backup secure storage space for startup, thereby achieving a secure upgrade of the secure firmware image.

[0180] It should be noted that the first secure firmware image storage area can be implemented using physical read-only memory to ensure that the trusted root firmware image of the second secure processor 30 cannot be tampered with. The second secure firmware image storage area can be implemented using programmable non-volatile memory with write protection, supporting version upgrades of the second secure firmware image when necessary.

[0181] By adopting the technical solution of the above embodiments, the first secure firmware image and the second secure firmware image are stored in different storage areas within the secure memory 80, achieving isolated storage and independent management of the two secure processor firmware images. The first secure firmware image uses physical read-only storage to ensure the immutability of the root of trust firmware image. The second secure firmware image supports secure upgrades, meeting the needs of dynamic updates to security policies. The secure memory is isolated from the firmware storage unit, further enhancing the storage security of the secure firmware image and avoiding the risk of tampering with it.

[0182] The following describes the safe startup process of the management controller 100.

[0183] Based on the above embodiments, as an optional embodiment, the second security processor 30 can also be used to retrieve and run the second security firmware image from the security memory 80 when the management controller 100 is powered on.

[0184] The second security processor 30 restricts unauthorized processors from accessing the security memory 80.

[0185] The second security processor 30 retrieves the first security firmware image from the security memory 80.

[0186] The second security processor 30 performs firmware verification on the first security firmware image.

[0187] When the firmware verification result is qualified, the second security processor 30 sends a startup command to the first security processor 20.

[0188] The first security processor 20 can also be used to retrieve and run the first security firmware image from the security memory 80 after receiving a boot command.

[0189] In one feasible implementation, when the management controller 100 is powered on, the second security processor 30, as the hardware root of trust, is the first to start. The second security processor 30 reads the second security firmware image from the security memory 80 and loads the second security firmware image into its own internal memory for execution. The second security firmware image initializes the hardware resources and security configuration of the second security processor 30, putting the second security processor 30 into a ready state.

[0190] In one feasible implementation, the second security processor 30 can restrict unauthorized processors' access to the security memory 80 by configuring its access control register. The second security processor 30 sets the access permissions for the security memory 80 to allow only the first security processor 20 and the second security processor 30 to access it. Access requests from unauthorized processors such as the main processor 10, the sub-processor 60, and the neural network processor 70 are denied.

[0191] In one implementation, the second security processor 30 may configure a list of authorized processor identifiers in the access control register. Upon receiving an access request, the security memory 80 extracts the processor identifier carried in the access request and matches it against the list of authorized processor identifiers. The security memory 80 only responds to the access request if a match is found.

[0192] In one feasible implementation, the second security processor 30 can retrieve the first secure firmware image from the second secure firmware image storage area. The second security processor 30 verifies the first secure firmware image to confirm its integrity and authenticity. The second security processor 30 calculates the hash value of the first secure firmware image and compares the calculated hash value with a pre-stored base hash value. The second security processor 30 uses a built-in root public key to verify the digital signature of the first secure firmware image.

[0193] If the hash value match and the digital signature verification passes, the second security processor 30 determines that the firmware image verification result indicates successful verification. If the hash value match does not match or the digital signature verification fails, the second security processor 30 determines that the firmware image verification result indicates failed verification.

[0194] If the firmware image verification result indicates that the verification is successful, the second security processor 30 generates a boot command and sends it to the first security processor 20. The boot command can be transmitted to the first security processor 20 via a dedicated inter-core communication interface or hardware signal line. The boot command may include information such as the load address of the first secure firmware image and the verification result.

[0195] In one feasible implementation, after receiving a boot command, the first security processor 20 retrieves a first security firmware image from the second security firmware image storage area. The first security processor 20 loads the first security firmware image into its internal memory. After loading, the first security firmware image executes its initialization program. The first security firmware image initializes the hardware resources of the first security processor 20, configures monitoring policies and security rules, enabling the first security processor 20 to monitor both the main operating system and the secondary operating system.

[0196] It should be noted that if the firmware image verification result indicates verification failure, the second security processor 30 does not send a boot command to the first security processor 20. The first security processor 20 remains in a reset state and cannot load or run the first secure firmware image. This design prevents tampered firmware images from running on the first security processor 20, thus avoiding damage to the security monitoring function.

[0197] Optionally, after completing the boot control of the first security processor 20, the second security processor 30 can further control the boot of the main processor 10. The second security processor 30 obtains the bootloader for the main processor 10 from the firmware storage unit 200. The second security processor 30 performs integrity verification and signature verification on the bootloader. If the verification passes, the second security processor 30 sends a boot command to the main processor 10, causing the main processor 10 to load and run the main operating system. Through this method, a fully trusted boot chain is achieved from the second security processor 30 to the first security processor 20 and then to the main processor 10.

[0198] By adopting the technical solution of the above embodiments, the second security processor, as the hardware root of trust, boots first and restricts unauthorized processors' access to the secure memory by configuring access control registers. The second security processor verifies the first secure firmware image and only sends a boot command to the first security processor after successful verification. This boot process ensures that the firmware image running on the first security processor has not been tampered with, establishes a hierarchical trust transfer method from the second security processor to the first security processor, and improves the boot security of the management controller.

[0199] To ensure that the firmware image running on the main processor has not been tampered with and meets security requirements, an optional embodiment is provided based on the above embodiments.

[0200] When the management controller is powered on, the first security processor 20 can also be used to obtain several firmware images and firmware image information of several firmware images stored in the firmware storage unit.

[0201] The first security processor 20 can perform integrity verification on several firmware images and security verification on the firmware image information of several firmware images.

[0202] The first security processor 20 outputs the run instruction only when both the integrity verification and security verification results are passed.

[0203] The main processor 10 is also used to receive execution instructions and run several firmware images.

[0204] In one implementation, the first security processor 20 can retrieve several firmware images from the main memory 40 of the firmware storage unit 200 after startup. These firmware images may include the bootloader firmware image of the management controller 100, the main operating system firmware image, application firmware images, etc. The first security processor 20 can simultaneously retrieve firmware image information corresponding to each firmware image. The firmware image information may include security attributes such as digital signature, hash value, version number, release time, permission configuration, and dependencies.

[0205] In one implementation, the first security processor 20 can perform integrity verification on several firmware images. The first security processor 20 can calculate a hash value for each firmware image using a hash algorithm. The first security processor 20 can extract a pre-stored base hash value from the firmware image information. The first security processor 20 can then compare the calculated hash value bit-by-bit with the base hash value.

[0206] If the hash values ​​of all firmware images match, the first security processor 20 can determine that the first verification result indicates successful verification. If the hash values ​​of any firmware image do not match, the first security processor 20 can determine that the first verification result indicates failed verification and record the identifier of the failed firmware image.

[0207] In one implementation, the first security processor 20 can verify the firmware image information of several firmware images. The first security processor 20 can use a pre-stored public key to verify the digital signature in the firmware image information to confirm the authenticity of the firmware image information.

[0208] The first security processor 20 can check whether the firmware image version number is within the allowed range to prevent the execution of firmware images with known vulnerabilities due to outdated versions. The first security processor 20 can also check the permission configuration of the firmware image according to security policies to confirm whether the access permissions requested by the firmware image are reasonable. Furthermore, the first security processor 20 can analyze the dependencies between firmware images to confirm whether the dependent firmware images are complete and their versions match. If all the above verification items pass, the first security processor 20 can determine that the second verification result indicates successful verification.

[0209] If both the first and second verification results indicate that the verification is successful, the first security processor 20 can generate a run instruction. The run instruction may include a list of allowed firmware images, the firmware image load address, and run permissions. The first security processor 20 can send the run instruction to the main processor 10 via the inter-core communication interface.

[0210] Upon receiving a run command, the main processor 10 can parse the firmware image list within the run command. The main processor 10 can load the firmware images sequentially according to the boot order. The main processor 10 can first load the bootloader firmware image, and then load the main operating system firmware image through the bootloader. After the main operating system has booted, the main processor 10 can load and run the application firmware images.

[0211] By adopting the technical solution of the above embodiments, the first security processor performs integrity verification and static analysis on the firmware image of the main processor during the startup phase. It not only verifies the integrity of the firmware image content, but also conducts a comprehensive check on the security attributes of the firmware image such as version, permissions, and dependencies. Only after both verifications are passed is the main processor allowed to run the firmware image, thus ensuring the security of the main processor's operating environment.

[0212] To accurately determine whether a firmware image has been tampered with, as an optional embodiment based on the above embodiments, the first security processor 20 can also be used to calculate the hash value of each firmware image among several firmware images.

[0213] The first security processor 20 can compare the hash value of each firmware image with a preset baseline value.

[0214] When the hash value of each firmware image is consistent with the preset baseline value, the first security processor 20 determines that the integrity verification result is successful.

[0215] In one feasible implementation, the first security processor 20 can sequentially read the data content of each firmware image, perform hash algorithm calculations on the firmware image data, and obtain the hash value corresponding to each firmware image. A preset baseline value can be stored in the secure memory 80. The first security processor 20 can retrieve the preset baseline value from the secure memory 80 and compare the calculated hash value with the preset baseline value one by one.

[0216] If the hash values ​​of all firmware images match the corresponding preset baseline values, the first security processor 20 can determine that the integrity verification result is successful, indicating that the contents of several firmware images are complete and have not been modified. If the hash value of any firmware image does not match the preset baseline value, the first security processor 20 can determine that the integrity verification result is unsuccessful.

[0217] It should be noted that the preset baseline value can be calculated and provided by the firmware image publisher when the firmware image is generated, and stored in the secure storage 80 when the firmware image is deployed.

[0218] By adopting the technical solution of the above embodiments, by calculating the hash value of the firmware image and comparing it with a preset benchmark value, any changes in the firmware image content can be accurately identified, ensuring the reliability of firmware image integrity verification.

[0219] To comprehensively evaluate the security attributes of firmware images, in one implementation, the first security processor 20 can also be used to verify the digital signatures of each firmware image among several firmware images, obtaining signature verification results.

[0220] In another implementation, the first security processor 20 can compare the version identifier of each firmware image with a preset version identifier to obtain the firmware image version verification result.

[0221] In another implementation, the first security processor 20 can compare the loading address of each firmware image with a preset address range to obtain the address verification result.

[0222] In another implementation, the first security processor 20 can acquire the code features of each firmware image and analyze the code features of each firmware image to obtain code verification results.

[0223] The first security processor 20 determines that the security verification result is passed only when the signature verification result indicates that the digital signature of each firmware image is valid, the firmware image version verification result indicates that the version identifier of each firmware image matches the preset version identifier, the address verification result indicates that the loading address of each firmware image is within the preset address range, and the code verification result indicates that the code structure characteristics of each firmware image do not contain malicious code.

[0224] In one feasible implementation, the first security processor 20 can use a pre-stored public key to verify the digital signatures of each firmware image. The first security processor 20 can check whether the signature was generated by a trusted publisher and whether the signature certificate is valid. If the digital signatures of each firmware image are valid, the first security processor 20 can determine that the signature verification result indicates that the digital signatures of each firmware image are valid.

[0225] The first security processor 20 can extract the version identifier of each firmware image from the firmware image information and compare it with the preset version identifier stored in the security storage 80. The preset version identifier may include a list of allowed versions or a minimum version requirement. If the version identifiers of each firmware image meet the requirements, the first security processor 20 can determine that the firmware image version verification result indicates that the version identifier of each firmware image matches the preset version identifier.

[0226] The first security processor 20 can obtain the load address of each firmware image from the firmware image information and determine whether the load address falls within a preset address range. The preset address range can be a legal storage area allocated for the firmware image. If the load addresses of each firmware image are all within the preset address range, the first security processor 20 can determine that the address verification result indicates that the load address of each firmware image is within the preset address range.

[0227] The first security processor 20 can perform static analysis on the code of each firmware image. The first security processor 20 can extract code features such as function call relationships, system call types, and file operation behaviors from the firmware images. The first security processor 20 can compare these code features with a known malware signature database. If the code features of any firmware image do not match any malware signatures, the first security processor 20 can determine that the code verification results indicate that the code structure features of each firmware image do not contain malicious code.

[0228] If all four verification results are passed, the first security processor 20 can determine that the security verification result is passed, indicating that the security attributes of each firmware image meet the requirements.

[0229] It should be noted that if any verification result indicates verification failure, the first security processor 20 can determine that the security verification result is verification failure and record the specific reason for failure and the corresponding firmware image identifier.

[0230] By adopting the technical solutions of the above embodiments, and by performing multi-dimensional verification on the digital signature, version, loading address, and code characteristics of the firmware image, the security attributes of the firmware image can be comprehensively evaluated, and firmware images that have been tampered with, have abnormal versions, out-of-bounds addresses, or contain malicious code can be effectively identified.

[0231] Figure 5 This is a schematic diagram of a server provided in an embodiment of this application.

[0232] like Figure 5 As shown, server 500 may include a management controller 100, a firmware storage unit 200, and a secure storage unit 80. The management controller 100 may include a main processor 10, a first secure processor 20, and a second secure processor 30. The firmware storage unit 200 may include a main storage unit 40, a backup main storage unit 50, and a secure storage unit 80. The secure storage unit may include a main secure storage space and a backup secure storage space.

[0233] In server 500, main processor 10 can establish communication connections with first security processor 20 and firmware storage unit 200 via a communication bus. First security processor 20 can establish communication connections with main processor 10, second security processor 30, firmware storage unit 200, and security memory 80 via the communication bus. Second security processor 30 can establish communication connections with first security processor 20 and security memory 80 via the communication bus.

[0234] In practical applications, the management controller 100 can serve as the management subsystem of the server 500. The management controller 100 is responsible for monitoring the hardware status of the server 500, performing firmware image upgrade operations, and handling remote management requests.

[0235] The specific structure and working process of the management controller 100 in the server 500 can be referred to the above embodiment, and will not be elaborated further here.

[0236] Figure 6 This is one of the flowcharts illustrating a security monitoring method for a management controller provided in an embodiment of this application.

[0237] This application also discloses a security monitoring method for a management controller, which is applied to the aforementioned management controller, including a main processor, a first security processor, and a second security processor.

[0238] like Figure 6 As shown, the security monitoring method for the management controller may specifically include the following steps.

[0239] The S610 performs hardware management tasks for the management controller via the main processor.

[0240] The S620 monitors abnormal events generated during the operation of the main processor through the first security processor and outputs monitoring reports.

[0241] S630 uses the second security processor to check the working status of the first security processor based on the monitoring report and outputs the check results.

[0242] S640: When the anomaly level corresponding to the monitoring report exceeds the first warning threshold, the corresponding abnormal event is processed by the first security processor.

[0243] S650 When the anomaly level corresponding to the monitoring report exceeds the second warning threshold, or the inspection result is an inspection failure, the corresponding abnormal event is handled by the second security processor; wherein, the value of the second warning threshold is greater than the first warning threshold.

[0244] exist Figure 6 Based on this, please refer to Figure 7 , Figure 7 This is a second flowchart illustrating a security monitoring method for a management controller provided in an embodiment of this application.

[0245] like Figure 7 As shown, the security monitoring method for the management controller includes a startup phase, a verification phase, and an exception handling phase.

[0246] During the startup phase, in response to the power-on of the management controller, the second security processor preferentially retrieves and runs the second security firmware image from the secure memory to complete its own startup. The second security processor verifies the first security firmware image to ensure that it has not been tampered with. If the verification is successful, the second security processor sends a startup command to the first security processor, causing the first security processor to retrieve and run the first security firmware image, thereby establishing a hierarchical trust transfer relationship from the second security processor to the first security processor.

[0247] During the verification phase, the first security processor retrieves several firmware images and their information from the firmware storage unit, and performs integrity and security attribute verification on these images. If the verification passes, the first security processor sends a run command to the main processor, which then runs the firmware images, ensuring that the images run by the main processor have not been tampered with and meet security requirements.

[0248] During the anomaly handling phase, the first security processor continuously monitors anomalies generated during the main processor's operation and generates monitoring reports. The second security processor acquires these reports and verifies the execution information from the first security processor. Based on the anomaly level and the verification results, either the first or second security processor handles the anomaly accordingly, achieving a tiered response to anomalies.

[0249] The above process may specifically include the following steps.

[0250] S701, when the management controller is powered on, the second security processor retrieves the second security firmware image from the security memory.

[0251] S702, the second security processor runs the second security firmware image.

[0252] S703, the second security processor retrieves the first security firmware image from the security memory.

[0253] S704, the second security processor verifies the first security firmware image.

[0254] S705, if the verification is successful, the second security processor sends a startup command to the first security processor.

[0255] S706, the first security processor, in response to the boot command, retrieves the first security firmware image from the security memory.

[0256] S707, the first security processor runs the first security firmware image.

[0257] S708, the first security processor, acquires several firmware images and firmware image information.

[0258] S709, the first security processor verifies several firmware images.

[0259] If the verification is successful, the first security processor sends the execution command to the main processor.

[0260] The S711's main processor runs several firmware images.

[0261] S712, the first security processor, monitors abnormal events.

[0262] S713, the first security processor, generates monitoring reports based on abnormal events.

[0263] S714, the second security processor, acquires monitoring reports.

[0264] In the case of a low-level anomaly, the first security processor in the S715 handles the abnormal event.

[0265] S716, Second Security Processor Inspection and Monitoring Report.

[0266] The S717, the second security processor, handles abnormal events when the anomaly level is high or when monitoring reports anomalies.

[0267] The processes S610~S650 and S701~S717 described above can be referred to the working process of the management controller in the above embodiments, and will not be elaborated further here.

[0268] 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 firmware image upgrade embodiments described above.

[0269] 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 security monitoring method for a management controller.

[0270] 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.

[0271] 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 security monitoring method for a management controller.

[0272] 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 security monitoring method for a management controller.

[0273] Any of the components, modules, units, parts, methods, and operations described herein can be implemented using software, firmware images, hardware (e.g., fixed logic circuit systems), 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 described 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 a processor firmware image, 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.

[0274] 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.

[0275] The above provides a detailed description of the management controller and server 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 core ideas of this application. 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 management controller, characterized in that, include: The main processor, located inside the management controller, is used to execute the hardware management business of the management controller; The first security processor is communicatively connected to the main processor and is used to monitor abnormal events generated during the operation of the main processor and output monitoring reports. The second security processor prohibits external devices from initiating active access. It is communicatively connected to the first security processor and the main processor, and is used to check the working status of the first security processor based on the monitoring report and output the check result. The first security processor is also used to process the corresponding abnormal event when the anomaly level corresponding to the monitoring report exceeds the first warning threshold; The second security processor is also used to process the corresponding abnormal event when the anomaly level corresponding to the monitoring report exceeds the second warning threshold, or when the inspection result is an inspection failure; wherein, the value of the second warning threshold is greater than the first warning threshold; The second security processor is also used for: Based on the event type of at least one target anomaly event in the monitoring report, determine the target severity information of the at least one target anomaly event; The severity information of the at least one target abnormal event is compared with the severity information of the corresponding abnormal event in the monitoring report to obtain the data verification result of the monitoring report; The operating status parameters of the first security processor are obtained from the monitoring report; the operating status parameters include at least one of firmware metric values, operating status register values, and abnormal event identifiers; The operating status parameters are compared with preset status parameters to obtain the status verification result of the monitoring report; The inspection result is determined to be passed only if both the data inspection result and the status inspection result are passed.

2. The management controller according to claim 1, characterized in that, The first security processor is also used for: Monitor several abnormal events generated during the operation of the main processor; Based on the event types of the aforementioned abnormal events, determine the severity information of each of the aforementioned abnormal events; The severity information of the aforementioned abnormal events is weighted and summed to obtain the abnormality level of the aforementioned abnormal events; A monitoring report is output based on the aforementioned abnormal events and their levels.

3. The management controller according to claim 2, characterized in that, The first security processor is also used for: Obtain the duration of each of the aforementioned abnormal events; The attenuation coefficient of each abnormal event is determined based on its duration; the attenuation coefficient of each abnormal event is negatively correlated with its duration. The severity information of each abnormal event is weighted and summed with the corresponding attenuation coefficient to obtain the abnormality level of the several abnormal events.

4. The management controller according to claim 1, characterized in that, The first security processor is also used for: When the anomaly level corresponding to the monitoring report exceeds the first warning threshold, a maintenance instruction is generated based on the anomaly event in the monitoring report. The main processor is also used to receive the maintenance instructions and to handle the corresponding abnormal events using non-interrupt maintenance.

5. The management controller according to claim 1, characterized in that, The second security processor is also used for: When the anomaly level corresponding to the monitoring report exceeds the second warning threshold, or when the test result is a test failure, an interruption command is generated based on the anomaly event in the monitoring report. The main processor is also used to receive the interrupt instruction, terminate the running task corresponding to the abnormal event, and send a warning prompt to the user.

6. The management controller according to claim 5, characterized in that, The second security processor is also used for: When the anomaly level corresponding to the monitoring report exceeds the second warning threshold, the target severity information of each anomaly event among several anomalies in the monitoring report is determined. The target severity information of each abnormal event is compared with the severity information of the corresponding abnormal event in the monitoring report to obtain the comparison results; When the comparison result indicates that the target severity information of each abnormal event is the same as the corresponding severity information, an interruption command is generated based on the abnormal event in the monitoring report.

7. The management controller according to claim 5, characterized in that, Also includes: Several secondary processors are used to perform auxiliary computing tasks; The first security processor is also used to monitor abnormal events generated during the operation of the plurality of sub-processors and output monitoring reports of the sub-processors; The second security processor is also configured to generate a switching instruction based on the abnormal event in the monitoring report of the sub-processor when the abnormality level in the monitoring report of the sub-processor is greater than the second warning threshold; The first of the plurality of sub-processors is used to receive the switching instruction and terminate the running task corresponding to the abnormal event. The second subprocessor among the plurality of subprocessors has the same processing capability as the first subprocessor and is used to receive the switching instruction and execute the running task corresponding to the abnormal event.

8. The management controller according to claim 1, characterized in that, The second security processor runs the first security firmware image; The first security processor runs the second security firmware image; The first secure firmware image and the second secure firmware image are stored in different storage areas of the secure memory.

9. The management controller according to claim 8, characterized in that, The second security processor is also used for: When the management controller is powered on, it retrieves and runs the second security firmware image from the security memory; Restrict unauthorized processors' access to the secure memory; Obtain a first secure firmware image from the secure storage, and perform firmware verification on the first secure firmware image; When the firmware verification result is qualified, a startup command is sent to the first security processor; The first security processor is further configured to, upon receiving the boot instruction, retrieve and run the first security firmware image from the security memory.

10. The management controller according to claim 1, characterized in that, Several firmware images running on the main processor are stored in the firmware storage unit; The first security processor is also configured to, when the management controller is powered on, acquire a plurality of firmware images stored in the firmware storage unit and firmware image information of the plurality of firmware images; Integrity verification is performed on the aforementioned firmware images, and security verification is performed on the firmware image information of the aforementioned firmware images. The execution command is output only if both the integrity verification and the security verification pass. The main processor is also used to receive the running instructions and run the several firmware images.

11. The management controller according to claim 10, characterized in that, The first security processor is also used for: Calculate the hash value of each firmware image in the plurality of firmware images; The hash value of each firmware image is compared with the preset baseline value; When the hash value of each firmware image is consistent with the preset baseline value, the integrity verification result is determined to be successful.

12. The management controller according to claim 10, characterized in that, The first security processor is also used for: Verify the digital signature of each firmware image in the plurality of firmware images to obtain the signature verification result; The version identifier of each firmware image is compared with the preset version identifier to obtain the firmware image version verification result; The loading address of each firmware image is compared with the preset address range to obtain the address verification result; The code characteristics of each firmware image are obtained and analyzed to obtain code verification results. The security verification result is determined to be successful only when the signature verification result indicates that the digital signature of each firmware image is valid, the firmware image version verification result indicates that the version identifier of each firmware image matches the preset version identifier, the address verification result indicates that the loading address of each firmware image is within the preset address range, and the code verification result indicates that the code structure features of each firmware image do not contain malicious code.

13. The management controller according to claim 10, characterized in that, The firmware storage unit includes a main memory and a backup main memory; The main memory is used to store the running firmware image; The backup main storage is used to store at least one of the backup firmware image and the firmware image to be upgraded.

14. A server, characterized in that, include: Firmware storage unit; The management controller as described in any one of claims 1 to 13; The management controller is communicatively connected to the firmware storage unit.

Images