Server startup verification system

Abstract

Embodiments of the present application provide a server startup verification system. The system comprises: a system startup device and a target verifier; the system startup device comprises a system controller, a management controller, a switcher and a memory; the memory stores target startup firmware of a server system, and the target verifier stores target verification information of the server system; the switcher is configured to control the system controller to be communicated with the memory when the server system is started, and control the management controller to be communicated with the memory when the startup firmware in the memory is to be updated; and the system controller is configured to access the target verifier and the memory when the server system is started, and use the target verification information to verify the target startup firmware. The present application solves the problem in the related art of low security in a server startup stage, thereby achieving the effect of improving the security in the server startup stage.

Description

Server startup verification system

[0001] Cross-reference to related applications

[0002] This application claims priority to Chinese Patent Application No. 202411812509.6, filed on December 10, 2024, entitled "Server Startup Verification System", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of computers, and more specifically, to a server startup verification system. Background Technology

[0004] As the initial stage of the system's operational cycle, the security of the server startup phase directly impacts subsequent system operations. Therefore, security verification during the server startup process is crucial for the secure operation of the server system. In related technologies, server architectures commonly employ a configuration where the management controller and system controller are both connected to storage. In this configuration, the management controller updates and maintains the startup firmware stored in storage, while the system controller uses this firmware to start the system during startup. However, this architecture presents several challenges. First, the simultaneous access to storage by both the management controller and system controller can lead to errors or corruption of the startup firmware data. Second, the startup firmware in storage is susceptible to tampering, making it easy for the system controller to use a corrupted firmware during system startup, resulting in low security during the server startup phase. Summary of the Invention

[0005] This application provides a server startup verification system to at least address the problem of low security during the server startup phase in related technologies.

[0006] According to one embodiment of this application, a server startup verification system is provided, comprising:

[0007] The system startup device includes a system controller, a management controller, a switch, and a memory. The management controller, system controller, and memory are all connected to the switch. The target verifier is connected to the system startup device. The memory stores the target startup firmware of the server system, and the target verifier stores the target verification information of the server system. The target verification information is used to indicate the firmware data of the startup firmware that is allowed to be used when the server system starts up.

[0008] The switch is configured to connect the control controller to the memory when the server system is started, and to connect the control management controller to the memory when the boot firmware in the memory is pending an update.

[0009] The system controller is configured to access the target verifier and memory when the server system is started; and to verify the target boot firmware using the target verification information.

[0010] Optionally, the target verifier is connected to the connection link between the system controller and the switch.

[0011] Optionally, the server boot verification system also includes a reference verifier, which is connected to the connection link between the management controller and the switch. The reference verifier stores reference verification information of the server system, which is used to indicate the firmware data that the boot firmware is allowed to be written to the memory.

[0012] The management controller is configured to access the reference verifier when the boot firmware in the memory is to be updated; to verify the reference boot firmware to be updated in the memory using the reference verification information; and to access the memory and update the reference boot firmware to the memory if the reference boot firmware verification passes.

[0013] Optionally, the server startup verification system also includes a synchronization controller, which is connected to both the reference verifier and the target verifier.

[0014] The synchronization controller is configured to match a first version of the reference verification information with a second version of the target verification information; if the first and second versions do not match, the target verification information stored in the target verifier is updated using the reference verification information.

[0015] Optionally, the switch is configured with a first interface, a second interface and a third interface, wherein the first interface is configured to connect to the system controller, the second interface is configured to connect to the management controller, and the third interface is configured to connect to the memory.

[0016] The switch is configured to control the connection between the first and third interfaces when the server system is started, and to control the connection between the second and third interfaces when the boot firmware in the memory is to be updated.

[0017] Optionally, the switch is also equipped with a fourth interface, on which the target verifier is connected. The target verifier also stores reference verification information, which is used to indicate the firmware data that the boot firmware that is allowed to be written into the memory has.

[0018] The switch is configured to connect the first and fourth interfaces when the server system is started, connect the first and third interfaces when the system controller accesses the target verification information stored in the target verifier, connect the second and fourth interfaces when the boot firmware in the memory is to be updated, and connect the second and third interfaces when the management controller accesses the reference verification information stored in the target verifier.

[0019] Optionally, the memory includes multiple sub-memories, and the switch is connected to each sub-memory respectively;

[0020] Multiple sub-storages are configured to redundantly store the boot firmware required for the server system to start.

[0021] Optionally, the memory also includes a memory controller, wherein a first port of the memory controller is connected to a switch, and a second port of the memory controller is connected to each sub-memory respectively;

[0022] The storage controller is configured to control the access status of each sub-memory.

[0023] Optionally, the second port of the storage controller includes multiple sub-ports, each sub-port being connected to a sub-memory in a one-to-one correspondence;

[0024] The storage controller is configured to, upon receiving an access request for a sub-memory, select a target sub-memory from a plurality of sub-memories; and control the sub-port connected to the target sub-memory to be in a connected state with the first port.

[0025] Optionally, the storage controller includes a logic controller and a reference switch, the logic controller being connected to the reference switch, and the reference switch being configured with a first port and multiple sub-ports;

[0026] The logic controller is configured to control the reference switch to adjust the on / off state of the first port and each sub-port.

[0027] Optionally, the logic controller is configured to, upon receiving an access request to a sub-memory, select a first sub-memory that is not currently occupied from a plurality of sub-memories; and, if there are multiple first sub-memories, select a target sub-memory from the plurality of first sub-memories whose calling priority is greater than or equal to the target priority, based on the priority information of the sub-memories, wherein the priority information is determined based on the storage performance of each sub-memory.

[0028] Optionally, the logic controller is also configured to detect the occupancy status of each second sub-memory when the access request is an update request for the boot firmware, wherein the second sub-memory is a memory other than the target sub-memory among a plurality of sub-memories; and to update the updated boot firmware stored in the target sub-memory to the second sub-memory when the second sub-memory is in an unoccupied state.

[0029] Optionally, the logic controller is also configured to acquire the access failure frequency of each sub-memory that was accessed before the current time; sort the multiple sub-memories in ascending order of access failure frequency to obtain the access order of the multiple sub-memories; and determine the access order as the priority information when the multiple sub-memories are accessed.

[0030] Optionally, the target verifier is connected to the connection link between the storage controller and the switch. The target verifier also stores reference verification information of the server system, which is used to indicate the firmware data that the boot firmware is allowed to be written into the memory.

[0031] The management controller is configured to access the target verifier when the boot firmware in the memory is to be updated; to verify the reference boot firmware to be updated in the memory using reference verification information; and to access the memory and update the reference boot firmware to the memory if the reference boot firmware verification passes.

[0032] Optionally, the target verifier is connected to the connection link between the sub-memory and the corresponding sub-port. The target verifier also stores reference verification information of the server system. The reference verification information is configured to indicate the firmware data that the boot firmware is allowed to be written into the memory.

