A method for auditing the secure boot and configuration of a raid card and a raid card

Abstract

The application discloses a kind of RAID card security start and configuration audit method and RAID card, it is related to data storage technical field.The method is prior to main control chip power-on by hardware root of trust circuit independent of RAID main control chip and carries out integrity check to firmware, eliminates attack window period;Meanwhile, all configuration modification requests are captured and reported hardware root of trust circuit by audit agent unit embedded in firmware in runtime, and the audit log that is not tampered with is generated.The application constructs the security closed loop of depth defense that hardware root of trust protects firmware and firmware audit agent monitors configuration behavior, and attacker needs to break through two independent security levels simultaneously to modify configuration secretly.When firmware is all invalid, hardware root of trust circuit can enter minimal security mode, realize remote repair through BMC channel, and avoid device brick.

Description

Technical Field

[0001] This invention relates to the field of data storage technology, and in particular to a method for secure boot and configuration auditing of a RAID card and the RAID card itself. Background Technology

[0002] As the core control unit of a storage array, the integrity and security of the firmware and configuration data of the RAID card directly affect the reliable operation of the entire storage system. Currently, there are two main types of RAID card firmware protection solutions: one is a self-recovery mechanism based on the main controller chip, which stores two copies of the firmware (primary and backup) in the onboard flash memory. When the primary firmware fails to boot, the bootloader inside the RAID main controller chip switches to the backup firmware. However, this type of solution lacks a trust anchor independent of the main controller chip; if the main controller chip itself is attacked or the primary firmware is maliciously tampered with, the backup mechanism may also fail. The other type is an external monitoring solution represented by platform firmware protection and recovery technology. This uses an independent CPLD or MCU to actively measure and recover the firmware, but it mainly targets server motherboard platform-level firmware protection. After the root of trust completes the measurement, it returns control to the system and boots according to the standard procedure, without participating in the configuration security management at the RAID card level.

[0003] Regarding configuration data security protection, existing technologies primarily focus on the storage protection and read verification of configuration data, without addressing real-time auditing and tamper-proof logging of configuration modification operations. Furthermore, some solutions place the security verification on the host side, where the BIOS or operating system uses a hash algorithm to measure and compare the RAID card firmware during server startup. This approach not only involves verification occurring late in the system startup process, resulting in a long attack window, but its verification mechanism also relies on the security of the host operating system; once the host system is compromised, the verification mechanism becomes ineffective. Additionally, such solutions can only perform a one-time static verification at startup, failing to monitor and audit configuration tampering that occurs during system operation. Summary of the Invention

[0004] The technical problem to be solved by the embodiments of the present invention is that existing RAID cards lack an independent security mechanism that can complete firmware verification before the main control chip starts up and perform hardware-level mandatory auditing of configuration modification behavior during system operation, resulting in a long attack window and the inability to form a complete security closed loop.

[0005] In a first aspect, embodiments of the present invention provide a secure boot and configuration auditing method for a RAID card, applied to a RAID card, wherein the RAID card includes a RAID controller chip, a hardware root of trust circuit, and a memory, the hardware root of trust circuit being independent of the RAID controller chip, and including: Hardware-level secure boot procedure: After the hardware root trust circuit is powered on, before releasing the reset signal of the RAID master control chip, the firmware to be booted is read from the memory and its integrity is verified. Only after the verification is passed is the reset signal released to allow the RAID master control chip to boot. Runtime auditing steps for configuration modifications: When the RAID master control chip is running, the audit agent unit embedded in the firmware captures the modification request for the RAID card configuration parameters, extracts the summary information of the modification request, and reports it to the hardware root trust circuit through a dedicated communication interface; the hardware root trust circuit receives and records the summary information to generate a security audit log.

[0006] Secondly, embodiments of the present invention also provide a RAID card with a hardware root of trust, used to implement a method for secure boot and configuration auditing of the RAID card, including: RAID controller chip; The hardware root trust circuit, whose output is connected to the reset pin of the RAID master controller chip, is configured to power on before the RAID master controller chip and control its reset state. A memory, connected to the hardware root of trust circuit, is used to store firmware data and security audit logs; The firmware running on the RAID master control chip includes an audit agent unit, which is used to capture modification requests to the RAID card configuration and extract summary information. The RAID master control chip is connected to the hardware root trust circuit through a dedicated communication interface to report the summary information to the hardware root trust circuit for recording.

