Recovery of a management controller based unresponsive bus interface controller

Abstract

The present disclosure relates to recovery of a non-responsive bus interface controller based on a management controller. A computer platform includes a host and a management controller. The management controller operates independently of the host. A hardware processor of the management controller executes a firmware management stack to manage the host. A bus interface controller of the management controller generates bus signals to access non-volatile memory. A secure enclave of the management controller includes a bus controller interface recovery engine to communicate with the bus interface controller to reset the bus interface controller in response to the bus interface controller exhibiting non-responsive behavior.

Description

Background Technology

[0001] In computer platforms (e.g., servers), electronic devices use communication links or buses to transmit data. For this purpose, electronic devices may include or use their own bus interface controllers (also referred to as "bus controllers"). The bus interface controller generates signals on the bus according to a signaling protocol and senses or receives signals from the bus. For a given data transmission, the signals on the bus represent information about the data transmission, such as the data itself, the address where the data is stored or will be stored, and the command corresponding to the type of data transmission (e.g., read or write). Attached Figure Description

[0002] Figure 1 This is a block diagram of a computer platform having a bus interface controller recovery engine based on a baseboard management controller, according to an example implementation.

[0003] Figure 2 This is a block diagram of a bus interface controller monitoring and recovery architecture according to an example implementation.

[0004] Figure 3 This is a state diagram depicting the state and state transitions of a fault detection engine for detecting bus interface controller faults, based on an example implementation.

[0005] Figure 4 It is a flowchart depicting the sequence of actions taken by the recovery engine and the bus interface controller to detect a fault in the bus interface controller and to recover the bus interface controller from the fault, according to an example implementation.

[0006] Figure 5 This is a flowchart illustrating the sequence of actions taken by the recovery engine to detect a fault in the bus interface controller and to recover the bus interface controller from the fault, based on an example implementation.

[0007] Figure 6 This is a block diagram of a management controller including a bus interface controller recovery engine based on a secure enclave, according to an example implementation.

[0008] Figure 7 This is a block diagram of a computer platform having a bus interface controller recovery engine based on a baseboard management controller, according to an example implementation.

[0009] Figure 8 This is a flowchart depicting a technique for detecting and recovering a non-responsive bus interface controller, based on an example implementation. Detailed Implementation

[0010] "Open computing server" refers to a server with open-source software and / or open-source firmware. "Open-source" software or firmware typically means that it is publicly released; the underlying source code is accessible; and the source code is permissible to modify (e.g., any licensed modifications or modifications permitted by an open-source license). Furthermore, open-source software or firmware is free to use. LINUX is an example of open-source operating system software. The OpenBMC (OpenBMC) firmware management stack is an example of open-source firmware. The Baseboard Management Controller (BMC) executes the firmware management stack to perform various management-related functions for the server, such as operating system runtime services; resource detection and initialization; empty media management; telemetry monitoring; etc.

[0011] The growing demand for open computing servers can be attributed to several reasons, such as their relatively easy scaling and configuration for large data centers. One example of the potential advantages of open-source firmware is that server clusters can be built by multiple different server manufacturers, and using the same open-source firmware management stack across all servers may require less personnel training and reduce the footprint of remote management software used to manage the cluster. Furthermore, open-source firmware or software is better suited to handling specific modifications to the server for particular use.

[0012] The BMC is a fairly complex subsystem, and hardware failures are unavoidable due to underlying flaws or errors in its firmware management stack. Furthermore, hardware failures in the BMC may be even more common when it executes an open-source firmware stack. As a more concrete example, the open-source firmware stack can access the BMC's bus interface controller (e.g., the Serial Peripheral Interface (SPI) controller) via a user-space application programming interface (API) (e.g., the Linux spidev driver). The BMC can also access this bus interface controller via a kernel-space driver. The firmware management stack's use or configuration of the bus interface controller may conflict with how the kernel-space driver configures or uses the bus interface controller, leading to bus interface controller failure. In one example, a failed bus interface controller might "hang" and become unresponsive to new requests.

[0013] In one method for handling a failed bus interface controller, the BMC performs "power cycles" on the server. This means the BMC de-energizes the server, then restores power, and restarts it. Power cycles temporarily remove power from the bus interface controller so that it can be reinitialized when power is restored. However, power cycles on a server with a failed bus interface controller can damage the server and potentially even permanently. In one example, as part of an orderly server shutdown, the server prepares for power removal by reading certain system management data from volatile memory and writing the read data to non-volatile memory. Therefore, the system management data is retained when power is removed. On subsequent startup, the server retrieves this system management data from the non-volatile memory, allowing the server to be placed in the appropriate state. If the corresponding bus interface controller is unresponsive and locked, the contents of the volatile memory cannot be written back to the non-volatile memory.

[0014] Therefore, if a power-off restart method is used to restore the bus interface controller used to write system management data to non-volatile memory, the system management data in volatile memory will not be written back to non-volatile memory (and therefore will not be retained). Thus, a power-off restart only achieves partial recovery.

[0015] The BMC and its bus interface controller can be powered by an auxiliary power supply, which can be powered on and off independently of the server's main power supply. Powering off and restarting the auxiliary power supply while keeping the server's main power supply on to restore the bus interface controller located in the BMC would temporarily disable the server's BMC security services. Therefore, powering off and restarting the server's auxiliary power supply is not a feasible solution for restoring the bus interface controller located in the BMC.

[0016] According to the example implementation described herein, the BMC recovers the bus interface controller by performing a directed reset on the bus interface controller, rather than by power-down rebooting the computer platform (e.g., a server). Therefore, as part of an orderly shutdown of the computer platform, even if the bus interface controller is used to write system management data to non-volatile memory, the directed reset allows the bus interface controller to be recovered and still usable for this purpose. Furthermore, since the power to the computer platform is not removed, the directed reset preserves the system management data stored in volatile memory.

[0017] According to an example implementation, the bus is a serial bus (e.g., an SPI bus), in which data can be sequentially transferred between the bus interface controller and non-volatile memory, one bit at a time. To this end, the bus interface controller generates and responds to signals on the serial bus according to a signaling protocol. According to an example implementation, the bus interface controller is part of the BMC. In one example, the bus interface controller is part of the BMC's management plane, and the BMC's security processor, located in a secure enclave within the BMC, acts as the bus interface controller recovery engine (referred to herein as the "recovery engine"). As described herein, in response to the bus interface controller exhibiting unresponsive behavior, the recovery engine restores the bus interface controller to normal operation by resetting it.