[0033] The management controller is configured to access the target verifier when the boot firmware in the memory is to be updated; to verify the reference boot firmware to be updated in the memory using reference verification information; and to access the target sub-memory and update the reference boot firmware to the target sub-memory if the reference boot firmware verification passes.

[0034] This application addresses the issue of low security during server system startup by deploying a switch connected between the system controller, management controller, and memory. When the server system is booting, the system controller connects to the memory; when the boot firmware in the memory needs updating, the management controller connects to the memory. This effectively prevents simultaneous access to the memory by both the system controller and management controller, thus avoiding data misalignment and corruption of the boot firmware stored in the memory. Furthermore, by deploying a target verifier connected to the system boot device, the system controller can access the target verifier to verify the target boot firmware stored in the memory during server system startup, preventing the system controller from using tampered boot firmware to boot the system, thereby improving the security of the server system startup process. Therefore, this application solves the problem of low security during the server startup phase in related technologies, achieving a significant improvement in the security of the server startup phase. Attached Figure Description

[0035] Figure 1 is a hardware connection diagram of a server startup verification system according to an embodiment of this application;

[0036] Figure 2 is a schematic diagram of a server startup verification system according to an embodiment of this application;

[0037] Figure 3 is a schematic diagram of a server startup verification system according to an embodiment of this application;

[0038] Figure 4 is a schematic diagram of a server startup verification system according to an embodiment of this application;

[0039] Figure 5 is a schematic diagram of a server startup verification system switching connection links according to an embodiment of this application;

[0040] Figure 6 is a schematic diagram of a server startup verification system switching connection links according to an embodiment of this application;

[0041] Figure 7 is a schematic diagram of a server startup verification system according to an embodiment of this application;

[0042] Figure 8 is a schematic diagram of a server startup verification system according to an embodiment of this application;

[0043] Figure 9 is a schematic diagram of a server startup verification system according to an embodiment of this application;

[0044] Figure 10 is a schematic diagram of a server startup verification system according to an embodiment of this application;

[0045] Figure 11 is a schematic diagram of a server startup verification system according to an embodiment of this application;

[0046] Figure 12 is a schematic diagram of a server BIOS security verification system according to an embodiment of this application;

[0047] Figure 13 is a schematic diagram of a server BIOS security verification system according to an embodiment of this application;

[0048] Figure 14 is a schematic diagram of an optimized server BIOS security verification system according to an embodiment of this application;

[0049] Figure 15 is a schematic diagram of an optimized server BIOS security verification system according to an embodiment of this application. Detailed Implementation

[0050] The embodiments of this application will be described in detail below with reference to the accompanying drawings and examples.

[0051] It should be noted that the terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0052] This embodiment provides a server startup verification system. Figure 1 is a hardware connection diagram of a server startup verification system according to an embodiment of this application. As shown in Figure 1, the system includes:

[0053] The system startup device includes a system controller, a management controller, a switch, and a memory. The management controller, system controller, and memory are all connected to the switch. The target verifier is connected to the system startup device. The memory stores the target startup firmware of the server system, and the target verifier stores the target verification information of the server system. The target verification information is used to indicate the firmware data of the startup firmware that is allowed to be used when the server system starts up.

[0054] The switch is configured to connect the control controller to the memory when the server system is started, and to connect the control management controller to the memory when the boot firmware in the memory is pending an update.

[0055] The system controller is configured to access the target verifier and memory when the server system is started; and to verify the target boot firmware using the target verification information.

[0056] By deploying a switch connecting the system controller, management controller, and memory, the system controller connects to the memory when the server system is booting; and the management controller connects to the memory when the boot firmware in the memory is awaiting an update. This effectively prevents simultaneous access to the memory by the system controller and management controller, thus avoiding data misalignment and corruption issues in the boot firmware stored in the memory. Furthermore, by deploying a target verifier connected to the system boot device, the system controller can access the target verifier to verify the target boot firmware stored in the memory during the server system boot process, preventing the system controller from using tampered boot firmware to boot the system, thereby improving the security of the server system boot process. Therefore, this addresses the issue of low security during the server boot phase in related technologies, achieving the effect of improving the security of the server boot phase.

[0057] Optionally, in this embodiment, the system controller is configured to communicate with the memory via a switch when the server system is started. The system controller and the switch are connected via an SPI bus. When the system needs to be started, the switch connects the system controller and the memory controller, keeping them in a connected state, and disconnects the connection between the management controller and the memory. This allows the system controller to load and run the server system's startup firmware stored in the memory. Simultaneously, during the startup process, the system controller can access a target verifier and use the target verification information stored therein to verify the startup firmware's legitimacy, ensuring the server starts securely. In this embodiment, the system controller can be, but is not limited to, a PCH (Platform Controller Hub), a CPU (Central Processing Unit), etc., and this solution does not limit this.

[0058] Optionally, in this embodiment, the management controller is configured to connect to the memory via a switch during the firmware update phase. When the management controller needs to access the memory, it sends an access request to the switch. Upon receiving the access request, the switch controls the connection between the management controller and the memory to be open and controls the connection between the management controller and the memory to be closed. This allows the management controller to access and update the boot firmware in the memory. To ensure the security of the boot firmware update, the management controller can communicate with a verifier to access reference verification information stored in the verifier (the reference verification information indicates the firmware data that can be written to the boot firmware in the memory). The management controller then uses the reference verification information to verify the legitimacy of the updated firmware, ensuring the security and integrity of the updated firmware. In this embodiment, the management controller can be, but is not limited to, a BMC (Baseboard Management Controller), iLO (Integrated Light-Out), etc. The iLO is a controller with remote server management capabilities; it is a remote server management processor embedded in the motherboard of the server and computing module. By using iLO, the server can be monitored and controlled from a remote location. When the management controller is iLO, remote access to the server can be achieved through remote access to iLO. In turn, access requests to the memory can be sent to the switch via external access. With the switch establishing a connection between the management controller and the memory, the boot firmware in the memory can be accessed through iLO, thereby enabling updates and upgrades to the boot firmware.

[0059] Optionally, in this embodiment, the switch is configured to dynamically switch the data path based on the server status (started or pending update), enabling separate access to the memory by the system controller and the management controller. When the server is in the start state, the switch will open the data path between the system controller and the memory. When the boot firmware in the memory is in the pending update state, the switch will switch to the data path between the system controller and the memory, thereby ensuring the independence and security of data updates. In this embodiment, the switch can be, but is not limited to, a MUX (Multiplexer), SPI Switch ICs, etc., and this solution does not limit it.

