Abstract: Systems and methods for a memory architecture for Out-of-Band (OOB) manageability in heterogeneous computing platforms. In some embodiments, an Information Handling System (IHS) may include: a heterogeneous computing platform having a plurality of devices, and an OOB Microcontroller Unit (MCU) integrated into the heterogeneous computing platform, where the OOB MCU is configured to: identify a command in an OOB packet received while a host processor is in a low-power state, and determine, based at least in part upon the command, whether to wake up an external memory device coupled to the heterogeneous computing platform.

Abstract: Systems and methods for enabling Out-of-Band (OOB) management of heterogeneous computing platforms in low-power states. In some embodiments, an Information Handling System (IHS) may include a heterogeneous computing platform and an Embedded Controller (EC) integrated into or coupled to the heterogeneous computing platform, where the EC is configured to: wake up from a low-power state while a host processor of the heterogeneous computing platform remains in the low-power state, and wake up a network device configured to access a cloud service through an OOB channel to check a status of an OOB command buffer while the host processor remains in the low-power state.

Abstract: Systems and methods for routing manageability data in heterogeneous computing platforms. In some embodiments, an Information Handling System (IHS) may include a heterogeneous computing platform comprising a plurality of devices and an Out-of-Band (OOB) Microcontroller Unit (MCU), an Embedded Controller (EC), or a network device integrated into or coupled to the heterogeneous computing platform and distinct from any host processor of the heterogeneous computing platform, where the OOB MCU, EC, or network device is configured to receive a packet or command from a cloud service, and send the packet or command to a selected one of the plurality of devices.

Abstract: Systems and methods for a security architecture for Out-of-Band (OOB) manageability in heterogeneous computing platforms. In some embodiments, an Information Handling System (IHS) may include a heterogeneous computing platform and an OOB Microcontroller Unit (MCU) integrated into the heterogeneous computing platform, where the OOB MCU is configured to receive a command and transmit the command or an indication of the command to a crypto device via an interconnect while a host processor is in a low-power state.

Abstract: Systems and methods for manageability data handling for heterogeneous computing platforms. In some embodiments, an Information Handling System (IHS) may include: a heterogeneous computing platform and an Out-of-Band (OOB) Microcontroller Unit (MCU) integrated into or coupled to the heterogeneous computing platform, where the OOB MCU is configured to receive, from a cloud service, a packet stored in a command buffer associated with the IHS, and where the packet comprises at least one of: a baseline packet, or an opaque packet.

Abstract: Systems and methods for network connectivity for Out-of-Band (OOB) processors in heterogeneous computing platforms. In some embodiments, an Information Handling System (IHS) may include an OOB Microcontroller Unit (MCU) integrated into a heterogeneous computing platform and a network device coupled to the heterogeneous computing platform, where the OOB MCU is configured to communicate with the network device via a high-speed bus.

Abstract: Systems and methods for power management of Out-of-Band (OOB) processors in heterogeneous computing platforms. In some embodiments, a heterogeneous computing platform may include: a first, low-power domain including a first set of one or more devices, where the first, low-power power domain is configured to receive a first voltage supply during an Out-of-Band (OOB) packet sniffing operation while a second set of one or more devices is in a low-power state; and a second, high-power domain including the second set of one or more devices, where the second, high-power domain is configured to receive a second voltage supply under control of at least one of the first set of one or more devices.

Abstract: Systems and methods for Unified Extensible Firmware Interface (UEFI)-level processing of Out-of-Band (OOB) commands in heterogeneous computing platforms. In some embodiments, an Information Handling System (IHS) may include: a heterogeneous computing platform having a plurality of devices, and an OOB Microcontroller Unit (MCU), Embedded Controller (EC), or networking device integrated into or coupled to the heterogeneous computing platform and distinct from a host processor of the heterogeneous computing platform, where the OOB MCU, EC, or networking device is configured to: receive an OOB packet while the host processor is in a low-power state, and execute an OOB command contained in the OOB packet, by the host processor, at least in part through initialization of UEFI without initialization of any video device.

Abstract: Systems and methods for Out-of-Band (OOB) networking for heterogeneous computing platforms in low-power states. In some embodiments, an Information Handling System (IHS) may include a heterogeneous computing platform and a network device integrated into or coupled to the heterogeneous computing platform, and the network device may be configured to: wake up from a low-power state while a host processor of the heterogeneous computing platform remains in the low-power state, and access a cloud service through an OOB channel to check a status of an OOB command buffer while the host processor remains in the low-power state.

Abstract: Systems and methods for an interconnect architecture for Out-of-Band (OOB) manageability in heterogeneous computing platforms. In some embodiments, an Information Handling System (IHS) may include a heterogeneous computing platform having a plurality of devices and an OOB Microcontroller Unit (MCU) integrated into the heterogeneous computing platform, where the OOB MCU is configured to: receive a command; and transmit the command or an indication of the command to a selected one of the plurality of devices via an interconnect while a host processor is in a low-power state.

Abstract: An information handling system determines a fan speed value based on a current fan speed value and at least one factor, and transmits the fan speed value instead of the current fan speed value to an operating system scheduler. The system may also determine a fan acoustic level based on the fan speed value, and perform an action based on the fan acoustic level.

