OpenFSP Service Processor
Project Charter

Executive Summary

Enterprise POWER servers include a dedicated service processor — a management controller that runs continuously and independently of the host OS, handling power sequencing, hardware error logging, secure boot enforcement, and out-of-band console access. This firmware executes at the highest trust level in the server, below any hypervisor or operating system, and is the component most directly subject to emerging firmware auditability requirements under DORA, NIS2, and FFIEC.

The OpenFSP project delivers an open source service processor implementation for OpenPOWER hardware: built on the Linux Foundation's OpenBMC project, in the standardized OCP DC-SCM (Data Center Secure Control Module) form factor. OpenFSP gives POWER-class server operators full source-level visibility into the firmware executing below their OS — critical for regulated industries where supply chain transparency is a compliance requirement.

OpenFSP builds on existing work: OpenBMC already runs on a range of OpenPOWER hardware, and member community platforms have demonstrated this approach in production. This project formalizes, extends, and productizes that foundation for current-generation OpenPOWER hardware in the OCP DC-SCM standard form factor.

Service Processor Capabilities

A POWER-class service processor is not a simple BMC. OpenFSP is scoped to provide the following enterprise management functions:

• Out-of-band management: Independent power control, console access, and hardware inventory — operating even when the host system is powered off or crashed.
• Hardware error logging (HEL): Collects, decodes, and stores hardware errors from the processor, memory, and I/O subsystems. Error Log Analysis (ELA) correlates low-level hardware signals into actionable service events.
• Secure boot enforcement: Validates the chain of trust from power-on through hostboot, skiboot/OPAL, and the OS bootloader — controlling which firmware the server will execute.
• Power and thermal management: CPU throttling, fan control, power capping. Monitors and responds to thermal events without OS intervention.
• Management console communication: The service processor is the communication endpoint for the management console. All LPAR management operations flow through it before reaching the main processor.
• Firmware update orchestration: Coordinates firmware updates including system firmware, hostboot, and OPAL — rolling back automatically on failure.

The DC-SCM Form Factor

The OCP DC-SCM (Data Center Secure Control Module) v2.0 specification defines a standardized, pluggable form factor for the management controller in a server. Rather than integrating the BMC directly onto the motherboard (as in traditional server designs), DC-SCM places it on a standardized module that can be independently replaced, upgraded, or sourced from multiple vendors.

For OpenFSP, the DC-SCM form factor provides three strategic advantages:

• Multi-vendor sourcing: The module is independently manufactured. Any OCP-compliant server can host OpenFSP without redesigning the motherboard.
• Independent auditability: The service processor module can be physically inspected, replaced, and re-verified independently of the compute components.
• Security isolation: DC-SCM's physical separation of management electronics from compute creates a hardware security boundary that supports zero-trust infrastructure models.

Technical Subsystems

Existing Work and Upstream Relationship

OpenFSP is not a fork — it is a focused extension and productization of upstream work:

• OpenBMC (Linux Foundation): The base platform. OpenFSP contributes POWER-specific hardware support and error analysis upstream.
• skiboot/OPAL: The runtime firmware that OpenFSP manages. Error event interface is already partially defined in OPAL.
• Raptor Computing Systems platform BMC: Prior art for OpenBMC on OpenPOWER hardware. OpenFSP extends this to current-generation OpenPOWER systems and standardizes the DC-SCM form factor.
• OCP DC-SCM v2.0 Specification: The hardware form factor target. OpenFSP will be a reference implementation for POWER-class DC-SCM modules.

Regulatory and Security Value

The FSP executes at a privilege level below everything else in the server — below the OS, below the hypervisor, below even OPAL. For regulated industries, this creates a specific and pressing audit challenge: demonstrating to examiners that the firmware with the highest privilege in their infrastructure has been validated. IBM's closed FSP firmware cannot satisfy this requirement.

OpenFSP addresses this through:

• Full source availability: Every line of code executing on the service processor is auditable by the operator, their auditors, or their regulators.
• Reproducible builds: Bit-for-bit reproducible build process, enabling independent verification that deployed firmware matches audited source.
• TPM-backed measured boot: Cryptographic attestation of the boot chain from power-on, providing evidence that the service processor has not been tampered with.
• Structured security event logs: Every firmware action logged in a tamper-evident structured format suitable for SIEM ingestion.
• National supply chain eligibility: DC-SCM form factor enables domestic manufacturing of the management module independently of the compute silicon.

Deliverables

Milestones

• Month 1TSC formed. OpenBMC upstream engagement established. DC-SCM hardware platform selected for reference implementation.
• Month 3OpenBMC bring-up on target DC-SCM hardware. Power control and sensor monitoring operational.
• Month 6Full hardware bring-up milestone: console access, IPMI, Redfish API, power/thermal management. Integration with skiboot verified.
• Month 10OPAL event bridge: hardware errors from OPAL runtime appear in OpenBMC event log with field replaceable unit attribution.
• Month 14Power and thermal management subsystem complete. CPU power capping, fan control, thermal event response.
• Month 16Hardware Error Analysis engine alpha. Error correlation and service event generation for common hardware fault classes.
• Month 18Secure boot with TPM 2.0 attestation. Measured boot log integrated into OpenBMC event framework.
• Month 20OpenHMC integration complete. All Redfish endpoints consumed by OpenHMC management console.
• Month 24Third-party security audit. Reproducible build verification. SBOM pipeline established.
• Month 28OpenFSP 1.0 GA. DC-SCM reference hardware BOM published. Founding member production deployments begin.