Abstract: Disclosed methods and systems consume vulnerability information from one or more security services associated with an information handling system. Based at least in part on the vulnerability information, a vulnerability status of the information handling system and/or an application running on the information handling system is determined. A vulnerability mitigation policy corresponding to the vulnerability status is determined and the vulnerability mitigation policy is then enforced while the vulnerability status persists. Enforcing the vulnerability mitigation policy may include restricting functionality of the information handling system, restricting execution of the application, or both.

Abstract: Disclosed systems and methods for securing an information handling system monitor for certain predetermined events, and, upon detecting any one of the predetermined events, requesting ownership data indicative of the authorized or recognized owner. In some embodiments, the ownership data is conveyed via a digital certificate establishing a trusted relationship between the owner and the information handling system. The digital certificate cryptographically associates a manifest of the system's key components and a device identifier such as a service tag.

Abstract: Disclosed systems and methods employ an embedded controller (EC) to monitor password activity and, responsive to detecting the password activity satisfying a criterion associated with a security policy managed by the EC, take action to restrict access to and/or operation of the platform in accordance with the security policy. The monitoring of password activity may include monitoring unsuccessful password change and password unlock attempts in both a preboot and runtime operating environment and within any of various available boot paths including, as examples, an operating system (OS) boot path, a network OS boot path, and a service OS (SOS) boot path. The OS boot source may be one of various telemetry events reported to a cloud-based risk assessment engine. Monitoring password change and password unlock attempts may include monitoring how many unsuccessful password change and unlock attempts have occurred since a most recent successful password change or password unlock attempt.

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: Disclosed methods include initiating a system basic I/O system (BIOS) and, responsive to detecting an empty drive, accessing evaluating local BIOS telemetry data associated with installation of a new drive. Upon determining that the BIOS telemetry data a specified criteria, a long disk self-test (DST) and a short DST, may be performed. If the DSTs generate no hardware errors, hard drive service data including, for example, call log and service tag history associated with the information handling system, may be retrieved from a cloud backend to authorize an OS installation. Upon approving an OS installation, a service operating system (SOS) image may be retrieved from an OEM backend and a special key operable to cause a startup service of the SOS to boot to an os installation flow may be accessed from a firmware volume in SPI flash to enable the SOS to initiate an OS installation flow.

Abstract: An operating system (OS) software service detects an accessibility change event and takes a snapshot of the accessibility settings before sending and receiving memory-mapped input/output (MMIO) commands with an embedded controller (EC) to establish trust using existing security hardening methods. The software service may send an MMIO command that includes the profile as a payload to the EC. The EC extracts the profile payload and saves it to an NVRAM variable before signaling a basic input/output system (BIOS) during early boot of an available accessibility profile. The EC publishes an accessibility profile presence to a BIOS pre-EFI initialization (PEI) layer, which sends a command to the EC to return the response.

Abstract: Systems and methods are provided to perform BIOS recovery for a first information handling system that is in a no-boot state, i.e., in which the original equipment manufacturer (OEM) boot block (OBB) on the first information handling system is corrupted or damaged and thus does not properly execute. OBB BIOS recovery may be achieved using logic executing on a second and different information handling system that is wirelessly communicating with initial boot block (IBB) BIOS firmware that is executing on the first information handling system. The logic executing on the second information handling system may select and download (e.g., from a remote server) a correct uncorrupted and undamaged copy of the BIOS recovery firmware version for the first information handling system, and then wirelessly transfer the downloaded new copy of the OBB BIOS firmware version to the first information handling system via an established secure wireless connection.

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: Systems and methods are provided to perform BIOS recovery for a first information handling system that is in a no-boot state, i.e., in which the original equipment manufacturer (OEM) boot block (OBB) on the first information handling system is corrupted or damaged and thus does not properly execute. OBB BIOS recovery may be achieved using logic executing on a second and different information handling system that is wirelessly communicating with initial boot block (IBB) BIOS firmware that is executing on the first information handling system. The logic executing on the second information handling system may select and download (e.g., from a remote server) a correct uncorrupted and undamaged copy of the BIOS recovery firmware version for the first information handling system, and then wirelessly transfer the downloaded new copy of the OBB BIOS firmware version to the first information handling system via an established secure wireless connection.

Abstract: SPI firmware updates can be performed at runtime. A secure SPI flash access domain can be created during pre-boot and used at runtime to deliver and write a SPI firmware update to SPI flash. The secure SPI flash access domain can ensure that only a trusted component running on a trusted CPU core can access a SPI memory layout used to deploy the SPI firmware update to the SPI flash. Once the SPI firmware update is written to the SPI flash, a reboot can be triggered so that the updated SPI firmware is loaded to perform the boot process.