[0060] Optionally, in this embodiment, the memory is configured to store the boot firmware of the server system. The memory is connected to the system controller and management controller via a switch, ensuring secure and independent access to the firmware during boot and update processes. The memory can be a single-chip design or a redundant design with multiple chips. The design of multiple redundant memory chips ensures that even if one memory chip fails, the system can still read data from other healthy memory chips. For example, when the server system boots up, the firmware in multiple memory chips can be verified separately. If the firmware data in one memory chip is found to be tampered with or corrupted, the system can automatically switch to another memory chip to read the correct firmware data, preventing server boot anomalies caused by firmware data corruption in a single memory chip. In this embodiment, the memory can be, but is not limited to, Flash, SSD (Solid State Drive), MRAM (Magnetoresistive Random Access Memory), etc., and this solution does not limit it to these types.

[0061] Optionally, in this embodiment, the verifier is configured to perform security verification on the firmware data in the memory during the server system startup phase and the firmware data update phase in the memory. The verifier stores verification information for the server system. During the firmware data update phase, before writing the updated firmware to the memory, the management controller communicates with the verifier to verify the updated firmware using the verification information in the verifier. Only if the verification passes will the management controller be allowed to write the updated firmware to the memory. During the server system startup phase, the system controller accesses the verifier first and uses the verification information in the verifier to verify the firmware data in the memory. Only if the verification passes will the system controller be allowed to use the firmware data to start the server system. In this embodiment, the verifier can be, but is not limited to, a TPM (Trusted Platform Module), an SBR (Secure Boot ROM), etc., and this solution does not limit this.

[0062] Optionally, in this embodiment, Figure 1 is a hardware connection diagram of a server boot verification system according to an embodiment of this application. As shown in Figure 1, the system boot device includes a system controller, a management controller, a switch, and a memory. The management controller, system controller, and memory are directly connected to the switch via an SPI bus. The target verifier is connected to the system boot device. When the management controller needs to update the boot firmware in the memory, the management controller sends an SEL signal to the switch. The switch then switches the SPI bus path to control the connection between the management controller and the memory. The management controller loads the new firmware file and communicates with the TPM before writing it to the memory. It uses the verification information stored therein to verify the legality of the updated firmware. If the verification passes, the management controller is allowed to write the updated firmware into the memory. When the server is in the boot state, the switch disconnects the connection between the management controller and the memory and switches to the path between the system controller and the memory. The system controller then accesses the TPM to obtain the target verification information and performs integrity and legality verification on the target boot firmware in the memory to ensure that the firmware data and verification information are completely matched. If the verification passes, the system controller is allowed to use the target boot firmware to boot the server.

[0063] As an optional embodiment, the target verifier is connected to the connection link between the system controller and the switch.

[0064] Optionally, in this embodiment of the application, Figure 2 is a schematic diagram of a server boot verification system according to an embodiment of the application. As shown in Figure 2, the TPM (Target Verifier) ​​is connected to the connection link between the PCH (System Controller) and the MUX (Switcher). The PCH, management controller, TPM, and FLASH (Memory) are connected via an SPI bus. The TPM is directly connected to the PCH. The management controller and PCH can independently access the FLASH through the MUX switch. When the server system is in the boot phase, the MUX controls the PCH to connect to the FLASH. Then, the PCH accesses the TPM located between the PCH and the MUX to obtain the target verification information stored in the TPM. The PCH uses the target verification information to perform security verification on the target boot firmware stored in the FLASH. Then, if the verification passes, the PCH uses the target boot firmware to boot the server system.

[0065] With the above configuration, by connecting the target verifier to the connection link between the system controller and the switch, the target verifier can verify the legality and integrity of the boot firmware in the memory when the server system starts up, ensuring the security of the server during startup and operation.

[0066] As an optional embodiment, the server boot verification system further includes a reference verifier, wherein the reference verifier is connected to the connection link between the management controller and the switch, and the reference verifier stores reference verification information of the server system, which is used to indicate the firmware data of the boot firmware that is allowed to be written to the memory.

[0067] The management controller is configured to access the reference verifier when the boot firmware in the memory is to be updated; to verify the reference boot firmware to be updated in the memory using the reference verification information; and to access the memory and update the reference boot firmware to the memory if the reference boot firmware verification passes.

[0068] Optionally, in this embodiment, Figure 3 is a schematic diagram of a server boot verification system according to an embodiment of this application. As shown in Figure 3, the server boot verification system includes TPM0 (target verifier) ​​and TPM1 (reference verifier). TPM1 is connected to the connection link between the management controller and the MUX (switcher). When the boot firmware in the memory is awaiting update, the management controller sends a SEL signal to the MUX. After receiving the signal from the management controller, the MUX switches the path to control the management controller to connect to the FLASH. Before writing the updated firmware to the FLASH, the management controller accesses TPM1 and obtains the reference verification information stored therein, thereby controlling the connection between the management controller and the FLASH. The management controller uses the reference verification information to perform integrity and validity checks on the new firmware data to be written to the FLASH. If the verification passes, the management controller is allowed to write the new firmware data into the FLASH, completing the update of the boot firmware in the FLASH. When the server is in the boot state, the MUX disconnects the connection path between the management controller and the FLASH, switches the path to control the connection between the PCH and the FLASH, and then the PCH accesses TPM0 and obtains the target verification information stored therein. The PCH then uses the target verification information to perform integrity and validity checks on the target boot firmware in the FLASH. If the verification passes, the PCH is allowed to use the target boot firmware to boot the server system.

[0069] With the above configuration, by connecting the reference verifier to the connection link between the management controller and the switch, it can be ensured that the boot firmware can be securely verified by the verifier on the corresponding link during the server upgrade and startup process. This prevents the FLASH information from being illegally damaged or tampered with during the boot firmware upgrade process, thus ensuring the security of the server system during upgrades and startups.

[0070] As an optional embodiment, the server startup verification system further includes a synchronization controller, wherein the synchronization controller is connected to both the reference verifier and the target verifier.

[0071] The synchronization controller is configured to match a first version of the reference verification information with a second version of the target verification information; if the first and second versions do not match, the target verification information stored in the target verifier is updated using the reference verification information.

[0072] Optionally, in this embodiment of the application, Figure 4 is a schematic diagram of a server startup verification system according to an embodiment of the application. As shown in Figure 4, the server startup verification system further includes a synchronization controller, which is connected to a reference verifier (TPM1) and a target verifier (TPM0) respectively. The synchronization controller is configured to monitor and maintain the consistency of verification information between different verifiers in the server system.

[0073] Optionally, in this embodiment, during server startup or within a specific maintenance cycle, the synchronization controller actively triggers the synchronization of verification information between the target verifier and the reference verifier. The synchronization controller reads the latest first information version from the reference verifier and the latest second information version from the target verifier. The synchronization controller then compares the two versions of verification information to check if they are consistent. If the first information version and the second information version are inconsistent, the synchronization controller uses the latest verification information in the reference verifier to update the information in the target verifier to ensure that the information versions of all verifiers are consistent.

[0074] By configuring the above settings and setting up a synchronization controller between the target verifier and the reference verifier, it is possible to ensure that the verification information stored in the system remains consistent and up-to-date, reducing the risk of using outdated or incorrect verification information for verification and further improving the security and reliability of the entire server system.

