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

Abstract: An information handling system may include a processor and a basic input/output system communicatively coupled to the processor and comprising a program of executable instructions configured to determine a context associated with a current boot session of the information handling system and based on user boot history stored during one or more previous boot sessions of the information handling system and the context, load one or more network drivers necessary to boot the information handling system in accordance with the context.

Abstract: A vulnerability management method acquires, during an OS runtime of an information handling system, vulnerability information indicating potentially vulnerable resources of the system. Disclosed methods calculate a vulnerability determination code (VDC) based on the vulnerability information. The VDC may indicate a scan zone that includes one or more scan zone components. Each component may correspond to a region of a potentially vulnerable resource. After a system reset, disclosed methods may perform a vulnerability aware (VA) boot sequence. The VA boot sequence may include, prior to booting a runtime operating system, determining, in accordance with the vulnerability information, whether to perform a comprehensive vulnerability detection (CVD) boot. A CVD boot refers to a boot sequence configured to boot a distinct operating system dedicated to performing a targeted vulnerability assessment that includes scanning the scan zone components indicated by the VDC.

Abstract: An information handling system may include a processor and first non-transitory computer-readable media communicatively coupled to the processor and having stored thereon a basic input/output system (BIOS) core comprising BIOS core firmware sufficient to execute features of a BIOS of the information handling system to a particular portion of BIOS execution and an extension agent configured to identify and enumerate a firmware volume of a second non-transitory computer-readable media communicatively coupled to the processor and having stored thereon a BIOS extension comprising BIOS extension firmware for executing completion of BIOS execution from the particular portion of BIOS execution.

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: A system for network management comprising a silicon management system operating on a processor that causes the processor to load one or more algorithms stored in a non-transient data memory to cause the processor to identify a version for a plurality of silicon data processing devices and to implement an update to one or more of the silicon data processing devices, a chipset management system operating on a processor that causes the processor to load one or more algorithms stored in a non-transient data memory to cause the processor to identify a version for a plurality of chipsets, each chipset associated with one of the silicon data processing devices and to implement an update to one or more of the chipsets and a boot system configured to cause a system associated with the updated silicon data processing devices and the updated chipsets to reboot.