Abstract: Systems and methods are provided for vulnerability proofing subsystems of hardware components of an IHS (Information Handling System). A request to modify configurations of a hardware component of the IHS is detected. Catalogs specifying known vulnerabilities of hardware components are accessed to determine whether any of the modified hardware configurations are identified as vulnerable in one or more of the catalogs. When vulnerabilities are identified in the modified configurations for the hardware component, other hardware components of the IHS are identified that are interdependent on the hardware component as part of an IHS subsystem. Hardware configurations for any of the hardware components of the subsystem are evaluated for vulnerabilities based on the catalogs.

Abstract: Systems and methods are provided for vulnerability proofing updates to an IHS (Information Handling System). An update system receives a notification of an update including updated configurations for hardware components of the IHS. The update system queries the IHS for vulnerability proofing requirements for updates that modify configurations of hardware components of the IHS. In response to the query, vulnerability proofing requirements are retrieved from a persistent data storage of the IHS and transmitted to the update system, where the vulnerability proofing requirements specify catalogs of known vulnerabilities of hardware components. The update system determines whether the updated configurations are identified as vulnerable in the one or more of catalogs. If the updated configurations are not identified in the catalogs, the update is transmitted to the IHS. If configurations from the update are identified in the catalogs, the update is terminated and the IHS is notified.

Abstract: Systems and methods are provided for vulnerability proofing the use of risk scores in the administration of hardware components of an IHS (Information Handling System). Proposed configurations for a first of the hardware components of the IHS are detected, where the proposed configurations are associated with a risk score. Catalogs specifying known vulnerabilities of hardware components are accessed and used to determine whether any of the proposed configurations of the first hardware component are identified as vulnerable in one or more of the catalogs. When a vulnerability for the proposed configuration is identified in the catalogs, the risk score of the configuration is increased based on the vulnerabilities identified in the plurality of catalogs. When the risk score is increased to an elevated level, the hardware component is disabled until the proposed configurations are changed to include no configurations with vulnerabilities identified in the catalogs.

Abstract: Systems and methods are provided for vulnerability proofing an IHS (Information Handling System) while being administered using a bootable image. Launching of a bootable image by the one or more CPUs is detected and one or more IHS configurations to be made using the bootable image are identified. One or more catalogs specifying known vulnerabilities of hardware components are accessed and used to determine whether any of the IHS configurations to be made using the bootable image are identified as vulnerable in one or more of the catalogs. Configuration of the IHS using the bootable image is blocked until the configurations to be made using the bootable image are modified to include no configurations with vulnerabilities identified in the plurality of catalogs.

Abstract: Systems and methods are provided for vulnerability proofing the launching of application instances by an IHS (Information Handling System). The launching of an application instance on the IHS is detected, where the application instance is launched using an application template that includes configurations for one or more hardware components of the IHS. One or more catalogs are accessed that specify known vulnerabilities of hardware components. Hardware component configurations included in the application template are identified as vulnerable in one or more of the catalogs. If the application template includes configurations that are identified as vulnerable in the catalogs, launching of the application is prevented until the hardware component configurations within the application template are modified to include no configurations with vulnerabilities identified in the catalogs.

Abstract: A method for processing data, comprising receiving a folder attached request at a virtual media service operating on a processor, creating a virtual image data file and lookup table in response to the folder attached request at the virtual media service, preparing content to be populated into a master boot record region in response to the folder attached request and generating a virtual USB device in response to the populated master boot record.

Abstract: Systems and methods are provided for vulnerability proofing the administration of hardware components of an IHS. A proposed configuration for a hardware component of the IHS is detected. Multiple catalogs specifying known vulnerabilities of hardware components are accessed, such as a catalog of known vulnerabilities provided by a manufacturer of the hardware component and such as a catalog of known vulnerabilities provided by a manufacturer of the IHS. The proposed configuration of the hardware component is evaluated as being vulnerable in the first catalog and also in the second catalog. If the proposed configuration is identified as vulnerable in either the first catalog or in the second catalog, the hardware component is disabled until the proposed configurations for the hardware component are changed to include no configurations with vulnerabilities identified in either the first or second catalogs.