[0075] As an optional embodiment, the switch is configured with a first interface, a second interface and a third interface, wherein the first interface is configured to connect to the system controller, the second interface is configured to connect to the management controller, and the third interface is configured to connect to the memory.

[0076] The switch is configured to control the connection between the first and third interfaces when the server system is started, and to control the connection between the second and third interfaces when the boot firmware in the memory is to be updated.

[0077] Optionally, in an embodiment of this application, Figure 5 is a schematic diagram of a server startup verification system switching connection link according to an embodiment of this application. As shown in Figure 5, the switch (MUX) is configured with a first interface, a second interface, and a third interface. The first interface is configured to connect to the system controller (PCH), the second interface is configured to connect to the management controller, and the third interface is configured to connect to the flash memory. When the server system is started, the switch (MUX) controls the first interface and the third interface to connect, that is, controls the system controller (PCH) and the flash memory to connect. When the startup firmware in the flash memory is to be updated, the switch (MUX) controls the second interface and the third interface to connect, that is, controls the management controller and the flash memory to connect.

[0078] The above configuration enables independent and secure access to the memory by the management controller and system controller through the switch, avoiding the problem of simultaneous access to the memory by the management controller and system controller, which could lead to firmware errors during startup and improves the security and stability of the server system.

[0079] As an optional embodiment, the switch is also configured with a fourth interface, on which the target verifier is connected. The target verifier also stores reference verification information, which is used to indicate the firmware data of the boot firmware that is allowed to be written into the memory.

[0080] The switch is configured to connect the first and fourth interfaces when the server system is started, connect the first and third interfaces when the system controller accesses the target verification information stored in the target verifier, connect the second and fourth interfaces when the boot firmware in the memory is to be updated, and connect the second and third interfaces when the management controller accesses the reference verification information stored in the target verifier.

[0081] Optionally, in this embodiment of the application, Figure 6 is a schematic diagram of a server startup verification system switching connection link according to an embodiment of the application. As shown in Figure 6, the switch (MUX) is also configured with a fourth interface, and the target verifier (TPM) is connected to the fourth interface. The TPM stores target verification information for indicating the firmware data of the startup firmware allowed to be used when the server system starts up, and also stores reference verification information for indicating the firmware data of the startup firmware allowed to be written into the memory.

[0082] Optionally, in this embodiment, when the boot firmware in the memory is to be updated, the management controller sends a SEL signal to the MUX, thereby connecting the second and fourth interfaces of the MUX, i.e., connecting the management controller with the TPM. The management controller can then access the TPM and obtain its stored reference verification information. After obtaining the reference verification information, the MUX connects the second and third interfaces of the MUX, i.e., connecting the management controller with the FLASH. The management controller then uses the obtained reference verification information to perform a security verification on the new boot firmware. If the verification passes, the management controller is allowed to write the new firmware data to the FLASH. When the server system is started, the MUX disconnects the second and third interfaces and connects the first and fourth interfaces, i.e., connecting the PCH with the TPM. The PCH can then access the TPM and obtain its stored target verification information. After obtaining the target verification information, the MUX connects the first and third interfaces of the MUX, i.e., connecting the PCH with the FLASH. The PCH then uses the obtained target verification information to perform a security verification on the target boot firmware in the FLASH. If the verification passes, the PCH is allowed to use the target boot firmware to start the server.

[0083] With the above configuration, by adding a fourth interface to connect to the target verifier and adding control logic to the switch, it is possible to perform security verification on firmware data during both the server update and startup phases using a single verifier. This not only improves the security of the server during startup and update processes but also simplifies system configuration.

[0084] As an optional embodiment, the memory includes multiple sub-memories, and the switch is connected to each sub-memory respectively;

[0085] Multiple sub-storages are configured to redundantly store the boot firmware required for the server system to start.

[0086] Optionally, in this embodiment of the application, Figure 7 is a schematic diagram of a server startup verification system according to an embodiment of the application. As shown in Figure 7, the memory includes multiple sub-memories (such as FLASH0, FLASH1, etc.), and the switch (MUX) is connected to each sub-memory. Each sub-memory independently stores a complete copy of the server startup firmware. This redundant storage design allows the system to still load the firmware from other healthy sub-memories when one or more sub-memories fail or the data is corrupted, ensuring the normal startup and operation of the server.

[0087] By configuring the memory as described above, which includes multiple sub-memories and allows the switch to connect to each sub-memory individually, the system can be provided with higher data redundancy and fault tolerance, thereby enhancing the stability and security of the server.

[0088] As an optional embodiment, the memory further includes a memory controller, wherein a first port of the memory controller is connected to a switch, and a second port of the memory controller is connected to each sub-memory respectively;

[0089] The storage controller is configured to control the access status of each sub-memory.

[0090] Optionally, in this embodiment of the application, Figure 8 is a schematic diagram of a server startup verification system according to an embodiment of the application. As shown in Figure 8, the memory also includes a storage controller. The first port of the storage controller is connected to the switch (MUX) and is responsible for receiving access requests and instructions from the switch (MUX). The second port of the storage controller is connected to each sub-memory (such as FLASH0, FLASH1) respectively, and can dynamically control the access status of each sub-memory according to the instructions of the switch, that is, determine which sub-memories can be read or written.

[0091] With the above configuration, the storage controller is connected to the sub-storages one-to-one through its second port, which allows the storage controller to independently control access to each sub-storage without affecting the state of other sub-storages, thus improving the security of data storage and the flexibility of access control.

[0092] As an optional embodiment, the second port of the storage controller includes multiple sub-ports, each sub-port being connected to a sub-memory in a one-to-one correspondence;

[0093] The storage controller is configured to, upon receiving an access request for a sub-memory, select a target sub-memory from a plurality of sub-memories; and control the sub-port connected to the target sub-memory to be in a connected state with the first port.

[0094] Optionally, in this embodiment, the second port of the storage controller includes multiple sub-ports, each sub-port being connected to a sub-memory in a one-to-one correspondence. The storage controller can control the connection status between the switch and the multiple sub-memories by controlling the connection status of the first port and the multiple sub-ports. When the server starts up or needs to be updated with firmware, the system controller or management controller sends an access request to the storage controller through the switch. When the storage controller receives the access request, it performs status checks and filtering on the multiple sub-memories. This can be done by pre-setting a master memory and slave memory among the multiple sub-memories, and then prioritizing the master memory for status checks. If the master memory is currently in good health, it is determined as the target sub-memory. If the master memory fails or its data is corrupted, the status checks are then performed on the multiple slave memories sequentially, and the first healthy slave memory is selected as the target sub-memory. In this embodiment, the storage controller can also check the access history of each sub-memory. Based on the access frequency or load balance of each sub-memory, it can prioritize selecting the sub-memory that has been accessed less frequently over a period of time as the target sub-memory to avoid data overload or wear caused by repeated accesses to the same sub-memory, thus achieving balanced data access. Once the target sub-memory is identified, the storage controller will control the sub-port connected to the target sub-memory to be in a connected state with the first port (i.e. the port connected to the switch), thereby allowing data read or write operations.

