Michał Żygowski
Michał Żygowski is a versatile engineer with a strong focus on system firmware. Works as a senior firmware engineer at 3mdeb Embedded Systems Consulting . Active contributor of coreboot and other open-source projects. Core coreboot developer, maintainer of Braswell SoC, PC Engines, Protectli, MSI and Libretrend platforms. Loves travelling and attending conferences, which actively speaks on. Mainly interested in the firmware, security and advanced hardware features.
Sessions
This talk examines the practical experience of implementing and evaluating
fwupd HSI on the Gigabyte MZ33-AR1, a server platform running Dasharo
open-source firmware based on coreboot and EDKII. The platform reaches HSI-2
with all requirements for HSI-4 met - a strong baseline - yet several attributes
remain out of reach for various reasons. SPI replay protection, for instance,
is unavailable due to the SPI flash chip chosen in the board design rather
than any AMD-specific limitation. Other gaps are more directly tied to AMD
platform specifics: non-trivial interactions between HSI test tooling and
superuser privileges, and incorrect upstream interpretation of suspend-to-idle
support. These cases illustrate how the gap between what HSI tests
for and what AMD silicon currently exposes to firmware creates friction for
both developers and end users trying to interpret their security scores.
The goal is to give firmware engineers and security practitioners a clear
picture of where HSI on AMD stands today, what is blocking progress, and what
a more complete AMD security attestation story could look like as the
open-source firmware ecosystem matures.
Every open-source firmware port follows the same path: expert engineers
discover hardware, evaluate scope, write bring-up code, run a validation
matrix, and ship a signed image. The bottleneck at every stage is identical:
people. Scaling firmware enablement has meant scaling headcount, until now.
BenchRack, 3mdeb's reference substrate for firmware bring-up and validation,
and the Foundation agentic pipeline built on top of it, intends to break that
dependency. The pipeline spans five stages: Discovery, Evaluation, Porting,
Validation, Release, and closes the inner loop between Validation and Porting
autonomously. Machine-readable test results drive the next porting iteration
without a human reading logs. Scorecard-driven Maturity continues after the
initial release, pushing shipped firmware toward higher Hardware Security
Index scores, SBOM completeness, and compliance targets (EU Cyber Resilience
Act, SOC 2) through agent-orchestrated, supervisor-approved iteration.
This talk presents the architecture of that system: the BenchRack substrate,
the OSFV-backed Validation layer, the agentic Porting feedback loop, the
framework-support spectrum that classifies targets from "upstream-supported"
to "from-scratch," and the three-tier delivery model that matches pipeline
autonomy to target complexity. The goal is a clear picture of what autonomous
firmware enabling looks like when operating in production - and what it opens
up for the open-source firmware ecosystem across x86 and ARM.