BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//pretalx//cfp.3mdeb.com//bsmconf//speaker//WUJUZ8
BEGIN:VTIMEZONE
TZID:CET
BEGIN:STANDARD
DTSTART:20001029T040000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20000326T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:pretalx-bsmconf-RHXQSM@cfp.3mdeb.com
DTSTART;TZID=CET:20260924T143000
DTEND;TZID=CET:20260924T150000
DESCRIPTION:This talk examines the practical experience of implementing and
  evaluating\nfwupd HSI on the Gigabyte MZ33-AR1\, a server platform runnin
 g Dasharo\nopen-source firmware based on coreboot and EDKII. The platform 
 reaches HSI-2\nwith all requirements for HSI-4 met - a strong baseline - y
 et several attributes\nremain out of reach for various reasons. SPI replay
  protection\, for instance\,\nis unavailable due to the SPI flash chip cho
 sen in the board design rather\nthan any AMD-specific limitation. Other ga
 ps are more directly tied to AMD\nplatform specifics: non-trivial interact
 ions between HSI test tooling and\nsuperuser privileges\, and incorrect up
 stream interpretation of suspend-to-idle\nsupport. These cases illustrate 
 how the gap between what HSI tests\nfor and what AMD silicon currently exp
 oses to firmware creates friction for\nboth developers and end users tryin
 g to interpret their security scores.\n\nThe goal is to give firmware engi
 neers and security practitioners a clear\npicture of where HSI on AMD stan
 ds today\, what is blocking progress\, and what\na more complete AMD secur
 ity attestation story could look like as the\nopen-source firmware ecosyst
 em matures.
DTSTAMP:20260801T203422Z
LOCATION:GPN-T Main Room
SUMMARY:Host Security ID (HSI) on AMD servers today and tomorrow - Michał 
 Żygowski
URL:https://cfp.3mdeb.com/bsmconf/talk/RHXQSM/
END:VEVENT
BEGIN:VEVENT
UID:pretalx-bsmconf-GWPNQP@cfp.3mdeb.com
DTSTART;TZID=CET:20260925T155000
DTEND;TZID=CET:20260925T162000
DESCRIPTION:Every open-source firmware port follows the same path: expert e
 ngineers\ndiscover hardware\, evaluate scope\, write bring-up code\, run a
  validation\nmatrix\, and ship a signed image. The bottleneck at every sta
 ge is identical:\npeople. Scaling firmware enablement has meant scaling he
 adcount\, until now.\n\nBenchRack\, 3mdeb's reference substrate for firmwa
 re bring-up and validation\,\nand the Foundation agentic pipeline built on
  top of it\, intends to break that\ndependency. The pipeline spans five st
 ages: Discovery\, Evaluation\, Porting\,\nValidation\, Release\, and close
 s the inner loop between Validation and Porting\nautonomously. Machine-rea
 dable test results drive the next porting iteration\nwithout a human readi
 ng logs. Scorecard-driven Maturity continues after the\ninitial release\, 
 pushing shipped firmware toward higher Hardware Security\nIndex scores\, S
 BOM completeness\, and compliance targets (EU Cyber Resilience\nAct\, SOC 
 2) through agent-orchestrated\, supervisor-approved iteration.\n\nThis tal
 k presents the architecture of that system: the BenchRack substrate\,\nthe
  OSFV-backed Validation layer\, the agentic Porting feedback loop\, the\nf
 ramework-support spectrum that classifies targets from "upstream-supported
 "\nto "from-scratch\," and the three-tier delivery model that matches pipe
 line\nautonomy to target complexity. The goal is a clear picture of what a
 utonomous\nfirmware enabling looks like when operating in production - and
  what it opens\nup for the open-source firmware ecosystem across x86 and A
 RM.
DTSTAMP:20260801T203422Z
LOCATION:GPN-T Main Room
SUMMARY:The Autonomous Firmware Factory: BenchRack and the Agentic Pipeline
  Redefining Open-Source Firmware Enablement - Michał Żygowski
URL:https://cfp.3mdeb.com/bsmconf/talk/GWPNQP/
END:VEVENT
END:VCALENDAR