Abstract: A disclosed method includes employing a hybrid context sensing protocol to learn power and video capabilities of a platform to perform seamless graphics remediations, providing a video management module to handle video policies and thermal attributes for seamless recovery of video capabilities across firmware updates/rollbacks, and implementing a hybrid video firmware (HVF) to create a virtual video domain to partially or fully utilize video capabilities based on platform power budgeting policies. The method may further include maintaining a silicon agnostic protected sync of a map between the video random access memory (VRAM)and GPU memory to ensure seamless High Bandwidth Digital Content Protect (HDCP) capability rendering on targeted video devices. The method further comprises using a system on chip (SoC)-agnostic runtime VRAM for uninterrupted graphics rendering across integrated graphics processing unit (iGPU) to discrete GPU (dGPU) transitions or switches.

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 method for deploying an information handling system (platform) determines whether a hardware key coupled to the platform constitutes a deployment key by validating a GUID of the key against a deployment key signature, generated by a trusted server and stored on the key. If the key is validated, a trust factor evaluation is performed by validating the deployment key against a second key, which is bound to a nonvolatile storage component containing a second key signature, generated by the trusted server based on a GUID of the nonvolatile storage component. Upon validating the trust factor, the platform boots into an unattended deployment mode loaded from the deployment key and validates an unattended deployment binary stored in the deployment key against the second key signature to establish a trusted execution session for loading unattended deployment modules from the deployment key and deploying the platform by executing the unattended deployment modules.

Abstract: Systems and methods are provided for supporting use of system BIOS components (e.g., such as BIOS debug messages, debugger firmware, UEFI drivers, etc.) that are stored separately from the remainder of system BIOS firmware for an information handling system. The system BIOS components may represent only a portion of the total BIOS firmware, and may be selectively retrieved and loaded from the separate storage into system memory when needed by the system BIOS for operating purposes (e.g., such as debugging operations).

Abstract: SPI firmware updates can be performed at runtime. A secure SPI flash access domain can be created during pre-boot and used at runtime to deliver and write a SPI firmware update to SPI flash. The secure SPI flash access domain can ensure that only a trusted component running on a trusted CPU core can access a SPI memory layout used to deploy the SPI firmware update to the SPI flash. Once the SPI firmware update is written to the SPI flash, a reboot can be triggered so that the updated SPI firmware is loaded to perform the boot process.

Abstract: A method for deploying an information handling system (platform) determines whether a hardware key coupled to the platform constitutes a deployment key by validating a GUID of the key against a deployment key signature, generated by a trusted server and stored on the key. If the key is validated, a trust factor evaluation is performed by validating the deployment key against a second key, which is bound to a nonvolatile storage component containing a second key signature, generated by the trusted server based on a GUID of the nonvolatile storage component. Upon validating the trust factor, the platform boots into an unattended deployment mode loaded from the deployment key and validates an unattended deployment binary stored in the deployment key against the second key signature to establish a trusted execution session for loading unattended deployment modules from the deployment key and deploying the platform by executing the unattended deployment modules.

Abstract: An information handling system may include at least one processor, a memory coupled to the at least one processor, and an information handling resource including a firmware. The information handling system may be configured to: boot into an operating system stored on the memory; after booting into the operating system, receive, from at least one remote server, information regarding a vulnerability associated with the firmware; based on a security policy, determine a resolution for mitigation of the vulnerability; and store information regarding the resolution in a storage location accessible to a preboot environment of the information handling system, wherein the preboot environment is configured to apply the resolution upon a subsequent boot of the information handling system.

Abstract: An information handling system may include a processor and a basic input/output system communicatively coupled to the processor and comprising a plurality of firmware volumes embodied in non-transitory computer readable media, each firmware volume comprising executable code for a respective functionality of the basic input/output system, wherein the basic input/output system is configured to, based on the presence or absence of an action or event associated with the basic input/output system, select a boot path for execution from a plurality of boot paths, each of the plurality of boot paths comprising a respective trust chain of a subset of the plurality of firmware volumes and execute the boot path selected.

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 include at least one processor, and a computer-readable medium having instructions thereon that are executable by the at least one processor. The instructions may be executable for: in response to detection of a first trigger event, enabling an accelerated boot process; and in response to detection of a second, different trigger event, enabling a non-accelerated boot process. The non-accelerated boot process may include parsing an internal forms representation (IFR), and the accelerated boot process may include not parsing the IFR.