Abstract: Disclosed systems and methods address escalated vulnerability attributable to system down time. In at least one embodiment, a customer-selectable threshold of detection establishes the number of days a system is allowed to be “down” before forcing a secured update path as described herein. The threshold may represent a compromise and balance between inconvenience and security based on each customer's preference. Tracking of system down time or offline time may be managed via EC/SBIOS and a real time clock (RTC) timer. The system down time may then be compared to the customer setting, e.g., whenever the system is booted.

Abstract: An information handling system includes an embedded controller and a memory device storing code that when executed causes the embedded controller to perform operations that includes receiving a request to change a security setting, determining a security policy associated with the security setting, and determining whether the change to the security setting deviates from the security policy. In addition, the embedded controller in response to determining that the change to the security setting deviates from the security policy, denying the request and reverting the change to the security setting.

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: prior to initialization of an operating system, executing a first-party pre-boot firmware application, wherein the first-party pre-boot firmware application is configured to provide system-level context information; executing a third-party pre-boot firmware application, wherein the third-party pre-boot firmware application is configured to receive the system-level context information from the first-party pre-boot firmware application; and displaying a user interface for the third-party pre-boot firmware application, wherein at least one element of the user interface is based on the system-level context information.

Abstract: Systems and methods for security for a split-boot architecture are described. In an illustrative, non-limiting embodiment, an Information Handling System (IHS) may include: a printed circuit board; a processor coupled to the printed circuit board; and a memory coupled to the processor, wherein the memory comprises program instructions stored thereon that, upon execution by the processor, cause the IHS to: obtain one or more cryptographic keys associated with firmware onboard the printed circuit board; and verify extended firmware using the cryptographic keys.

Abstract: Systems and methods for accident detection and notification are described. In some embodiments, an Information Handling System (IHS) may include: an Embedded Controller (EC); and a memory coupled to, or integrated into, the EC, where the memory includes program instructions that, upon execution by the EC, cause the EC to: receive sensor data from a sensor; determine, based at least in part on the sensor data, that an accident occurred to the IHS; and in response to the determination, issue a notification. In some embodiments, to issue the notification, the program instructions, upon execution, further cause the EC to: transmit information to a second IHS via a personal area network (PAN).

Abstract: Machine-learning systems and methods to predict device failures are described. In some embodiments, an Information Handling System (IHS) may include: a processor; and a memory coupled to the processor, the memory having program instructions stored thereon that, upon execution by the processor, cause the IHS to: obtain a shock event notification of a second IHS; execute an Artificial Intelligence/Machine Learning (AI/ML) model; and determine, by the AI/ML model and based, at least in part, on the shock event notification, a likelihood or probability that one or more failures of the second IHS will occur. In some embodiments, the determination, by the AI/ML model, is further based, at least in part, on device model characteristics of the second IHS, device health telemetry of a plurality of other IHSs, and/or service records of a plurality of other IHSs.

Abstract: Systems and methods for determining risk and recyclability of IHSs in response to accidents are described. In some embodiments, an Information Handling System (IHS) may include: a processor; and a memory coupled to the processor, the memory having program instructions stored thereon that, upon execution, cause an Operating System (OS) to: receive an accident indication of the IHS or a second IHS; and determine information regarding recyclability, condition, or risk of the IHS or second IHS based, at least in part on, the accident indication. In some embodiments, the information regarding the recyclability, condition, or risk of the IHS or second IHS can include: (1) a recyclability score that indicates a likelihood that the IHS or the second IHS can be refurbished or resold, and/or (2) a risk score that indicates a likelihood of one or more repairs for the IHS or the second IHS.

Abstract: Systems and methods for diagnosing accidents in Information Handling Systems (IHSs) are described. In some embodiments, an IHS may include a processor and a memory coupled to the processor, the memory having program instructions stored thereon that, upon execution, cause an Operating System (OS) to: in response an accident, collect fan data and, based at least in part upon a comparison between collected fan data and stored fan data, perform an accident remediation or mitigation operation.