[0007] This invention eliminates the attack window caused by relying on the main control chip or host operating system for verification by setting up a hardware root of trust circuit independent of the RAID main control chip. This allows the circuit to power on and complete firmware integrity verification before the main control chip, thus fundamentally eliminating the attack window caused by the traditional solution. At the same time, by embedding an audit agent unit in the firmware and working in conjunction with the hardware root of trust circuit, it achieves hardware-level forced capture and tamper-proof audit records of all configuration modification operations during RAID card operation. This constructs a defense-in-depth closed loop where the hardware root of trust protects firmware integrity, and the audit agent in the firmware monitors configuration behavior and reports to the hardware root of trust. This makes it so that if an attacker wants to secretly modify the configuration, they must simultaneously break through two physically and logically independent security layers: the hardware root of trust and the firmware, significantly improving the attack difficulty and overall system security. Attached Figure Description

[0008] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0009] Figure 1 This is a block diagram of the RAID card hardware structure provided in an embodiment of the present invention; Figure 2 A timing diagram illustrating the hardware-level secure boot process provided in an embodiment of the present invention; Figure 3 Signaling interaction diagram of the runtime configuration audit process provided in this embodiment of the invention; Figure 4 This is a state transition diagram for the minimized security mode provided in an embodiment of the present invention; Figure 5 A schematic diagram of the hierarchical structure of the security closed loop provided in an embodiment of the present invention; Detailed Implementation

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