[0095] The above configuration, by setting up a storage controller in the memory and adopting a sub-port design that corresponds one-to-one with the sub-memory, improves the security of data storage and the flexibility of access control, and enhances the stability and security of the server during startup and firmware update processes.

[0096] As an optional embodiment, the storage controller includes a logic controller and a reference switch, the logic controller being connected to the reference switch, and the reference switch being configured with a first port and multiple sub-ports;

[0097] The logic controller is configured to control the reference switch to adjust the on / off state of the first port and each sub-port.

[0098] Optionally, in this embodiment, the storage controller includes a logic controller and a reference switch. The logic controller is configured to control the reference switch to adjust the on / off state of the first port and multiple sub-ports corresponding to the multiple sub-memories. The logic controller can be, but is not limited to, a CPLD (Complex Programmable Logic Device), an FPGA (Field-Programmable Gate Array), etc., and this solution does not limit it. Figure 9 is a schematic diagram of a server startup verification system according to an embodiment of this application. As shown in Figure 9, the logic controller (CPLD) is connected to the reference switch (MUX1). The reference switch (MUX1) is configured with a first port (the port connected to the switch MUX0) and multiple sub-ports (ports connected to the multiple sub-memories).

[0099] Optionally, in this embodiment of the application, in the server's BIOS security verification system, the sub-memories are assigned as the master FLASH (assuming FLASH0) and the slave FLASH (assuming FLASH1). Under this design, the PCH (System Controller) can only operate and interact with the master FLASH during normal startup, and when the management controller performs a BIOS firmware update. The slave FLASH is isolated during this stage and does not accept direct external access, ensuring the security and stability of its data. The CPLD periodically synchronizes the data from FLASH0 to FLASH1, thereby isolating the PCH and management controller from direct operations on FLASH1, ensuring the security and stability of the FLASH1 data.

[0100] Optionally, in this embodiment, when FLASH0 malfunctions or the management controller refreshes abnormally, causing FLASH0 to fail the TPM verification, the CPLD will switch the permissions of the FLASH, switching FLASH1 to the primary FLASH for normal system use and switching FLASH0 to the secondary FLASH. This ensures the stable operation of the machine and isolates the impact of FLASH0 data abnormalities on the system. At the same time, the CPLD will report the abnormal event to the system and notify the operation and maintenance personnel to take timely measures.

[0101] Through the above configuration, the combined use of logic controllers and reference switches provides the server security verification system with advanced data access control and storage resource management capabilities, significantly improving the system's security, stability, and management efficiency.

[0102] As an optional embodiment, the logic controller is configured to, upon receiving an access request to a sub-memory, select a first sub-memory that is in an unoccupied state from a plurality of sub-memories; and, if there are multiple first sub-memories, select a target sub-memory from the plurality of first sub-memories with a calling priority greater than or equal to a target priority, wherein the priority information is determined based on the storage performance of each sub-memory.

[0103] Optionally, in this embodiment, when the logic controller receives an access request for a sub-memory, the logic controller first filters out all first sub-memories that are in an unoccupied state, i.e., sub-memories that are not currently undergoing read / write operations. If there is only one first sub-memory, the single first sub-memory is identified as the target sub-memory. If there are multiple first sub-memories, the logic controller further filters based on the priority information of each sub-memory. The priority information is determined based on the storage performance of the sub-memory, such as the read / write speed, storage capacity, and data access latency. Thus, the logic controller selects the best target sub-memory from the unoccupied first sub-memories with a priority greater than or equal to the target priority.

[0104] With the above configuration and the intelligent screening and priority management mechanism of the logic controller, the server security verification system can achieve efficient and secure access to the sub-memory, ensuring data security and system stability during the startup phase and firmware update process.

[0105] As an optional embodiment, the logic controller is also configured to detect the occupancy status of each second sub-memory when the access request is an update request for the boot firmware, wherein the second sub-memory is a memory other than the target sub-memory among a plurality of sub-memories; and when the second sub-memory is in an unoccupied state, update the updated boot firmware stored in the target sub-memory to the second sub-memory.

[0106] Optionally, in this embodiment, when the logic controller receives a request to update the boot firmware, in order to ensure that after the firmware update of the target sub-memory, other unoccupied sub-memories can be configured as backups or subsequent updates, it will check the occupancy status of all second sub-memories (i.e., sub-memories other than the target sub-memory). Then, if it detects that one or more second sub-memories are in an unoccupied state, the logic controller will update the updated boot firmware stored in the target sub-memory to the second sub-memory.

[0107] The above configuration provides redundant firmware backup for the server. Even if the target sub-storage fails, the system can still boot normally through the second sub-storage, improving the server's stability and availability.

[0108] As an optional embodiment, the logic controller is also configured to acquire the access failure frequency of each sub-memory that was accessed before the current time; sort the multiple sub-memories in ascending order of access failure frequency to obtain the access order of the multiple sub-memories; and determine the access order as priority information when the multiple sub-memories are accessed.

[0109] Optionally, in this embodiment, the logic controller continuously monitors the access history of each sub-memory, recording the number of faults that occur when the sub-memory is accessed within a specific time window, including but not limited to data read failure, write delay, data integrity verification failure, etc., and then comprehensively extracts the access fault frequency of each sub-memory. Based on the acquired access fault frequency data, the logic controller sorts the multiple sub-memories in order of access fault frequency from low to high to obtain the access order of the multiple sub-memories, and determines the access order as the priority information of the multiple sub-memories when they are accessed. Furthermore, as the fault frequency changes dynamically, the priority of the sub-memory can also be adjusted in real time. For example, during the access of a sub-memory, if the fault frequency of the currently accessed sub-memory suddenly increases, the logic controller will immediately reduce its priority and isolate it from the normal access list when the fault frequency of the sub-memory exceeds a certain threshold to avoid further impact on the system.

