A 3mdeb design pattern

Rack-scale firmware development.
On your desk.

BenchRack mirrors a rack-scale system on commodity hardware and reference designs - so your team can bring up firmware and OS locally, before ever touching production racks.

The problem

Rack-scale systems don't fit on a desk

Monolithic by design

The entire rack must be assembled and powered before it does anything useful.

Prohibitive cost and footprint

A full rack system is out of reach for small teams - and it definitely won't sit on a desk.

Remote access falls short

Low-level firmware work needs local hands on serial consoles and SPI flash headers.

No spare unit to borrow

A single compute unit can't be pulled out of the rack for local experimentation.

Slow iteration

Every firmware change means scheduling rack access, coordinating a team, and hoping a single flash attempt doesn't take the whole system down.

Why now

Rack-scale demand is accelerating

GPU accelerator pods

Dozens of tightly-coupled accelerators packed into a single rack unit, managed as one system.

Hyperscaler rack designs

Proprietary firmware stacks spanning compute, networking, and power management at rack level.

Compute has to scale fast

New rack-scale platforms must be evaluated and brought up before they're widely available - de-risking procurement and deployment decisions.

Reproducing these at bench scale matters

  • Firmware and OS bring-up moves to a bench-side twin first - production racks only see code that already works.
  • CI/CD loops close faster - no scheduling time on a shared rack.
  • Hardware-in-the-loop feedback happens locally, not on shared infrastructure.
  • The same approach carries over to the next rack-scale platform.

Vision

Divide and conquer, applied to firmware

Rack-scale systems get tractable the same way every hard engineering problem does: by decomposing them into pieces you can reason about, verify, and fix independently. BenchRack exists to build that firmware due-diligence and patching harness - one component at a time, instead of betting an entire rack-scale system on a single flash.

Divide et impera

Traditionally attributed to Philip II of Macedon, who broke the power of the Greek city-states by tackling them one at a time rather than all at once.
  • Break a monolithic rack into independently testable components, and each one becomes small enough to actually reason about.
  • Fixes and validation happen one piece at a time, not as an all-or-nothing gamble on the full system.
  • The same principle carries over to compliance: OCP SOLID breaks datacenter security into per-component requirements, and OCP SAFE verifies each device against them one at a time, through escalating scopes, rather than one spec and one audit for an entire system.
  • The same run that produces a fix also validates it on a physical twin and emits the compliance evidence as a byproduct - not a separate audit pass.
  • It's applied to server-class host firmware, not microcontroller territory - and built on public specs throughout, not a closed, self-hosted tier.

How it works

How the BenchRack pattern works

BenchRack isn't a product you buy off the shelf - it's the approach 3mdeb uses to shrink a rack-scale system down to a single desk-side unit, so firmware and OS work can move at developer speed instead of rack-scheduling speed.

A reusable blueprint

At its core, BenchRack pairs a remote control environment with the target's own server board, plus whatever extra services a platform needs. Swap in different target infrastructure and the same blueprint fits a different rack-scale system.

  • Any rack-scale system can have a BenchRack analog.
  • Only the target-specific pieces change - everything else about the pattern carries over.
Extra services (optional)Target-specific infrastructureRuntime environmentServer board
The BenchRack pattern: a runtime environment and target infrastructure on an off-the-shelf server board.

Real-world proof

A BenchRack you can order today

The pattern isn't just theory: Dasharo BenchRack for the ASRock TURIND8UD-2T/X550 ships today, running open firmware and controlled end-to-end through an RTE.

coreboot and LinuxBoot are both open source, built from Dasharo/coreboot - only a few vendor blobs stay closed.
coreboot LinuxBoot Target OS
benchctl drives the bench remotely - flashing, power, and serial, all through the RTE, a solution that has been proven over many years.

It also doubles as a reference for compliance showcasing, firmware due-diligence, and decomposing complex rack systems.

See it in the 3mdeb shop

CPU

Single-socket SP5, AMD EPYC 9005 series

Memory

8x DDR5 RDIMM, up to 6400 MHz

Expansion

4x PCIe 5.0/CXL 2.0 x16, 2x M.2 (PCIe 5.0 x4)

Networking

Onboard 10 GbE

See it in action

BenchRack, running

A short excerpt showing the bench in operation - firmware flashed and validated end to end through the RTE, no rack required.