[0011] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0012] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0013] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0014] As used in this specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if [described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [described condition or event] is detected," or "in response to detection of [described condition or event]."

[0015] Before providing a detailed description of the specific implementation methods, several key terms involved in this invention will be uniformly defined and explained.

[0016] RAID card: A hardware device used to combine multiple physical disks into a single logical storage unit, including a RAID controller chip and peripheral circuitry.

[0017] RAID controller chip: The core processor on the RAID card, responsible for RAID array control, data striping, and redundancy calculation. In specific embodiments, the RAID controller chip can be a general-purpose RAID-on-Chip processor such as Broadcom SAS3916 or Microchip PM8069, communicating with the host via a PCIe interface and connecting to the back-end disk array via SAS / SATA ports.

[0018] Hardware root of trust circuit: A hardware unit independent of the RAID controller chip, serving as the physical foundation for system security trust. It powers on before the controller chip and performs security verification and arbitration. Specifically, it can be implemented as a programmable logic device such as a CPLD, MCU, FPGA, or ASIC. It should be noted that although a CPLD is used as an exemplary device for implementing the hardware root of trust circuit in the embodiments of this invention, the invention is not limited to this. Any hardware unit that can independently perform firmware / configuration integrity verification before the RAID controller chip powers on and control the reset state of the RAID controller chip based on the verification results should be considered as the hardware root of trust circuit of this invention and fall within the protection scope of this invention.

[0019] Audit Agent Unit: A logical module embedded in the RAID master controller chip firmware, located on the configuration command parsing path. It is used to capture all modification requests for RAID card configuration parameters and report their summary information to the hardware root of trust circuit. As a component of the RAID master firmware, the integrity of the audit agent unit is verified by the hardware root of trust circuit during the secure boot process.

[0020] Memory: In a specific embodiment of the present invention, a 256MB SPI NOR Flash memory (e.g., Winbond W25Q256JV) can be used, connected to the hardware root of trust circuit via the SPI bus, and the hardware root of trust circuit communicates with the RAID master controller chip after internal logic arbitration. The internal partitions of the memory include: hardware root of trust firmware area, RAID master firmware area, RAID backup firmware area, master configuration area, backup configuration area, security audit log area, and key storage area.

[0021] BMC: Baseboard Management Controller, an out-of-band management system for servers, providing a remote management channel independent of the host operating system.

[0022] Minimum Security Mode: A restricted operating state that the RAID card enters when all firmware fails, maintaining only communication with the BMC for remote repair.

[0023] This invention provides a method for secure boot and configuration auditing of a RAID card, applied to a RAID card. The RAID card includes a RAID controller chip, a hardware root of trust circuit, and a memory. The hardware root of trust circuit is independent of the RAID controller chip and includes: Hardware-level secure boot procedure: After the hardware root trust circuit is powered on, before releasing the reset signal of the RAID master control chip, the firmware to be booted is read from the memory and its integrity is verified. Only after the verification is passed is the reset signal released to allow the RAID master control chip to boot. Runtime auditing steps for configuration modifications: When the RAID master control chip is running, the audit agent unit embedded in the firmware captures the modification request for the RAID card configuration parameters, extracts the summary information of the modification request, and reports it to the hardware root trust circuit through a dedicated communication interface; the hardware root trust circuit receives and records the summary information to generate a security audit log.

[0024] In this embodiment, the hardware root of trust circuit is connected to the RAID master controller chip via I2C and SPI buses. The I / O pins of the hardware root of trust circuit are connected to the reset pin (RESET_N) of the RAID master controller chip to control the reset state of the master controller chip in hardware. The audit agent unit communicates with the RAID master controller chip and the hardware root of trust circuit via the I2C bus as a dedicated communication interface. In addition, the RAID card also includes a power monitoring circuit, which uses a voltage monitoring chip to monitor the power supply rails of the RAID card. Its output is connected to the external interrupt pin of the hardware root of trust circuit to provide protection against abnormal power loss.

[0025] The following combination Figure 2 The timing diagram provides a detailed explanation of the hardware-level secure boot process. (Refer to...) Figure 2 After the server powers on: At time T0, the 3.3V auxiliary voltage is established, and the hardware root of trust circuit begins its power-on reset. At time T1 (T0+10ms), the hardware root of trust circuit completes its internal logic configuration and enters the working state; at this time, the reset pin of the RAID controller chip is pulled low by the hardware root of trust circuit and is in a reset hold state. During T1 to T2, the hardware root of trust circuit reads firmware data from the RAID main firmware area in memory via the SPI bus, calculates the hash value using its internal hardware-implemented hash engine (e.g., SHA-256), and compares it with the base hash value pre-stored in the key storage area. At time T2 (T1+15ms), the comparison result matches, and the hardware root of trust circuit releases (pulls high) the reset pin of the RAID controller chip. After time T2, the RAID controller chip begins the firmware loading process, reads the firmware from memory and initializes it, and finally enters the normal working state. The audit agent unit is loaded as part of the firmware and begins running.

[0026] During the above process, the RAID controller chip remains in a reset state until time T2, and its internal CPU does not execute any instructions, thus ensuring the absolute pre-emptive nature of the verification in terms of hardware timing. This method, which uses an independent hardware root of trust circuit as the security core, powers on before the RAID controller chip, and actively controls the controller chip's reset signal, achieves complete physical isolation between the verification logic and the RAID controller chip. Furthermore, since the verification action occurs before the controller chip starts up, it fundamentally eliminates the attack window and host-side dependency inherent in existing technologies where verification is performed by host software. It achieves true hardware-driven, pre-verification, pre-startup assurance.

[0027] In a specific embodiment, during the runtime auditing step of the configuration modification, the auditing agent unit is located on the configuration command parsing path of the RAID master control chip, and its integrity is verified by the hardware root of trust circuit during the hardware-level secure boot step.

[0028] In this embodiment, the audit agent unit is embedded in the firmware image of the RAID main firmware as a component of the RAID main controller chip. During the hardware-level secure boot process, the hardware root of trust circuit performs hash verification on the entire firmware image, including the audit agent unit. Therefore, any attempt to tamper with or remove the audit agent unit will cause the firmware integrity verification to fail, thus being detected and blocked by the hardware root of trust circuit during the power-on phase. This mechanism establishes the first layer of trust transmission chain, with the hardware root of trust protecting the firmware and the audit agent unit embedded within the firmware, ensuring the reliability of the audit agent unit itself.

[0029] In a specific embodiment, during the runtime auditing step of the configuration modification, the summary information includes at least the command type, origin identifier, and timestamp.

[0030] In this embodiment, the sources of the modification requests include, but are not limited to: the BMC out-of-band management channel, the host BIOS / UEFI configuration interface, and in-band management tools running in the host operating system. The audit agent unit is located on the configuration command parsing path, and all modification requests for RAID card configuration parameters must pass through this unit. When the audit agent unit captures a configuration modification request, it immediately extracts the request's summary information, including the command type (e.g., deleting an array, modifying stripe size, etc.), modification parameters (e.g., target array ID, new parameter values, etc.), origin identifier (e.g., process ID, management channel type, etc.), and timestamp. By recording this complete contextual information, the traceability and evidentiary value of each audit log are ensured.

[0031] In a specific embodiment, during the runtime auditing step of the configuration modification, after analyzing the summary information, the hardware root of trust circuit returns a confirmation signal indicating whether execution is allowed or denied to the RAID master controller chip through the dedicated communication interface, thereby controlling the execution of the configuration modification request.

[0032] In this embodiment, combined with Figure 3 The signaling interaction diagram illustrates the complete runtime configuration audit process. In step 301, the administrator issues a command to the server BMC to "modify the RAID stripe size to 512KB" through the data center management software; alternatively, an attacker directly sends a configuration command to the RAID card to "delete all RAID arrays" through an in-band tool of the host operating system (such as StorCLI). In step 302, when the RAID controller chip parses the command, the audit agent unit embedded in the firmware captures the configuration modification request. In step 303, the audit agent unit extracts the request's summary information. In step 304, the audit agent unit sends the summary information to the hardware root trust circuit through the dedicated I2C communication interface. In step 305, the hardware root trust circuit receives the summary information, verifies its integrity, and writes a log containing complete context information to the security audit log area of ​​the memory. In step 306, after analyzing the summary information, the hardware root trust circuit returns a confirmation signal to the RAID controller chip via the dedicated communication interface, indicating whether execution is allowed or denied, to control the execution of the configuration modification request. In step 307, the RAID master controller chip decides whether to perform configuration modifications based on the confirmation signal.

[0033] This embodiment embeds the audit agent unit into the firmware's configuration command parsing path and works in conjunction with the hardware root of trust circuit to achieve real-time capture and hardware-level auditing of configuration modification operations on all channels (BIOS, in-band tools, BMC) during RAID card operation. Unlike existing technologies that only focus on the static integrity of firmware, this invention constructs a complete behavioral auditing closed loop: any configuration modification is captured by the audit agent, and any attempt to bypass the audit agent (such as firmware tampering) is detected and blocked by the hardware root of trust upon power-up. Simultaneously, the hardware root of trust circuit maintains a monotonically increasing configuration version number, incrementing after each successful configuration modification, and rejects any attempt to roll back to a lower configuration version, further preventing configuration rollback attacks.

[0034] In a specific embodiment, the hardware root trust circuit determines whether the origin identifier in the digest information is an unauthorized management channel. If so, it returns the confirmation signal of refusal to execute.

[0035] In this embodiment, the hardware root trust circuit maintains a preset security policy that defines the operation permissions for different management channels. For example, the configurable security policy can be: prohibiting the deletion of the array via the host's in-band management tools, and only allowing such high-risk operations via the BMC's out-of-band management channel. When the hardware root trust circuit receives the digest information, it checks whether the management channel indicated by the origin identifier is an authorized channel for this operation type. If it is an unauthorized channel, it returns a rejection signal, the RAID controller chip terminates command execution and returns an error; otherwise, it returns an allow signal. This proactive interception mechanism based on channel permissions effectively prevents attackers from performing destructive operations on the RAID configuration through in-band tools even after gaining control of the host operating system.

[0036] In a specific embodiment, the hardware-level secure boot step specifically includes: if the main firmware verification fails, the hardware root of trust circuit reads the backup firmware from the memory for integrity verification; if the backup firmware verification passes, the backup firmware is overwritten to the main firmware storage area, and then the reset signal of the RAID master control chip is released.

[0037] In this embodiment, it is assumed that the RAID master firmware area suffers data corruption due to bit flips caused by storage media aging. The power-on process is as follows: The hardware root trust circuit reads the master firmware area and calculates a hash value, which is inconsistent with the baseline value. The hardware root trust circuit immediately reads the backup firmware area data and calculates a hash value, which is consistent with the baseline value. The hardware root trust circuit performs a repair operation: erasing the backup firmware area data page by page and writing it to the master firmware area. After the repair is complete, the hardware root trust circuit appends a record to the security audit log area, including a timestamp and the EVENT_FW_RECOVERED event identifier, indicating that the master firmware has been successfully recovered from the backup firmware. The hardware root trust circuit then releases the RAID controller chip reset signal, and the system starts normally. This automatic repair mechanism ensures that when non-malicious firmware damage occurs (such as storage media aging, bit flips, etc.), the system can autonomously recover to a safe state without external intervention, significantly improving the system's reliability and maintainability.

[0038] In a specific embodiment, the RAID card secure boot and configuration auditing method further includes a minimized security mode step: when the hardware root trust circuit fails to verify both the main firmware and the backup firmware in sequence, it refuses to release the reset signal of the RAID master control chip and enters the minimized security mode; in this mode, the hardware root trust circuit only activates the communication interface with the baseboard management controller (BMC), reports fault alarm information through this interface, and responds to the firmware repair command issued by the BMC to receive the repair firmware and write it into the memory.

[0039] In this embodiment, combined with Figure 4 The state transition diagram illustrates the complete process of the minimized security mode. In state 401, after the hardware root trust circuit powers on, it sequentially verifies the primary and backup firmware, both of which fail. At this point, the hardware root trust circuit does not release the reset signal of the RAID controller chip, and the state transitions to minimized security mode 402. In state 402, the hardware root trust circuit sends a standard IPMI OEM command to the BMC via the BMC interface, reporting a fault code (e.g., 0xFA, indicating double firmware corruption) and its own serial number. The hardware root trust circuit continuously listens for firmware transmission commands issued by the BMC. When it receives a firmware image data packet from the BMC, it sequentially writes the data to the primary firmware area of ​​the memory. This minimized security mode ensures that even in the most extreme case of double firmware corruption (such as simultaneous damage to the primary and backup firmware due to malicious attacks or severe storage failures), the device still has the ability to be remotely repaired via the BMC, completely avoiding the long-term business interruption and high maintenance costs associated with physical return for repair.

[0040] In a specific embodiment, during the minimized security mode step, the hardware root trust circuit actively performs an integrity check on the firmware after it is written; if the check passes, it exits the minimized security mode and jumps to execute the hardware-level secure boot step; otherwise, it remains in minimized security mode and waits for the next repair instruction.

[0041] In this embodiment, refer to Figure 4 The state transition diagram shows that after firmware writing is complete, the state transitions to the verification node: the hardware root trust circuit performs integrity verification on the newly written master firmware. If the verification passes, the state transitions to normal boot process 403, and the hardware root trust circuit exits the minimized security mode and executes the normal hardware-level secure boot process; if the verification still fails, it returns to minimized security mode 402, waiting for the next repair attempt. This cyclical verification and retry mechanism ensures that even if data errors occur during BMC transmission, the system can eventually recover through repeated repair attempts, avoiding the device permanently remaining in a faulty state due to a single repair failure.

[0042] The following combination Figure 5 The hierarchical structure diagram illustrates the overall security closed loop constructed by this invention. Figure 5 It demonstrates the complete protection process that attackers attempt to bypass audits, showcasing a layered and interconnected defense-in-depth architecture.

[0043] Step 501 (Attack Triggered): The attacker sends a configuration command to the RAID card to "Delete all RAID arrays" via the server operating system's command-line tool (such as StorCLI).

[0044] Step 502 (Audit Agent Capture): When the RAID controller chip's firmware parses the command, the embedded audit agent unit captures the configuration modification request, extracts the summary information, and reports it to the hardware root trust circuit. The hardware root trust circuit generates an immutable audit log. The attack is recorded.

[0045] Step 503 (Attacker Attempts to Bypass): Finding it impossible to directly and secretly modify the configuration (because all configuration changes are captured and recorded by the audit agent unit), the attacker instead attempts to modify the RAID firmware, trying to disable or remove the audit agent unit. The attacker writes the tampered firmware to flash memory using a programmer.

[0046] Step 504 (Hardware Root of Trust Interception): When the system restarts, the hardware root of trust circuit performs a hash check on the main firmware during the power-on phase and finds that the hash value does not match the baseline value.

[0047] Step 505 (Automatic Recovery): The hardware root trust circuit reads the original firmware from the backup firmware area, overwrites the tampered main firmware area, and completes the automatic repair. Simultaneously, the "FW_TAMPER_DETECTED_AND_RECOVERED" event is recorded in the audit log.

[0048] Step 506 (Loop Complete): The RAID card boots normally with the original firmware, and the audit agent unit is running smoothly. All attacker attempts are logged, and the system automatically recovers to a secure state.

[0049] In summary, this invention establishes a complete security closed loop: First, a hardware root of trust circuit protects the RAID firmware, detecting and preventing any tampering. Second, an audit agent unit embedded within the RAID firmware ensures that any request to modify the RAID configuration must pass through this unit. Third, the audit agent unit proactively reports to the hardware root of trust circuit, which generates an immutable security audit log. Attackers must simultaneously breach three independent security layers to secretly modify the configuration: the operating system / in-band tools, the RAID firmware (audit agent unit), and the hardware root of trust circuit. This defense-in-depth architecture significantly increases the cost and difficulty of attacks.

[0050] This invention also provides a RAID card with a hardware root of trust, used to implement the RAID card secure boot and configuration auditing method described in the above embodiments, including: RAID controller chip; The hardware root trust circuit, whose output is connected to the reset pin of the RAID master controller chip, is configured to power on before the RAID master controller chip and control its reset state. A memory, connected to the hardware root of trust circuit, is used to store firmware data and security audit logs; The firmware running on the RAID master control chip includes an audit agent unit, which is used to capture modification requests to the RAID card configuration and extract summary information. The RAID master control chip is connected to the hardware root trust circuit through a dedicated communication interface to report the summary information to the hardware root trust circuit for recording.

[0051] In this embodiment, refer to Figure 1The RAID card hardware structure block diagram shown in this embodiment includes the following: a RAID controller chip 101, which uses a general-purpose RAID-on-Chip processor such as Broadcom SAS3916 or Microchip PM8069, communicates with the host through a PCIe interface, and connects to the back-end disk array through a SAS / SATA port. A hardware root of trust circuit 102, taking a CPLD as an example, uses a Lattice MachXO3 series or Intel MAX 10 series CPLD, connected to the RAID controller chip 101 via I2C and SPI buses; the I / O pins of the CPLD 102 are connected to the reset pin (RESET_N) of the RAID controller chip 101 to control the reset state of the controller chip in hardware. An audit agent unit 106, embedded in the firmware of the RAID controller chip 101, is located on the configuration command parsing path of the RAID controller chip 101, and communicates with the CPLD 102 through the I2C bus (as a dedicated communication interface) between the RAID controller chip 101 and the CPLD 102. The dedicated flash memory 103 uses a 256MB SPI NOR Flash memory (such as Winbond W25Q256JV), which is connected to the CPLD 102 via the SPI bus, and communicates with the RAID master control chip 101 through internal logic arbitration by the CPLD 102. The flash memory is internally partitioned as follows: CPLD firmware area (addresses 0x00000000-0x0000FFFF, read-only), RAID master firmware area (addresses 0x00010000-0x00FFFFFF), RAID backup firmware area (addresses 0x01000000-0x01FFFFFF), master configuration area (addresses 0x02000000-0x0200FFFF), backup configuration area (addresses 0x02010000-0x0201FFFF), security audit log area (addresses 0x02020000-0x0202FFFF), and key storage area (addresses 0x02030000-0x0203FFFF). The BMC interface 104 communicates with the server BMC via the SMBus / I2C sideband signals on the PCIe gold fingers. The power monitoring circuit 108 uses a voltage monitoring chip (such as TI TPS3808) to monitor the 3.3V, 1.8V and 1.2V power rails of the RAID card, and its output is connected to the external interrupt pin of CPLD 102.

[0052] In a specific embodiment, the hardware root of trust circuit contains a hardware hash engine, which reads firmware from the memory and calculates a check value before releasing the reset signal of the RAID master controller chip, and compares it with a preset benchmark value.

[0053] In this embodiment, the hardware hash engine is specifically implemented as a SHA-256 hardware accelerator, integrated into the CPLD's internal logic. During the verification process, the CPLD reads firmware data from the RAID master firmware area of ​​the dedicated flash memory via the SPI bus. The hardware hash engine performs real-time hash calculations on the firmware data in a pipelined manner, requiring no software intervention, and its calculation speed is far higher than that of software-implemented hash algorithms. After the calculation is completed, the obtained hash value is compared with the baseline hash value pre-stored in the dedicated flash memory key storage area. This purely hardware-based verification method ensures the security of the verification process itself, eliminating the possibility of software tampering or bypassing.

[0054] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0055] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Since these modifications and variations fall within the scope of the claims and their equivalents, this invention also intends to include these modifications and variations.