[0110] Optionally, in this embodiment of the application, Figure 9 is a schematic diagram of a server boot verification system according to an embodiment of the application. As shown in Figure 9, when the server system boot firmware needs to be upgraded online, the management controller sends a SEL signal to the MUX0 (switch), and then the MUX0 connects the management controller and the storage controller. After receiving the access request to the sub-memory, the storage controller selects the target sub-memory from multiple sub-memories according to the priority information of the sub-memory. Then, during the firmware update process, the management controller will securely write the new firmware data into the target sub-memory. After the firmware update is completed on the target sub-memory (e.g., FLASH0), the logic controller (CPLD) starts to perform firmware data redundancy backup between the sub-memories. First, the CPLD detects the current occupancy status of other sub-memories in the system besides the target sub-memory (i.e., the second sub-memory, such as FLASH1). When the second sub-memory is unoccupied, the CPLD sends a control signal to MUX1 (reference switcher) to adjust the connection status between MUX1 and the sub-memory, switching the data path from the target sub-memory to the second sub-memory. Then, the CPLD updates the updated boot firmware stored in the target sub-memory to the second sub-memory. When the server is in the startup state, MUX0 disconnects the management controller from MUX1 and switches the link control PCH to connect with MUX1. The PCH then accesses the TPM (Target Verifier) ​​and retrieves the stored target verification information. It performs integrity and validity verification on the target boot firmware in the target sub-memory, ensuring a complete match between the firmware data and the verification information. If the verification passes, the PCH is allowed to use the target boot firmware to start the server. If the target boot firmware verification in the target sub-memory fails, the CPLD automatically switches the data access link between MUX1 and the sub-memory according to the pre-set sub-memory priority information, connecting the healthy second sub-memory to MUX1. This allows the PCH to use the boot firmware in the second sub-memory to start the server, ensuring rapid recovery from memory failures and maintaining stable system operation. Simultaneously, during server operation, the CPLD continuously monitors the status and failure frequency of all sub-memories, dynamically adjusting priority information to ensure the system selects the optimal sub-memory for data access based on the latest performance data and health status.

[0111] With the above configuration, the server security verification system can not only complete firmware updates securely and efficiently, but also reduce system interruption time caused by a memory failure through data redundancy synchronization and fault switching strategies, thereby improving the stability and security of the server in complex operating environments.

[0112] As an optional embodiment, the target verifier is connected to the connection link between the storage controller and the switch. The target verifier also stores reference verification information of the server system, which is used to indicate the firmware data of the boot firmware that is allowed to be written into the memory.

[0113] The management controller is configured to access the target verifier when the boot firmware in the memory is to be updated; to verify the reference boot firmware to be updated in the memory using reference verification information; and to access the memory and update the reference boot firmware to the memory if the reference boot firmware verification passes.

[0114] Optionally, in this embodiment of the application, FIG10 is a schematic diagram of a server boot verification system according to an embodiment of the application. As shown in FIG10, the target verifier (TPM) is connected to the connection link between the storage controller and the switch (MUX0). The TPM stores target verification information for indicating the firmware data of the boot firmware allowed to be used when the server system starts up, and also stores reference verification information for indicating the firmware data of the boot firmware allowed to be written into the memory.

[0115] Optionally, in this embodiment, the TPM is positioned on the connection link between the MUX0 and the storage controller. This ensures that both the PCH and the management controller can directly access the TPM without the MUX0 frequently switching data paths, reducing the frequency and complexity of data switching and improving the efficiency and stability of data transmission. Both BIOS upgrades and BIOS boots can directly verify the legitimacy and integrity of the boot firmware by accessing the TPM.

[0116] By configuring the target verifier to be connected to the connection link between the storage controller and the switch, it is possible to ensure that both the system controller and the management controller can directly access the TPM, thereby reducing the processing load on the switch and lowering the resource consumption of the server system.

[0117] As an optional embodiment, the target verifier is connected to the connection link between the sub-memory and the corresponding sub-port. The target verifier also stores reference verification information of the server system, which is used to indicate the firmware data that the boot firmware allowed to be written into the memory has.

[0118] The management controller is configured to access the target verifier when the boot firmware in the memory is to be updated; to verify the reference boot firmware to be updated in the memory using reference verification information; and to access the target sub-memory and update the reference boot firmware to the target sub-memory if the reference boot firmware verification passes.

[0119] Optionally, in this embodiment of the application, Figure 11 is a schematic diagram of a server startup verification system according to an embodiment of the application. As shown in Figure 11, the target verifier (TPM) is connected to the connection link between the sub-memory and the corresponding sub-port, so that the TPM can directly participate in the verification of the firmware data stored in the sub-memory without the need for a switch, thereby simplifying the data path and reducing the latency and potential errors in the data transmission process.

[0120] Optionally, in this embodiment, the TPM and multiple sub-memories are all positioned after the SPI bus MUX1 (reference switch), enabling the TPM to monitor and verify the integrity and validity of the firmware data in the sub-memories in real time. During BIOS online upgrades, the server needs to enter S5 state (STBY standby state) for the BIOS firmware upgrade. At this time, the PWRON signal is low, which controls the MUX0 chip to switch to the management controller, ensuring that control of the SPI bus remains with the management controller and is completely isolated from the PCH. The management controller first selects the first FLASH chip via the SEL signal to ensure the SPI path from the management controller to FLASH0 is connected. Then, it loads the BIOS FW (BIOS firmware file) burning file. Next, the management controller calls the TPM's HASH checksum to verify the security and legitimacy of the BIOS FW burning file. Only after the verification is passed is the management controller allowed to burn the BIOS FW file into FLASH0. After successful burning, the management controller selects the SPI bus of FLASH1 via the SEL signal and repeats the previous step to burn the BIOS FW file into FLASH1. This ensures that the BIOS FW files in the two FLASH chips are consistent. When the server is running, if the enabled FLASH chip is tampered with or the FW integrity verification fails, it can switch to the other FLASH chip for booting, ensuring the normal boot of the server BIOS and improving the server's security and stability.

[0121] In a normal server startup scenario, when the server powers on, the PWRON signal is high, controlling MUX0 to switch to PCH and completely isolating the management controller connection, ensuring path security and preventing risks such as management controller tampering with the BIOS firmware. At this time, PCH loads the BIOS firmware from FLASH0 and verifies the integrity and validity of the BIOS firmware through TPM. If the verification passes, the BIOS firmware will run until the server starts normally. If the verification fails, PCH will switch to FLASH1 via the SEL signal to perform the same firmware integrity and validity verification. If the verification is normal, the startup continues; if it fails, the server is prevented from booting, and the user is informed that the server's BIOS is abnormal and cannot boot, and measures should be taken as soon as possible.

[0122] With the above configuration, the design of directly connecting the target verifier between the sub-memory and the corresponding sub-port simplifies the data transmission path, avoids complex data switching in components such as switches, and effectively improves the server system's defense capabilities against firmware security threats through real-time security verification.

[0123] Optionally, in this embodiment of the application, a server BIOS security verification system is also provided. Figure 12 is a schematic diagram of a server BIOS security verification system according to an embodiment of the application. As shown in Figure 12, the PCH (System Controller), BMC (Management Controller), TPM (Target Verifier), and FLASH (Memory) are connected via an SPI bus. The TPM is directly connected to the PCH. The BMC and PCH can access the BIOS FLASH in a time-sharing manner through a MUX (Switcher) to upgrade the BIOS FW (boot firmware). However, the BMC cannot interact with the TPM. The BIOS FLASH is configured with FLASH0 and FLASH1. When one of the FLASH chips malfunctions or the BIOS FW in the FLASH fails the TPM verification, it will automatically switch to the other FLASH chip for booting. When both FLASH chips are damaged or the verification fails, the service refuses to start and alerts the user that the BIOS FLASH is damaged or has been tampered with. By setting up dual BIOS FLASH chips, a hard backup of the BIOS FW can be achieved, ensuring the security and stability of the BIOS.

