Abstract: Disclosed subject matter enables a recovery and resume of secure platform services based on indicator of attack for the UEFI boot path and UEFI drivers for any access to storage or network medium. Disclosed methods may employ an unsupervised learning model, based on information referred to herein as Indicator of Attack (IOA) information, and create a unique resilient BIOS access for UEFI drivers, file system, media and network. Disclosed teachings enable secure services for access to UEFI drivers, file systems, media, and network using a dynamic resilient layer to handle IOA. Dynamic methods to create runtime metadata for file system logical blocks for OEM nested file system partition and pre boot OEM authentication are also disclosed. Disclosed teachings support a UEFI file system interface that implements a runtime remap method for OEM-provided drivers.

Abstract: An information handling system includes a basic input/output system (BIOS), and multiple virtual machines including first and second virtual machines. The first virtual machine communicates with the BIOS and other hardware components within the information handling system. The second virtual machine is configured in a BIOS update configuration. The first virtual machine receives a hypercall from the second virtual machine. The hypercall includes a command having a command type. The first virtual machine determines whether the command type within the hypercall matches a cloud policy assigned to the second virtual machine. In response to the command type matching the cloud policy, the first virtual machine provides the command to a proper hardware component within the information handling system.

Abstract: An information handling system determines a difference between a first set of initialization information and a second set of initialization information during a pre-extensible firmware interface initialization phase of a boot process that is based on a first basic input/output system (BIOS), wherein the first set of initialization information is associated with the first BIOS and the second set of initialization information is associated with a second BIOS. The system also creates and publishes a hand-off block that includes an entry which describes the difference between the first set of initialization information and the second set of initialization information. The system parses the hand-off block during a driver execution environment phase to determine the difference between the first set of initialization information and the second set of initialization information, wherein the hand-off block is passed from the pre-extensible firmware interface initialization phase of the boot process.

Abstract: Temporary firmware is provided as cloud services. Different temporary firmware containers are downloaded via a communications network. A light-weight operating system launches and executes the temporary firmware containers during a boot operation, POST operation, or other scheme. The temporary firmware containers thus detect and perhaps resolve POST errors. The light-weight operating system may also download a full-service/resource operating system. A second or subsequent boot operation may be performed, but control is ceded to the full-service/resource operating system. Multiple firmware tenants may thus be temporarily downloaded to a bare metal machine to support POST error detection activities. Advanced OS serviceability, diagnostics, and other containerized firmware may thus be quickly and simply launched without requiring the excessive time and difficulties of using the full-service/resource operating system.

Abstract: A basic input output system (BIOS) of an information handling system may access a first list indicating one or more activation statuses of one or more BIOS firmware modules. The BIOS may determine a BIOS firmware module of the one or more BIOS firmware modules to load based, at least in part, on the first list. The BIOS may load the determined BIOS firmware module during booting of the information handling system.

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: 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: Systems and methods are provided that may be implemented to provide a basic input/output system (BIOS) with the ability to authenticate and then execute one-time unique instructions that are previously left behind (i.e., stored) in public memory of an information handling system by a containerized computing environment session that is no longer executing on the information handling system. The disclosed systems and methods may be so implemented to share with the system BIOS privileged instructions to identify which executables are authorized for execution on a targeted information handling system. The privileged instructions may be previously created and optionally stored together with an executable code in system public memory, and these instructions may provide instructions on how to execute the executable code.

Abstract: A disclosed method installs an I/O trap protocol to provide an authentication callback function for handling I/O trap events. I/O trap events may include write operations accessing any of one or more identified I/O addresses. An I/O trap event may be registered with the authentication callback function for each of one or more identified I/O addresses. Original values of data may be stored in a memory resource. Any occurrences of an I/O trap event triggers the authentication callback function to perform I/O trap operations. The I/O trap operations may include determining whether the I/O trap event is associated with an approved driver and, if not, restoring data stored at the identified I/O address to an original value. Installing the I/O trap protocol may include installing the I/O trap protocol during a system management mode (SMM) phase of a UEFI boot sequence.

Abstract: Client machines, whether consumer or Enterprise, are notified of software updates using a decentralized, peer-to-peer blockchain infrastructure. Any software update is written to a block of data and distributed to blockchain nodes associated with a blockchain network. A smart contract, executed by any of the blockchain nodes, causes the corresponding blockchain node to notify specific client machines of the block of data recording the software update. The client machines contact the blockchain node and request the software update written to the block of data. The blockchain node retrieves and sends the software update written to the block of data. When the client machines receive the software update, the client machines apply or install the software update to improve their computer functioning.

