American Megatrends International, LLC

American Megatrends, Inc.

Madhan B Santharam

Stefano Righi

Harikrishna Doppalapudi

Purandhar Nallagatla

Chandrasekar Rathineswaran

Igor Kulchytskyy

Arun Subramanian Baskaran

Howelle Blaine Summers

Paul Anthony Rhea

Muthukkumaran Ramalingam

Presanna Raman

Arun Subramanian

Feng Li

Joseprabu Inbaraj

Amanda Nicole Stark

A computing device is configured with a hardware root of trust ('HRoT'). The HRoT and a remote registration server exchange public keys while the device is in a trusted environment. The device is then locked by setting a lock status in the HRoT. The device can then be shipped to a recipient. When the device is powered on following transit, the HRoT pauses booting of the device. If a request to unlock the device is received, the HRoT provides an encrypted one-time password to the registration server. The registration server decrypts the one-time password and provides the decrypted one-time password to the HRoT. If the HRoT determines that one-time password received from the registration server is identical to the one-time password it generated, the HRoT sets the lock status of the device to unlocked and allows the device to boot.

Securing computing devices during transit

A computing system includes a baseboard management controller ('BMC') that receives a security token from a management system. The computing system also executes a firmware that collects measurements from components of the computing system. The measurements include data describing the components for use in attestation. The firmware provides the measurements to the BMC, which generates a digital signature of the measurements and the security token. The BMC provides the measurements and the digital signature to the management system, which attempts to verify the digital signature utilizing a public key associated with the BMC. If the management system can verify the digital signature, then the BMC utilized the correct security key to generate the digital signature and the measurements were not tampered with after collection by the firmware. The measurements can then be utilized to attest the computing system.

Out-of-band (OOB) remote attestation

Technologies are described for performing firmware attestation on system reset. When a managed computing system is reset, a baseboard management controller ('BMC') generates a notification that the managed computing system has been reset and transmits the notification to an event listener executing in a management system by way of an out-of-band (“OOB”) network. The event listener receives the notification that the managed computing system has been reset and, in turn, causes a security manager executing in the management system to transmit a request for firmware attestation data to a platform security agent executing on the managed computing system. The security manager receives the firmware attestation data from the platform security agent by way of an in-band network and stores the firmware attestation data in a database for exposure to other program components for use in evaluating the trustworthiness of the firmware executing on the managed computing system.

Firmware attestation on system reset

