By day, I am a software engineer in web and app development.
In my free time, I work on free and open source software, especially operating systems and distributions, bringup and application firmware, with a focus on tooling, integration, and documentation.
I created Fiedka the firmware editor 🧰⚙️🐙.
@orangecmsGithub – Homepage –
SBoM Annotations and Audits
When firmware is only available in binary form, i.e., the end user or corporate
entity has no access to its source code, quality and security assessment is
limited by legal constraints, and fixing bugs and flaws harder to achieve. While
possible escape hatches have been developed, such as replacing large parts of
the stock firmware with auditable environments like LinuxBoot, some uncertainty
still remains regarding drivers and other components that cannot be removed.
However, there are still options to help oneself where the OEM or other vendor
does not offer the flexibility or assurance one needs: We can build up a
knowledge database of drivers, offer guidance towards patching or replacing
them, and provide the tooling to automate the process. With Fiedka the firmware
editor, components can be annotated and those annotations
exported for reuse. In this short talk, we will evaluate the necessary workflows
and discuss user experience design considerations around the process.
This year we pivoted the oreboot project, a downstream fork of coreboot
written entirely in Rust, to focus on RISC-V platforms, including the first
version of Beagle-V. We have focused our energies on platforms we can control from power-on reset, with no binary blobs.
Over the last year, the Allwinner D1 SoC, which offers a Linux-capable 64bit
XuanTie C906 RISC-V core and is found on many boards, has been fully ported,
including DRAM init. In addition, we picked up the work on the JH7100 SoC again
that was found on the BeagleV Starlight SBC, because it is also on the StarFive
VisionFive board, which has been provided to us by RISC-V International for the
developer support program.
In this talk, we present challenges we faced during
the development, including writing DRAM code from C code, not chipset documentation;
how we are taking advantage of the rapid growth of "bare metal" support in the Rust ecosystem and
how it has impacted our code, in ways large and small; and how the project is growing as new members
Finally, we summarize the current status of the oreboot project.