[0124] When the BIOS firmware needs to be upgraded online, the SPI MUX chip can be controlled through the BMC to switch the SPI bus to the BMC, and then the BIOS firmware can be burned into the FLASH. The BIOS firmware upgrade can be performed with one or two FLASH chips as needed, which improves convenience.

[0125] During online BIOS firmware upgrades, if illegal operations or FLASH information are performed, the firmware file can still be written to the FLASH memory. This can lead to BIOS corruption or data loss, causing the server to fail to boot, posing a significant threat to server security and reliability. Because the BMC cannot access the TPM during online upgrades, it cannot verify the integrity and legitimacy of the BIOS firmware upgrade file. The BMC only verifies the integrity of the BIOS firmware file, thus failing to guarantee the security and legitimacy of the BIOS firmware upgrade file.

[0126] Figure 13 is a schematic diagram of a server BIOS security verification system according to an embodiment of this application. As shown in Figure 13, the TPM module's single BIOS FLASH is connected to the BMC and PCH via the SPI bus. The MUX switches between them to ensure that both the PCH and BMC can access the BIOS FLASH, but only the PCH can access the TPM. The BMC cannot access it normally, ensuring that the BIOS can verify the legality and integrity of the firmware through the TPM during startup, thus ensuring the security of the server during startup and operation.

[0127] The PCH and BMC communicate with the BIOS FLASH by switching the MUX chip. This solution can only guarantee the integrity and legitimacy of the BIOS FW during BIOS startup. That is, when the BIOS starts, it will be verified by the TPM. If the verification is successful, the BIOS will be allowed to start normally. If the BIOS is illegally tampered with or the BIOS FW is damaged, the verification will fail, and the BIOS will be prohibited from starting. This ensures the security and legitimacy of BIOS startup.

[0128] When upgrading the BIOS via the BMC, the MUX connects to the BMC via the SEL signal, allowing direct flashing of the BIOS FLAH file. This only involves the BMC verifying the integrity of the flashed BIOS FW file. Since the TPM cannot be accessed, the BIOS FW can be directly flashed or modified. The BIOS FW's legitimacy is only verified during boot after the flashing is complete. If the BIOS FW is illegally modified at this time, the system cannot intercept the behavior, ultimately leading to abnormal tampering of the server, causing the legitimacy verification to fail and preventing boot, thus affecting the server's security and stability.

[0129] Figure 14 is a schematic diagram of an optimized server BIOS security verification system according to an embodiment of this application. As shown in Figure 14, the TPM module and two BIOS FLASH chips are both placed after the SPI bus MUX, ensuring that both the PCH and BMC can access the TPM. Whether it is a BIOS upgrade or a BIOS boot, the legality and integrity of the firmware can be verified through the TPM, ensuring the security of the server during upgrades and boots.

[0130] Two BIOS flash chips are connected directly to the TPM via the SPI bus, allowing the TPM to monitor and verify the integrity and validity of the data in both flash chips in real time. During online BIOS upgrades, the server needs to enter S5 state (STBY standby state) for the BIOS flash upgrade. In this state, the PWRON signal is low, which controls the MUX chip to switch to the BMC, ensuring that the BMC has control of the SPI bus and is completely isolated from the PCH. The BMC first selects the first FLASH chip via the SEL signal to ensure the SPI path from the BMC to FLASH0 is connected. Then, it loads the BIOS programming file. Next, the BMC calls the TPM's HASH checksum to verify the security and legitimacy of the BIOS programming file. Only after the verification passes is the BMC allowed to program the BIOS programming file into FLASH0. After successful programming, the BMC selects the SPI bus of FLASH1 via the SEL signal and repeats the previous step to program the BIOS programming file into FLASH1. This ensures that the BIOS programming files in the two FLASH chips are consistent. When the server is running, if the enabled FLASH chip is tampered with or the programming file integrity verification fails, it can switch to the other FLASH chip for booting, ensuring the normal boot of the server BIOS and improving the server's security and stability.

[0131] In a normal server startup scenario, when the server powers on, the PWRON signal is high, controlling the MUX to switch to the PCH and completely isolating the BMC connection, ensuring the security of the path and preventing risks such as tampering of the BIOS firmware by the BMC. At this time, the PCH loads the BIOS firmware from FLASH0 and verifies the integrity and validity of the BIOS firmware through TPM. If the verification passes, the BIOS firmware will run until the server starts normally. If the verification fails, the PCH will switch to FLASH1 through the SEL signal to perform the same firmware integrity and validity verification. If the verification is normal, the startup continues; if it fails, the server is prevented from booting, and the user is informed that the server's BIOS is abnormal and cannot boot, and measures should be taken as soon as possible.

[0132] In normal server operation, the PWRON signal remains high, keeping the SPI path always connected to the PCH, enabling real-time verification of data integrity and validity. This ensures that after normal boot, the PCH has sole, unalterable control, preventing the risk of BMC tampering with or damaging the BIOS firmware or data.

[0133] The dual BIOS FLASH configuration ensures hardware redundancy in the BIOS FW, improving server security and stability; configuring BMC access to the TPM path ensures the security and legitimacy of online BIOS FW file upgrades, preventing BIOS tampering and damage.

[0134] Figure 15 is a schematic diagram of an optimized server BIOS security verification system according to an embodiment of this application. As shown in Figure 15, the read and write operations performed by the three hosts involved in the topology—PCH, BMC, and CPLD (Logic Controller Device)—on the two flash chips all need to be verified by the TPM.

[0135] FLASH0 is the master flash memory, and FLASH1 is the slave flash memory. During normal PCH startup, access to the flash memory and data interaction are performed. Alternatively, during a BMC BIOS firmware upgrade, only the master flash memory (flash0) can be accessed. FLASH1 is the slave flash memory, and the CPLD periodically synchronizes data from flash0 to FLASH1, thus isolating direct operations on FLASH1 by the PCH and BMC, ensuring the security and stability of the data in FLASH1.

[0136] When FLASH0 malfunctions or BMC refresh fails, causing FLASH to fail TPM verification, the CPLD will switch the permissions of the two FLASH chips. FLASH1 will be switched to the primary FLASH chip for normal system use, while FLASH0 will be switched to the secondary FLASH chip. This ensures stable machine operation and isolates the impact of flash data anomalies on the system. At the same time, the CPLD will report the abnormal event to the system, notifying maintenance personnel to take timely measures.