Technologies are described herein for a representational state transfer ('REST' or 'RESTful') over Intelligent Platform Management Interface (&#x201c;IPMI&#x201d;) interface for firmware to baseboard management controller (&#x201c;BMC&#x201d;) communication and applications thereof. These applications include, but are not limited to, remote firmware configuration, firmware updates, peripheral device firmware updates, provision of management information such as system inventory data, cloning and batch migration of firmware configuration settings, and firmware integrity monitoring.

Cloning of firmware configuration settings using rest over IPMI interface

During boot time of a computing system, a human-readable lookup table is utilized to generate a binary lookup table. At runtime, a hook to a function for reading or setting a firmware variable receives a request in a custom format or a standard format. If the request is in the custom format, the hook locates a mapping identifier (ID) associated with a setup question value to be read or set and a performs a lookup operation in the binary lookup table for the mapping ID. The hook retrieves the offset and bit width associated with the setup question value to be read or set from the binary lookup table. The hook then performs the requested get or set operation using the offset and width for the value and a conventional firmware function for getting or setting a firmware variable.

Runtime access to firmware platform configuration data

Standard I/O library functions for accessing files stored on mass storage devices are modified to enable access to files stored in firmware volumes. An application can be compiled against the modified standard I/O library functions to generate a pre-boot application. When the pre-boot application is executed within a pre-boot execution environment, it can utilize standard I/O library functions to access files stored in a firmware volume. In response to receiving a request to open a file from a pre-boot application, the called I/O function searches a file cross-reference table to locate the filename for the file. If the filename is in the file cross-reference table, the GUID associated with the filename is retrieved from the file cross-reference table and used to obtain a file handle to the file. The file handle can then be returned to the pre-boot application and used to perform other types of operations on the file.

Accessing files stored in a firmware volume from a pre-boot application

Technologies are described herein for a representational state transfer ('REST' or 'RESTful') over IPMI interface for firmware to BMC communication and applications thereof. These applications include, but are not limited to, remote firmware configuration, firmware updates, peripheral device firmware updates, provision of management information such as system inventory data, cloning and batch migration of firmware configuration settings, and firmware integrity monitoring. This functionality can be provided in a way that enables communication between BMCs and firmware to utilize modern manageability interfaces while maintaining backward compatibility with previous IPMI implementations.

Peripheral device firmware update using rest over IPMI interface firmware shell utility

A management server exposes a web services interface through which managed clients that are not equipped with baseboard management controllers ('BMCs') can submit management data at boot time. The firmware of the managed clients can receive management commands from the management server during boot time. The management server can also expose a web services interface to management clients through which the management clients can obtain the management data provided by the managed clients as if the management data were being provided through a BMC. The management server can also receive management commands from the management client computers for performance at the managed client computers. The management server queues the management commands for provision to the appropriate managed clients during the next boot of the managed clients.

Platform management for computing systems without baseboard management controllers

A firmware, such as a unified extensible firmware interface (UEFI)-compliant firmware, provides a network protocol stack in a pre-boot execution environment. A network layer in the network protocol stack receives network packets. A firmware driver executing in the network layer determines whether individual network packets received at the network layer meet one or more pre-defined criteria. If individual network packets meet the pre-defined criteria, the firmware driver provides the network packets to a transport layer in the network protocol stack. If, however, the network packets received at the network layer do not meet the pre-defined criteria, the firmware driver discards the individual network packets.

Network packet filtering in network layer of firmware network stack

Technologies for receiving and using alternate firmware files of a computer are described herein. In some examples, firmware files to be used instead of currently used firmware files are stored in a firmware volume, which is stored in a UEFI partition. A flag is set indicating the presence of a firmware volume containing the alternate firmware files. At boot time, if it is determined that the flag has been set, the computer will utilize files stored in the firmware volume stored in the UEFI partition rather than corresponding files in a firmware.

Firmware security patch deployment

Technologies are described herein for a representational state transfer ('REST' or 'RESTful') over Intelligent Platform Management Interface (&#x201c;IPMI&#x201d;) interface for firmware to baseboard management controller (&#x201c;BMC&#x201d;) communication and applications thereof. These applications include, but are not limited to, remote firmware configuration, firmware updates, peripheral device firmware updates, provision of management information such as system inventory data, cloning and batch migration of firmware configuration settings, and firmware integrity monitoring. This functionality can be provided in a way that enables communication between BMCs and firmware to utilize modern manageability interfaces while maintaining backward compatibility with previous IPMI implementations.

Described herein are technologies for maintaining firmware setting during firmware updates. PLDM data is created prior to a firmware update. In instances of firmware updates, such as during runtime, recovery, or capsule, a flashing tool is used to perform the firmware flashing as well as exporting the setup configuration in a particular or required PLDM format. After the firmware is updated, the PLDM data is imported to preserve the firmware settings.

Preserving firmware settings during firmware updates

Firmware configuration using REST over IPMI interface

A firmware development tool generates platform-specific firmware images for a multitude of different computing platforms. A multi-platform firmware image creation tool receives the platform-specific firmware images and generates a multi-platform firmware image therefrom. A portion of the multi-platform firmware image includes firmware files that are common across all of the platform-specific firmware images. Other portions of the multi-platform firmware image include firmware files that are specific to each of the platform-specific firmware images. At boot time of a computer system utilizing the multi-platform firmware image, the platform that the computer system uses is detected. The firmware files that are common across the platform-specific firmware images are then loaded into memory. The firmware files that are specific to the detected platform are also loaded into memory. Once the firmware files have been loaded into memory, they can be executed to boot the computer system and provide other types of functionality.

Multi-platform firmware support

Technologies are described herein for a representational state transfer ('REST' or 'RESTful') over an Intelligent Platform Management Interface (&#x201c;IPMI&#x201d;) interface for firmware to a baseboard management controller (&#x201c;BMC&#x201d;) communication and applications thereof. These applications include, but are not limited to, remote firmware configuration, firmware updates, peripheral device firmware updates, provision of management information such as system inventory data, cloning and batch migration of firmware configuration settings, and firmware integrity monitoring. This functionality can be provided in a way that enables communication between BMCs and firmware to utilize modern manageability interfaces while maintaining backward compatibility with previous IPMI implementations.

Growing community of inventors

Duluth, GA, United States of America

Madhan B Santharam