Abstract: A system, method, and computer-readable medium for performing a data center asset telemetry operation. The data center asset telemetry operation includes: determining telemetry capabilities of a plurality of data center assets; constructing normalized telemetry information collection requests; providing the normalized telemetry information collection requests to the plurality of data center assets; and, receiving telemetry information from the plurality of data center assets.

Abstract: An information handling system may include at least one processor; and an information handling resource, wherein the information handling resource has hardware definition information associated therewith, and wherein the hardware definition information is not stored in a physical storage resource of the information handling resource; wherein the information handling system is configured to: determine a storage location of a database including the hardware definition information of the information handling resource; and retrieve the hardware definition information from the database.

Abstract: Systems and methods for providing an external embedded controller (EC) with access to internal resources of a heterogenous computing platform. In an illustrative, non-limiting embodiment, an Information Handling System (IHS) may include: a heterogeneous computing platform having a Reduced Instruction Set Computer (RISC) processor and a plurality of devices coupled to an interconnect; and an external EC coupled to the interconnect via a bridge integrated into the heterogeneous computing platform, where the bridge is configured to provide the external EC with access to the plurality of devices. These systems and methods may provide an EC with access to an internal System-on-Chip (SoC)'s fabric, whether in a fully internal, partially internal/external, or fully external implementation (e.g., via an enhanced serial peripheral interface or “SPI”).

Abstract: Embodiments of systems and methods to provide a firmware update to devices configured in a redundant configuration in an Information Handling System (IHS) are disclosed. In an illustrative, non-limiting embodiment, an IHS may include a Baseboard Management Controller (BMC) having computer-executable instructions to receive a request to boot a factory firmware on the BMC in which the factory firmware is signed by a first private key of a first asymmetric private/public key pair. Using the first private key, the instructions verify an authenticity of the factory firmware using a public key associated with the first private/public key pair, and allow booting of the factory firmware only when it is authenticated by the first public key.

Abstract: Systems and methods are provided for vulnerability proofing the use of an IHS (Information Handling System) in a computing cluster. Notification is received by the IHS of modifications to configurations of a computing cluster that includes the IHS. Vulnerability proofing requirements for computing cluster configurations including the IHS are retrieved from a persistent data storage of the IHS. Based on the vulnerability proofing requirements, catalogs comprising known vulnerabilities of IHS hardware components are accessed. Modifications to the computing cluster configurations are identified as vulnerable in one or more of the catalogs. When modifications to the computing cluster configurations are identified as vulnerable, participation by the IHS in the computing cluster is suspended until the modifications to the computing cluster configurations are changed to include no configurations with vulnerabilities identified in the catalogs.

Abstract: With introduction of RDMA (Remote Data Memory Access) NICs (Network Interface Cards), it may be desirable for a client device to be able to use TCP (Transmission Control Protocol) and RDMA transports over a same RDMA NIC/IP. However, current systems do not support connections with different transport protocols from the RDMA NIC/IP. Accordingly, to solve this issue, embodiments allow a client to use different transports from the same RDMA NIC-IP in parallel. In one or more embodiments, a transport type (e.g., TCP or RDMA) may be added to or embedded in one or more identifiers thereby allowing a client to use an intended transport over a same NIC.

Abstract: A system, method, and computer-readable medium for performing a telemetry aggregation operation. The telemetry aggregation operation includes: associating a data center asset from a plurality of data center assets with a data center asset group, the associating being based upon a telemetry information response time of the data center asset; identifying a telemetry aggregation cycle time for the data center asset group; collecting telemetry information from the data center asset of the plurality of data center assets; and, aggregating the telemetry information according to the telemetry aggregation cycle time.

