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: Provided is a device unit, including a module, which can configure the device unit with an operating state from among different operating states during the start-up process and/or during ongoing operation of the device unit, wherein a first protected operating state of the different operating states is designed to allow the execution of at least one operating process which can be predefined and to optionally protect the operating process by means of defined cryptographic means, wherein at least one second operating state of the different operating states is designed to deactivate the first protected operating state and to allow at least one other changeable operating process and to optionally protect the operating process by means of specifiable cryptographic means.

Abstract: An information handling system wirelessly interfaces with a location peripheral aid through primary radios that have a communication protocol, such as Bluetooth Low Energy or a wireless local area network, and through secondary radios having a low power wake and sleep using wake and sleep signals sent between the secondary radios. The location peripheral aid establishes communication with the information handling system, which reports its position to a network location to allow tracking location of the peripheral aid. The peripheral primary and secondary radio transmit and receive states operate with different profiles to manage power based upon bi-directional communications tracked over time.

Abstract: Systems and procedures are provided for validating an IHS (Information Handling System) as operating using only factory-provisioned firmware. During factory provisioning of the IHS, a signed inventory certificate is uploaded to the IHS that includes an inventory identifying firmware for use in the operation of the IHS. Upon delivery and initialization of the IHS, the inventory certificate is retrieved by a pre-boot validation process. An inventory of firmware used by hardware components of the IHS is then collected. The validation process compares the collected inventory of firmware against the inventory of factory-provisioned firmware from the inventory certificate in order to validate the IHS is operating using only factory-provisioned firmware. A validation failure is signaled when the comparison indicates that a hardware component is not operating using the factory-provisioned firmware specified in the inventory certificate.

Abstract: Techniques are disclosed for the protection and accuracy of system time used in systems, such as automotive systems, from attacks. In some embodiments, a cumulative trustworthiness score is determined for available time sources, other than a real time clock, by adding together trustworthiness scores associated with the available time sources after a system time is initialized to time of the real time clock during booting. The cumulative trustworthiness score is then used to determine an appropriate technique for updating the system time based on time from one of the available time sources, depending on whether the cumulative trustworthiness score is greater than a maximum threshold, between a minimum threshold and the maximum threshold, or less than the minimum threshold.

Abstract: Embodiments described herein are directed to transferring the ownership of a computing device from one entity to another entity. For example, a security processor is utilized to boot the computing device. During a boot session, the security processor loads and executes boot code, which determines whether specialized firmware authorized by the current owner indicates whether a transfer of ownership is to occur. In response to determining that the specialized firmware indicates that a transfer of ownership is to occur, the secure processor loads and executes the specialized firmware. The specialized firmware, when executed, causes the security processor to program a set of fuses with the public key of the new owner. Execution of the specialized firmware also causes the security processor to invalidate the public key of the original owner, which is stored in another set of fuses.

Abstract: An apparatus to facilitate permissions at a computing system platform is disclosed. The apparatus includes a plurality of agents, each including a non-volatile memory storing firmware executed to perform a function associated with the agent and attestation hardware to detect an update at the computing system platform, generate a cryptographic key associated with each of the plurality of agents, perform an attestation with a relying party using the generated cryptographic keys and receive a tuple associated with each of the plurality of agents, wherein a tuple includes one or more permissions indicating platform resources an agent is permitted to access.

Abstract: In various examples there is a computing device comprising: a first microcontroller comprising a first immutable bootloader and first mutable firmware. The first immutable bootloader uses a unique device secret burnt into hardware of the computing device in order to generate an attestation of the first mutable firmware. The computing device has a second microcontroller. There is second mutable firmware at the second microcontroller. There is a second immutable bootloader at the second microcontroller which sends a measurement of the second mutable firmware to the first immutable bootloader whenever the second microcontroller restarts, such that the first microcontroller is able to include the measurement in the attestation.

Abstract: Embodiments described herein are directed to firmware policy enforcement of a computing device. For example, a security processor of the computing device is utilized to boot the computing device. During a boot session, the security processor loads and executes specialized firmware. The specialized firmware, when executed, causes the security processor to determine whether other types of firmware to be executed on the computing device is in compliance with a policy specified by the specialized firmware. Based at least on a determination that the other firmware is in compliance with the policy, the security processor executes the other firmware. Based at least on a determination that the other firmware is not in compliance with the policy, the security processor performs a mitigation with respect to the other firmware.

Abstract: A method includes detecting a change in control of a peripheral device from a first security domain to a second security domain of a computer system and in response to detecting the change in control of the peripheral device, reading a current firmware version of the peripheral device and determining whether the current firmware version of the peripheral device is trusted by the computer system. The method further includes in response to determining that the current firmware version is trusted by the computer system, providing control of the peripheral device to the second security domain.