Excerpt from Dasharo openSIL integration status - 14 July 2026.

Scoring

The BenchRack scorecard

Beyond the pattern itself, here's how the reference BenchRack actually scores - security posture, firmware openness, and validation results, measured and unedited.

Host Security ID

HSI:1-! Placeholder value - pending a live fwupd run
HSI-1
8/8
HSI-2
4/5
HSI-3
2/5
HSI-4
2/3
Runtime
3/7

Openness Score

Same board, two firmware stacks - the Dasharo openness-score utility measures how much of each is actually open source.

LinuxBoot (BenchRack default)
76% open
Stock UEFI
24.3% open
See the full breakdown →

OSFV Validation Results

Dasharo's Open Source Firmware Validation (OSFV) suite - automated checks across CPU, TPM, NVMe, USB, DMI, and boot integrity.

53/54 (98%)

One known, tracked failure: Boot-log sanity check.

See the full results →

Boot Time

Measured end to end from power-on, including PSP firmware initialization.

3:27 Stock UEFI
0:57 (-72%) coreboot + LinuxBoot
Read the full case study →

Compliance

What our SBOM actually proves

Every BenchRack build produces a software bill of materials (SBOM), checked automatically against the standards that matter for firmware. Here's a real, unedited result for each firmware variant - warnings included.

SBOM compliance status for the LinuxBoot variant: cross-standard overview showing passed, warning, and error results across multiple standards
Generated with sbom-tools.
LinuxBoot - EU CRA Phase 1 (2027): compliant with warnings - Security 7, Integrity 4, Doc Meta 1
LinuxBoot - EU CRA Phase 2 (2029): compliant with warnings - Security 9, Integrity 5, Doc Meta 3
LinuxBoot - NIST SSDF (SP 800-218): compliant with warnings - Doc Meta 1, Integrity 1, Security 1
The EU Cyber Resilience Act is already in force. Reporting obligations for actively exploited vulnerabilities and severe incidents start September 2026; full essential requirements - secure-by-design, conformity assessment, CE marking, and SBOM generation - become enforceable in December 2027. The CRA scores above already track both phases.

What's next

Coverage is expanding toward SOC 2, FedRAMP, DoD IL5/IL6, NIST SP 800-53. ISO 27001 and IEC 62443 are on the roadmap too.

Plans

What's next for BenchRack

Compliance work continues on the roadmap above - see the Compliance section for the standards we’re pursuing next.

Speaking at BSMConf

“The Autonomous Firmware Factory: BenchRack and the Agentic Pipeline Redefining Open-Source Firmware Enablement” - Michał Żygowski

A look at automating firmware bring-up end to end, from discovery through validation to release, with BenchRack as the substrate.

Speaking at BSMConf

“Unboxing Compliance: Tooling Lessons Learned from Scaling Our BenchRack Score” - Artur Raglis, Kamil Aronowski

Public scorers call BenchRack firmware "compliant with warnings" - our in-house EAP and SAM tools turn those warnings into an addressable backlog, tying CRA scoring directly to the CycloneDX SBOM of what we actually ship.

Speaking at BSMConf

“Host Security ID (HSI) on AMD servers today and tomorrow” - Michał Żygowski

A practical look at fwupd HSI on the Gigabyte MZ33-AR1 (Dasharo coreboot + EDKII) - HSI-2 achieved with every HSI-4 requirement met, and where AMD-specific gaps still create friction between what HSI tests for and what the silicon exposes.

Training at BSMConf

“Autonomous Dasharo Firmware Porting for ARM: Hands-On with BenchRack” - Michał Żygowski

Hands-on ARM coreboot porting on the Arm FVP Neoverse V2/V3 simulator - see how BenchRack's automated Validation-to-Porting loop carries the same pipeline from x86 over to ARM targets.

Training at BSMConf

“Autonomous OpenBMC Porting: Hands-On BMC Bring-Up with BenchRack” - Maciej Pijanowski

A three-day hands-on course porting OpenBMC to a real AMD/Intel server board on a live BenchRack rig - unpacking, board modeling, meta-layer generation, flashing, and validation, end to end.

Additional BSMConf sessions may be announced as the conference date approaches - subscribe below for updates.

Need a BenchRack for your platform?

The case study above shows what the pattern can do. Tell us about your rack-scale platform and we'll help you build your own bench-side sandbox.