Abstract: An information handling system includes a hardware processor, a memory device operatively coupled to a serial peripheral interface (SPI) chip and the hardware processor. The SPI chip interfaces the hardware processor executing plural stages of boot modules during a boot process of the information handling system with allocated, reserved portions of the memory device for each stage of boot module executed in pre-boot, boot, and runtime via a virtual memory interface generated by execution of an original equipment manufacturer (OEM)-defined agnostic memory allocation module. The hardware processor executes the OEM defined agnostic memory allocation firmware to redefine the virtual memory interface for each allocated reserved portion of the memory device at each of the plural stages of the boot modules that are executed from pre-boot, through boot, and to runtime to provide adjustments to allocated, reserved portions of memory for later stages of executed plural stages of the boot modules.

Abstract: Systems and methods for diagnostics and remediation for a split-boot architecture are described. In an illustrative, non-limiting embodiment, an Information Handling System (IHS) may include: a printed circuit board; a processor coupled to the printed circuit board; and a memory coupled to the processor, wherein the memory comprises program instructions stored thereon that, upon execution by the processor, cause the IHS to: send, in a split boot architecture, one or more commands from executed firmware onboard the printed circuit board to executed extended firmware via a communication protocol; and based, at least in part, on a response or a lack of response from the executed extended firmware to the one or more commands, perform one or more responsive actions.

Abstract: Systems and methods for security for a split-boot architecture are described. In an illustrative, non-limiting embodiment, an Information Handling System (IHS) may include: a printed circuit board; a processor coupled to the printed circuit board; and a memory coupled to the processor, wherein the memory comprises program instructions stored thereon that, upon execution by the processor, cause the IHS to: obtain one or more cryptographic keys associated with firmware onboard the printed circuit board; and verify extended firmware using the cryptographic keys.

Abstract: In an information handling system that includes one or more PCIe devices, responsive to enumerating a PCIe device and adding the PCIe device to a configuration space of the platform, a mapping entry is added to a device handler mapping table to associate a device handler for the PCIe device with information for accessing the PCIe device. If the PCIe device fails to enumerate in a boot path, a virtual pseudo PCIe (VPP) node corresponding to the PCIe device may be created and enumerated to enable the boot to complete. Upon subsequently detecting and enumerating the actual, physical PCIe device, the VPP node and the PCIe device may be connected to enable the full functionality of the PCIe device without re-booting the platform.

Abstract: A disclosed method monitors boot path driver events to identify faulty boot path drivers in a UEFI-compliant boot path. Upon identifying a faulty boot path driver, the faulty driver is isolated and a corresponding remediation driver is fetched. An override driver dispatch list is created by modifying an original driver dispatch list to replace the faulty driver with the remediation driver, wherein the remediation driver occupies the same place in the execution order of the override driver dispatch list as the faulty driver occupies in the original driver dispatch list. Following a warm reset, a boot path load is performed in accordance with the override driver dispatch list, thereby remediating the boot path without performing a firmware update on a serial peripheral interface (SPI) flash device or the like. In this manner, a faulty driver is detected, isolated, and remediated in a single boot path.

Abstract: An information handling system includes a hardware processor, a memory device operatively coupled to a serial peripheral interface (SPI) chip and the hardware processor. The SPI chip interfaces the hardware processor executing plural stages of boot modules during a boot process of the information handling system with allocated, reserved portions of the memory device for each stage of boot module executed in pre-boot, boot, and runtime via a virtual memory interface generated by execution of an original equipment manufacturer (OEM)-defined agnostic memory allocation module. The hardware processor executes the OEM defined agnostic memory allocation firmware to redefine the virtual memory interface for each allocated reserved portion of the memory device at each of the plural stages of the boot modules that are executed from pre-boot, through boot, and to runtime to provide adjustments to allocated, reserved portions of memory for later stages of executed plural stages of the boot modules.

