Multi-Boot BMC Data Sharing for Firmware Reliability

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Custom BMC firmware stacks, while providing enhanced manageability and customization, often suffer from software faults and security vulnerabilities due to uncontrolled development environments, which can lead to hardware damage and security breaches, and lack the reliability and functionality of standard BMC firmware stacks, necessitating a solution for seamless switching between different firmware stacks while maintaining security and configuration integrity.

Innovation Solution

A data sharing system and method for a multi-boot baseboard management controller (BMC) that allows switching between custom and standard BMC firmware stacks by copying data from a first memory location to a second, enabling the execution of multiple firmware stacks and providing a known good stable environment, while maintaining security domains and configuration synchronization through encrypted data sharing and secure boot mechanisms.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If custom BMC firmware stacks are used to provide enhanced manageability and customization, then adaptability and ease of operation are improved, but reliability and security are worsened due to software faults and vulnerabilities from uncontrolled development environments

Engineering Contradiction:
Improvecustomization capabilityVSAvoidfirmware reliability
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The system segments the firmware execution environment by implementing separate security domains for standard and custom firmware stacks. The BMC can execute different firmware stacks in isolated domains, allowing customization while maintaining reliability through controlled access and execution boundaries. This segmentation enables the system to leverage custom firmware capabilities without compromising overall system stability.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces an intermediary mechanism in the form of a boot loader and security domain manager that mediates between custom firmware development and system reliability. This intermediary layer validates, loads, and manages custom firmware stacks, ensuring they meet security requirements before execution. It acts as a buffer that allows customization while enforcing reliability constraints.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Ease of operation

If custom BMC firmware stacks are used to provide enhanced manageability, then ease of operation is improved, but security is worsened due to security vulnerabilities from uncontrolled development environments

Engineering Contradiction:
ImprovemanageabilityVSAvoidsecurity vulnerabilities
Core Design Contradiction:
Ease of operationVSObject-affected harmful factors

Solution Approach 1:

The system applies local quality by implementing security-specific properties in particular regions or domains of the firmware execution environment. Different security policies and validation mechanisms are applied to different firmware stacks based on their origin and purpose. Custom firmware domains have specific security attributes that differ from standard firmware domains, allowing tailored security management that maintains ease of operation while addressing vulnerabilities.

Inventive Principle:
Principle #3Local quality

Solution Approach 2:

The patent implements beforehand cushioning through pre-validation and pre-sandboxing of custom firmware stacks before they are allowed to execute. Security checks, signature verification, and isolation mechanisms are established in advance before custom firmware is loaded. This preparatory security cushioning prevents vulnerabilities from affecting the system, allowing easy deployment of custom firmware while maintaining security.

Inventive Principle:
Principle #11Beforehand cushioning (Prior cushioning)

3Adaptability or versatility

If multiple firmware stacks are executed to provide seamless switching capability, then adaptability is improved, but device complexity is worsened due to the need for data copying between memory locations

Engineering Contradiction:
Improvefirmware switching capabilityVSAvoidsystem complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The system achieves universality by implementing a unified memory management and data sharing mechanism that serves multiple firmware stacks. Instead of completely separate memory spaces, the patent creates a shared memory architecture with controlled access that allows different firmware stacks to operate with common data structures and communication protocols. This multi-functional memory system reduces complexity compared to entirely isolated implementations.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The patent employs copying mechanisms as a controlled method for data transfer between firmware stack memory locations. Rather than implementing complex shared memory synchronization protocols, the system uses targeted data copying between designated memory regions during firmware transitions. This copying approach, when applied selectively and efficiently, simplifies the switching mechanism while maintaining data integrity across firmware boundaries.

Inventive Principle:
Principle #26Copying

Data Source

PatentUS12164638B2Data sharing system and method for a multi-boot baseboard management controller (BMC)
Publication Date: 2024.12.10 DELL PROD LP
  • US12164638B2 patent drawing
  • US12164638B2 patent drawing
  • US12164638B2 patent drawing

AI summary

An Information Handling System (IHS) includes multiple hardware devices, and a baseboard Management Controller (BMC) in communication with the plurality of hardware devices. The BMC includes instructions for executing a first BMC firmware stack that uses certain data for its operation. The data used by the first BMC firmware stack is stored in a first memory location. The instructions are further configured to halt execution of the first BMC firmware stack, and begin execution of a second BMC firmware stack by copying the data from the first memory location to a second memory location used by the second BMC firmware stack.