[0018] The secure enclave is part of the BMC's security plane, protected by an encrypted boundary and isolated from the BMC's management plane. According to an example implementation, the BMC prevents entities outside the secure enclave (such as the BMC's management plane processing core or hosts managed by the BMC) from resetting the BMC's bus interface controller. Therefore, according to an example implementation, the recovery engine located in the secure enclave has exclusive reset control over the BMC's bus interface controller. Restricting reset control to the secure enclave prevents unintended bus interface controller resets (e.g., resets due to errors) and malicious bus interface controller resets (e.g., resets performed for further security attacks on the server).

[0019] In the context used herein, "unresponsive behavior" of a bus interface controller refers to the bus interface controller failing to act in the expected manner, such as failing to complete an operation within the expected timeframe or failing to respond to or accept a new request within the expected time interval. In one example of unresponsive behavior, the bus interface controller malfunctions and is unable to complete processing the request. Accordingly, the bus interface controller may "hang" and thus become unusable, for example, for reading data from or writing data to a specific non-volatile memory.

[0020] In other examples of unresponsive behavior, the bus interface controller fails to complete a bus cycle or a phase of a bus cycle within the expected time interval. Here, a "bus cycle" refers to a sequence of bus signals corresponding to a read, write, or erase transaction. In a more specific example, the bus interface controller fails to complete the command phase of a bus cycle within the expected time interval (e.g., a phase where the bus interface controller serially sends bytes representing a read, write, or erase command). In another example, the bus interface controller fails to complete the address phase of a bus cycle within the expected time interval (e.g., a phase where the bus interface controller serially sends bytes representing an address). In yet another example, for a bus cycle corresponding to a read transaction, the bus interface controller fails to complete the virtual clock phase of the bus cycle within the expected time interval (e.g., a phase where the bus interface controller waits for multiple virtual clock cycles before sampling received data on the bus). In yet another example, the bus cycle does not complete before the execution timer times out.

[0021] In a more specific example of why a bus interface controller might hang or become unresponsive, a user-space application uses the bus interface controller, while the operating system kernel is also using it without using semaphores. Because executing a single transaction involves multiple register accesses, and because the operating system is multithreaded, switching between user-space processes and the kernel, the kernel process might interfere with the user process and lead to incorrect programming of the bus interface controller, resulting in a hang.

[0022] According to some implementations, the bus interface controller includes a fault detection engine that allows the bus interface controller to self-detect unresponsive behavior and provide indications to the BMC's recovery engine regarding the detected unresponsive behavior, enabling the recovery engine to respond. In one example, for each bus cycle, the fault detection engine initializes and monitors expiration timers associated with different portions of that bus cycle (e.g., different phases or the entirety). By using these expiration timers, the fault detection engine is able to determine when the entire bus cycle or a portion of the bus cycle takes longer than expected to complete (and thus corresponds to a fault or unresponsive behavior).

[0023] The fault detection engine can provide any of several indications to notify the recovery engine that unresponsive behavior has been detected. In one example, when unresponsive behavior is detected, the fault detection engine generates an interrupt, and the recovery engine corresponds to an interrupt service routine for that interrupt, used to reset the bus interface controller. In another example, the fault detection engine sets (e.g., to a logic 1) a fault or error bit in a register of the bus interface controller, and this setting prompts the recovery engine to reset the bus interface controller. In one example, setting this bit generates an interrupt and triggers an interrupt service routine (corresponding to the recovery engine) to reset the bus interface controller. In another example, the recovery engine polls the bus interface controller's error register to detect when the fault detection engine set the bit.

[0024] According to some implementations, the recovery engine directly detects when the bus interface controller exhibits unresponsive behavior without relying on the bus interface controller's self-detection. In one example, the bus interface controller has a status register including a "busy" bit. The bus interface controller sets this "busy" bit (e.g., sets or changes it to a logic 1 value) to indicate that the bus interface controller is currently processing a request. The bus interface controller de-sets (e.g., clears or changes it to a logic 0 value) the busy bit to indicate that the bus interface controller is able to receive and process another request. The bus interface controller is expected to process requests at regular intervals. The recovery engine polls this busy bit (e.g., reads the status register at regular intervals to determine the state of the busy bit) to detect when the bus interface controller takes longer than expected to process a request.

[0025] According to a further implementation, the unresponsive behavior of the bus interface controller can be detected in other ways. In one example, a processing entity that is using or attempting to use the bus interface controller detects that the bus interface controller is exhibiting unresponsive behavior. In one example, the processing entity may have received a timeout indication when attempting to write to non-volatile memory. The processing entity sends a message to the recovery engine, notifying it of the detected unresponsive behavior. In one example, the message originates from the management processing core of the BMC. In another example, the message originates from an application on a host managed by the BMC. In one example, the message could be an API call.

[0026] The recovery engine can reset the bus interface controller in any of several different ways. In one example, the recovery engine uses the bus interface controller's "soft reset" function to reset the controller. In one example, a soft reset involves the recovery engine setting (e.g., setting) a bit in the bus interface controller's global configuration register. Setting that bit, in turn, puts the bus interface controller into a reset state. To complete the soft reset, the recovery engine then de-sets (e.g., clears) the same bit to release the bus interface controller from the reset state. In another example, the recovery engine resets the bus interface controller by writing to a register in the BMC that causes the BMC's hardware circuitry to switch the bus interface controller's reset terminator.

[0027] Reference Figure 1 As a more specific example, according to some implementations, computer platform 100 includes a collection of N non-volatile memories (NVMs) 170 accessed via their respective serial links or buses 167 (referred to herein as "serial bus 167"). Figure 1 The NVMs 170-1, 170-2, and 170-N described herein. According to an example implementation, serial bus 167 corresponds to N respective bus interface controllers 146-1 to 146-N. According to an example implementation, bus interface controller 146 (or "bus controller 146") is configured to receive data representing an NVM access request. In one example, the NVM access request is a write request for writing data to NVM 170. In another example, the NVM access request is a read request for reading data from NVM 170. In yet another example, the NVM access request is an erase request for erasing the contents of NVM 170. As further described herein, bus interface controller 146 is configured to apply command filtering to verify or authorize the NVM access request. If the command filtering authorizes the NVM access request, bus interface controller 146 is configured to generate a signal on its respective serial bus 167 to complete the request.

[0028] Signals on serial bus 167 correspond to bus cycles. Each bus cycle is associated with reading from NVM 170 (i.e., transferring data from NVM 170 to bus interface controller 146), writing to NVM 170 (i.e., transferring data from bus interface controller 146 to NVM 170), or erasing the contents of NVM 170. A bus cycle can be broken down into a series of phases, such as a command phase, an address phase, and a data phase. The command phase sends commands (e.g., read, write, or erase commands) to NVM 170. The address phase sends addresses (e.g., the address for reading or writing data) to NVM 170. The data phase sends data (e.g., data read from or written to NVM 170) to NVM 170. In another example, the bus cycle corresponding to a read includes a virtual phase that corresponds to a waiting period (e.g., multiple clock cycles) during which NVM 170 begins providing the read data to serial bus 167.

[0029] In one example, the NVM 170-1, corresponding to the bus interface controller 146-1, corresponds to the secure memory storage of the BMC 129. In one example, the NVM 170-1 stores data representing cryptographic components (encryption keys, digital certificates, encryption seeds, encryption secrets, passwords, or other security-related information).

[0030] In another example, the NVM 170-2, corresponding to the bus interface controller 146-2, stores system firmware 172 and system management data 174. In one example, a portion of system firmware 172 corresponds to the BMC firmware management stack image. In another example, a portion of system firmware 172 corresponds to the BIOS image (e.g., the image corresponding to the Power-On Self-Test (POST) instruction).

[0031] In another example, system firmware 172 includes instructions that correspond to the “initial portion” of system firmware 172 and are the first instructions executed by the security processor 150 (e.g., one or more physical central processing unit (CPU) cores) of the BMC 129 upon first power-on. As further described herein, this initial portion of system firmware 172 is first verified by the silicon root of trust or “SRoT” engine 143 of the BMC 129 before the security processor 150 is released from the reset state and allowed to execute.

[0032] In one example, system management data 174 represents the system state of computer platform 100 at the current startup time. In another example, system management data 174 represents the state of management engine 107 (e.g., Intel Management Engine (ME)) at the current startup time of computer platform 100. According to the example implementation, management engine 107 is a processing resource (e.g., a microcontroller running a microkernel operating system) used to provide functions such as out-of-band management services, protected audio / video paths (e.g., providing High Bandwidth Digital Content Protection (HDCP)), firmware-based Trusted Platform Module (TPM), and other components and services for computer platform 100. Figure 1 As depicted, management engine 107 may reside in input / output (I / O) bridge 106 of computer platform 100 (e.g., in platform controller hub (PCH) chipset). According to an example implementation, management engine 107 maintains and updates the current version of system management data in system memory 104 of computer platform 100, and writes this version to NVM 170-2 (to update system management data 174 stored in NVM 170-2) as part of an orderly shutdown of computer platform 100 (e.g., a power-down as part of a power-off restart or a power-down without immediate power-on).

[0033] In one example, system management data 174 includes data representing an anti-replay table. The anti-replay table prevents attackers from replacing files in system management data 174 with older versions. In another example, system management data 174 includes data representing the version of the firmware executed by management engine 107, also known as a "security version number" or "SVN". In another example, system management data 174 includes data representing the default configuration file of management engine 107. In another example, system management data 174 includes data representing a platform vendor-specific default configuration file of management engine 107. In another example, system management data 174 includes data representing Unified Extensible Firmware Interface (UEFI) variables. In another example, system management data 174 includes data representing System Management Basic Input / Output System (SMBIOS) information. In these examples, other NVMs 170-3 to 170-N may include information corresponding to UEFI applications and other system-related information.

[0034] According to an example implementation, BMC 129 includes a bus interface controller recovery engine 142 (referred to herein as "recovery engine 142"). Recovery engine 142 is configured to recover the bus interface controller 146-2 in the event of a failure. In this context, "recovering" the bus interface controller refers to a sequence of one or more events for restoring the bus interface controller to a state where the bus interface controller no longer exhibits unresponsive behavior.

[0035] More specifically, according to the example implementation, recovery engine 142 responds to unresponsive behavior of bus interface controller 146-2 by resetting bus interface controller 146-2. By using a directed reset of bus interface controller 146-2 instead of a power-off reboot of computer platform 100, bus interface controller 146-2 can be recovered and used to write the current version of system management data 174 to NVM 170-2 when computer platform 100 is shut down.

[0036] According to an example implementation, recovery engine 142 is also configured to respond to one or more other bus interface controllers 146 of the computer platform 100 (other than bus controller 146-2) exhibiting unresponsive behavior by resetting bus interface controller 146. In one example, recovery engine 142 is configured to reset any one of the bus interface controllers 146-1 to 146-N in response to unresponsive behavior. In another example, recovery engine 142 is configured to reset either bus interface controller 146-1 or bus controller 146-2 in response to unresponsive behavior. In yet another example, in response to unresponsive behavior of bus interface controller 146-2, the scope of recovery engine 142 is limited to resetting only bus interface controller 146-2.

[0037] In the context used herein, a "non-volatile" memory device refers to a memory device that continues to store data even when power is removed from it. In some examples, each of the NVM 170-1 to 170-N is implemented using a collection of flash read-only memory (ROM) devices, such as NOR flash or NAND flash devices. In other examples, the NVM 170-1 to 170-N may be implemented using other types of memory devices.

[0038] In the context used herein, "bus" refers to any communication link that includes a set of signal lines (a single signal line or multiple signal lines) through which data is transmitted. "Serial bus" refers to any communication link that includes a set of signal lines (a single signal line or multiple signal lines) through which data is transmitted sequentially, one bit at a time. A serial bus can be associated with half-duplex communication (e.g., a given bus interface controller 146 that transmits or receives at a given time) or full-duplex communication (e.g., a given bus interface controller 146 that can transmit and receive simultaneously at a given time). In some examples, serial bus 167 is an SPI bus. In other examples, serial bus 167 is an integrated circuit (I2C) bus, a modified I2C (I3C) bus, or other types of serial bus.

[0039] In the example where serial bus 167 is an SPI bus, the associated bus interface controller 146 is an SPI controller. If serial bus 167 is another type of bus, the associated bus interface controller 146 can be a different type of bus controller, such as an I2C bus controller, an I3C controller, or another type of bus controller.

[0040] According to an example implementation, the components of BMC 129 include a management plane 130 and a security enclave 140. The security enclave 140 corresponds to a security plane isolated from the management plane 130. The management plane 130 includes one or more main management processing cores 154 that execute instructions of the BMC firmware management stack to perform various management-related functions for the host 101 of the computer platform 100. For example, BMC 129 provides management-related functions such as operating system runtime services; resource detection and initialization; and pre-operating system services. In other examples, management-related functions include BMC 129 monitoring telemetry values ​​(e.g., cooling fan speed, temperature sensors, and tamper indication sensors) and reporting unexpected or out-of-range telemetry values. The firmware management stack may or may not be an open-source stack, depending on the specific implementation.

[0041] Management-related functions may also include remote management functions. As examples, remote management functions include keyboard, video, and mouse (KVM) functionality; virtual power functions (e.g., remote activation functions for remotely setting power states, such as power-on, power-off, reset, or power-off states); virtual media management functions; and one or more other management-related functions for host 101. According to an example implementation, BMC 129 may communicate with remote management server 190 to perform its management-related services. In this example, such communication may be via network interface controller (NIC) 158 of BMC 129 or NIC 124 of host 101.

[0042] like Figure 1 As depicted, among its other features, management plane 130 also includes bus interface controllers 146-2 to 146-N and volatile memory 155. Management processing core 154 retrieves instructions from volatile memory 155 for execution. Management plane 130 also includes one or more bus communication interfaces 156 accessible by host 101. In one example, bus communication interface 156 includes registers associated with the API provided by management plane 130. Through this API, application 115 can communicate with BMC 129 using an Input / Output Control (IOCTL) interface driver, Representation State Transfer (REST) ​​API calls (e.g., Redfish API calls), or some other system software agent.

[0043] According to the example implementation, the recovery engine 142 and the bus interface controller 146-1 are part of the secure enclave 140. Figure 1 As depicted, the secure enclave 140 includes a bus interface controller 146-1, a secure processor 150, volatile memory 151, and an SRoT engine 143. According to a further embodiment, although the SRoT engine 143 is referred to as a "silicon" root of trust engine, the SRoT engine 143 can be fabricated on a semiconductor substrate other than silicon.

[0044] The secure enclave 140 stores an immutable fingerprint, which is used by the SRoT engine 143 to verify the initial portion of the system firmware 172 before the security processor 150 executes its initial portion upon power-up of the BMC 129. According to an example implementation, in response to power-up of the BMC 129, the SRoT engine 143 holds the security processor 150, management processing core 154, and main CPU core 102 of the computer platform 100 in a reset state until the SRoT engine 143 verifies the initial portion of the system firmware 172. More specifically, the SRoT engine 143 verifies the initial portion of the system firmware 172 and loads it into the volatile memory 151 of the secure enclave 140 so that the initial portion is now trusted. Furthermore, the SRoT engine 143 locks the memory 151 to prevent writes before loading the firmware portion into the volatile memory 151. After successfully verifying the initial portion of firmware 172, SRoT engine 143 releases security processor 150 from the reset state to allow security processor 150 to execute the loaded firmware instructions.

[0045] By executing these firmware instructions, the security processor 150 can then verify one or more portions of the system firmware 172, including additional instructions for execution by the security processor 150. Furthermore, according to an example implementation, the security processor 150 also verifies another portion of the system firmware 172 corresponding to a portion of the BMC's management firmware stack. Upon successful verification, the security processor 150 loads this portion of the firmware stack into the volatile memory 155 of the management plane 130, which can then be executed by the main processing core 154 (when released from a reset state). This causes the main processing core 154 to load an additional portion of the firmware 172 and place the loaded portion in volatile memory 164 external to the BMC 129. Access to volatile memory 164 may involve additional training and initialization steps (e.g., training and initialization steps as specified in the DDR4 specification). These instructions can be executed from the verified portion of the BMC's firmware management stack in volatile memory 155.

[0046] Therefore, according to the example implementation, the cryptographic trust chain anchored by the SRoT engine 143 can be extended from SRoT to the firmware management stack executed by the BMC's main processing core 154. Furthermore, for the boot of host 101, the firmware management stack executed by the main processing core 154 can verify the host system firmware (such as UEFI 111 firmware), thereby extending the trust chain to the host system firmware.

[0047] According to the example implementation, the secure enclave 140 is entirely situated within an encrypted boundary. In this context, an "encrypted boundary" refers to a continuous boundary or perimeter that includes the logical and physical components of an encrypted subsystem, such as the BMC component forming the secure enclave. According to the example implementation, the secure enclave 140 is isolated from the BMC's management plane 130. In the context used herein, a "secure enclave" refers to a subsystem, such as the BMC 129, to which access is strictly controlled. A secure enclave may also be referred to as a "secure boundary," "secure perimeter," or any other similar term. The following is combined with… Figure 2 To describe in more detail an example structure for a secure enclave.

[0048] like Figure 1As depicted in the example implementation, the components of BMC 129 are located within a semiconductor package (or "chip") 157. Depending on the specific implementation, the semiconductor package 157 may include one or more dies (or "dice"). The semiconductor package 157 may have one of a variety of different forms. In one example, the semiconductor package 157 may include one or more dies (corresponding to their respective integrated circuits) mounted on a printed circuit board (PCB) substrate that interconnects these dies. In another example, the semiconductor package 157 may include multiple dies interconnected by bonding wires. In one example, the semiconductor package is packaged. In another example, the semiconductor package 157 is not packaged. In other examples, the semiconductor package 157 may correspond to any of a variety of different containers, such as surface mount packages, through-hole packages, ball grid array packages, small outline packages, or chip-size packages. Regardless of its specific form, the semiconductor package 157 is operatively electrically coupled to its integrated circuits to the motherboard of the computer platform 100.

[0049] According to an example implementation, computer platform 100 is a modular unit that includes a frame or chassis. Furthermore, the modular unit may also include hardware mounted to the chassis and capable of executing machine-readable instructions. In the example, computer platform 100 is a server, such as a blade server, rack server, or tower server. In other examples, computer platform 100 may be a component other than a server, such as a client, desktop computer, smartphone, wearable computer, networking component, gateway, network switch, storage array, portable electronic device, portable computer, tablet computer, thin client, laptop computer, television, modular switch, consumer electronics device, home appliance, edge processing system, sensor system, watch, removable peripheral card, or generally, any other processor-based electronic device.

[0050] According to an example implementation, computer platform 100 has an auxiliary power supply (not shown) that provides auxiliary power to BMC 129 when AC power is available (e.g., when the power cord of computer platform 100 is plugged into a power outlet). When the auxiliary power supply is available, BMC 129, including security enclave 140, is powered on. In one example, management processing core 154, memory 155, security enclave 140, networking components, and other components of BMC 129 are powered by the auxiliary power supply. Power-on to host 101 of the computer platform occurs later in response to a host power request. Host 101 is powered by mains power (not shown). In the context used herein, a “power-down restart” of computer platform 100 refers to a sequence that includes a mains power outage followed by a restart of host 101 after the mains power is restored. In one example, a power-down restart of computer platform 100 includes a mains power outage followed by a power restoration, while the auxiliary power supply remains powered on.

[0051] In the context used herein, "host" refers to a collection of components of computer platform 100 that have a non-abstract view of the resources of computer platform 100. Figure 1 In the example implementation depicted, resources for host 101 include a main CPU core 102 (e.g., a CPU processing core) and memory devices connected to the main CPU core 102 to form system memory 104. Host 101 operates under the control of an operating system 113 (e.g., a Linux operating system, a Windows operating system, or another operating system) independent of BMC 129. According to some implementations, computer platform 100 may include multiple hosts 101. According to an example implementation, BMC 129 provides management-related services and security-related services for each host 101.

[0052] The main CPU core 102 can be coupled to one or more I / O bridges 106, allowing communication between the main CPU core 102 and the BMC 129, as well as communication with various devices such as storage drives 122; one or more NICs 124; one or more Universal Serial Bus (USB) devices 126; I / O devices; video controllers; etc. Figure 1 As depicted, NIC 124 can be coupled to network architecture 161. Furthermore, as... Figure 1As depicted, the computer platform 100 may include one or more Peripheral Component Interconnect Rapid (PCIe) devices 110 (e.g., PCIe expansion cards), which may be coupled to the main CPU core 102 via a corresponding independent PCIe bus 108. According to a further example embodiment, the PCIe device 110 may be coupled to an I / O bridge 106 instead of the main CPU core 102. According to a further embodiment, the I / O bridge 106 and the PCIe interface may be part of the main CPU core 102.

[0053] Generally, the memory devices forming system memory 104, as well as other memories and storage media described herein, can be formed of non-transitory memory devices, such as semiconductor memory devices, flash memory devices, memristors, phase-change memory devices, and combinations of one or more of the above-mentioned memory technologies. Furthermore, the memory devices can be volatile memory devices (e.g., dynamic random access memory (DRAM) devices, static random access memory (SRAM) devices, etc.) or non-volatile memory devices (e.g., flash memory devices, read-only memory (ROM) devices, etc.), unless otherwise stated herein.

[0054] According to some implementations, one or more of the PCIe devices 110 may be intelligent input / output peripherals or "intelligent I / O peripherals" capable of providing backend I / O services for one or more applications 115 (or application instances) executing on computer platform 100. "Intelligent I / O peripherals" may also be referred to as data processing units (DPUs) or infrastructure processing units (IPUs). Generally, an intelligent I / O peripheral is a hardware processing unit that has been assigned a certain personality (e.g., programmed with a certain personality). Intelligent I / O peripherals may provide one or more backend I / O services (or "host offloading services") according to their personality. Backend I / O services may be non-transparent services (e.g., hypervisor virtual switch offloading services) or transparent services (encryption services, compression services, packet processing services, overlay network access services, and firewall-based network protection services).

[0055] According to the example implementation, network structure 161 may be associated with one or more types of communication networks, such as (as an example) Fibre Channel network, Computing High-Speed ​​Link (CXL) architecture, private management network, local area network (LAN), wide area network (WAN), global network (e.g., Internet), wireless network, or any combination thereof.

[0056] As used herein, an “engine” (such as recovery engine 142) can refer to one or more circuits. For example, these circuits can be hardware processing circuitry, which may include any one or a combination of microprocessors, cores of multi-core microprocessors, microcontrollers, programmable integrated circuits (e.g., programmable logic devices (PLDs), such as complex PLDs (CPLDs)), programmable gate arrays (e.g., field-programmable gate arrays (FPGAs)), application-specific integrated circuits (ASICs), or other hardware processing circuitry. An “engine” can refer to a combination of one or more hardware processing circuitry and machine-readable instructions (software and / or firmware) executable on said one or more hardware processing circuitry. In one example and as combined below… Figure 2 As further described, recovery engine 142 may be formed by a security processor (such as security processor 150) to execute machine-readable instructions stored in memory (such as non-volatile memory 151). In other examples, recovery engine 142 may be formed wholly or partially by a PLD, ASIC, FPGA or other hardware of BMC 129.

[0057] Figure 2 A block diagram of a bus interface controller monitoring and recovery architecture 200 (referred to herein as "architecture 200") according to an example implementation is depicted. (Refer to...) Figure 2 The architecture 200 includes N bus interface controllers 244 ( Figure 2 The bus interface controllers 244-1, 244-2, and 244-N are depicted in the document. Architecture 200 also includes a security enclave 240, which includes a bus interface controller recovery engine 242 (referred to herein as "recovery engine 242"), which, according to an example implementation, is configured to reset any of the controllers 244 exhibiting unresponsive behavior. Figure 1 The bus interface controller 146, security enclave 140, and recovery engine 142 are examples of bus interface controller 244, security enclave 240, and recovery engine 242, respectively. Figure 1 Similar to safe enclave 140, safe enclave 240 can be part of BMC and associated with the safety plane of BMC.

[0058] Bus interface controller 244-1 is located within secure enclave 242. In response to NVM access requests (e.g., read, write, and erase requests) generated by secure processor 250 of secure enclave 240, bus interface controller 244-1 generates signals on serial bus 245 to provide bus cycles on serial bus 245 for accessing the NVM. In one example, the NVM accessed via serial bus 245 may be secure memory storage for secure enclave 240, storing cryptographic elements (encryption keys, digital certificates, encryption seeds, encryption secrets, passwords, or other security-related information).

[0059] Bus interface controllers 244-2 to 244-N are located outside of secure enclave 240. In one example, bus interface controllers 242-2 to 244-N are BMCs (e.g., Figure 1 The NVM is part of the BMC 129 and belongs to the BMC's management plane. Bus interface controllers 244-2 to 244-N each generate signals on their respective serial buses 247 to provide bus cycles on the serial bus 247 to access the NVM. The NVM, coupled to the serial bus 245, can store any kind of data for the computer platform. In one example, the NVM can store system data (e.g., data related to the management engine, such as...) Figure 1 The NVM can store data associated with the management engine 107 and system firmware (e.g., BIOS firmware, firmware for booting the security processor 250, and BMC management stack firmware). In another example, the NVM can store UEFI applications.

[0060] Each of the bus interface controllers 244-2 to 244-N can receive requests 280 from various sources. For example, a given request 280 may be an instruction to read data from the NVM, write data to the NVM, erase the contents of the NVM, read the contents of the status register 264 of the bus interface controller 244, or write to the configuration register 264 of the bus interface controller 244.

[0061] In one example, request 280 includes request 286 originating from secure enclave 240. In one example, read request 286 is generated by SRoT engine 243 of secure enclave 240 to load firmware (e.g., an initial portion of the firmware) into non-volatile memory 252 of secure enclave 240 for execution by secure processor 250. In another example, read request 286 is generated by secure processor 250 to read register 264 of bus interface controller 244 to determine the state of the bus interface controller (e.g., busy, faulty, or other state). In another example, write request 286 is generated by secure processor 250 to set a reset bit in register 264 of bus interface controller 244 (e.g., a global configuration register) to put bus interface controller 244 into a reset state. In yet another example, write request 286 is generated by secure processor 250 to de-set the reset bit to release bus interface controller 244 from the reset state.

[0062] Request 280 also includes request 284 originating from the BMC's management plane. In one example, read request 284 is processed by the BMC's management processing core (e.g., Figure 1 The management processing core 154 in the middle generates instructions for loading the BMC firmware management stack into volatile memory (e.g., Figure 1 The process is executed by the management processing core 154 in the volatile memory 155.

[0063] Request 280 also includes a host originating from computer platform 100 (e.g., Figure 1 The request 282 from host 101 (although this request can be received via the management plane API and translated into another request sent to the bus interface controller 244 by the management plane). In one example, the main CPU core (e.g., Figure 1 The main CPU core 102 generates a read request 282 to load system firmware instructions (e.g., UEFI or BIOS instructions) into system memory (e.g., ...). Figure 1 In system memory 104, the data is processed by one or more CPU cores. In another example, the computer platform's management engine (e.g., Figure 1 In one example, the management engine 107 generates a read request 282 to read data representing the system management status. In another example, the management engine generates a write request 282 in response to a power outage on the computer platform to write system management data to the NVM.

[0064] Bus interface controller 244 includes register 264. In this example, register 264 includes a data transmit register, a data receive register, a flow control register, a command register, an address register, an error register, a global configuration register, and a command filter register. In one example, an entity submits a request to bus interface controller 244 by writing data to the appropriate register 264. In one example, a write request involves an entity writing to the command, address, and data registers 264 of bus interface controller 244. In another example, a read request involves an entity writing to the command and address registers 264 of bus interface controller 244 and reading the corresponding read data from the data register 264 of bus interface controller 244. In yet another example, register 264 includes a command filter register 264.

[0065] The bus interface controller 244 includes a bus control engine 270 for controlling communication with the NVM via a serial bus. The bus control engine 270 can be implemented using a portion of the hardware processing circuitry of the bus interface controller 244 or machine-readable instructions.

[0066] The bus interface controller 244 includes a command filter 268 configured to selectively allow or disable commands that allow access to the NVM (read or write). Examples of these commands include read commands for reading data, write commands for writing data, erase commands for deleting data (e.g., erase commands that can erase the entire memory or some specified portions of the memory), and / or other commands.

[0067] In some examples, command filter register 264 stores a list of commands. The "list" of commands can refer to a single command or multiple commands. In some examples, the command list includes a list of permitted commands that are allowed to be executed against the NVM. In such examples, when command filter 268 receives a command to access the NVM, command filter 268 compares the received command with the list of permitted commands. If the received command is part of the list of permitted commands, command filter 268 allows the received command to be executed against the NVM.

[0068] In a different example, the command list includes a list of unauthorized commands that are not permitted to be executed against the NVM. In such an example, command filter 268 compares the received command with the list of unauthorized commands, and if the received command is part of the list of unauthorized commands, command filter 268 prevents the received command from being executed against the NVM.

[0069] According to an example implementation, bus interface controller 244 blocks bus interface controller reset-related requests 280 from entities outside the secure enclave 240 (e.g., a host, management processing core). This allows recovery engine 242 to have exclusive control over resetting bus interface controller 244. In this context, a "reset-related request" (or "bus interface controller reset-related request") refers to a write operation that manipulates the reset state of bus interface controller 244, such as a write that puts bus interface controller 244 into a reset state or a write that releases bus interface controller 244 from a reset state.

[0070] According to an example implementation, the global configuration register 264 of the bus interface controller 244 has a bit that, when set (e.g., set or set to logic 1), places the bus interface controller 244 in a reset state, and when this bit is de-set (e.g., cleared or set to logic 0), releases the bus interface controller 244 from the reset state. The global configuration register 264 has a lock bit that, when set (e.g., set to logic 1), exclusively restricts writes to the reset bit to entities within the secure enclave 140. In one example, as part of BMC initialization, the recovery engine 242 sets the lock bit, and the lock bit cannot be de-set except by a secure enclave entity. After the lock bit is set, only a secure enclave entity (such as the recovery engine 242) can manipulate the state of the reset bit to place or release the bus interface controller 244 from the reset state. According to the example implementation, each request 280 carries an ownership code that allows the bus interface controller 244 to identify the entity associated with the request 280, and thus, when the lock bit is set, the bus interface controller 244 prevents entities outside the secure enclave 240 from manipulating its reset state.

[0071] like Figure 2 As shown, the secure enclave 240 is contained within a tightly controlled encrypted boundary 204. Generally, components of the secure enclave 240 can communicate with each other using bus infrastructure 256. According to an example implementation, bus infrastructure 256 may include features such as a data bus, control bus, address bus, system bus, one or more buses, one or more bridges, etc.

[0072] In one example, such as Figure 2As depicted, the recovery engine 242 is formed by a secure processor 250 that executes processor-readable instructions 254 stored in volatile memory 252. In another example, the recovery engine 242 may correspond to dedicated hardware circuitry that does not execute instructions. In yet another example, the recovery engine 242 may correspond to such dedicated hardware circuitry and a secure processor 250 that executes instructions. In one example, the volatile memory 252 is static random access memory (SRAM).

[0073] According to an example implementation, the secure enclave 240 includes a secure bridge 262 that controls access to the secure enclave 240 (i.e., establishes a firewall for the secure enclave 240) via a secure interconnect 263. As an example, the secure interconnect 263 may include a bus or internal interconnect structure, such as an Advanced Microcontroller Bus Architecture (AMBA) Advanced Scalable Interface (AXI) structure or an AMBA Advanced High-Performance Bus (AHB) structure.

[0074] According to an example implementation, the security bridge 262 includes an upstream interface to allow the security enclave 240 to "access" the security interconnect 263. This allows the recovery engine 242 to send requests to the bus interface controllers 244-2 to 244-N for purposes such as accessing registers to assess whether any of the bus interface controllers 244-2 to 244-N are exhibiting unresponsive behavior and to reset any bus interface controllers 244-2 to 244-N exhibiting unresponsive behavior. The security enclave 240 can use this upstream interface to access firmware (e.g., Figure 1 The system firmware 172 in the system is used to verify the firmware (e.g., verify the system firmware 172). Figure 1 The initial part of system firmware 172 in the system firmware) and load the firmware into (e.g., put Figure 1 The initial portion of the system firmware 172 is loaded into the volatile memory 252.

[0075] The secure bridge 262 can filter and monitor the secure interconnect 263 to prevent unauthorized access within the encrypted boundary 204. According to an example implementation, the BMC management plane (e.g., Figure 1 The management plane 130 can communicate with the security enclave 240 by executing one or more security service APIs, which are provided and processed by the security bridge 262.

[0076] Security Enclave 240 may include various components to provide security-related services to the computer platform. In one example, Security Enclave 240 includes an encryption processing engine 258 that encrypts data written to an NVM coupled to a bus interface controller interface 244-1 and decrypts data read from that NVM. In another example, Security Enclave 240 includes one or more encryption accelerators 260, such as symmetric and asymmetric encryption accelerators, that assist Security Processor 250 in operations such as key generation, signature verification, encryption, decryption, and hashing. Encryption accelerator 260 may include a true random number generator to provide a trusted source of entropy for encryption operations. Furthermore, encryption accelerator 260 may also include a deterministic random number generator (DRNG). In another example, security-related services include Security Enclave 240 detecting and reporting unexpected listings (e.g., observed listings that differ from those corresponding to the base platform certificate and any Delta platform certificate).

[0077] In another example of the additional components, the secure enclave 240 may include tamper detection circuitry that receives one or more environmental signals from the computer platform (e.g., sensor signals representing die temperature, clock rate, supply voltage value, housing open state, removal state, etc.) and uses these signals to detect tampering. In another example, the secure enclave 240 includes a set of one-time programmable (OTP) fuses for storing data representing immutable properties. Among its other features, the secure enclave 240 may have other components, as will be understood by those skilled in the art, that may be present in a processor-based architecture, such as timers, interrupt controllers, etc.

[0078] The unresponsive behavior of the bus interface controller 244 can be detected in any of a variety of different ways. In one example, such as... Figure 2 As depicted herein, the bus interface controller 244 includes a fault detection engine 266 that allows the controller 244 to self-detect unresponsive behavior. According to an example embodiment, the fault detection engine 266 monitors the state of the bus interface controller 244 corresponding to different portions of a bus cycle to determine whether a bus cycle or a portion thereof has taken an unexpectedly long time to complete. A bus cycle or a portion thereof taking an unexpectedly long time to complete is referred herein to as the bus interface controller 244 “hanging” or exhibiting unresponsive behavior. As further described herein, the fault detection engine 266 may use an expiration timer to determine when a bus cycle or a portion thereof has taken an unexpectedly long time to complete. When the fault detection engine 266 detects unresponsive behavior, it notifies the recovery engine 242. This notification may be made in a variety of different ways, as further described below.

[0079] Figure 3 The following describes a fault detection engine (such as...) according to an example implementation. Figure 2 The example state diagram 300 used by the fault detection engine 266 in the example is shown in Figure 266. (See Figure 266 for reference.) Figure 3 State diagram 300 depicts the states associated with a specific bus cycle and the corresponding state transitions.

[0080] More specifically, before the start of a bus cycle, the fault detection engine is in bus idle state 308. It's important to note that the fault detection engine can enter bus idle state 308 from reset state 304, which is the engine's initial state after the bus interface controller is reset. As depicted at 310, in response to the start of a new bus cycle, the fault detection engine transitions from bus idle state 308. More specifically, the fault detection engine transitions from bus idle state 308 to state 312, where the fault detection engine starts its timer set. In this context, "starting" a timer means initializing it so that it has an initial value and begins counting up or down, depending on the specific implementation.

[0081] The fault detection engine uses these timers to determine whether any particular portion of the bus cycle (e.g., a specific phase or the entire bus cycle) takes longer than expected to complete. According to an example implementation, a portion of the bus cycle taking longer than expected to complete corresponds to the bus interface controller exhibiting unresponsive behavior. In one example, the address phase of the SPI bus cycle corresponds to four bytes, or thirty-two bits. Therefore, the address phase should not exceed thirty-two SPI clock cycles. In one example, the fault detection engine includes an address phase timer set to expire thirty-three SPI clock cycles after the start of the address phase, and this timer expiration indicates that the address phase is longer than expected.

[0082] These timers measure the time taken to complete their respective associated phases of a bus cycle, and each timer indicates whether the associated phase took longer than expected to complete (or was never completed). In one example, the timers are expiration timers, and the bus interface controller stops or resets each expiration timer when the associated phase completes. If a particular expiration timer counts or measures for a period exceeding its respective threshold (e.g., the timer counts up and overflows, or the timer counts down and reaches zero), the timer provides a corresponding indication (e.g., setting an overflow flag) to indicate that the associated phase lasted longer than expected. In another example, the expiration timers include an expiration timer that measures the entire bus cycle to indicate whether the overall execution time lasted longer than expected.

[0083] In one example, the fault detection engine has a timer for each corresponding phase of the bus cycle. In one example, the bus cycle includes a command phase where the bus interface controller generates a bit sequence (e.g., a bit sequence representing a byte) that represents the command associated with the bus cycle (e.g., a write command, read command, or erase command). For example, for an SPI bus, all SPI commands are exactly one byte. Therefore, for instance, the fault detection engine includes a command phase timer that is set to expire after eight SPI clock cycles, and this timer expiration indicates that the command phase lasted longer than expected.

[0084] In another example, the bus cycle includes an address phase following the command phase, and the bus interface controller has a corresponding address phase timer, such as the address timer for the SPI bus discussed above. During the address phase, the bus interface controller generates a bit sequence representing the target address of the NVM (e.g., a sequence representing multiple bytes). In another example, the bus cycle includes a virtual phase following the address phase. In the virtual phase, the bus interface controller waits for a response from the NVM. In one example, the virtual phase for a read transaction involves the bus interface controller waiting for the NVM to respond with the requested data.

[0085] According to the example implementation, the fault detection engine may further include an execution timer corresponding to the overall time of completing a bus cycle. When the bus interface controller initiates a bus cycle, it knows the instruction, clock frequency, and controller configuration. Based on this information, the bus interface controller determines the precise execution time. In the example for the SPI bus, the bus cycle for the erase command does not have any address phase, virtual phase, or data phase. The bus cycle for the erase command should complete within approximately eight SPI clock times plus a small margin (e.g., two SPI clocks) to account for state machine overhead. Therefore, for this example, the bus interface controller sets the execution timer to expire within ten clock cycles or within 400 nanoseconds (ns) for a 25 MHz SPI clock frequency.

[0086] In another example for the SPI bus, for a bus cycle corresponding to a 256-byte write, the bus interface controller determines the execution time based on the following: eight SPI clocks for the command phase; thirty-two SPI clocks for the address phase; 2048 (i.e., 256x8) SPI clocks for transferring data to the NVM; and a small margin for state machine overhead. In another example for the SPI bus, for a bus cycle corresponding to a 100-byte read, the bus interface controller determines the execution time based on the following: eight SPI clocks for the command phase; thirty-two SPI clocks for the address phase; up to eight SPI clocks for the virtual phase; 800 (i.e., 100x8) SPI clocks for fetching data from the NVM; and a small margin for state machine overhead.

[0087] After the timer is started, the fault detection engine transitions from state 312 through a series of states to check the corresponding expired timer. According to the example implementation, checking the timer includes the fault detection engine determining whether the timer has expired. Figure 3 As shown, the fault detection engine first transitions from state 312 to state 316. In state 316, the fault detection engine checks the instruction timer to determine if the command phase of the bus cycle has lasted longer than expected. In other words, the fault detection engine checks if the instruction timer has expired. If the instruction timer has expired, the fault detection engine transitions to state 350.

[0088] In state 350, the fault detection engine notifies the recovery engine about the detected unresponsive behavior. The notification can be done in any of a few different ways. In one example, the fault detection engine sets an interrupt, and the recovery engine corresponds to the interrupt service routine that resets the bus interface controller in response to that interrupt. In another example, notifying the recovery engine involves the fault detection engine setting (e.g., setting to a logic 1 value) the status register of the bus interface controller (e.g., ...). Figure 2 The recovery engine polls the status register (264) to indicate the detected unresponsive behavior. In one example, as further described herein, the recovery engine polls the status register and uses this polling to detect the set bit. In another example, setting the bit causes the bus interface controller to generate an interrupt, which is serviced by the interrupt service routine corresponding to the recovery engine.

[0089] If, in state 316, the fault detection engine determines that the command phase did not last longer than expected, then, as shown at 320, the fault detection engine transitions to state 324 to check the address timer. If the address timer indicates that the address phase lasted longer than expected, then, as shown at 326, the bus interface controller transitions to state 350 and notifies the recovery engine. Otherwise, as shown at 328, the fault detection engine transitions to state 332.

[0090] In state 332, the fault detection engine checks the virtual timer to determine if the virtual phase of the bus cycle has lasted longer than expected. As shown at 334, if the virtual phase of the bus cycle has lasted longer than expected, the fault detection engine transitions to state 350 and notifies the recovery engine. Otherwise, as shown at 336, the fault detection engine transitions to state 340.

[0091] In state 340, the fault detection engine checks the execution timer. The execution timer measures the total time of a bus cycle, and expires if a bus cycle lasts longer than expected. If this occurs, the fault detection engine transitions to state 350 and notifies the recovery engine, as shown at 342. Otherwise, as shown at 344, the fault detection engine transitions back to bus idle state 308. It is understood that if the fault detection engine transitions from state 340 back to bus idle state 308, the bus interface controller has not failed and therefore does not exhibit any unresponsive behavior associated with the bus cycle.

[0092] Reference Figure 4 Sequence flowchart 400 depicts the actions taken by the recovery engine 450 and the bus interface controller 444, according to an example implementation, to detect and repair unresponsive behavior of the bus interface controller 444. Figure 4 As shown, the recovery engine 450 is a component of the safety enclave 440. Furthermore, for this example, the bus interface controller 444 includes a fault detection engine 466 for self-detection of unresponsive behavior of the bus interface controller 444. Figure 1 Recovery Engine 142 and Figure 2 Recovery Engine 242 in the example is Recovery Engine 450. Figure 1 The bus interface controller 146 and Figure 2 The bus interface controller 244 in the example is a bus interface controller 444. Figure 2 The fault detection engine 266 in the middle is Figure 4 An example of the fault detection engine 466 is shown. In addition to the fault detection engine 466, the bus interface controller 444 also includes a bus control engine 470, a fault status register 464, and a global configuration register 465. Figure 2Register 264 in the example is the fault status register 464 and the global configuration register 465. Figure 2 Bus control engine 270 in the text is an example of bus control engine 470.

[0093] According to sequence flowchart 400, bus control engine 470 generates signals on the serial bus to control bus cycles. In this example, a bus cycle may be associated with a read transaction, a write transaction, or an erase transaction. As shown at 404, fault detection engine 466 determines whether a timeout has occurred that is related to a specific phase of the bus cycle or to the overall execution time of the bus cycle.

[0094] In this example, the fault detection engine 466 determines that a timeout has occurred, and as shown at 406, the fault detection engine 466 updates the fault status register 464 (e.g., sets a specific bit in register 464) to indicate the detected timeout. In other words, the update of the fault status register indicates that the fault detection engine 466 has detected that the bus interface controller 444 is exhibiting unresponsive behavior.

[0095] By updating the fault status register 464, the fault detection engine 466 notifies the recovery engine 450 of the detected unresponsive behavior. As shown at 410, the recovery engine 450 detects the timeout (i.e., becomes aware of the fault detection engine's notification). In one example, the recovery engine 450 detects the timeout by polling the fault status register 464 to determine if a bit indicating the detected unresponsive behavior is set. In another example, the fault detection engine 466 triggers or starts an interrupt in the bus interface controller 444 upon the bit being set, and the recovery engine's detection of the timeout corresponds to an interrupt service routine.

[0096] Regardless of how the recovery engine 450 detects the timeout, it will continue to reset the bus interface controller 444. In one example, the reset is a soft reset, in which the recovery engine 450 writes to the global configuration register 465 of the bus interface controller 444 to reset the controller 444. More specifically, as shown at 414 and 415, the recovery engine 450 sets a bit in the global configuration register 465 (e.g., to a logic 1 value) to put the bus interface controller 444 into a reset state. Furthermore, as shown at 418 and 419, the recovery engine 450 then de-sets the same bit in the global configuration register 465 (e.g., to a logic 0 value) to release the bus interface controller 444 from the reset state.

[0097] In another example, the recovery engine 450 can perform a reset on the bus interface controller 444 other than a soft reset. For example, the recovery engine 450 can set and deset bits in registers (e.g., registers inside or outside the safe enclave) to manipulate the state of the external reset terminal of the bus interface controller 444.

[0098] Reference Figure 5 Sequence flowchart 500 illustrates the actions taken by recovery engine 550 and bus interface controller 544 to detect unresponsive behavior of bus interface controller 544 and reset bus interface controller 544. In these example embodiments, recovery engine 550, rather than a fault detection engine of bus interface controller 544, determines whether bus interface controller 544 exhibits unresponsive behavior. Recovery engine 550 is part of safety enclave 540. Figure 1 Safe Enclave 140 and Figure 2 Safe Enclave 240 is an example of Safe Enclave 540. Figure 1 Recovery Engine 142 and Figure 2 Recovery engine 242 is an example of recovery engine 550. Bus interface controller 544 includes status register 560 and global configuration register 565. Figure 1 The bus interface controller 146 and Figure 2 The bus interface controller 244 in the example is a bus interface controller 544. Figure 2 Register 264 in the table is an example of status register 560 and global configuration register 565.

[0099] As shown at 504 and 508, the busy bit of the recovery engine 550 polls the status register 560. According to an example implementation, the bus interface controller 544 uses the logical state of this busy bit to indicate whether it is currently processing a request. In one example, the bus interface controller 544 sets (e.g., sets to a logical 1 state) the busy bit to indicate that it is currently processing a request and cannot accept another request. In another example, the bus interface controller 544 desets (e.g., clears or sets to a logical 0 state) the busy bit to indicate that it is not processing a request and can therefore accept new requests.

[0100] In one example, the recovery engine 550 samples the logical state of the busy bit by polling to determine whether the time interval during which the busy bit has been set, as indicated by the sampling, exceeds a predetermined time interval threshold. In other words, by polling, the recovery engine 550 determines whether the current bus cycle has taken an unexpectedly long time. As shown at 504, in polling, the recovery engine 550 reads the busy bit and then continues until it determines whether the polling indicates that the time interval during which the busy bit has been set exceeds the predetermined time interval threshold, as shown at 508. In one example, the recovery engine 550 may read the busy bit in predetermined time increments, and the recovery engine 550 determines whether the predetermined time interval threshold has been exceeded based on multiple consecutive busy bit reads. Note that in response to the recovery engine 550 reading a busy bit that has been de-set, the recovery engine 550 will restart counting.

[0101] If the recovery engine 550 determines (e.g., by polling) that the bus interface controller 544 is exhibiting unresponsive behavior, the recovery engine 550 resets the bus interface controller 544. Figure 5 As shown, this reset can be a soft reset, in which the recovery engine 550 sets (block 512) a bit in the global configuration register 565 to put the bus interface controller 544 into a reset state, and then desets the bit (as shown at 516) to release the bus interface controller 544 from the reset state. According to a further example, the recovery engine 550 can use a reset method other than a soft reset to reset the bus interface controller 544, such as those described above. Figure 4 The method described above.

[0102] According to a further example implementation, the recovery engine can determine whether the bus interface controller is exhibiting unresponsive behavior in other ways. For example, according to a further example implementation, the recovery engine (such as...) Figure 1 Recovery Engine 142 or Figure 2 The recovery engine 242 uses register access as an indicator of whether the bus interface controller is exhibiting unresponsive behavior. In one example, the recovery engine attempts to write to a register of the bus interface controller (e.g., a register used to receive data representing the address of a command or request), and the recovery engine determines that the bus interface controller is exhibiting unresponsive behavior in response to the bus interface controller not acknowledging the write. In another example, the recovery engine attempts to read the contents of a register of the bus interface controller, and the recovery engine determines that the bus interface controller is exhibiting unresponsive behavior in response to the read failing.

[0103] Other implementations are envisioned, all within the scope of the appended claims. For example, according to a further example implementation, the entity submitting the request to the bus interface controller can send a message to notify the recovery engine (e.g., Figure 1 Recovery Engine 142 or Figure 2 The recovery engine 242 bus interface controller is exhibiting unresponsive behavior. In one example, the management processing core (e.g., Figure 1 The management processing core 154 can determine that the bus interface controller is exhibiting unresponsive behavior and send a corresponding message to the recovery engine. In one example, this message could be a security service API call, which is made by the recovery engine (such as...). Figure 2 The safe enclave (such as the recovery engine 242) in the middle Figure 2 The safety bridge (such as the safety enclave 240) in the middle) Figure 2 The security bridge (262) in the middle provides and handles this. In one example, the management processing core can determine that the bus interface controller is exhibiting unresponsive behavior based on the interaction between the management processing core and the bus interface controller (e.g., fault register polling or attempted register access).

[0104] In another example, the management processing core can be based on a fault detection engine (e.g., by the bus interface controller) Figure 2 The fault detection engine 266 in the system provides notifications or indications to determine that the bus interface controller is exhibiting unresponsive behavior. In another example, the management processing core can respond to a notification or indication from the application (e.g., ...). Figure 1 Application 115 in the process receives a message indicating a failure in the bus interface controller (e.g., a Redfish API call) and determines that the bus interface controller is exhibiting unresponsive behavior. In another example, in response to detecting that the bus interface controller is exhibiting unresponsive behavior, the SRoT engine (e.g., Figure 1 SRoT engine 143 or Figure 2 The SRoT engine (243) requests a reset of the bus interface controller. After the bus interface controller is reset, the SRoT engine can change the configuration of the bus interface controller and then try to use the bus interface controller again.

[0105] According to a further embodiment, the management controller, in addition to the baseboard management controller, may include a recovery engine for recovering the bus interface controller, as described herein. In one example, the management controller is a chassis management controller. In another example, the management controller is a smart I / O peripheral.

[0106] Reference Figure 6According to an example implementation, the management controller 600 includes a management plane 604 and a security enclave 610. In one example, the management controller 600 is a board management controller. In another example, the management controller 600 is a chassis management controller. In yet another example, the management controller is a smart I / O peripheral.

[0107] In one example, management plane 604 provides management services for the computer platform. For example, management services include operating system runtime services; resource detection and initialization; and pre-operating system services. In other examples, management services include monitoring telemetry values ​​(e.g., cooling fan speed, temperature sensors, and tamper indication sensors) and reporting unexpected or out-of-range telemetry values. In other examples, management services include detecting and reporting a list of expected values. In other examples, management services include remote management capabilities.

[0108] The management plane 604 includes a management hardware processor 606 and a bus interface controller 608. The management hardware processor 606 executes the firmware management stack to manage the host. The management controller is part of the computer platform and operates independently of the host. In one example, the firmware management stack is open-source firmware. In another example, the firmware management stack is the OpenBMC firmware management stack.

[0109] Bus interface controller 608 generates bus signals to access non-volatile memory. In one example, bus interface controller 608 is an SPI controller. In another example, bus interface controller 608 is an I2C controller. In yet another example, bus interface controller 608 is an I3C controller. In one example, the non-volatile memory includes a collection of NOR flash memory devices. In another example, the non-volatile memory includes a collection of NAND flash memory devices. In one example, the non-volatile memory stores system firmware. In one example, the non-volatile memory stores a firmware management stack image. In one example, the non-volatile memory stores system management data. In one example, the non-volatile memory stores a UEFI application. In one example, the non-volatile memory stores a BIOS image. In one example, the non-volatile memory stores power-on self-test instructions. In one example, the non-volatile memory stores firmware executed by the security processor of the management controller.

[0110] The secure enclave 610 is isolated from the management plane 604 and includes a hardware root trust engine 614 and a bus interface controller recovery engine 618. The hardware root trust engine 614 corresponds to a hardware root trust for the computer platform. In one example, the secure enclave 610 has an associated cryptographic boundary. In one example, the secure enclave 610 stores an immutable fingerprint, which the hardware root trust engine uses to verify the initial portion of the firmware stored in non-volatile memory before execution.

[0111] In one example, Security Enclave 610 provides security services for a computer platform. In one example, the security service includes firmware verification. In another example, the security service includes encryption services, including decryption and encryption. In one example, the security service includes managing the storage of cryptographic components of the computer platform. In one example, the security service includes monitoring environment indicators as part of providing computer platform tamper detection services. In one example, Security Enclave 610 includes an encryption accelerator. In one example, Security Enclave 610 includes a security bridge to control communication with Security Enclave 610 via the security service API.

[0112] In one example, the bus interface recovery engine 618 is formed by a secure processor of a secure enclave 610 that executes hardware processor-readable instructions. In another example, the bus interface recovery engine 618 includes dedicated hardware circuitry (e.g., an ASIC, FPGA, or PLD) of the secure enclave 610.

[0113] In response to bus interface controller 608 exhibiting unresponsive behavior, bus interface controller recovery engine 618 communicates with bus interface controller 608 to reset bus interface controller 608. In one example, the unresponsive behavior corresponds to bus interface controller 608 taking longer than expected to complete a bus cycle. In another example, the unresponsive behavior corresponds to bus interface controller 608 taking longer than expected to complete a specific phase of a bus cycle. In another example, the unresponsive behavior corresponds to bus interface controller 608 setting its busy bit for a longer than expected time interval. In another example, the unresponsive behavior corresponds to bus interface controller 608 not responding to register access attempts. In another example, the unresponsive behavior of bus interface controller 608 corresponds to the fault detection engine of bus interface controller 608 detecting unresponsive behavior. In another example, the unresponsive behavior of bus interface controller 608 corresponds to the recovery engine polling the fault register of bus interface controller 608 to detect unresponsive behavior. In another example, the unresponsive behavior of bus interface controller 608 corresponds to the recovery engine serving an interrupt generated by bus interface controller 608 since detecting unresponsive behavior.

[0114] In one example, in response to bus interface controller 608 exhibiting unresponsive behavior, bus interface controller recovery engine 618 writes to a register of bus interface controller 608 (e.g., a global configuration register) to perform a soft reset of bus interface controller 608. In another example, to reset bus interface controller 608, bus interface controller recovery engine 618 sets a bit in a register to put bus interface controller 608 into a reset state, and then desets the bit to release bus interface controller 608 from the reset state. In yet another example, bus interface controller recovery engine 618 sets and desets bits in registers (e.g., registers within or outside safety enclave 610) to manipulate the state of an external reset terminal of bus interface controller 608.

[0115] Reference Figure 7 According to an example implementation, computer platform 700 includes non-volatile memory 704, bus 708, bus interface controller 712, host 716, baseboard management controller 740, and security hardware processor 750. Bus 708 is coupled to non-volatile memory 704. Bus interface controller 712 includes register 714.

[0116] In one example, computer platform 700 is a server, such as a blade server, rack server, or tower server. In other examples, computer platform 700 is a client, desktop computer, smartphone, wearable computer, networking component, gateway, network switch, storage array, portable electronic device, portable computer, tablet computer, thin client, laptop, television, modular switch, consumer electronics device, home appliance, edge processing system, sensor system, watch, removable peripheral card, or in general, any other processor-based electronic device.

[0117] In one example, register 714 receives the command corresponding to the request. In another example, register 714 receives the data corresponding to the request. In yet another example, register 714 receives the address corresponding to the request.

[0118] The host 716 includes a hardware processor 720 that, in response to power-down of the host 716, writes data representing the state of the computer platform 700 to register 714, causing the bus interface controller 712 to generate a signal on bus 708 to store the data in non-volatile memory 704. In one example, the data stored in non-volatile memory 704 is system management data. In one example, the data stored in non-volatile memory 704 represents the state of the management engine of the computer platform 700. In one example, the management engine is part of the I / O bridge of the computer platform 100. In one example, the data stored in non-volatile memory 704 represents a replay protection table. In another example, the data stored in non-volatile memory 704 represents the firmware version executed by the management engine. In another example, the data stored in non-volatile memory 704 represents a default profile for the management engine. In yet another example, the data stored in non-volatile memory 704 represents a platform vendor-specific default profile for the management engine.

[0119] The baseboard management controller 740 includes a hardware processor 744 for executing instructions from the firmware management stack to manage the host 716. In one example, the hardware processor 744 includes one or more CPU cores. In one example, the firmware management stack is open-source firmware. In one example, the firmware management stack is the OpenBMC firmware management stack.

[0120] The security hardware processor 750 detects that the bus interface controller 712 has a predetermined health state. In response to detecting that the bus interface controller 712 has a predetermined health state, the security hardware processor 750 communicates with the bus interface controller 712 to reset the bus interface controller 712. In one example, the predetermined health state corresponds to a failure of the bus interface controller 712. In another example, the predetermined health state of the bus interface controller 712 corresponds to the bus interface controller 712 exhibiting unresponsive behavior.

[0121] In one example, the security hardware processor 750 communicates with the bus interface controller 712 to reset the bus interface controller 712, including the security hardware processor 750 performing a soft reset of the bus interface controller 712. In one example, to reset the bus interface controller 712, the security hardware processor 750 sets a bit in a register of the bus interface controller 712 to put the bus interface controller 712 into a reset state, and then the security hardware processor 750 desets the bit to release the bus interface controller 712 from the reset state.

[0122] Reference Figure 8According to an example implementation, technology 800 includes the host writing (block 804) data representing the state of the computer platform to the non-volatile memory of the computer platform in response to a power-down of the host of the computer platform. The bus interface controller is part of the baseboard management controller of the computer platform.

[0123] In one example, the computer platform is a server, such as a blade server, rack server, or tower server. In other examples, the computer platform is a client, desktop computer, smartphone, wearable computer, networking component, gateway, network switch, storage array, portable electronic device, portable computer, tablet computer, thin client, laptop, television, modular switch, consumer electronics device, home appliance, edge processing system, sensor system, watch, removable peripheral card, or generally any other processor-based electronic device.

[0124] In one example, a power outage of the computer platform includes turning off the main power supply to the computer platform. In another example, a power outage of the computer platform includes keeping the auxiliary power supply on to keep the computer platform powered on.

[0125] In one example, writing data to (block 804) nonvolatile memory includes writing system management data to that nonvolatile memory. In one example, the system management data represents the state of the computer platform's management engine. In one example, the management engine is part of the computer platform's I / O bridge. In one example, the system management data includes data representing a replay protection table. In another example, the system management data includes data representing the version of the firmware executed by the management engine. In another example, the system management data includes data representing a default profile used for the management engine. In yet another example, the system management data includes data representing a platform vendor-specific default profile used for the management engine.

[0126] The write (block 804) involves the host writing data to a register of the computer platform's bus interface controller. In one example, the write includes writing a command corresponding to that register. In another example, the write includes writing system management data to that register. In yet another example, the write includes writing an address corresponding to a request to that register.

[0127] Technique 800 includes the detection (block 804) of unresponsive behavior of the bus interface controller by a security processor of the baseboard management controller. In one example, unresponsive behavior corresponds to the bus interface controller taking longer than expected to complete a bus cycle. In one example, unresponsive behavior corresponds to the bus interface controller taking longer than expected to complete a specific phase of a bus cycle. In one example, unresponsive behavior corresponds to the bus interface controller having its busy bit set for a longer than expected time interval. In one example, unresponsive behavior corresponds to the bus interface controller not responding to register access attempts.

[0128] In one example, the detection (block 804) includes the bus interface controller's fault detection engine detecting unresponsive behavior. In another example, the detection (block 804) includes the security processor polling the bus interface controller's fault register. In yet another example, the detection (block 804) of the unresponsive behavior includes the security processor servicing an interrupt generated by the bus interface controller since the bus interface controller detected the unresponsive behavior. In yet another example, the detection (804) includes the hardware processing core of the baseboard management controller's management plane sending a message (e.g., making an API call) to the security processor.

[0129] Technique 800 includes resetting (block 812) the bus interface controller by a security processor in response to detecting unresponsive behavior of the bus interface controller. In one example, the reset (block 812) includes performing a soft reset on the bus interface controller. In another example, the reset (block 812) includes the security processor manipulating the state of the reset terminal of the bus interface controller.

[0130] According to an example implementation, the bus interface controller includes a fault status register, and the bus interface controller includes fault detection circuitry to detect faults associated with the bus interface controller. The fault detection circuitry causes the fault status register to indicate that a fault has been detected. A bus interface controller recovery engine reads the fault status register and resets the bus interface controller in response to the fault status register indicating that a fault has been detected. Among the potential advantages is that a faulty bus interface controller can be recovered without a power-on reboot of the computer platform.

[0131] According to an example implementation, the bus interface controller includes fault detection circuitry for detecting faults associated with the bus interface controller and generating an interrupt in response to the fault detection. A bus interface controller recovery engine resets the bus interface controller in response to the interrupt. A potential advantage is that a faulty bus interface controller can be recovered without a power-on restart of the computer platform.

[0132] According to an example implementation, the unresponsive behavior corresponds to at least one of the bus cycle associated with the bus interface controller or a phase of that bus cycle exceeding a predetermined time interval threshold. A potential advantage is that a faulty bus interface controller can be recovered without powering off the computer platform.

[0133] According to an example implementation, the bus interface controller includes a register. This register includes a bit indicating whether the bus interface controller is busy. A bus interface controller recovery engine polls this bit to determine if the time interval during which the bus interface controller has been busy exceeds a threshold duration. In response to determining that the time interval during which the bus interface controller has been busy has exceeded the threshold duration, the bus interface controller recovery engine resets the bus interface controller. Among the potential advantages is that a failed bus interface controller can be recovered without a power-on reboot of the computer platform.

[0134] According to an example implementation, the bus interface controller includes registers. A bus interface controller recovery engine attempts to access these registers, and the bus interface controller resets itself in response to a failed access attempt. A potential advantage is that a faulty bus interface controller can be recovered without a power-on reboot of the computer platform.

[0135] According to an example implementation, the management hardware processor generates an indication of whether the bus interface controller is exhibiting unresponsive behavior. In response to the indication that the bus interface controller is exhibiting unresponsive behavior, the bus interface controller recovery engine resets the bus interface controller. A potential advantage is that a faulty bus interface controller can be recovered without a power-on restart of the computer platform.

[0136] According to an example implementation, the instruction includes a message sent by the management processor to the bus interface controller recovery engine. Among the potential advantages is the ability to recover a faulty bus interface controller without powering off the computer platform.

[0137] According to an example implementation, the bus interface controller includes a register, and this register includes a bit for initiating a reset. The bus interface controller recovery engine writes to this register to manipulate the state of this bit to initiate a reset. Among the potential advantages is the ability to recover a faulty bus interface controller without powering off the computer platform.

[0138] In the context of this document, the BMC (Browser Control Center) is a dedicated service processor used to monitor the physical status of servers or other hardware using sensors and to communicate with the management system via a management network. The BMC can also communicate with applications running at the operating system level through IOCTL interface drivers, REST API calls, or other system software agents that facilitate communication between the BMC and applications. The BMC can have hardware-level access to hardware devices located in the server chassis, including system memory. The BMC can directly modify hardware devices. The BMC can run independently of the operating system of the system in which it resides. The BMC can be located on the motherboard or main circuit board of the server or other monitored device.

[0139] The fact that the BMC is mounted on the motherboard of the managed server / hardware or otherwise connected or attached to the managed server / hardware does not preclude the BMC from being considered "decoupled" from that server / hardware. As used herein, the BMC has the ability to manage the subsystems of the computing device and is decoupled from the processing resources that execute the operating system of the computing device. The BMC is decoupled from the processor (such as the central processing unit) that executes the advanced operating system or hypervisor on the system.

[0140] The detailed description set forth herein is with reference to the accompanying drawings. Where possible, the same reference numerals are used in the drawings and the foregoing description to refer to the same or similar parts. However, it should be clearly understood that the drawings are for illustrative and descriptive purposes only. While several examples have been described in this document, modifications, adjustments, and other embodiments are possible. Therefore, this detailed description does not limit the disclosed examples. Rather, the appropriate scope of the disclosed examples may be defined by the appended claims.

[0141] The terminology used herein is for the purpose of describing particular examples only and is not intended to be restrictive. As used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. As used herein, the term “multiple” is defined as two or more. As used herein, the term “another” is defined as at least a second or more. As used herein, the term “connection” is defined as a connection, whether a direct connection without any intermediate elements or an indirect connection using at least one intermediate element, unless otherwise stated. Two elements may be mechanically, electrically, or communicatively linked together by a communication channel, path, network, or system. As used herein, the term “and / or” refers to and covers any one of the associated listed items and all possible combinations thereof. It should also be understood that while the terms first, second, third, etc., may be used herein to describe various elements, these elements should not be limited by these terms, as these terms are only used to distinguish one element from another, unless otherwise stated or indicated by the context. As used herein, the term “comprising” means including but not limited to. The term "based on" means at least partially based on.

[0142] While this disclosure has been described with respect to a limited number of embodiments, many modifications and variations will be understood by those skilled in the art upon which this disclosure is received. The appended claims are intended to cover all such modifications and variations.

Claims

1. A management controller, the management controller comprising: Management plane, the management plane including: A management hardware processor is used to execute a firmware management stack to manage the host, wherein the management controller is part of the computer platform and wherein the management controller operates independently of the host; Bus interface controller, used to generate bus signals for accessing non-volatile memory; and A safe enclave, isolated from the management plane, wherein the safe enclave comprises: A hardware root trust engine, which corresponds to a hardware root trust engine for the computer platform; and A bus interface controller recovery engine is used to communicate with the bus interface controller to reset the bus interface controller in response to the bus interface controller exhibiting unresponsive behavior.

2. The management controller as described in claim 1, wherein: The bus interface controller includes a fault status register; The bus interface controller includes a fault detection circuit for detecting faults associated with the bus interface controller. The fault detection circuit causes the fault status register to indicate that the fault has been detected. as well as The bus interface controller recovery engine reads the fault status register and resets the bus interface controller in response to the fault status register indicating that the fault has been detected.

3. The management controller as described in claim 1, wherein: The bus interface controller includes a fault detection circuit for detecting faults associated with the bus interface controller and generating an interrupt in response to detecting the fault. as well as The bus interface controller recovery engine resets the bus interface controller in response to the interrupt.

4. The management controller as described in claim 1, wherein, The unresponsive behavior corresponds to at least one of the bus cycles or phases of the bus cycle associated with the bus interface controller exceeding a predetermined time interval threshold.

5. The management controller as described in claim 1, wherein: The bus interface controller includes registers; The register includes bits indicating whether the bus interface controller is busy; and The bus interface controller recovery engine is further used for: Poll the bit to determine if the bus interface controller is busy for a time interval exceeding a threshold duration; as well as In response to determining that the time interval during which the bus interface controller is busy exceeds the threshold duration, the bus interface controller is reset.

6. The management controller as claimed in claim 1, wherein: The bus interface controller includes registers; and The bus interface controller recovery engine is further used for: Attempt to access the register; and The bus interface controller is reset in response to a failed access attempt.

7. The management controller as claimed in claim 1, wherein: The management hardware processor is used to generate indications of the health status of the bus interface controller; and The bus interface controller recovery engine is further configured to reset the bus interface controller in response to an indication that the bus interface controller is exhibiting unresponsive behavior.

8. The management controller as claimed in claim 7, wherein, The instruction includes a message sent by the management hardware processor to the bus interface controller to restore the engine.

9. The management controller as claimed in claim 1, wherein: The bus interface controller includes registers; The register includes bits for initiating the reset; and The bus interface controller recovery engine is used to write to the register to manipulate the state of the bit in order to initiate the reset.

10. The management controller of claim 1, further comprising: An additional bus interface controller, wherein the monitoring engine selectively resets the additional bus interface controller based on its health status.

11. The management controller as claimed in claim 10, wherein, The additional bus interface controller is located in either the management plane or the secure enclave.

12. The management controller as claimed in claim 1, wherein, The non-volatile memory stores a firmware image associated with the startup of the computer platform.

13. A computer platform, the computer platform comprising: Non-volatile memory; A bus, which is coupled to the non-volatile memory; A bus interface controller, coupled to the bus, wherein the bus interface controller includes registers; A host computer, comprising a first hardware processor configured to, in response to power-down of the host computer, write data representing the state of the computer platform into the register, cause the bus interface controller to generate a signal on the bus, and store the data in the non-volatile memory; and A baseboard management controller, the baseboard management controller including a second hardware processor, the second hardware processor being configured to execute instructions of a firmware management stack to manage the host; and Security hardware processor, used for: The bus interface controller is detected to have a predetermined health state; and In response to detecting that the bus interface controller has the predetermined health state, communicate with the bus interface controller to reset the bus interface controller.

14. The computer platform as described in claim 13, wherein, The bus interface controller is part of the baseboard management controller, and the computer platform further includes a semiconductor package containing the baseboard management controller.

15. The computer platform as described in claim 13, wherein: The non-volatile memory stores a mirror image corresponding to the firmware management stack; The substrate management controller further includes volatile memory; and The security hardware processor is further configured to perform the following operations in response to power-on of the baseboard management controller: The bus interface controller is used to read the firmware management stack from the non-volatile memory; and The firmware management stack is stored in the volatile memory.

16. The computer platform of claim 13, further comprising: A bridge, the bridge including a management engine separate from the baseboard management controller, wherein the management engine is used to write data to the non-volatile memory using the bus interface controller in response to the computer platform undergoing a power-off restart.

17. A method, the method comprising: In response to the host power-down of the computer platform, the host writes data representing the state of the computer platform into the non-volatile memory of the computer platform, wherein the writing includes the host writing the data into the register of the bus interface controller of the computer platform, and wherein the bus interface controller is part of the baseboard management controller of the computer platform. The security processor of the baseboard management controller detects the unresponsive behavior of the bus interface controller; as well as In response to the detection of the unresponsive behavior of the bus interface controller, the security processor resets the bus interface controller.

18. The method of claim 17, further comprising: The bus interface controller detects the timeout of its operation. as well as In response to the timeout detected in the operation, the bus interface controller provides a notification of the timeout detected in the operation. Detecting the non-responsive behavior includes receiving the notification by the security processor.

19. The method of claim 17, further comprising: The security processor polls the state of the registers of the bus interface controller in multiple polling transactions. Detecting the unresponsive behavior includes the security controller determining whether the bus interface controller exhibits the unresponsive behavior based on the polling.

20. The method of claim 17, wherein resetting the bus interface controller comprises: The security processor writes to the configuration register of the bus interface controller to transition a bit in the configuration register from a first logical state to a second logical state, wherein transitioning the bit from the first logical state to the second logical state transitions the bus interface controller to a reset state; and The security processor writes to the configuration register to transition the bit from the second logic state to the first logic state, wherein transitioning the bit from the second logic state to the first logic state releases the bus interface controller from the reset state.

Images