Abstract: Systems and methods for providing a seamless and secure motherboard replacement system and method are described. In some embodiments, an Information Handling System (IHS) may include a processor and a memory coupled to the processor, the memory having program instructions that, upon execution, cause the IHS to when a previous motherboard is replaced with a replacement motherboard; detect that the previous motherboard has been replaced with the replacement motherboard, access context data associated with the previous motherboard from a storage unit configured in the IHS, the context data comprising configuration settings of the previous motherboard, and update the replacement motherboard according to the stored context information.

Abstract: An information handling system includes a memory and a processor. The memory stores a current basic input/output system (BIOS) firmware image. During a regular boot mode of the information handling, the processor creates a first set of tables associated with the current BIOS firmware image, stores the first tables to the memory, and receives a BIOS firmware update image. During a BIOS update boot mode of the information handling system, the processor creates a second plurality of tables associated with the BIOS firmware update image, and compares the first and second tables. In response to a difference being determined between the first and second tables, the processor aborts the BIOS update boot mode and generate an error log.

Abstract: In one aspect, a disclosed method includes learning one or more chip agnostic parameters across a plurality of best known configuration (BKC) firmware versions, performing BKC attributes tuning based on said learning, implementing platform specific BKC table offsets and a handoff block to pass the table offsets to update routines by creating a trusted session for platform firmware table updates, and dynamically publishing changes in BKC policy. A BKC firmware serialization protocol may be implemented to ensure gaps in firmware versions at an end user platform are resolved by synchronizing each BKC version attribute. The serialization protocol may employ node-based cloud ecosystem learning. The method may further include reloading memory map parameters for uninterrupted services. The uninterrupted services may include, as examples, user presence detection after power resume and central processing unit (CPU) power cap functions.

Abstract: A disclosed fail-safe boot block method leverages embedded controller (EC) functionality to monitor power on self-test (POST) messages and, in response to detecting a POST error message, execute a sequence of main basic input/output system (BIOS) recovery operations including, in at least some embodiments, performing top-block swap recovery features supported by the platform. If the main BIOS recovery operations fail to resolve the POST error issue, e.g., fail to resolve a No Boot/No Post/No Video (NB/NP/NV) state of the platform, a resiliency boot block bit is set and a reset is executed to boot the platform, via a fail-safe boot block, into the safe BIOS mode for error analysis and corrective action. The fail safe boot block and the safe BIOS firmware may reside in a flash partition that is factory-programmed and sealed to prevent substantially any subsequent programming and/or of the storage device. Additional benefit of the fail-safe boot features are disclosed herein.

Abstract: This disclosure describes systems and methods for performing an update or multiple updates to firmware on an information handling system in a single reboot cycle. According to some aspects of the disclosure, firmware updates may be stored in a boot partition. During reboot, an information handling system may determine whether a firmware update is present in the boot partition, and when a firmware update is present performing the update. According to some aspects of the disclosure, performing the update may include creating a firmware update hand-off block (HOB), which may correspond to the firmware update and identify where the update is stored in the boot partition.

Abstract: Systems and methods for telemetry driven platform restoration for a split-boot architecture are described. In an illustrative, non-limiting embodiment, an Information Handling System (IHS) comprises a printed circuit board (PCB); a processor coupled to the PCB; and a memory coupled to the processor, wherein the memory comprises program instructions stored thereon that cause the IHS to: obtain, in a split boot architecture, telemetry data from firmware onboard the PCB, and from extended firmware; and detect one or more boot failure events using the obtained telemetry data. In another embodiment, a method comprises obtaining first telemetry data associated with a first firmware executed, during a boot process, by a first hardware component of an IHS; obtaining second telemetry data associated with a second firmware executed, during the boot process, by a same or different hardware component; and detecting a boot failure event using the first and second telemetry data.

