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.
G06F 21/00 - Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
G06F 21/57 - Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
G06F 13/42 - Bus transfer protocol, e.g. handshake; Synchronisation
G06F 21/53 - Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity, buffer overflow or preventing unwanted data erasure by executing in a restricted environment, e.g. sandbox or secure virtual machine
G06F 21/74 - Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information operating in dual or compartmented mode, i.e. at least one secure mode
2.
Verifying the integrity of data transmitted between a firmware and a baseboard management controller (BMC)
Technologies are described for verifying the integrity of data transmitted between a firmware and a baseboard management controller (“BMC”). During a first verification phase, a data integrity tool compares system inventory data provided by firmware protocols to a system inventory module to system inventory data in a device instance format. During a second verification phase, the data integrity tool verifies operation of a firmware conversion module by comparing the system inventory data in the device instance format to the system inventory data in a JavaScript Object Notation (“JSON”) format. During a third verification phase, the data integrity tool retrieves the system inventory data from a management server and compares the system inventory data retrieved from the management server to the system inventory data previously transmitted to the management server. Identified discrepancies can be utilized to modify the system inventory module, the firmware conversion module, or the management server.
G06F 9/44 - Arrangements for executing specific programs
G06Q 10/087 - Inventory or stock management, e.g. order filling, procurement or balancing against orders
G06F 21/57 - Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
H04L 41/0869 - Validating the configuration within one network element
3.
Remotely disabling execution of firmware components
The components of a firmware that are to be executed are identified, such as firmware device drivers and SMI interrupt handlers. Performance data is also obtained for the components. An inventory identifying the components and the performance data are provided to a BMC. The BMC provides the inventory and the performance data to a remote management client through an out-of-band (“OOB”) network connection. The BMC might also receive a blacklist instruction from the management client. The blacklist instruction provides an indication to the BMC that one or more of the components of the firmware are not to be executed by the computing system. The BMC provides the blacklist instruction to the firmware. The firmware adds the component, or components, identified in the blacklist instruction to a blacklist. The next time the computing system is booted, the firmware will not execute the components identified in the blacklist.
G06F 21/57 - Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
4.
Remote configuration of multi-mode DIMMs through a baseboard management controller
Technologies are described herein for remotely configuring multi-mode dual in-line memory modules (“multi-mode DIMMs”) using a firmware or a baseboard management controller (“BMC”). Technologies are also described for simultaneously initiating multiple commands for configuring multi-mode DIMMs using a BMC and for updating inventory data regarding multi-mode DIMMs stored by a BMC.
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.
G06F 21/57 - Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
G06F 21/74 - Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information operating in dual or compartmented mode, i.e. at least one secure mode
G06F 21/85 - Protecting input, output or interconnection devices interconnection devices, e.g. bus-connected or in-line devices
G06F 9/30 - Arrangements for executing machine instructions, e.g. instruction decode
6.
Firmware update method and computer program product for updating firmware
A firmware update method and computer program product for updating firmware are provided. The method includes: generating a plurality of container files each corresponding to a hardware device among a plurality of hardware devices coupled to a computing system, wherein each container file includes a firmware update utility to be installed on the computing system to update a firmware installed on the corresponding hardware device; generating an image file of the computing system, wherein the image file has a container layer including the plurality of container files; booting the computing system using the image file, wherein the container files are executed consecutively; installing the firmware update utility of each container file on the computing system when each one of the container files is executed; and for each of the hardware devices, installing a firmware image thereon using the corresponding firmware update utility installed on the computing system.
A method for generating a hybrid BMC system and a hybrid BMC system are provided. The method includes: selecting, among a plurality of BMCs, one BMC to be a host BMC; selecting, among the plurality of BMCs, another BMC to be a client BMC, wherein the client BMC uses a first communication protocol different from a second communication protocol used by the host BMC, the client BMC being configured to perform a first task, and the host BMC being configured to perform a second task different from the first task; and configuring an adapter module of the host BMC to interface with the client BMC through the first communication protocol and interface with the host BMC through a second communication protocol such that the host BMC performs the first task through the adapter module.
Technologies are described herein for a representational state transfer (“REST” or “RESTful”) over Intelligent Platform Management Interface (“IPMI”) interface for firmware to baseboard management controller (“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.
G06F 21/57 - Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
9.
Runtime access to firmware platform configuration data
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.
A firmware enumerates the buses of root bridges in the computing system. If an OOR condition occurs during enumeration of the buses, the firmware determines the number of required buses for each root bridge causing an OOR condition. The number of required buses for bridge devices connected to each root bridge causing an OOR condition can be identified using the same set of bus numbers. Once the firmware has determined the number of buses required by each root bridge, including those not causing an OOR condition, the firmware reallocates the number of available buses between the root bridges such that each root bridge is allocated a number of the available buses greater than or equal to the number of required buses. The firmware stores data identifying the allocation and restarts the computing device. Upon rebooting, the computing system utilizes the new allocation of bus numbers to eliminate the OOR condition.
An automatic installation method is disclosed. The system suitable for a baseboard management controller (BMC) comprises: transmitting a enable remote media and setting an automatic configuration file to a BMC; mounting a share folder from a first server to the BMC; uploading an ISO file from the BMC to the first server, and mounting the ISO file into the share folder; copying the auto installation configuration file to the share folder, and repacking the auto installation configuration file into the ISO file to generate a repacked ISO file; and transmitting the repacked ISO file to the first server.
Technologies are disclosed herein for updating a firmware file system (FFS) file by preserving the original FFS file in its current firmware volume and then storing an updated version of the original FFS file in a firmware volume for updated FFS files. The updated FFS file may be stored in the firmware volume for updated FFS files referenced to the same FFS file identifier as the original FFS file. During boot-up of a system incorporating the updated firmware, the firmware volume for updated FFS files may be accessed to determine if an updated version of any FFS files are present. If updated FFS files are present, then those updated FFS files may be executed, rather than the original FFS files.
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.
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.
G06F 21/00 - Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
G06F 21/53 - Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity, buffer overflow or preventing unwanted data erasure by executing in a restricted environment, e.g. sandbox or secure virtual machine
G06F 21/51 - Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
G06F 11/36 - Preventing errors by testing or debugging of software
G06F 21/57 - Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
15.
Updating multi-mode DIMM inventory data maintained by a baseboard management controller
Technologies are described herein for remotely configuring multi-mode dual in-line memory modules (“multi-mode DIMMs”) using a firmware or a baseboard management controller (“BMC”). Technologies are also described for simultaneously initiating multiple commands for configuring multi-mode DIMMs using a BMC and for updating inventory data regarding multi-mode DIMMs stored by a BMC.
A firmware settings data structure and a settings mapping table for a first firmware are stored in a non-volatile memory. A second firmware settings data structure and a second settings mapping table for a second firmware are also stored. An entry is selected in the second firmware settings mapping table. A search is made of the first settings mapping table for an entry having an identifier that is the same as an identifier in the selected entry in the second firmware settings mapping table. If a matching entry is located, a value in the first firmware settings data structure identified by the entry in the first firmware settings mapping table is copied to the second firmware settings data structure. If a matching entry is not found in the first firmware settings data structure, a default value for the firmware setting is stored in the second firmware settings data structure.
H04L 9/06 - Arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for blockwise coding, e.g. D.E.S. systems
Control of a prompt for a credential to unlock a computer-readable storage device is provided. Some embodiments permit identifying a component that encrypted the computer-readable storage device and, depending on the identified component, prompting for such a credential. One embodiment can determine that a firmware encrypted the computer-readable storage device and can prompt for a password, for example, to unlock the computer-readable storage device during a boot-up process performed by the firmware. Other embodiments can determine that an operating system encrypted the computer-readable storage device, and can avoid the presentation of a prompt for a password, for example, during a boot-up process performed by the firmware. The computer-readable storage device can be a self-encrypting drive (SED) or another type of disk drive.
G06F 21/57 - Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
G06F 21/62 - Protecting access to data via a platform, e.g. using keys or access control rules
G06F 12/14 - Protection against unauthorised use of memory
G06F 21/78 - Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
18.
Accessing files stored in a firmware volume from a pre-boot application
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.
Technologies are described herein for remotely configuring multi-mode dual in-line memory modules (“multi-mode DIMMs”) using a firmware or a baseboard management controller (“BMC”). Technologies are also described for simultaneously initiating multiple commands for configuring multi-mode DIMMs using a BMC and for updating inventory data regarding multi-mode DIMMs stored by a BMC.
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.
G06F 21/00 - Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
G06F 21/62 - Protecting access to data via a platform, e.g. using keys or access control rules
H04L 9/32 - Arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system
21.
Automated identification and disablement of system devices in a computing system
Technologies are provided for automated identification of system devices to be disabled in a computing system and the disablement of the system devices during bootup of the computing system. In some embodiments, the computing system can execute a firmware configured to perform a bootup process of the computing system. The computing system includes multiple system devices. The firmware can generate program code for identifying a system device for disablement. The firmware can send the program code to a controller device curing the bootup process, where execution of the program code by the controller device generates data identifying one or several specific system devices to be disabled in the computing system. The firmware can then access such data from the controller device. Using the data, the firmware can determine that a specific system device to be disabled. The firmware can then disable that particular system device on a next bootup process.
In an aspect of the disclosure, a method, a computer-readable medium, and an apparatus are provided. The apparatus may be a pod manager. The pod manager receives receive a request for composing a target composed-node. The pod manager employs a first set of pooled hardware resources of the computing pod to build the target composed-node. The pod manager determines to reserve a second set of pooled hardware resources of the computing pod for a backup node of the target composed-node. The pod manager determines that the target composed-node has failed. The pod manager employs the second set of pooled hardware resources to build the backup node.
G06F 9/50 - Allocation of resources, e.g. of the central processing unit [CPU]
G06F 11/14 - Error detection or correction of the data by redundancy in operation, e.g. by using different operation sequences leading to the same result
A computing device includes a processor, a volatile memory, and a non-volatile memory. The computing device receives a firmware update that includes updated firmware runtime components, such as updated runtime interrupt handlers (e.g. SMI handlers). The computing device stores the updated firmware runtime components in the volatile memory (e.g. RAM) of the device. The computing device also causes the updated firmware runtime components stored in the volatile memory to be used during the runtime of the computing device instead of one or more other firmware runtime components previously stored in the volatile memory. For example, the contents of one or more interrupt routing tables can be adjusted such that updated runtime interrupt handlers stored in volatile memory are used instead of previously installed and potentially insecure runtime interrupt handlers. On a subsequent reboot of the computing device, updated firmware runtime components stored in the non-volatile memory will be utilized.
Technologies are disclosed for identifying firmware functions that were executed in a call chain prior to the occurrence of an error condition, such as an assert or an exception. In particular, a search is made from an instruction pointer (“IP”) for a memory address containing a signature identifying a firmware module. The firmware module that includes a function that generated the error condition can be identified based on the memory address. The name of the function that generated the error condition can be identified using a function mapping file. Previous functions in the same call chain are identified and their names determined using the function mapping file. Output can then be generated that includes the name of the firmware module that includes the function that generated the error condition, the name of the function that generated the error condition, and the names of other functions in the same call chain.
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.
A server deployment method and system in a hypervisor architecture are disclosed. The server deployment method, applied between a deployment management platform and at least one deployed server, includes steps of: (a) the deployed server requesting an internet protocol (IP); (b) the deployment management platform distributing the IP; (c) the deployed server requesting an agent; (d) the deployment management platform delivering the agent; (e) the deployed server automatically joining the deployment management platform; (f) the deployment management platform mounting a hard disk shared by the deployed server; (g) the deployment management platform selecting the type of central processing unit (CPU) and installing an operating system to the hard disk shared by the deployed server; and (h) establishing a connection of a monitor screen between the deployment management platform and the deployed server.
Technologies are described herein for a representational state transfer (“REST” or “RESTful”) over Intelligent Platform Management Interface (“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.
G06F 13/36 - Handling requests for interconnection or transfer for access to common bus or bus system
G06F 21/57 - Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
28.
System and method for updating files through a peer-to-peer network
A system and a method for updating files through a peer-to-peer (P2P) network are provided. The system includes a plurality of device nodes, and a link manager. The device nodes are distributed in a peer-to-peer network and respectively have baseboard management controllers (BMCs). The link manager connects to the peer-to-peer network via a management network and includes an update engine. The device nodes include at least a first device node, a second device node and a third device node. The link manager sends an update command to the peer-to-peer network. The update engine arranges a first update from the first device node to the second device node, and arranges a second update from the second device node to the third device node.
A method, a baseboard management controller (BMC) and a system for establishing a serial-over-LAN connection are provided. The method includes: receiving data from a server unit using the first UART at a current baud rate; detecting the current baud rate of the first UART using the BMC; configuring the baud rate of the second UART of the BMC as the current baud rate; controlling the second UART to retrieve the data from the first UART at the current baud rate using the BMC; and sending the data to a network using the BMC.
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.
Technologies are disclosed herein that allow for utilization of memory channel storage (“MCS”) devices in a computing system. The MCS device may be detected during a boot phase of the computing system, and the address data for the MCS device may be detected through repeated manipulation of a logical offset. The address data may then be stored for later use in memory allocation.
Debug trace statements from a firmware are captured during a boot cycle of a computer executing the firmware. The debug trace statements are written to a motherboard's Serial Peripheral Interface (“SPI”) device. A microcontroller's SPI device receives the debug trace statements from the motherboard's SPI device, transforms the data format of the debug trace statements, and transmits the transformed debug trace statements over a serial communications port of the microcontroller.
Non-destructive update of discrete firmware components of a firmware is provided. During a boot-up process, the availability of an update for the firmware can be determined prior to execution thereof. To that end, a controller device can be queried for availability of the update and, when the update is available, a processor that executes the firmware as part of the boot-up process can retrieve an updated version of one or more components of the firmware from a virtual drive device provided by the controller device. The processor can retain such component(s) in a main memory device. The processor can then execute the component(s) from the main memory and can execute other non-updated component(s) of the firmware from a non-volatile memory device that retains the firmware. Therefore, the firmware can be updated during the boot-up process, without changing the contents of the non-volatile memory device.
A method for firmware debug trace capture includes creating a hand-off block (“HOB”), capturing first debug trace statements during a boot sequence of a computer and writing the first debug trace statements to the HOB. A trace memory buffer can be created and the first debug trace statements can be copied from the HOB to the trace memory buffer. Second debug trace statements are captured during the boot sequence and appended to the trace memory buffer. In some configurations, the first debug trace statements can be written to the HOB during the pre-Extensible Firmware Interface initialization (“PEI”) phase of the boot sequence and the second debug trace statements can be written to the trace memory buffer during the driver execution (“DXE”) phase of the boot sequence.
Technologies are disclosed herein for utilizing near field communication (“NFC”) to improve the security, performance, and configuration of computing systems. In particular, NFC can be utilized to power an NFC-equipped server computer on or off, to log directly into an operating system executing on the NFC-equipped server computer, to stream firmware debugging data from an NFC-equipped server computer to an NFC-equipped mobile device, to initiate the update or recovery of firmware, to provide hardware inventory data, or to pair hardware devices. Firmware debugging data can also be streamed from a firmware to an NFC-equipped mobile device. NFC can also be utilized to disable functionality provided by a mobile device while the device is in motion, such as when a user of the mobile device is operating a motor vehicle.
H04W 4/80 - Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
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.
G06F 13/36 - Handling requests for interconnection or transfer for access to common bus or bus system
G06F 21/57 - Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
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.
G06F 13/36 - Handling requests for interconnection or transfer for access to common bus or bus system
G06F 21/57 - Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
A monitoring system may include a sensor configured to be mounted inside a computer chassis and generate sensor signals representative of a temperature associated with at least one computer component inside the computer chassis. The monitoring system may also include a sensor processor configured to receive the sensor signals and determine the temperature associated with the at least one computer component based at least in part on the sensor signals. The sensor processor may also be configured to compare the determined temperature with an expected temperature associated with the at least one computer component, and initiate a response when the determined temperature differs from the expected temperature by an amount equal to or greater than a threshold amount.
Technologies are disclosed herein for saving data, such as state data, during boot-up of a computer system, such that that data may be retrieved at a later time and restored to its original locations. The data that is stored may be from a shared partition of system memory that is accessible by both firmware services and runtime services, as enabled by an operating system and/or applications running on the computer system. The data may be stored in a partition of the system memory that is only accessible by firmware. In some embodiments, due to the data of the shared partition of the system memory being restored, some functions of the boot-up may not be repeated prior to loading a second operating system on the computer system.
A firmware can include multiple features for multiple users enabled based on the presence of authenticated variables. When attempting to access functionality of a feature, the firmware will check for the presence of an authenticated variable corresponding to the feature. The authenticated variable for the feature may be installed by a user. The firmware may data to enable a feature that includes an authenticated variable for enabling the feature and an authenticated variable corresponding to an end-user of the firmware. If the firmware has access to the end-user authenticated variable, the feature authenticated variable is installed.
A firmware attempts to allocate memory address resources, such as memory addresses in a PCI I/O and a PCI memory address space, to bus devices in a multi-processor computing system. If an out-of-resource (OOR) condition occurs during allocation of the memory address resources, memory address resources can be re-allocated from stacks that were successfully allocated requested resources to stacks that were not successfully allocated requested resources. Memory address resources can also, or alternately, be re-allocated from sockets that were successfully allocated requested resources to sockets that were not successfully allocated requested resources. If stack-level or socket-level readjustment of the memory address resource allocation fails, a base memory address of a configuration memory address space can be lowered, and the allocation can be retried. A pre-defined memory address resource allocation table can also be utilized to allocate the memory address resources following failure of the stack-level and socket-level allocation readjustment.
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.
A password protection module is added to a BIOS firmware initialization routine to lock a password protected device on a warm reset. The password protection module sets one or more variables associated with the operation of a password protected device. The variables enable password protection for the password protected device and enable a shift from an unlocked state to a locked state upon a warm reset.
G06F 15/177 - Initialisation or configuration control
G06F 9/00 - Arrangements for program control, e.g. control units
G06F 21/78 - Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
G06F 21/57 - Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
An external M.2 solid-state drive dock with local and network interfaces is disclosed. The dock includes an enclosure with apertures through which M.2 solid-state drives can be received. A circuit board is mounted within the enclosure that includes M.2 socket connectors for receiving the M.2 solid-state drives. The circuit board also includes a storage controller coupled to the M.2. socket connectors. A local interface controller is coupled to the storage controller for providing a local interface, such as a USB-C interface, to the M.2 solid-state drives to host computers. A network controller is also coupled to the storage controller for providing network interfaces, such as wired and/or wireless network interfaces, for accessing the M.2. solid-state drives. The storage controller can receive storage requests from the local interface controller and the network interface controller and provide the storage requests to the M.2 solid-state drives.
Technologies are disclosed herein for near field communication (“NFC”) enhanced firmware security. Using an implementation of the technologies disclosed herein, an NFC card or an NFC-equipped mobile device can be utilized to access an NFC-equipped server computer. The server computer reads a login key from an NFC card or an NFC-equipped mobile device. Based upon the login key, a firmware executing on the server computer can determine whether a user is to have administrator access rights, non-administrator user access rights, or no access rights at all to a firmware setup menu provided by the server computer. Based upon the login key, the firmware executing in the NFC-equipped server computer can also identify an operating system to be booted by the server computer. In some configurations, an NFC-equipped mobile device contacts an authorization server to obtain the login key based upon a user's access credentials.
G06F 21/35 - User authentication involving the use of external additional devices, e.g. dongles or smart cards communicating wirelessly
G06F 21/62 - Protecting access to data via a platform, e.g. using keys or access control rules
H04W 4/80 - Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
H04W 4/02 - Services making use of location information
46.
Identifying an remediating correctable hardware errors
Technologies are disclosed for identifying and remediating correctable hardware errors. A firmware can detect a system management interrupt (“SMI”) generated by a hardware device responsive to the occurrence of a correctable error. Once the firmware has identified the device that generated the SMI, the firmware can determine whether an earliest recorded error generated by the identified device is longer ago than a threshold amount of time. If the earliest recorded error generated by the device is not longer ago than the threshold amount of time, the firmware can increment an error count for the device. The firmware can also determine whether the error count for the device exceeds a threshold. If the error count for the device exceeds the threshold, the firmware can generate an error notification for the device. The firmware can also implement a remedial action policy for the device.
G06F 11/07 - Responding to the occurrence of a fault, e.g. fault tolerance
G06F 11/14 - Error detection or correction of the data by redundancy in operation, e.g. by using different operation sequences leading to the same result
G06F 13/42 - Bus transfer protocol, e.g. handshake; Synchronisation
47.
Rest over IPMI interface for firmware to BMC communication
Technologies are described herein for a representational state transfer (“REST” or “RESTful”) over an Intelligent Platform Management Interface (“IPMI”) interface for firmware to a baseboard management controller (“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.
G06F 21/57 - Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
48.
Option ROM dispatch policy configuration interface
A computer-implemented method renders user interfaces for devices with multi-image option ROMs according to option ROM dispatch policies associated with the devices. The option ROM dispatch policies can specify whether the multi-image option ROM for the device is enabled or disabled. The option ROM dispatch policies can also specify the image of the multi-image option ROM to execute during boot. The multi-image ROM can include a UEFI compliant image and a legacy BIOS image. The computer-implemented method may receive user selections modifying the option ROM dispatch policies via the rendered user interfaces.
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.
Firmware interfaces scale a fixed-font utilized by the firmware interfaces to display glyphs of the fixed-font at a native resolution or a preferred resolution of a display. A conversion factor is generated for scaling the glyphs of the font using the native resolution or the preferred resolution. The glyphs may be scaled using the conversion factor. The scaled glyphs may be stored and utilized to display text of the firmware interface in the native resolution or the preferred resolution.
A computer system has a first node including a first baseboard management controller (BMC) and a first host of the first BMC. The first node determines that the first node is an active node. The first node operates a first storage service at the first host. The first host is a first storage device connected to one or more storage drives. The first storage service manages a first Remote Direct Memory Access (RDMA) controller for accessing user data stored on the one or more storage drives. The first node indicates to a second node that the first node is operating normally. The first node syncs data available on the first node with the second node.
G06F 13/28 - Handling requests for interconnection or transfer for access to input/output bus using burst mode transfer, e.g. direct memory access, cycle steal
G06F 13/362 - Handling requests for interconnection or transfer for access to common bus or bus system with centralised access control
H04L 67/1097 - Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
G06F 9/50 - Allocation of resources, e.g. of the central processing unit [CPU]
H04L 43/0817 - Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
G06F 3/06 - Digital input from, or digital output to, record carriers
G06F 15/173 - Interprocessor communication using an interconnection network, e.g. matrix, shuffle, pyramid, star or snowflake
H04L 41/5054 - Automatic deployment of services triggered by the service manager, e.g. service implementation by automatic configuration of network components
G06F 11/20 - Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
52.
Auto-provisioning and auto-installation of server SAN target
A computer system includes a BMC and a host of the BMC. The BMC redirect, through a BMC communication channel, a local media including a disk management tool to a host of the BMC as a particular drive. The host is a storage device connected to one or more storage drives. The disk management tool is configured to prepare a storage area of the one or more storage drives for installation of storage service on the host. The storage service managing a RDMA controller at the host. The BMC configures the host to boot from the particular drive. The BMC sends a first instruction to the host instructing the BMC to reboot. The BMC receives from the host a command for reading the disk management tool. The BMC sends the disk management tool to the host.
G06F 13/28 - Handling requests for interconnection or transfer for access to input/output bus using burst mode transfer, e.g. direct memory access, cycle steal
G06F 13/42 - Bus transfer protocol, e.g. handshake; Synchronisation
G06F 13/362 - Handling requests for interconnection or transfer for access to common bus or bus system with centralised access control
H04L 67/1097 - Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
G06F 9/50 - Allocation of resources, e.g. of the central processing unit [CPU]
H04L 43/0817 - Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
G06F 3/06 - Digital input from, or digital output to, record carriers
G06F 15/173 - Interprocessor communication using an interconnection network, e.g. matrix, shuffle, pyramid, star or snowflake
H04L 41/5054 - Automatic deployment of services triggered by the service manager, e.g. service implementation by automatic configuration of network components
G06F 13/36 - Handling requests for interconnection or transfer for access to common bus or bus system
G06F 11/20 - Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
53.
Enablement of software defined storage solution for NVME over ethernet fabric management on a processor
A computer system includes a BMC and a host of the BMC. The BMC receives a first message from a first remote device on a management network. The BMC determines whether the first message is directed to a storage service or fabric service executed on a central processing unit of the host. The host is a storage device. The central processing unit is in commutation with a RDMA controller through an external communication channel. The RDMA controller being managed by the storage service. The BMC extracts a service management command from the first message, when the first message is directed to the storage service or fabric service. The BMC sends, through a BMC communication channel to the host, a second message containing the service management command to the host. The BMC communication channel has been established for communicating baseboard management commands between the BMC and the host.
G06F 13/362 - Handling requests for interconnection or transfer for access to common bus or bus system with centralised access control
G06F 3/06 - Digital input from, or digital output to, record carriers
G06F 15/173 - Interprocessor communication using an interconnection network, e.g. matrix, shuffle, pyramid, star or snowflake
G06F 13/28 - Handling requests for interconnection or transfer for access to input/output bus using burst mode transfer, e.g. direct memory access, cycle steal
H04L 29/08 - Transmission control procedure, e.g. data link level control procedure
G06F 9/50 - Allocation of resources, e.g. of the central processing unit [CPU]
In an aspect of the disclosure, a method, a computer-readable medium, and a computer system are provided. The computer system includes a baseboard management controller (BMC). The BMC receives a first message from a first remote device on a management network. The BMC determines whether the first message is directed to a storage service or fabric service running on a host of the BMC. The host is a storage device. The BMC extracts a service management command from the first message, when the first message is directed to the storage service or fabric service. The BMC sends, through a BMC communication channel to the host, a second message containing the service management command to the host. The BMC communication channel established for communicating baseboard management commands between the BMC and the host.
G06F 13/28 - Handling requests for interconnection or transfer for access to input/output bus using burst mode transfer, e.g. direct memory access, cycle steal
G06F 13/362 - Handling requests for interconnection or transfer for access to common bus or bus system with centralised access control
H04L 67/1097 - Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
G06F 9/50 - Allocation of resources, e.g. of the central processing unit [CPU]
H04L 43/0817 - Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
G06F 3/06 - Digital input from, or digital output to, record carriers
G06F 15/173 - Interprocessor communication using an interconnection network, e.g. matrix, shuffle, pyramid, star or snowflake
H04L 41/5054 - Automatic deployment of services triggered by the service manager, e.g. service implementation by automatic configuration of network components
G06F 11/20 - Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
55.
Secured and out-of-band (OOB) server san solution on a commodity storage box
A computer system includes a BMC and a host of the BMC. The BMC receives a first message from a first remote device on an existing out-of-band management network. The BMC determines whether the first message is directed to a storage service or fabric service running on the host, the host being a storage device. The storage service provides access to user data stored on one or more storage devices connected to the host via a storage network that is isolated from the management network. When the first message is directed to the storage service or fabric service: the BMC extracts a service command from the first message; the BMC sends, through a BMC communication channel to the host, a second message containing the service command to the host. The BMC communication channel has been established for communicating baseboard management commands between the BMC and the host.
G06F 13/28 - Handling requests for interconnection or transfer for access to input/output bus using burst mode transfer, e.g. direct memory access, cycle steal
G06F 13/362 - Handling requests for interconnection or transfer for access to common bus or bus system with centralised access control
H04L 29/08 - Transmission control procedure, e.g. data link level control procedure
G06F 9/50 - Allocation of resources, e.g. of the central processing unit [CPU]
A computer system includes a BMC and a host of the BMC. The BMC receives a first message from a first remote device on a management network. The BMC determines whether the first message is directed to a storage service or fabric service executed on a main processor of a storage controller of the host. The host is a storage device. The storage controller includes an RDMA controller in communication with the main processor through an internal communication channel of the storage controller. The RDMA controller is managed by the storage service. The BMC extracts a service management command from the first message, when the first message is directed to the storage service or fabric service. The BMC sends, through a BMC communication channel established for communicating baseboard management commands between the BMC and the host, a second message containing the service management command to the host.
G06F 13/00 - Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
G06F 13/28 - Handling requests for interconnection or transfer for access to input/output bus using burst mode transfer, e.g. direct memory access, cycle steal
G06F 13/362 - Handling requests for interconnection or transfer for access to common bus or bus system with centralised access control
H04L 67/1097 - Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
G06F 9/50 - Allocation of resources, e.g. of the central processing unit [CPU]
H04L 43/0817 - Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
G06F 3/06 - Digital input from, or digital output to, record carriers
G06F 15/173 - Interprocessor communication using an interconnection network, e.g. matrix, shuffle, pyramid, star or snowflake
H04L 41/5054 - Automatic deployment of services triggered by the service manager, e.g. service implementation by automatic configuration of network components
G06F 11/20 - Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
57.
Techniques of sending alerts from storage services running on server san target
A computer system includes a first baseboard management controller (BMC) and a first host of the first BMC. The first host operates a first storage service at the first host. The first host is a first storage device connected to one or more storage drives. The first storage service managing a first Remote Direct Memory Access (RDMA) controller for accessing user data stored on the one or more storage drives through a storage network. The first BMC receives state information of the one or more storage drives. The first BMC sends notifications to a client of the first BMC, in response to receiving the state information.
G06F 13/28 - Handling requests for interconnection or transfer for access to input/output bus using burst mode transfer, e.g. direct memory access, cycle steal
G06F 13/362 - Handling requests for interconnection or transfer for access to common bus or bus system with centralised access control
G06F 13/42 - Bus transfer protocol, e.g. handshake; Synchronisation
G06F 3/06 - Digital input from, or digital output to, record carriers
In an aspect of the disclosure, a method, a computer-readable medium, and a device are provided. The device determines one or more feature components of firmware of a BMC to be tested. The device also determines a respective QA category from a plurality of QA categories for each of the one or more feature components. Each of the plurality of QA categories is associated with a set of feature components and a set of the test cases. The device further determines respective at least one test case for each of the one or more feature components based on the respective QA category of the each feature component. The test case specifies hardware and a procedure to be used to test the each feature component.
Technologies are disclosed herein for launching updated firmware file system (FFS) files of an updated firmware. Original FFS files may be stored in a first firmware volume and updates to any of the original FFS files may be stored as updated FFS files in a second firmware volume. When booting up a computer system with an original FFS file and a corresponding updated FFS file, either the original FFS file or the updated FFS file may be executed based at least in part on an indication of the updated FFS file in one of either a black list or a launch list. The first time a computer system is boot up after storing an updated FFS file in the second firmware volume, the updated FFS file may be executed to determine whether the execution of the updated FFS file warrants inclusion in either the black list or the launch list.
In an aspect of the disclosure, a method, a computer-readable medium, and a device are provided. The device determines that a target event occurred at a first server in a group of servers that are jointly managed. The device obtains, for the first server, a public-private key pair including a first key and a second key. The device provides the first key to the first server such that the first server is accessible by authentication with the first key. The device provides the second key to a client device such that the first server is accessible by the client device by providing the second key to the server. Subsequently, the device revokes the first key from the first server.
A firmware enumerates the buses of root bridges in the computing system. If an OOR condition occurs during enumeration of the buses, the firmware determines the number of required buses for each root bridge causing an OOR condition. The number of required buses for bridge devices connected to each root bridge causing an OOR condition can be identified using the same set of bus numbers. Once the firmware has determined the number of buses required by each root bridge, including those not causing an OOR condition, the firmware reallocates the number of available buses between the root bridges such that each root bridge is allocated a number of the available buses greater than or equal to the number of required buses. The firmware stores data identifying the allocation and restarts the computing device. Upon rebooting, the computing system utilizes the new allocation of bus numbers to eliminate the OOR condition.
Technologies are disclosed herein for updating a firmware file system (FFS) file by preserving the original FFS file in its current firmware volume and then storing an updated version of the original FFS file in a firmware volume for updated FFS files. The updated FFS file may be stored in the firmware volume for updated FFS files referenced to the same FFS file identifier as the original FFS file. During boot-up of a system incorporating the updated firmware, the firmware volume for updated FFS files may be accessed to determine if an updated version of any FFS files are present. If updated FFS files are present, then those updated FFS files may be executed, rather than the original FFS files.
In an aspect of the disclosure, a method, a computer-readable medium, and an apparatus are provided. The apparatus is an embedded-system device. The embedded-system device loads a first boot loader from a read only section of a storage device in an initialization process of the embedded-system device. The embedded-system device also loads, by the first boot loader, a public key from the read only section. The embedded-system device further generates a first verification code for static code and data stored in a first section of the storage device. The embedded-system device then decrypts, by the first boot loader, an encrypted signature stored in the first section by using the public key to obtain a second verification code. The embedded-system device determines integrity of the static code and data based on the first verification code and the second verification code.
G06F 21/57 - Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
H04L 9/30 - Public key, i.e. encryption algorithm being computationally infeasible to invert and users' encryption keys not requiring secrecy
G06F 21/64 - Protecting data integrity, e.g. using checksums, certificates or signatures
H04L 9/32 - Arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system
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.
G06F 9/44 - Arrangements for executing specific programs
G06F 21/57 - Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
G06F 8/71 - Version control ; Configuration management
Technologies are described herein for a representational state transfer (“REST” or “RESTful”) over Intelligent Platform Management Interface (“IPMI”) interface for firmware to baseboard management controller (“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.
G06F 21/57 - Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
66.
Preserving firmware settings during firmware updates
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.
G06F 11/14 - Error detection or correction of the data by redundancy in operation, e.g. by using different operation sequences leading to the same result
In an aspect of the disclosure, a method, a computer-readable medium, and a computer system are provided. The computer system includes an initialization component of a host. The initialization component requests from a service processor of the host a first replacement firmware image of a first device of the host. The initialization component then receives the first replacement firmware image from the service processor. The initialization component further provides the first replacement firmware image to a first updating program. The initialization component uses the first updating program to replace the first existing firmware image on the first device with the first replacement firmware image.
In an aspect of the disclosure, a method, a computer-readable medium, and a computer system are provided. The computer system includes an initialization component of a host. The initialization component obtains a process file for dynamically creating a processing component on a management platform on a BMC of the host, the process file defining a logic to be implemented by the processing component, the initialization component operating to load an operating system of the host. The initialization component sends the process file to the BMC. The initialization component further sends a message to the BMC, the message including data to be processed by the processing component.
In an aspect of the disclosure, a method, a computer-readable medium, and a device are provided. The device the package determination component 430 determines one or more packages distributed in firmware of a BMC. The device determines a respective update of each of the one or more packages. The device determines a first set of security vulnerabilities of the each package that is addressed by the respective update. The device further determines a second set of security vulnerabilities of the each package after the respective update is applied. The device generates a first file indicating the first set of security vulnerabilities and the second set of security vulnerabilities.
G06F 21/57 - Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
G06F 11/36 - Preventing errors by testing or debugging of software
Technologies are disclosed herein for blocking access to some firmware variables during runtime. These firmware variables may be disallowed from runtime access (e.g., read/write access), by placing an indication of the firmware variables on a runtime blocklist. Upon completion of booting, runtime firmware services may access the runtime blocklist to determine if a firmware variable is to be accessed during runtime. In some cases, a firmware variable may be disallowed from runtime access by inclusion in the runtime blocklist, even if that firmware variable has an attribute that indicates that it is runtime accessible. The runtime blocklist may be generated based at least in part on indications of the firmware variables to be blocked during runtime. Additionally, runtime accessible firmware variables may be exposed to higher-level software, such as an O/S, if the firmware variables are not included in the runtime blocklist.
G06F 21/57 - Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
G06F 21/53 - Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity, buffer overflow or preventing unwanted data erasure by executing in a restricted environment, e.g. sandbox or secure virtual machine
71.
Firmware configuration using REST over IPMI interface
Technologies are described herein for a representational state transfer (“REST” or “RESTful”) over Intelligent Platform Management Interface (“IPMI”) interface for firmware to baseboard management controller (“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.
G06F 21/57 - Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
72.
Dynamic configuration of availability of debugging messages
Configuration of availability of debugging messages during the execution of a firmware in a debugging mode of operation is provided. The configuration can be updated without rebuilding the firmware. Thus, a selection of a group of available types of debugging messages can be updated dynamically, at various runtime instances of the firmware. The selection can be accomplished by configuring, at a runtime of the firmware, a level of recordation of debugging messages and one or more data structures associated with the level or recordation. Each of the one or more data structures includes elements indicative of respective types of debugging messages being enabled or disabled for presentation during the execution of the firmware in the debugging mode of operation. A debugging message can be provided based at least partially on at least one of the data structure(s) during the execution of the firmware in the debugging mode of operation.
G06F 21/57 - Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
G06F 3/0484 - Interaction techniques based on graphical user interfaces [GUI] for the control of specific functions or operations, e.g. selecting or manipulating an object, an image or a displayed text element, setting a parameter value or selecting a range
73.
Loading a serial presence detect table according to jumper settings
Technologies are disclosed herein for configuring a system memory of a computer system by determining which, of a plurality, of serial presence detect (SPD) tables to utilize, based at least in part on settings of one or more GPIO pins. The computer system may be available with variations of the configuration of system memory. The SPD tables corresponding to each of the different configurations of the system memory may be stored on the computer system, such as on an NVRAM of the computer system. After identifying the appropriate SPD table, a processor may load the SPD table to a memory reference code of the computer system. In some cases, the state GPIO pins indicating the system memory configuration is set at the time of manufacture of the computer system.
A first firmware component executes from a secure memory and a second firmware component executes from a non-secure memory. The first firmware component receives a request to store data in a non-volatile (NV) memory. In response to the request, the first firmware component stores the data in the NV memory and in a buffer located in the secure memory. The first firmware component also copies the buffer to non-secure memory. The first firmware component provides an indication to the second firmware component that the buffer was updated. The second firmware component can then update an internal data structure identifying the start, end, or size of the data stored in the buffer. Once the internal data structure is updated, the second firmware component can respond to requests to retrieve firmware variables of other types of data without accessing buffers in secure memory.
G06F 21/57 - Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
G06F 9/52 - Program synchronisation; Mutual exclusion, e.g. by means of semaphores
G06F 21/79 - Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data in semiconductor storage media, e.g. directly-addressable memories
75.
Restricting the use of a firmware tool to a specific platform
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.
G06F 21/00 - Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
G06F 21/62 - Protecting access to data via a platform, e.g. using keys or access control rules
H04L 9/32 - Arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system
In an aspect of the disclosure, a method, a computer-readable medium, and a computer system are provided. The computer system includes a BMC. The BMC receives, through a management platform on the BMC, a first part of initialization data from an initialization component of a host of the BMC. The BMC also receives an indication of a location at an initialization storage device of the host. The BMC then obtains access to the initialization storage device. The BMC reads a second part of the initialization data from the location of the initialization storage device.
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.
In an aspect of the disclosure, a method, a computer-readable medium, and a computer system are provided. The computer system includes a BMC of a host. The BMC redirects images from the host to a device for displaying at a redirection display. The BMC further receives an indication that the redirection display is no longer in an active mode. The BMC then stops redirecting the images from the BMC to the device in response to the indication.
A system may be configured to receive via a user interface a user-initiated prompt to begin start-up of a computer system firmware via access to a firmware start-up utility. The system may also generate a request for user authentication, and detect a private key for user authentication. The system may also determine whether the private key corresponds to a public key previously registered with the computer system firmware, and initiate, when the private key corresponds to the public key, completion of the start-up of the computer system firmware and allowance of operation of the computer system firmware via access to the firmware start-up utility. When the private key does not correspond to the public key, the system may prevent at least one aspect of an operation associated with the start-up of the computer system firmware.
G06F 21/57 - Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
H04L 9/32 - Arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system
A method for firmware debug trace capture includes creating a hand-off block (“HOB”), capturing first debug trace statements during a boot sequence of a computer and writing the first debug trace statements to the HOB. A trace memory buffer can be created and the first debug trace statements can be copied from the HOB to the trace memory buffer. Second debug trace statements are captured during the boot sequence and appended to the trace memory buffer. In some configurations, the first debug trace statements can be written to the HOB during the pre-Extensible Firmware Interface initialization (“PEI”) phase of the boot sequence and the second debug trace statements can be written to the trace memory buffer during the driver execution (“DXE”) phase of the boot sequence.
In an aspect of the disclosure, an apparatus, a computer-readable medium, and a method are provided. The apparatus may be a service processor. The service processor receives, a first command or data of a UBM protocol from a UBM host running on a host of the service processor. The UBM protocol is a first protocol supported by the service processor. The first command or data instructs a backplane controller of the host to perform a first task. The service processor generates a second command or data of a second protocol supported by the service processor. The second command or data instructs the backplane controller to perform the first task. The service processor sends the second command or data to the backplane controller.
Technologies are described herein for a representational state transfer (“REST” or “RESTful”) over an Intelligent Platform Management Interface (“IPMI”) interface for firmware to a baseboard management controller (“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.
G06F 13/36 - Handling requests for interconnection or transfer for access to common bus or bus system
G06F 8/71 - Version control ; Configuration management
G06F 21/57 - Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
G06F 11/14 - Error detection or correction of the data by redundancy in operation, e.g. by using different operation sequences leading to the same result
83.
Accessing files stored in a firmware volume from a pre-boot application
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.
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.
A computer system includes a memory and computer-readable instructions stored at the memory and executable by a microprocessor to: initiating power on mode in order to execute UEFI firmware for OS boot up procedure; initiating pairing with a wireless device; saving a pairing connection data of the wireless device to memory; retrieving the pairing connection data under Operating System environment; and initiating automatic pairing with the wireless device based on the pairing connection data.
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.
G06F 21/00 - Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
G06F 21/53 - Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity, buffer overflow or preventing unwanted data erasure by executing in a restricted environment, e.g. sandbox or secure virtual machine
G06F 21/51 - Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
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.
A computer-implemented method for predicting a risk of disk failure is described herein. The method can include collecting a performance parameter for respective disks in a group of disks, and calculating an expected value of the performance parameter for the group of disks. The method can also include comparing a respective value of the performance parameter for a respective disk in the group of disks to the expected value, and predicting a risk of disk failure based on the comparison. For example, when a difference between the respective value of the performance parameter for the respective disk and the expected value exceeds a threshold, the respective disk may be at risk of failing.
G06F 11/20 - Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
89.
Non-destructive update of discrete components of firmware
Non-destructive update of discrete firmware components of a firmware is provided. During a boot-up process, the availability of an update for the firmware can be determined prior to execution thereof. To that end, a controller device can be queried for availability of the update and, when the update is available, a processor that executes the firmware as part of the boot-up process can retrieve an updated version of one or more components of the firmware from a virtual drive device provided by the controller device. The processor can retain such component(s) in a main memory device. The processor can then execute the component(s) from the main memory and can execute other non-updated component(s) of the firmware from a non-volatile memory device that retains the firmware. Therefore, the firmware can be updated during the boot-up process, without changing the contents of the non-volatile memory device.
A firmware can include multiple features for multiple users enabled based on the presence of authenticated variables. When attempting to access functionality of a feature, the firmware will check for the presence of an authenticated variable corresponding to the feature. The authenticated variable for the feature may be installed by a user. The firmware may data to enable a feature that includes an authenticated variable for enabling the feature and an authenticated variable corresponding to an end-user of the firmware. If the firmware has access to the end-user authenticated variable, the feature authenticated variable is installed.
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.
G06F 11/14 - Error detection or correction of the data by redundancy in operation, e.g. by using different operation sequences leading to the same result
G06F 1/3209 - Monitoring remote activity, e.g. over telephone lines or network connections
G06F 21/57 - Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
H04L 29/06 - Communication control; Communication processing characterised by a protocol
G06F 8/654 - Updates using techniques specially adapted for alterable solid state memories, e.g. for EEPROM or flash memories
92.
Solid-state drive dock having local and network interfaces
An external M.2 solid-state drive dock with local and network interfaces is disclosed. The dock includes an enclosure with apertures through which M.2 solid-state drives can be received. A circuit board is mounted within the enclosure that includes M.2 socket connectors for receiving the M.2 solid-state drives. The circuit board also includes a storage controller coupled to the M.2. socket connectors. A local interface controller is coupled to the storage controller for providing a local interface, such as a USB-C interface, to the M.2 solid-state drives to host computers. A network controller is also coupled to the storage controller for providing network interfaces, such as wired and/or wireless network interfaces, for accessing the M.2. solid-state drives. The storage controller can receive storage requests from the local interface controller and the network interface controller and provide the storage requests to the M.2 solid-state drives.
A firmware attempts to allocate memory address resources, such as memory addresses in a PCI I/O and a PCI memory address space, to bus devices in a multi-processor computing system. If an out-of-resource (OOR) condition occurs during allocation of the memory address resources, memory address resources can be re-allocated from stacks that were successfully allocated requested resources to stacks that were not successfully allocated requested resources. Memory address resources can also, or alternately, be re-allocated from sockets that were successfully allocated requested resources to sockets that were not successfully allocated requested resources. If stack-level or socket-level readjustment of the memory address resource allocation fails, a base memory address of a configuration memory address space can be lowered, and the allocation can be retried. A pre-defined memory address resource allocation table can also be utilized to allocate the memory address resources following failure of the stack-level and socket-level allocation readjustment.
In an aspect of the disclosure, a method, a computer-readable medium, and a computer system are provided. The computer system includes an initialization component of a host. The initialization component determines presence or absence of a plurality of hardware components of the host. The initialization component further generates a first series of indicators indicating the determined presence or absence of the plurality of hardware components. The initialization component sends, to a service processor of the host, a message in accordance with a management protocol, the message including the first series of indicators.
In an aspect of the disclosure, a method, a computer-readable medium, and an apparatus are provided. The apparatus may be a service processor. The service processor generates a user interface on the service processor. The user interface providing access to platform specific configurations of the service processor. The service processor receives, through the user interface, an input for modifying a first configuration data item of the platform specific configurations. The service processor accordingly modifies the first configuration data item in accordance with the input.
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.
G06F 21/00 - Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
G06F 21/62 - Protecting access to data via a platform, e.g. using keys or access control rules
H04L 9/32 - Arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system
97.
System and method for automated integration and stress testing of hardware and software service in management controller using containerized toolbox
Systems and methods for automated integration and stress testing of hardware and software services in a management controller using a containerized toolbox. The method utilizes a containerized toolbox module, which includes multiple testing tools for a web-based protocol, such as a Representational State Transfer (REST) protocol, and an Intelligent Platform Management Interface (IPMI) protocol. A management controller to be tested by the containerized toolbox module provides multiple services accessible under the web-based protocol and the IPMI protocol. In operation, the containerized toolbox module is provided at the management controller, and receives a testing command to perform a plurality of tests to the services of the management controller. Based on the testing command, the containerized toolbox module performs the tests to the services of the management controller using the testing tools of the containerized toolbox module.
In an aspect of the disclosure, a method, a computer-readable medium, and a computer system are provided. A first service processor of the computer system emulates a first storage device to a composed machine of a computing pod. The first service processor exposes a bootable utility image to the composed machine through the first storage device. The bootable utility image is configured to boot a program that collects hardware inventory information from the composed machine. The first service processor emulates a second storage device to the composed machine. The first service processor receives the hardware inventory information from the composed machine through the second storage device.
In an aspect of the disclosure, a method, a computer-readable medium, and an apparatus are provided. The apparatus receives first command or data in accordance with a first management protocol from a first device. The apparatus then translates the first command or data into second command or data in accordance with second management protocol. The apparatus further sends the second command or data to a second device. One of the first device and the second device is a first managed element managing a first host.
Systems and methods for twin factor authentication, which may be applied to a controller, such as a baseboard management controller (BMC). The controller provides a service. When a first user attempts to access the service, the controller receives an access message for a first user to access the service, and searches for information of the first user and a second user corresponding to the first user based on the access message. Then the controller sends two security clearance requests based on the information of the first user and the second user, including a first security clearance request for security clearance from the first user, and a second security clearance request for security clearance from the second user. The twin factor authentication for the first user would be successful only when the controller receives security clearance from both the first user and the second user.
patents