Abstract: Embodiments allow for multiple instances of a state machine to connect with multiple clients. Additionally, a plurality of connection states, while maintaining a connection with a single physical client device, may support multiple modes. For example, a wireless peripheral device determines whether it is paired with a client device and connects if it is, by selecting a saved long term bonding key, based on a user selected device mode. When a scan timeout expires, the device switches to another saved bonding key. When an overall connection timeout expires, these steps repeat. If the device is not already paired, it pairs with a client by setting long term paring key generation key(s), bonding with the client using the generation key(s) to generate a paring key, distributing the pairing key to the client, and saving the pairing key, as a bonding key, based on user selected device mode.

Abstract: Managing firmware updates of an information handling system (IHS), including performing, at a first time, a calibration and configuration of a firmware update risk model, including: identifying predictor data associated with a plurality of IHS; training, based on the predictor data, the firmware update risk model, including generating a configuration policy including configuration rules, the configuration rules for performing computer-implemented actions responsive to a firmware update; receiving, at a second time, the firmware update at a particular IHS, and in response: identifying particular predictor data of the particular IHS; in response to identifying the particular predicator data of the particular IHS, i) accessing the firmware update risk model including the configuration policy, ii) identifying one or more of the configuration rules based on the identified particular predicator data, and iii) applying the one or more configuration rules to perform computer-implemented actions responsive to receivin

Abstract: Managing firmware updates of an information handling system (IHS), including performing, at a first time, a calibration and configuration of a firmware update risk model, including: identifying predictor data associated with a plurality of IHS; training, based on the predictor data, the firmware update risk model, including generating a configuration policy including configuration rules, the configuration rules for performing computer-implemented actions responsive to a firmware update; receiving, at a second time, the firmware update at a particular IHS, and in response: identifying particular predictor data of the particular IHS; in response to identifying the particular predicator data of the particular IHS, i) accessing the firmware update risk model including the configuration policy, ii) identifying one or more of the configuration rules based on the identified particular predicator data, and iii) applying the one or more configuration rules to perform computer-implemented actions responsive to receivin

Abstract: An information handling system may include at least one processor, and a memory coupled to the at least one processor. The information handling system may be configured to: detect a problem during a boot of the information handling system; transmit telemetry data associated with the problem to at least one remote telemetry server, wherein the at least one remote telemetry server is configured to analyze the telemetry data and other telemetry data from other information handling systems; receive resolution instructions from the at least one remote telemetry server; and implement a resolution of the detected problem based on the resolution instructions.

Abstract: An information handling system may include at least one processor, a memory coupled to the at least one processor, and an information handling resource including a firmware. The information handling system may be configured to: boot into an operating system stored on the memory; after booting into the operating system, receive, from at least one remote server, information regarding a vulnerability associated with the firmware; based on a security policy, determine a resolution for mitigation of the vulnerability; and store information regarding the resolution in a storage location accessible to a preboot environment of the information handling system, wherein the preboot environment is configured to apply the resolution upon a subsequent boot of the information handling system.

Abstract: Embodiments of information handling systems (IHS) and computer implemented methods are disclosed herein to proactively restore missing firmware components to a computer readable storage device of an IHS. In one embodiment, a method may execute a first set of program instructions, before an operating system (OS) is loaded into a system memory of the IHS, to determine if one or more firmware components previously stored within the computer readable storage device is/are missing. If the first set of program instructions determines at least one firmware component is missing, the method may execute additional program instructions to retrieve a copy of the missing firmware component(s) from a remotely located system, and store the retrieved copy of the missing firmware component(s) within the computer readable storage device. The additional program instructions can be executed before the OS is loaded in some embodiments, and after the OS is loaded in other embodiments.

Abstract: Embodiments of information handling systems (IHS) and computer implemented methods are disclosed herein to restore system firmware to a selected restore point. In one embodiment, the IHS may include a computer readable non-volatile memory configured to store system firmware, a computer readable storage device configured to store an operating system (OS), a system registry, and an OS restore application, and a processing device configured to execute program instructions within the OS restore application to restore the system registry to a selected restore point and reboot the IHS. As the IHS is in the process of being rebooted, the processing device may execute program instructions within a firmware restore application stored within the computer readable non-volatile memory or the computer readable storage device to restore the system firmware to the selected restore point.

Abstract: The present disclosure provides an information handling system (IHS) and related methods that use physical presence verification to establish unique trust relationships between boot firmware and one or more individual applications provided within an IHS. The IHS and methods disclosed herein provide secure verification of user physical presence by verifying the physical presence of a user during a pre-boot phase of the boot firmware (i.e., before an operating system (OS) is loaded and running). After user physical presence is verified during the pre-boot phase, the IHS and methods disclosed herein generate a physical presence (PP) bind token during OS runtime that may be used to establish a unique trust relationship between the boot firmware and one or more individual applications provided within the IHS.

Abstract: Systems and methods for providing a tamper-proof, dual-boot Information Handling System (IHS) having Operating System (OS)-specific hardware and/or firmware components. In some embodiments, a method may include: producing, by an Embedded Controller (EC) of an IHS, a Real-Time Clock (RTC) battery-powered General-Purpose Input/Output (GPIO) control or external latch; applying the RTC battery-powered GPIO control to a chip select circuit; and selecting, via the chip select circuit: (i) a first flash memory configured to boot the IHS into a diagnostic mode or first OS, or (ii) a second flash memory configured to boot the IHS into a native OS.