[0056] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for secure boot and configuration auditing of a RAID card, applied to a RAID card, the RAID card comprising a RAID controller chip, a hardware root of trust circuit, and a memory, wherein the hardware root of trust circuit is independent of the RAID controller chip, characterized in that, include: Hardware-level secure boot procedure: After the hardware root trust circuit is powered on, before releasing the reset signal of the RAID master control chip, the firmware to be booted is read from the memory and its integrity is verified. Only after the verification is passed is the reset signal released to allow the RAID master control chip to boot. Runtime auditing steps for configuration modifications: When the RAID master control chip is running, the audit agent unit embedded in the firmware captures the modification request for the RAID card configuration parameters, extracts the summary information of the modification request, and reports it to the hardware root trust circuit through a dedicated communication interface; the hardware root trust circuit receives and records the summary information to generate a security audit log.

2. The RAID card secure boot and configuration auditing method according to claim 1, characterized in that, In the runtime auditing step of the configuration modification, the audit agent unit is located on the configuration command parsing path of the RAID master controller chip, and its integrity is verified by the hardware root of trust circuit in the hardware-level secure boot step.

3. The RAID card secure boot and configuration auditing method according to claim 1, characterized in that, In the runtime auditing step of the configuration modification, the summary information includes at least the command type, origin identifier, and timestamp.