Abstract: Systems and methods for configuring peripherals in response to accidents are described. In some embodiments, an Information Handling System (IHS) may include: a processor; and a memory coupled to the processor, the memory having program instructions stored thereon that, upon execution by the processor, cause the IHS to: obtain a notification of a shock event of the IHS; communicate information regarding the shock event to peripheral firmware of one or more peripherals of the IHS. The peripheral firmware may receive the information regarding the shock event of the IHS from the IHS; and responsive to the information, perform a corrective action. In some embodiments, the corrective action includes a configuration update and a communication to the IHS of the configuration update, a self-test scan for health of the peripheral, shutting off port or data access to the peripheral, and/or collection of telemetry of the peripheral.

Abstract: Systems and methods for handling contextual accident data in an Information Handling System (IHS) are described. In some embodiments, an IHS may include an Embedded Controller (EC), and a memory coupled to, or integrated into, the EC, where the memory comprises program instructions that, upon execution by the EC, cause the EC to receive a power state indication and associate the power state indication with an accident indication.

Abstract: Systems and methods for collecting, storing, and reporting accident data in an IHS are described. In some embodiments, an Information Handling System (IHS) may include an Embedded Controller (EC) and a memory coupled to the EC, the memory having program instructions stored thereon that, upon execution, cause the EC to detect an accident and, before the accident ends, collect, store, or report data associated with the accident based, at least in part, upon an accident handling policy.

Abstract: Systems and methods for telemetry driven platform restoration for a split-boot architecture are described. In an illustrative, non-limiting embodiment, an Information Handling System (IHS) comprises a printed circuit board (PCB); a processor coupled to the PCB; and a memory coupled to the processor, wherein the memory comprises program instructions stored thereon that cause the IHS to: obtain, in a split boot architecture, telemetry data from firmware onboard the PCB, and from extended firmware; and detect one or more boot failure events using the obtained telemetry data. In another embodiment, a method comprises obtaining first telemetry data associated with a first firmware executed, during a boot process, by a first hardware component of an IHS; obtaining second telemetry data associated with a second firmware executed, during the boot process, by a same or different hardware component; and detecting a boot failure event using the first and second telemetry data.

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: Systems and methods for accident detection and handling are described. In some embodiments, an Information Handling System (IHS) may include an Embedded Controller (EC), and a memory coupled to, or integrated into, the EC, where the memory comprises program instructions that, upon execution by the EC, cause the EC to, in response to a determination that the IHS suffered an accident prior to a reboot, transmit an indication of the accident to a remote service during the reboot.

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 configuring Input/Output (I/O) ports 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 change a Power Delivery (PD) parameter of an I/O port in response to a determination that the IHS suffered an accident.

Abstract: Systems and methods for accident detection and handling are described. In some embodiments, an Information Handling System (IHS) may include an Embedded Controller (EC), and a memory coupled to, or integrated into, the EC, where the memory comprises program instructions that, upon execution by the EC, cause the EC to, in response to a determination that the IHS suffered an accident prior to a reboot, transmit an indication of the accident to a remote service during the reboot.

Abstract: Systems and methods for handling accident data in an Information Handling System (IHS) unable to boot are described. In some embodiments, an Information Handling System (IHS) may include an Embedded Controller (EC), and a memory coupled to, or integrated into, the EC, where the memory comprises program instructions that, upon execution by the EC, cause the EC to determine that a booting process is incomplete and, at least in part in response to the determination, store accident data in a Non-Volatile Memory (NVM).

Abstract: Systems and methods for post-accident health assurance in an Information Handling System (IHS) are described. In some embodiments, an IHS may include a processor and a memory coupled to the processor, where the memory comprises program instructions that, upon execution by the processor, cause a Basic Input/Output System (BIOS) to execute a diagnostics routine during a reboot in response to a determination that the IHS suffered an accident prior to the reboot.

Abstract: Systems and methods for data backup and restore operations in response to accidents are described. In some embodiments, an Information Handling System (IHS) may include a processor and a memory coupled to the processor, the memory having program instructions stored thereon that, upon execution, cause an Operating System (OS) to receive an accident indication and change a data backup setting in response to the indication.