Abstract: Embodiments of systems and methods to provide a firmware update to devices configured in a redundant configuration in an Information Handling System (IHS) are disclosed. In an illustrative, non-limiting embodiment, an IHS may include computer-executable instructions to receive a request for a secret known by the IHS, and attest the RAC by verifying that the public key exists in a manifest that is configured to store identifying information about a plurality of devices configured in the IHS. The request is signed using a private key of a first asymmetric key pair generated by a Remote Access Controller (RAC). Using a second public key of a second asymmetric key pair, the instructions encrypt the requested secret; and send the encrypted secret to the RAC, wherein the RAC is configured to use the second private key of the second asymmetric key pair to decrypt the encrypted secret.

Abstract: An air shroud may include a plurality of channels including at least a first channel configured to direct airflow driven by one or more chassis-level air movers from outside a chassis enclosing the air shroud into the chassis and into the first channel and a second channel configured to direct airflow driven by the one or more chassis-level air movers from outside the chassis into the chassis and into the second channel, and an opening formed in the air shroud and fluidically configured to be interfaced between the second channel and a shroud air mover such that, when the shroud air mover operates in a plurality of modes comprising a first mode in which the shroud air mover is inactive and a second mode in which the shroud air mover is active, airflow through the second channel is greater in the second mode than in the first mode.

Abstract: Techniques for performing an upgrade can include: defining integration points, each associated with a workflow processing point of an upgrade workflow of an upgrade infrastructure or framework; and performing processing by code of the upgrade infrastructure or framework that performs the upgrade workflow to upgrade a system, wherein the upgrade includes upgrading a first feature, facility or service of the system from a current version to a new version. The processing can include: dynamically determining, at runtime during execution of the upgrade workflow by the code of the upgrade infrastructure or framework, a set of code entities associated with a first of the integration points; executing code corresponding to workflow processing points, wherein a first of the workflow processing points is associated with the first integration point; and in response to said executing reaching the first workflow processing point, invoking each code entity of the set for upgrade processing.

Abstract: An information handling system may include at least one processor and a memory. The information handling system may be configured to receive a request to upgrade a component from a first version to a second version; perform a first check by determining if allowed source release (ASR) information of the second version includes a reference to the first version; perform a second check by determining if allowed target release (ATR) information of the first version includes a reference to the second version; and in response to either of the first check and the second check being successful, perform the component upgrade.

Abstract: An embedded controller (EC) of an information handling system is configured to detect and respond to anomalous conditions in which a pre-boot or runtime error has occurred and EC-local storage resources are not sufficient to store EC telemetry data, by redirecting the EC telemetry data through an available communication channel, e.g., SBIOS MBOX packets or ACPI MMIO, to offload the data to EC-external storage such as an ESP partition or Cloud storage. In a pre-boot mode, SBIOS may invoke a UEFI storage driver to write out EC log data to EC-external storage, e.g., SSD/NVMe device or the Cloud. In a runtime mode, the EC may be flagged by an OS bugcheck handler, e.g., via eSPI MMIO path, to save the log data. In an OS-context mode, ACPI methods may notify a persistent driver, e.g., Common Platform Services (CPS) driver, to write out the log to the EC-external storage.

Abstract: In at least embodiment, processing can include: receiving virtual utilizations (VUs) for resources consumed in connection with recording entries in a log for commands or operations, wherein each resource has a corresponding VU which denotes a number of allocated units of the resource associated with entries of the log which have not been flushed from the log; determining a first resource having a maximum VU with respect to VUs of consumed resources; determining whether the maximum VU is within an acceptable VU range, wherein the acceptable VU range has bounds determined in accordance with a maximum deviation threshold associated with the first resource; and responsive to determining the maximum VU is not within the acceptable VU range of the first resource, performing one of a plurality of regulation actions that varies an amount of a system resource to accordingly vary a flush rate of entries from the log.