4. The RAID card secure boot and configuration auditing method according to claim 1, characterized in that, In the runtime auditing step of the configuration modification, after analyzing the summary information, the hardware root of trust circuit returns a confirmation signal to the RAID master control chip through the dedicated communication interface, indicating whether execution is allowed or denied, in order to control the execution of the configuration modification request.

5. The RAID card secure boot and configuration auditing method according to claim 4, characterized in that, The hardware trust root circuit determines whether the origin identifier in the digest information is an unauthorized management channel. If so, it returns the confirmation signal of refusal to execute.

6. The RAID card secure boot and configuration auditing method according to claim 1, characterized in that, The hardware-level secure boot process specifically includes: if the main firmware verification fails, the hardware root of trust circuit reads the backup firmware from the memory for integrity verification; if the backup firmware verification passes, the backup firmware is overwritten to the main firmware storage area, and then the reset signal of the RAID controller chip is released.

7. The RAID card secure boot and configuration auditing method according to claim 6, characterized in that, It also includes a minimized security mode step: when the hardware root trust circuit fails to verify both the main firmware and the backup firmware in sequence, it refuses to release the reset signal of the RAID master control chip and enters the minimized security mode; in this mode, the hardware root trust circuit only activates the communication interface with the baseboard management controller (BMC), reports fault alarm information through this interface and responds to the firmware repair command issued by the BMC, so as to receive the repair firmware and write it into the memory.

8. The RAID card secure boot and configuration auditing method according to claim 7, characterized in that, In the minimized security mode step, the hardware root trust circuit actively performs an integrity check on the firmware after it is written; if the check passes, it exits the minimized security mode and jumps to execute the hardware-level secure boot step; otherwise, it remains in minimized security mode and waits for the next repair instruction.

9. A RAID card with a hardware root of trust, used to implement the RAID card secure boot and configuration auditing method as described in any one of claims 1 to 8, characterized in that, include: RAID controller chip; The hardware root trust circuit, whose output is connected to the reset pin of the RAID master controller chip, is configured to power on before the RAID master controller chip and control its reset state. A memory, connected to the hardware root of trust circuit, is used to store firmware data and security audit logs; The firmware running on the RAID master control chip includes an audit agent unit, which is used to capture modification requests to the RAID card configuration and extract summary information. The RAID master control chip is connected to the hardware root trust circuit through a dedicated communication interface to report the summary information to the hardware root trust circuit for recording.

10. The RAID card according to claim 9, characterized in that, The hardware root of trust circuit contains a hardware hash engine, which reads the firmware from the memory and calculates a check value before releasing the reset signal of the RAID master controller chip, and compares it with a preset benchmark value.

Images