Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: A firmware includes a firmware module for copying a digitally signed binary file that includes a firmware globally unique identifier (GUID), tool GUIDs, and feature GUIDs to an Advanced Configuration and Power Management interface (ACPI) table (the Firmware Enabled Tool Registry (FETR) table). If the FETR table is stored in memory, a firmware tool determines whether a digital signature of the signed binary file can be verified. If the digital signature can be verified, the firmware tool determines if the firmware GUID stored in the FETR table matches a firmware GUID stored in another ACPI table. If the firmware GUIDs match, the firmware tool determines whether its tool GUID matches a tool GUID stored in the FETR table. The firmware tool can continue to execute if the tool GUIDs match. Firmware tool features are enabled if feature GUIDs in the FETR table match feature GUIDs of the firmware tool.

Abstract: 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.

Abstract: 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.

Abstract: A firmware provides a setup browser that generates a setup menu. An internal forms representation of setup data for rendering the setup menu is converted to markup language (ML) setup data. The ML setup data is provided to an application that provides a GUI for defining a modified setup UI for the firmware. The application provides a graphical, drag-and-drop, WYSIWYG, UI through which a user can edit existing forms and controls, create new forms and controls, and specify default values and other properties. When a user modifies the setup menu using the application, customized ML setup data is generated that defines the modified setup UI. The customized ML setup data is used to create setup data that is stored in a firmware device for use by the setup browser with the internal format representation of setup data to render the modified setup UI.

Abstract: 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.

Abstract: 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.

Abstract: Technologies are disclosed that allow the firmware of a remotely located target device to be configured. The target device can receive a command to reboot into a special remote setup mode for remote configuration. Once in the remote setup mode, the firmware listens for and can respond to HTTP requests for information on configurable data and instructions to update the configurable data.