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 for assessing display health in response to accidents are described. In some embodiments, an Information Handling System (IHS) may include an Embedded Controller (EC) and a memory coupled to the EC, where the memory comprises program instructions that, upon execution by the EC, cause the IHS to initiate an integrated display's Built-In-Self-Test (BIST) in response to a determination that the IHS suffered an accident.

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.