Abstract: Disclosed is an electronic device comprising processor connected to a memory. The memory is configured to store a control application, a preferences file and an operating system image for executing a second operating system. The processor is configured to execute the control application in a first operating system. The processor is configured to determine whether preferences of the operating system image satisfy a defined condition in the control application The processor is also configured to change the preferences of the operating system image by using the preferences file when the preferences of the operating system image do not satisfy the defined condition. The processor is further configured to copy, to the operating system image, a package file for allowing the control application to control an operation of the second operating system.

Abstract: Methods and apparatus to provide power management for multi-die stacks using artificial intelligence are disclosed. An example integrated circuit (IC) package includes a computer processor unit (CPU) die, a memory die, inference engine circuitry within the CPU die, the inference engine circuitry to infer, based on a first machine learning model, a workload for at least one of the CPU die or the memory die, and power management engine circuitry within the CPU die, the power management engine circuitry distinct from the inference engine circuitry, the power management engine circuitry to adjust, based on a second machine learning model different than the first machine learning model, operational parameters associated with the at least one of the CPU die or the memory die, the inferred workload to be an input to the second machine learning model.

Abstract: An apparatus includes a power management integrated circuit (PMIC) and a power translator component coupled to the PMIC. The power translator component supplies power to the PMIC. The power translator component can further receive, from the PMIC, an indication that the PMIC has experienced a thermal event and responsive to receipt of the indication that the PMIC has experienced the thermal event, prevent powering of the PMIC.

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: Respective energy consumption data is collected via respective agents running on respective host servers. The respective energy consumption data represents energy consumed by the respective host servers over a time period. The respective agents communicate with hardware on each of the respective host servers using a unified application programming interface (API). Respective energy costs are determined over the time period for the respective host servers based on the respective energy consumption data. A subset of the respective host servers that are being underutilized is identified based on the respective energy consumption data and the respective energy costs. An action to take with respect to the subset of the respective host servers that are being underutilized is determined to reduce the energy costs.

Abstract: Resource access control in a system-on-chip (“SoC”) may employ an agent executing on a processor of the SoC and a trust management engine of the SoC. The agent, such as, for example, a high-level operating system or a hypervisor, may be configured to allocate a resource comprising a memory region to an access domain and to load a software image associated with the access domain into the memory region. The trust management engine may be configured to lock the resource against access by any entity other than the access domain, to authenticate the software image associated with the access domain, and to initiate booting of the access domain in response to a successful authentication of the software image associated with the access domain.

Abstract: A method is provided for authenticating firmware images in an embedded system. The method may include loading and executing a trusted firmware using a pre-existing Secure Boot on a baseboard management controller (BMC). The BMC is configured as a master for an embedded system including System On Chips (SOCs) configured as slaves, out-of-band interfaces between the BMC and the SOCs, and flash storages in electrical communication with the SOCs. The method may also include pushing or uploading, by the BMC, a secure SOC firmware image to one of the SOCs using one of the out-of-band interfaces, verifying a digital signature extracted from the SOC firmware image by using a hash code calculated from the SOC firmware image and decrypted using a public key stored on the BMC and notifying a user about verification of the digital signature.

Abstract: Apparatus, method, and machine-readable medium to provide performance state matching between source and target processors based on inter-processor interrupts. An exemplary apparatus includes a target processor to execute a receiving task at a first performance level and a source processor to execute a sending task at a second performance level higher than the first performance level. The sending task is to store interrupt routing data indicating a pairing between the sending task and the receiving task into a memory location and that the sending task is to dispatch work to be processed by the receiving task. The apparatus further includes a performance management unit to detect the pairing between the sending task and the receiving task based on the interrupt routing data and responsively adjust the performance level of the target processor from the first performance level to the second performance level based, at least in part, on the pairing.

Abstract: A method is provided in one example embodiment and includes storing secure boot variables in a baseboard management controller; and sending the secure boot variables to a basic input/output system (BIOS) during a power on self-test, where the BIOS utilizes the secure boot variables during runtime to authenticate drivers and an operating system loader execution. In particular embodiments, the secure boot variables may be included in a white list, a black list, or a key list and, further, stored in erasable programmable read only memory.

Abstract: This application relates to apparatus and methods for booting servers, such as cloud datacenter compute servers. The servers may execute one or more hypervisors, such as stateless hypervisors, with each hypervisor supporting one or more virtual machines. In some examples, each of a plurality of servers are configured to boot from a network. The compute servers may obtain an IP address identifying a location of hypervisor bootable images. Upon a reboot, the servers may request and obtain a hypervisor bootable image from the IP address. The servers may execute the hypervisor bootable image to run a hypervisor. In some examples, the servers also obtain virtual machine images from the network. One or more hypervisors executing on each server may obtain, and execute, one or more of the virtual machine images to run one or more virtual machines.