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 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.

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.

Abstract: An information handling system may include at least one processor; and an interface via which one or more peripherals are configured to be communicatively coupled to the at least one processor; wherein the at least one processor is configured to execute instructions for: storing a data structure that includes data indicative of configuration settings for each of the one or more peripherals; communicating with the one or more peripherals according to the configuration settings of the data structure; and in response to an occurrence of a critical event that causes a loss of communication with the one or more peripherals, restoring the configuration settings based on the data structure without a reboot of the information handling system.

Abstract: A disclosed method retrieves a first set of time coordinated computing (TCC) attributes from firmware objects of an existing boot image and a second group of TCC attributes from firmware objects of an update boot image, such as a BKC firmware update. A runtime TCC attributes map is generated based on the first and second TCC attributes. Device-specific, TCC firmware objects are created for one or more devices based on the runtime TCC attributes map, and attributes of the one or more devices are tuned at OS runtime based on the device-specific time coordinated firmware objects. Disclosed teaching achieves silicon-agnostic seamless BKC firmware updates without compromising on platform performance against TCC attributes. At OS runtime, dynamic tuning to time TCC attributes for various system software modules which have a hard dependency on hardware/firmware can be achieved without a platform reboot.

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: An information handling system may determine an allocated space in an option read-only memory (ROM), and store a firmware module in the allocated space in the option ROM. The system may load basic input/output system firmware from a serial peripheral interface flash memory with the firmware module from the allocated space in the option ROM.

Abstract: A virtual BIOS engine may be configured to, during runtime of an operating system, in response to an operating system event for updating firmware, load onto an isolated compute domain of the processor to emulate firmware update processes of a non-transitory computer-readable media with a virtual non-transitory computer-readable media and emulate the firmware update processes of the cryptoprocessor with a virtual cryptoprocessor, extract a firmware payload to the virtual non-transitory computer-readable media, and execute a virtual trust chain to measure the firmware payload in the virtual non-transitory computer-readable media.

Abstract: A UEFI client initiates an SMB negotiation with a remote server for an augmented capability protocol that supports secure distributed namespace compounding via customized commands and trusted share-specific and transaction-specific data structures, referred to herein simply as secure blobs, communicated over a secure tunnel. The client platform may include a nonvolatile storage resource containing factory-installed AC modules for both the client and the server, as well as factory stored profile information for known remote shares. Upon successfully negotiating for the AC protocol, the UEFI client may retrieve and install the AC client and server modules to enable the AC protocol. The AC client may mount a local namespace, which includes a namespace folder for each remote share. The AC server module, in combination with remote share profile information provided by the AC client, enables the remote server to mount a virtual distributed namespace and function as a RVDN server.

Abstract: Disclosed methods may push a capsule update including a best known configuration-compute express link (BKC-CXL) firmware update to a boot time memory area. Following a platform reboot, BKC-CXL firmware update operations are performed. The update operations include mapping a BKC-CXL runtime memory area to a non-volatile BKC store, identifying current CXL attributes from the runtime memory area, extracting the firmware update, creating one or more BKC-CXL objects from the firmware update to enable dynamic configuration of CXL parameters, comparing current CXL attributes with stored CXL attributes to identify CXL attribute changes, and saving information indicative of the CXL attribute changes back to the non-volatile BKC store.