Abstract: UEFI images can be securely loaded at runtime so that it is unnecessary to flash the entire platform firmware whenever a UEFI image is added or updated. The platform firmware can include an OEM file list that maps file GUIDs to public keys. When it is desired to add a UEFI image, the OEM can employ one of the file GUIDs in the OEM file list and a private key corresponding to the mapped public key to create the UEFI image. During the PEI phase of the boot process, a verification module in the platform firmware can verify any added UEFI image using the OEM file list. Additionally, to ensure that the added UEFI images will pass the subsequent Secure Boot verification, a sync module can add custom Secure Boot keys for the added UEFI images to the Secure Boot databases during the DXE phase of the boot process.

Abstract: An information handling system may load first data from a location information area of a first memory, specifying a plurality of locations of metadata for a plurality of stages of basic input/output system (BIOS) initialization. The information handling system may then load first metadata for a first stage of BIOS initialization from a first metadata location of the plurality of locations specified by the first data. The first metadata may contain information for indexing first initialization data located at a first initialization data location. The information handling system may then index the first initialization data of the first initialization data location based, at least in part, on the first metadata. The information handling system may then perform the first stage of BIOS initialization based, at least in part, on the first initialization data.

Abstract: An information handling system may connect to a remote client to display a user interface of the information handling system on a display of the remote client while the information handling system is in a pre-boot stage. The information handling system may transmit user interface data to the remote client for display of the user interface on the remote client. The information handling system may filter the user interface data to remove private information from the user interface data before transmitting the user interface data to the remote client.

Abstract: Upon detection of a change in resolution from a first resolution to a second resolution, one or more user interface elements may be dynamically scaled based, at least in part, on the detected change in resolution. The user interface elements may be dynamically scaled in such a way as to maintain an aspect ratio of each of the user interface elements while adjusting a resolution of each of the user interface elements to the second resolution. After the user interface elements are dynamically scaled, a user interface, at the second resolution, may be presented on a display of an information handling system.

Abstract: In one or more embodiments, one or more systems, methods, and/or processes may receive an interrupt from a device associated with the information handling, the device different from a memory medium; retrieve an executable from the device; store the executable via the memory medium; provide a signal to an operating system executing on the information handling system, the signal indicating that the executable was stored via the memory medium; and execute the executable via the processor, the executable configured to: retrieve, from the device, a device driver and firmware for the device; and install the device driver and the firmware for the device.

Abstract: UEFI images can be securely loaded at runtime so that it is unnecessary to flash the entire platform firmware whenever a UEFI image is added or updated. The platform firmware can include an OEM file list that maps file GUIDs to public keys. When it is desired to add a UEFI image, the OEM can employ one of the file GUIDs in the OEM file list and a private key corresponding to the mapped public key to create the UEFI image. During the PEI phase of the boot process, a verification module in the platform firmware can verify any added UEFI image using the OEM file list. Additionally, to ensure that the added UEFI images will pass the subsequent Secure Boot verification, a sync module can add custom Secure Boot keys for the added UEFI images to the Secure Boot databases during the DXE phase of the boot process.

Abstract: In one or more embodiments, one or more systems, methods, and/or processes may receive an interrupt from a device associated with an information handling system; may retrieve an executable from the device; may store the executable via a memory medium of the information handling system; may provide a signal, to an operating system executing via at least one processor of the information handling system, that indicates that the executable was stored via the memory medium; may execute the executable via the at least one processor; may retrieve one or more of a device driver for the device and firmware for the device; and may install the one or more of the device driver for the device and the firmware for the device. In one or more embodiments, the device may include a docking station or a peripheral device, among others.

Abstract: Provided herein are systems, methods, and computer program products for testing a firmware update in a secure virtual environment prior to actually installing the firmware update in a device or system. In one embodiment, a firmware update is received. The system is rebooted after receiving the firmware update, and a virtual machine monitor (VMM) is launched following the reboot. In turn, the VMM registers various exit handlers and policies, and launches a virtual machine within a unified extensible firmware interface (UEFI) stored within a reprogrammable read only memory. The process uses the VMM to launch a virtual machine, which is used to perform a test installation of the firmware update. If no violations or other errors are detected in connection with the test installation, the process reboots the system again and installs the firmware update in the regular operating environment following the reboot.

Abstract: A method, information handling system (IHS) and a management system for managing boot failures in an IHS. The method includes transmitting, via a processor, a request for at least one unified extensible firmware interface (UEFI) image from a boot file or HTTP server and receiving the at least one UEFI image from the HTTP server. The IHS is booted using the UEFI image. The method further includes determining if a boot failure of the IHS has occurred. In response to determining that a boot failure of the IHS has occurred, a memory location is identified in a first memory device for storage of a system dump file. The method also includes storing contents of the first memory device to the system dump file at the indentified memory location of the first memory device.

Abstract: A system for configuring a processor is disclosed that includes a processor, a memory, and a firmware startup algorithm stored in the memory at a first predetermined location, the firmware start-up algorithm has one or more user-configurable driver algorithm memory storage locations. A driver algorithm stored at one of the user-configurable driver algorithm memory storage locations is configured to modify an operating system memory storage location for use by the firmware startup algorithm.

