American Megatrends, Inc.

American Megatrends International, LLC

Stefano Righi

Paul Anthony Rhea

Madhan B Santharam

Ashraf Javeed

Presanna Raman

Brian Richardson

Jerry Petree

Arun Subramanian Baskaran

Howelle Blaine Summers

Eric Mills

Sanjoy Maity

Muthukkumaran Ramalingam

Umasankar Mondal

Oleksiy Yakovlev

Natalya Kalistratova

Jerry Lynn Petree, Jr

Arun Subramanian

Joseprabu Inbaraj

Saikat Bhattacharjee

Ganesan Vengateswaran

Feng Li

Subramanian Ananthram

Sasi Vellolil

Amanda Nicole Stark

Andrew Clifford McCallum

Brandon Burrell

An application framework for managing information technology ('IT') infrastructure includes components that enable jobs to be defined and executed that perform IT infrastructure management tasks. Jobs are defined utilizing a user interface (“UI”) that includes a first pane that provides functionality for receiving a selection of a target type of IT infrastructure for a job. Compatible action blocks are then displayed in a second pane of the UI. User input can be received associating action blocks with a third pane of the UI. When user input is received associating an action block with the third pane of the UI, a task identifier is displayed in the third pane of the UI. The UI can also receive a selection of target devices upon which the actions defined by a job are to be performed. The framework executes program code corresponding to action blocks in the job on the target devices.

Application framework for managing information technology infrastructure

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 providing a Baseboard Management Controller ('BMC')-based security processor. The disclosed BMC-based security processor can provide a hardware Root of Trust (“RoT”) for a computing platform without the addition of specialized silicon to the platform and while minimizing the number of attack points. The disclosed BMC-based security processor can also provide functionality for securely filtering requests made on certain buses in a computing platform. Through implementations of the features identified briefly above, and others described herein, various technical benefits can be achieved such as, but not limited to, increased security as compared to previous computing systems that utilize a BMC to provide a hardware RoT and reduced complexity and cost as compared to previous computing systems that utilize a separate hardware device, such as a Field Programmable Gate Array (“FPGA”) or a microcontroller, to provide a hardware RoT.

Baseboard Management Controller (BMC)-based security processor

Technologies are described herein for providing a Baseboard Management Controller ('BMC') -based security processor. The disclosed BMC-based security processor can provide a hardware Root of Trust ('RoT') for a computing platform without the addition of specialized silicon to the platform and while minimizing the number of attack points. The disclosed BMC-based security processor can also provide functionality for securely filtering requests made on certain buses in a computing platform. Through implementations of the features identified briefly above, and others described herein, various technical benefits can be achieved such as, but not limited to, increased security as compared to previous computing systems that utilize a BMC to provide a hardware RoT and reduced complexity and cost as compared to previous computing systems that utilize a separate hardware device, such as a Field Programmable Gate Array (&#x201c;FPGA&#x201d;) or a microcontroller, to provide a hardware RoT.

Baseboard management controller (BMC)-based security processor

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

Technologies are disclosed herein that allow for utilization of firmware specific data through an Advanced Configuration and Power Interface (ACPI) Firmware Identification (FID) table in a computing system. The ACPI FID table can be loaded during a boot of a computer system. The ACPI FID table can be read after an operating system has been loaded on the computer system. Based upon firmware specific data in the ACPI FID table, functionality provided by the application can be restricted. The use of various features provided by the application can be restricted or the application can be restricted from executing entirely. Compatibility between the application and the firmware can be ensured based upon firmware specific data in the ACPI FID table.

Providing firmware specific information via ACPI tables

A firmware security vulnerability verification service provides functionality for verifying the presence or absence of security vulnerabilities in firmware source code and firmware. The service can generate a white box testing application to test for the presence of security vulnerabilities using revoke operations on the firmware source code. The white box testing application can report the results of the revoke operations to the service. The service can also generate a black box testing application. The black box testing application can obtain modules for testing the firmware for the presence of security vulnerabilities. The black box testing application can then execute the modules to test the firmware. The results of the black box testing can also be reported back to the network service. The network service can then make the results of the white and black box testing available to a user of the service.

Firmware security vulnerability verification service

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 provided for generation of firmware configured to restrict use of a firmware tool. Some embodiments include a computing system that can obtain firmware source code comprising a module configured to copy contents of a digitally signed binary file to an advanced configuration and power management interface (ACPI) table at runtime of a firmware. The computing system can generate a firmware image of the firmware, the firmware image comprising the module, a first firmware globally unique identifier (GUID), and a defined area storing digital content that remains unchanged upon a change to the firmware. The computing system also can obtain a binary file comprising a second firmware GUID, a firmware tool GUID, and a feature GUID, and can digitally sign the binary file using a private encryption key to generate the digitally signed binary file. The computing system can store the digitally signed binary file within the defined area.

Generation of a firmware configured for use in restricting the use of a firmware tool

Technologies are disclosed herein for identifying and resolving firmware component dependencies within a firmware project. Dependency information is generated and stored for firmware components that can be used to create a firmware project. The dependency information may define one or more mandatory dependencies, optional dependencies, and/or incompatible dependencies. The dependency information for the firmware components in the firmware project is evaluated to identify any unsatisfied dependencies when a firmware project is opened, when a firmware component is added to a firmware project, when a firmware component in a firmware project is updated, or when the firmware project is built. If any unsatisfied dependencies are identified, the dependencies can be satisfied by adding a firmware component to the firmware project, updating a firmware component in the firmware project, or by removing a firmware component from the firmware project.

Identifying and resolving firmware component dependencies

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

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.

Growing community of inventors

Lawrenceville, GA, United States of America

Stefano Righi