Abstract: Methods, systems, and devices for providing for trust in a distributed environment are disclosed. In a distributed environment, various devices may be remote to one another and may interact with one another via one or more operable connections. Through the operable connections, various communications may be exchanged. However, the operable connections may not natively support authentication of any particular device in the distributed system. Consequently, entities in the distributed system may not intrinsically trust that the communications received through the distributed environment are authentic. The entities of the system may mutually authenticate one another prior to trusting communications from the other entities. For example, in a scenario where a client wishes to access data hosted by a data source, the client and data source may go through a process of mutually authenticating one another. By doing so, a trusted environment may be established.

Abstract: The technology described herein, which can be incorporated into a bare metal as a service environment, is generally directed towards monitoring retrieving and analyzing security configuration stored on recovery partition storage (e.g., OEM partition drives), which can contain critical logs, error state data, and boot critical security data. A backend security policy engine enforces security context configuration policy data, including to prevent malicious attacks on the backend services. Bare metal in-band compute device health is monitored by an out-of-band network using telemetry data services. When an unrecoverable system state is detected, the out-of-band network activates the recovery partition storage for recording the system sensitive logs, debug data and error states, which is stored as encrypted per security policies. Security policy is enforced, including on system logs, to prevent data tampering and/or malicious attacks. A recovery scenario is performed to restore operation of the compute device.

Abstract: A system can receive, from a remote computer of remote computers, inventory data representative of an inventory, wherein the inventory data indicates that the remote computer is configured to interact with other remote computers of the remote computers according to a compute express link protocol. The system can receive, from the remote computer, a request to onboard the remote computer, wherein the request adheres to a defined security protocol and data model architecture, and wherein the system is configured to remotely manage the remote computers as part of a hybrid cloud platform that comprises the remote computers. The system can authenticate the remote computer based on the request and according to the defined security protocol and data model architecture. The system can remotely monitor hardware resources of the remote computers based on workload configuration map data representative of a workload configuration map of the remote computers.

Abstract: A system can receive, from a remote computer of remote computers, inventory data representative of an inventory, wherein the inventory data indicates that the remote computer is configured to implement a shared memory pool with the remote computers according to a compute express link protocol. The system can receive, from the remote computer, a request to onboard the remote computer, wherein the request adheres to a defined security protocol and data model architecture, and wherein the system is configured to remotely manage the remote computers as part of a hybrid cloud platform that comprises the remote computers. The system can authenticate the remote computer based on the request and according to the defined security protocol and data model architecture. The system can implement the shared memory pool for the remote computers.

Abstract: A system, method, and computer-readable medium are disclosed for servicing and managing a bare metal information handling system. An embedded lightweight operating system on the bare metal information handling system is booted up. The embedded lightweight operating system initiates a platform inference engine which is provided rules and policies as to applications to be run on the bare metal information handling system. The platform inference engine initiates a secure workspace launcher to launch a user workspace user experience environment. The user workspace user experience environment is provided on the bare metal 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: 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 systems for managing the operation of host devices is disclosed. A host device may include a computing device that operates in accordance with operation data. The operation data may include, for example, startup data such as code for a management entity (e.g., a basic input output system), settings (e.g., hardware and/or software) for the startup management entity, setting for general operation after booting to an operating system, copies of code (e.g., computer instructions executable with a processor) for applications to be executed by the host device, etc. If the operation data is modified, operation of the host device may be similarly modified.

Abstract: In response to reception of a hypercall addition request, a virtual machine receives a public key. Based on the public key, the virtual machine determines whether the hypercall addition request is valid. In response to the hypercall being valid, the virtual machine adds a hypercall associated with the hypercall addition request within a hypervisor of an information handling system.

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 configured to be the first code executed by the processor when the information handling system is booted and configured to initialize components of the information handling system into a known state, the basic input/output system further configured to implement a virtual machine monitor, the virtual machine monitor configured to isolate resources of the information handling system allocated to a network boot process of the information handling system from other resources of the information handling system allocated to other components of the basic input/output system.

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