Abstract: A multiple processor system comprising a first processor configured to utilize an inter-processor messaging protocol and a second processor configured to utilize the inter-processor messaging protocol is disclosed. The system includes a non-volatile memory device coupled to the first processor, wherein the second processor is configured to access the non-volatile memory device by utilizing the inter-processor messaging protocol.

Abstract: A pair of servers may include a source server hosting a source virtual machine (VM) and a target server hosting a target VM. The source server may include a source central processing unit (CPU) and a source baseboard management controller (BMC), and the target server may include a target CPU and a target BMC. The source server and the target server are connected by an inband connection, and the source BMC and the target BMC are connected by a connection distinct from the inband connection. The source VM may be migrated to the target server over the inband connection, and in response to migrating the source VM, security data corresponding to the source VM is communicated from the source BMC to the target BMC over the connection between the BMCs.

Abstract: A method to enforce secure boot policy in an IHS configured with a plurality of virtual machines. The method includes detecting a request for a virtual machine to access a service processor. In response to detecting the request, the method includes triggering a handshake request between a hypervisor boot emulator and the service processor to initiate a sequence of authentication steps to access a corresponding secure partition of memory from among a plurality of secure partitions of memory associated with the service processor. Each secure partition of memory has a corresponding virtual platform key for preserving secure access to the corresponding secure partition of memory stored in a secure platform. The method further includes dynamically generating unlock keys, derived in part by the corresponding virtual platform key, to authenticate a requesting virtual machine as a valid virtual machine to obtain access to a corresponding secure partition of memory.

Abstract: Provided herein are systems, methods, and computer program products for testing a firmware update in a secure virtual environment prior to actually installing the firmware update in a device or system. In one embodiment, a firmware update is received. The system is rebooted after receiving the firmware update, and a virtual machine monitor (VMM) is launched following the reboot. In turn, the VMM registers various exit handlers and policies, and launches a virtual machine within a unified extensible firmware interface (UEFI) stored within a reprogrammable read only memory. The process uses the VMM to launch a virtual machine, which is used to perform a test installation of the firmware update. If no violations or other errors are detected in connection with the test installation, the process reboots the system again and installs the firmware update in the regular operating environment following the reboot.

Abstract: An information handling system includes a memory, a remote access controller, and a host processor. The memory to store an extensible firmware interface (EFI) system resource table (ESRT) and an ESRT capsule. The remote access controller to detect an insertion of a hot-pluggable device into the information handling system, to retrieve firmware details for the hot-pluggable device, to create a firmware capsule payload based on the firmware details, and to store the firmware capsule payload in the memory. The host processor to operate in a pre-boot mode, and in an operating system runtime mode. The host processor, while in the operating system runtime, to retrieve the firmware capsule payload from the memory, to update a cached operating system ESRT based on the firmware capsule payload, to retrieve updated firmware for the hot-pluggable device, and to create the ESRT capsule based on the updated firmware.

Abstract: A first firmware volume of a Unified Extensible Firmware Interface (UEFI) compliant information handling system is accessed. Authentication information is retrieved from the first firmware volume using a UEFI Secure Architecture Protocol. Based on the authentication information, it is determined if the first firmware volume is a first type of firmware volume. If the first firmware volume is the first type of firmware volume, the first firmware volume is authenticated using the first authentication information and an authentication procedure other than Secure Boot authentication. If the first firmware volume is a second type of firmware volume, the second type different than the first type, the first firmware volume is authenticated using the first authentication information and the Secure Boot authentication.

Abstract: In one or more embodiments, one or more systems, methods, and/or processes may receive an interrupt from a device associated with an information handling system; may retrieve an executable from the device; may store the executable via a memory medium of the information handling system; may provide a signal, to an operating system executing via at least one processor of the information handling system, that indicates that the executable was stored via the memory medium; may execute the executable via the at least one processor; may retrieve one or more of a device driver for the device and firmware for the device; and may install the one or more of the device driver for the device and the firmware for the device. In one or more embodiments, the device may include a docking station or a peripheral device, among others.

Abstract: An information handling system has a secure data storage partition allocation. Access to the secure storage partition is limited to a set of authorized functions authorized to access the secure storage partition. The authorization of a function may be determined by a unique identification corresponding to the function or a reverse trace.

Abstract: An information handling system may include at least one processor and a network interface controller communicatively coupled thereto. The network interface controller may be configured to provide network communication between the information handling system and a remote information handling system according to a Server Message Block (SMB) protocol. The information handling system may further be configured to establish a communication session with the remote information handling system according to a first SMB channel having a first bandwidth, and in response to an indication from the remote information handling system, transition the communication session to a second, different SMB channel having a second bandwidth greater than the first bandwidth.

Abstract: A virtual memory system includes a virtual memory engine coupled to a plurality of physical memory devices and a virtual memory database. During an initialization process, virtual memory engine uses a first unique global identifier to create virtual memory in the virtual memory database by mapping a continuous virtual memory address range to non-continuous physical memory device address ranges that are provided across the plurality of physical memory devices. During the initialization process, or subsequently during runtime, the virtual memory engine uses a second global unique identifier to define a virtual memory device namespace in the virtual memory that includes a first continuous subset of the continuous virtual member address range. During runtime, the virtual memory engine then provides read and write block mode access to the plurality of physical memory devices via the virtual memory device namespace defined in the virtual memory database.