A quick tour of go-tcg-storage, the pure-Go library for driving TCG Storage self-encrypting drives. Where the project stands today, what might be next, and a perspective from someone stepping up to help maintain it.
TCG Storage self-encrypting drives (SEDs) put full-disk encryption in the drive controller itself, exposed through the Trusted Computing Group's Security Subsystem Classes — Opal, Pyrite, Enterprise, and Ruby. In practice, managing them means wrestling with ComIDs, locking ranges, pre-boot authentication and shadow MBR, usually via legacy tooling like sedutil or vendor specific tools.
go-tcg-storage takes a different path: a pure-Go, kernel-independent implementation of the TCG Storage stack, layered from a low-level drive interface (IF-SEND/IF-RECV over NVMe, SATA, and SAS) up through a core session library to a high-level locking API.
This lightning talk covers three things: (1) a short primer on TCG Storage and why an open, library matters for firmware and boot security; (2) the current state of go-tcg-storage — what works, which drives and SSCs are covered, and where the rough edges are; and (3) the roadmap: broader SSC and transport coverage, PBA workflows, release and packaging, testing, and documentation.
I am a firmware and embedded systems engineer with experience in safety‑critical operating systems, high‑security platform design, and host firmware development for modern hardware platforms. I have spent the past decade working on microkernel‑ and Linux‑based systems for defense and high‑assurance environments, focusing on partitioning, isolation, and robust system architectures that meet safety and security certification requirements.
Most recently, I have led open‑source firmware efforts at 9elements, driving host firmware projects around coreboot, EDK2 (UEFI), and secure storage. Contributing to the development of secure and transparent firmware solutions for servers and security‑sensitive platforms.