[0137] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0138] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0139] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. A server startup verification system, Its features are, It includes: a system startup device and a target verifier. The system startup device includes a system controller, a management controller, a switch, and a memory. The management controller, the system controller, and the memory are all connected to the switch. The target verifier is connected to the system startup device. The memory stores the target startup firmware of the server system. The target verifier stores the target verification information of the server system. The target verification information is used to indicate the firmware data of the startup firmware that is allowed to be used when the server system starts up. The switch is configured to, when the server system is started, control the system controller to connect to the memory; and when the boot firmware in the memory is pending an update, control the management controller to connect to the memory. The system controller is configured to access the target verifier and the memory when the server system is started; and to verify the target boot firmware using the target verification information.

2. The system according to claim 1, characterized in that, The target verifier is configured to perform security verification on the target boot firmware in memory during the server system startup phase and the firmware data update phase in memory.

3. [Amended according to Rule 26 07.08.2025] The system according to claim 1 is characterized in that, The target verifier is connected to the connection link between the system controller and the switch.

4. [Amended according to Rule 26 07.08.2025] The system according to claim 3 is characterized in that, The server startup verification system also includes a reference verifier, wherein the reference verifier is connected to the connection link between the management controller and the switch, and the reference verifier stores reference verification information of the server system, which is used to indicate the firmware data that the startup firmware can be written into the memory. The management controller is configured to access the reference verifier when the boot firmware in the memory is to be updated; to use the reference verification information to verify the reference boot firmware to be updated in the memory; and to access the memory and update the reference boot firmware to the memory if the reference boot firmware verification passes.

5. The system according to claim 4, characterized in that, The management controller is configured to send a switching signal to the switcher when the boot firmware in the memory is in a state of pending update. The switcher is configured to respond to the switching signal and control the management controller to connect to the memory; The management controller is configured to access reference verification information stored in the reference verifier before writing the firmware to be updated into the memory, use the reference verification information to verify the firmware data to be updated, and allow the management controller to write the new firmware data into the memory if the verification passes.

6. The system according to claim 4, characterized in that, The server startup verification system further includes a synchronization controller, wherein the synchronization controller is connected to both the reference verifier and the target verifier. The synchronization controller is configured to match a first version of the reference verification information with a second version of the target verification information; if the first version and the second version do not match, the reference verification information is used to update the target verification information stored in the target verifier.

7. The system according to claim 2, characterized in that, The switch is configured to disconnect the connection between the management controller and the memory when the server is in the startup state, and to control the connection between the system controller and the memory. The system controller is configured to access the target verification information stored in the target verifier when the server is in the startup state. The target boot firmware in the memory is used to perform integrity and legality verification using the target verification information. If the verification passes, the server system is started using the target boot firmware.

8. The system according to claim 1, characterized in that, The switch is equipped with a first interface, a second interface, and a third interface, wherein the first interface is configured to connect to the system controller, the second interface is configured to connect to the management controller, and the third interface is configured to connect to the memory; The switch is configured to control the connection between the first interface and the third interface when the server system is started; and to control the connection between the second interface and the third interface when the boot firmware in the memory is to be updated.

9. The system according to claim 8, characterized in that, The switch is also equipped with a fourth interface, the target verifier is connected to the fourth interface, and the target verifier also stores reference verification information, which is used to indicate the firmware data that the boot firmware is allowed to be written into the memory. The switch is configured to connect the first interface and the fourth interface when the server system is started; connect the first interface and the third interface when the system controller accesses the target verification information stored in the target verifier; connect the second interface and the fourth interface when the startup firmware in the memory is to be updated; and connect the second interface and the third interface when the management controller accesses the reference verification information stored in the target verifier.

10. The system according to claim 1, characterized in that, The memory includes multiple sub-memories, and the switch is connected to each of the sub-memories respectively; Multiple sub-memories are configured to redundantly store the boot firmware required to start the server system.

11. The system according to claim 10, characterized in that, The memory further includes a memory controller, wherein a first port of the memory controller is connected to the switch, and a second port of the memory controller is connected to each of the sub-memories; The storage controller is configured to control the access status of each of the sub-memories.

12. The system according to claim 11, characterized in that, The second port of the storage controller includes multiple sub-ports, each of which is connected to a sub-memory in a one-to-one correspondence. The storage controller is configured to, upon receiving an access request for the sub-memory, select a target sub-memory from a plurality of sub-memories; and control the sub-port connected to the target sub-memory to be in a connected state with the first port.

13. The system according to claim 12, characterized in that, The storage controller is also configured to detect the historical access frequency of each of the sub-memories and identify the sub-memories whose access frequency is lower than a set frequency as target sub-memories.

14. The system according to claim 12, characterized in that, The storage controller includes a logic controller and a reference switch, the logic controller being connected to the reference switch, and the reference switch being configured with the first port and a plurality of the sub-ports; The logic controller is configured to control the reference switch to adjust the on / off state of the first port and each of the sub-ports.

15. The system according to claim 14, characterized in that, The logic controller is configured to, upon receiving an access request to the sub-memory, select a first sub-memory that is in an unoccupied state from a plurality of the sub-memories. When there are multiple first sub-memories, the target sub-memories with a calling priority greater than or equal to the target priority are selected from the multiple first sub-memories according to the priority information of the sub-memories, wherein the priority information is determined according to the storage performance of each sub-memories.

16. The system according to claim 14, characterized in that, The logic controller is further configured to, when the access request is an update request for the boot firmware, detect the occupancy status of each second sub-memory, wherein the second sub-memory is a memory other than the target sub-memory among the plurality of sub-memories; and when the second sub-memory is in an unoccupied state, update the updated boot firmware stored in the target sub-memory to the second sub-memory.

17. The system according to claim 15, characterized in that, The logic controller is further configured to acquire the access failure frequency of each of the sub-memories that was accessed before the current time; sort the multiple sub-memories in ascending order of the access failure frequency to obtain the access order of the multiple sub-memories; and determine the access order as the priority information when the multiple sub-memories are accessed.

18. The system according to claim 11, characterized in that, The target verifier is connected to the connection link between the storage controller and the switch. The target verifier also stores reference verification information of the server system. The reference verification information is used to indicate the firmware data that the boot firmware is allowed to be written into the memory. The management controller is configured to access the target verifier when the boot firmware in the memory is pending an update. The reference verification information is used to verify the reference boot firmware to be updated in the memory; If the reference boot firmware verification passes, the memory is accessed and the reference boot firmware is updated to the memory.

19. The system according to claim 12, characterized in that, The target verifier is connected to the connection link between the sub-memory and the corresponding sub-port. The target verifier also stores reference verification information of the server system. The reference verification information is used to indicate the firmware data that the boot firmware is allowed to be written into the memory. The management controller is configured to access the target verifier when the boot firmware in the memory is pending an update. The reference verification information is used to verify the reference boot firmware to be updated in the memory; If the reference boot firmware verification passes, the target sub-memory is accessed and the reference boot firmware is updated to the target sub-memory.

20. [Corrected according to Rule 91, 07.08.2025] The system according to claim 11, characterized in that, The target verifier is connected to the reference switch, and the target verifier also stores the reference verification information of the server system.

Images