Abstract: Systems and methods are provided for remotely supporting managed hardware components of an IHS (Information Handling System). Prior to booting an operating system of the IHS, the managed hardware components are enumerated as supporting remote management and a network stack is created in a secured IHS memory, where the network stack is for transfer of remote device management communications directed at the managed hardware components. Still prior to booting the operating system, the IHS chipset is configured to route device management messages received from remote management tools to the network stack. After booting the operating system, a secure remote management session is established between a remote management tool and an IHS device management agent. During operation of the device management agent in the booted operating system, device management messages are retrieved from the network stack and decoded device management messages are delivered to a managed hardware component.

Abstract: An information handling system may include at least one processor, a Basic Input/Output System (BIOS), a physical information handling resource, and a computer-readable medium having instructions thereon that are executable by the at least one processor for: executing an operating system (OS) that includes a BIOS Data Advanced Configuration and Power Interface (ACPI) Table (BDAT) driver; executing at least one virtual machine (VM) that includes a virtual BDAT driver; detecting an event notification generated by the physical information handling resource; and transmitting, to the VM, information regarding the event notification via the BDAT driver and the virtual BDAT driver.

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 is configured to support first and second boot sequences, which invokes first and second bootloaders respectively. The bootloaders may be stored in an NVMe storage boot partition. Each bootloader may be associated with a corresponding encryption key generated by a trusted platform module, which may seal the first and second keys in accordance with one or more measurements taken during the respective boot sequences. The system determines whether a boot sequence in progress comprises is to invoke the first or second bootloader. The system then unseals the appropriate encryption key to access the appropriate bootloader. The first bootloader may be a host OS bootloader and the second bootloader may be for a recovery resource invoked when the host OS fails to load. The recovery resource may enables BIOS to connect to a remote store and download an image via a HTTP mechanism.

Abstract: A basic input/output system (BIOS) may load an embedded operating system (EOS), and the light-weight EOS may operate as a single captive portal for all pre-boot operations. With a single captive portal, the EOS may provide a multi-task environment to facilitate quicker execution of multiple pre-boot tasks within a single environment to reduce a number of reboots. In some embodiments, power consumption by performing the tasks within the EOS may be reduced by executing operations using a low-power core of an information handling system, such as a “little” core of a system on chip (SoC) having multiple “big” and “little” cores or a hybrid core of an information handling system. More generically, the EOS may execute on one or both of a first processor core and second processor core of an information handling system, in which the first and second processor cores are configured differently.

Abstract: Establishing a diagnostic OS for an information handling system platform performing a UEFI BIOS boot to place the platform in a pre-OS state. Upon detecting a particular POST error and/or a platform configuration policy, an embedded OS kernel may be launched into a DRTM-authenticated measured launch environment (MLE). Additional objects for the diagnostic OS may be downloaded. The additional objects may include an initial ramdisk (initrd) module and one or more applications specific to the particular diagnostic OS. The diagnostic OS may be launched as follows: for each diagnostic OS application, launching the application and extending a measurement of the application into a DRTM PCR. Launching the diagnostic OS may include launching an initrd module and extending a measurement of the initrd module into the DRTM PCR. A measurement of embedded OS kernel may be extended into the TPM and the embedded OS kernel may validate the UEFI BIOS sequence.

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 subsystem and non-transitory computer-readable media communicatively coupled to the processor subsystem and storing instructions, the instructions configured to, when read and executed by the processor subsystem: execute a basic/input output service to create a link aggregation table with details based on wireless and wired network interface modules present within the information handling system; execute a first operating system service on a container instantiated on a hypervisor of the information handling system to instantiate virtual link aggregation tables for the container based on a network bandwidth policy of the container and link aggregation capabilities as set forth in the link aggregation table; and execute a second operating system service on the hypervisor to instantiate an operating system driver based on operating systems for network instances of link aggregation drivers and dynamic detection of network driver requirements determined by the

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: In one embodiment, a method for method for managing a virtual service in an information handling system includes: identifying, by a virtual image of a plurality of virtual images of the virtual service, a device setting to be modified, the device setting associated with a device of the information handling system, each of the plurality of virtual images having respective device settings; accessing, by a host service, a protected namespace of a plurality of protected namespaces, the protected namespace associated with the virtual image; identifying, by the host service, a device index stored in the protected namespace, the device index pointing to a device-specific function associated with the device, the device-specific function stored in a translation table; accessing, by the host service, the device-specific function stored in the translation table based on the device index; and causing, by the host service, the device-specific function to modify the device setting.