Abstract: An information handling system includes a memory and a processor. The memory stores a current basic input/output system (BIOS) firmware image. During a regular boot mode of the information handling, the processor creates a first set of tables associated with the current BIOS firmware image, stores the first tables to the memory, and receives a BIOS firmware update image. During a BIOS update boot mode of the information handling system, the processor creates a second plurality of tables associated with the BIOS firmware update image, and compares the first and second tables. In response to a difference being determined between the first and second tables, the processor aborts the BIOS update boot mode and generate an error log.

Abstract: An information handling system includes a memory device, a memory, a chipset, and a basic input/output system (BIOS). The chipset includes a main processor and a hybrid processor. During a first pre-boot phase, the BIOS memory maps the hybrid processor to a first portion of the memory device, and stores an embedded operating system in the memory. During a second pre-boot phase, the BIOS memory maps the main processor to a second portion of the memory device, stores a host operating system in the memory, and loads the embedded operating system on the hybrid processor. The second portion is a larger portion of the memory device than the first portion.

Abstract: An information handling system may include at least one processor and an information handling resource. The information handling system may be configured to enable memory-mapped input/output (MMIO) communication between a program executing on the at least one processor and the information handling resource via a sealed memory region based on a cryptographic trust relationship existing between the program and the information handling resource.

Abstract: An information handling system may include at least one processor and a storage resource having a bare-metal operating system thereon. Upon a first boot of the information handling system, the bare-metal operating system may deploy a hypervisor to be executed by the at least one processor; and implement a device enumeration protocol mapping virtual objects associated with the bare-metal operating system to virtual device objects associated with the hypervisor.

Abstract: Methods and system disclosed herein provide secure sensor hub enumerations to support native sensor behavior that is vulnerability free and does not permit sensor behavior overrides. In addition, disclosed subject matter enables a firmware protocol to dynamically sense vendor attributes and enumerate a unified layer that handles multiple tailored sensor hub APIs to run seamless sensor operations across various chipset vendors and to enable sensor attribute reset without a need for factory defaults. Disclosed methods may create an abstracted firmware map used to dynamically generate a runtime sensor memory map that is independent of silicon vendor to abstract the flash payload with sensor HID attribute objects.

Abstract: Disclosed subject matter implements a secure, cloud-based boot sequence for a recovery OS. In at least some embodiments, a three phase solution is employed. The first phase, which may occur during the DXE phase of a boot sequence, establishes trust by configuring at least a portion system memory as a trust zone RAM disk and attesting modules that interact with the RAM disk. The second phase downloads file from the cloud and performs a cumulative hash verification and handshaking with the EC. During the third phase, a memory identification table for the trust zone s migrated to OS runtime environment to enable secured, OS runtime access to the RAM disk contents.

Abstract: Disclosed methods enable a mutable OEM identity to dynamically perform context-specific rebranding as part of a zero trust platform boot. This zero trust rebrand (ZTR) boot may implement an OEM security context identity method to fully ensure trusted rebrand boot paths against tampered, vulnerable, or corrupted payloads while leveraging existing customer-agnostic secure boot flow. Disclosed platforms may implement context-specific mutable entities via multiple boot paths to support the dynamic rebranding. A factory deploy engine may perform a bare metal deploy with a disclosed OEM security identity protocol, initialized by enumerating, for each of one or more OEMs, all OEM context attributes required for dynamic rebrand support. The rebrand protocol may create a protected namespace in non-volatile storage, e.g., a serial peripheral interface (SPI) flash area, to perform a once-only store of all OEM-specific mutable entities.

Abstract: Disclosed subject matter enables early PEI phase initialization of GPU cores and dynamic configuration of the GPU core computing to accept sliced workloads for parallel execution. Disclosed methods dynamically adapt based on various factors to a graphics rendering context determined based on factors such as the connected monitors, their various resolutions, etc., to provide advanced GPU rendering in pre-boot operating environment. Methods and systems may support pre-boot hybrid graphics rendering including dynamic utilization of integrated and discrete GPU cards/memory, along with the central processing unit (CPU) and cache to provide seamless and faster graphics rendering operations for all preboot requirements.