Patina: a Rust Implementation of Uefi Firmware
Posted3 months agoActive2 months ago
github.comTechstory
calmpositive
Debate
20/100
RustUefiFirmware
Key topics
Rust
Uefi
Firmware
The HN community discusses Patina, a Rust implementation of UEFI firmware, exploring its potential as an alternative to TianoCore and its compatibility with existing hardware and software.
Snapshot generated from the HN discussion
Discussion Activity
Active discussionFirst comment
13h
Peak period
12
Days 11-12
Avg / period
3.8
Comment distribution23 data points
Loading chart...
Based on 23 loaded comments
Key moments
- 01Story posted
Oct 10, 2025 at 5:02 PM EDT
3 months ago
Step 01 - 02First comment
Oct 11, 2025 at 6:25 AM EDT
13h after posting
Step 02 - 03Peak activity
12 comments in Days 11-12
Hottest window of the conversation
Step 03 - 04Latest activity
Nov 6, 2025 at 4:56 PM EST
2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45543746Type: storyLast synced: 11/20/2025, 5:51:32 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Looking at the members on the repository this seems to be a Microsoft project?
As far as I remmeber, they control the issuance of keys for bootloaders. Or is this project supposed to do away with that?
https://microsoft.github.io/mu/
Mu has some bits & pieces of Rust code and EDKII is still the upstream for Mu.
Patina is 100% Rust DXE Core implemented from spec.
They are also the one party that is forcing freedom-enabling but formal standard breaking ability of resetting Platform Key, because Microsoft actually documents (or used to) a process to deploy systems signed with your own key as part of the highest security deployment documentation for enterprise customers
[0] https://github.com/OpenDevicePartnership/patina-qemu
[1] https://github.com/OpenDevicePartnership/patina-dxe-core-qem...
---
Unrelated: I've been playing around with uefi-rs and it's a surprisingly ergonomic API, especially for someone completely new to UEFI. It also provides a global allocator that can be used to *dynamically* allocate Vec and Box types. It feels like a cheat to safely(!) open a PXE Base Code protocol on a handle, read file size from TFTP, and *dynamically* allocate a Vec<u8> (with size limits of course). I highly recommend people check out uefi-rs as a "side reading" to this project.
https://rust-osdev.github.io/uefi-rs/index.html
Honestly, I need to ask for a security audit for this stub loader — it currently works and can be used to set up a simple SecureBoot boot path.
If you are lucky and have PXE BC available, then you can actually "re-use" the IP address assigned to your machine if you PXE boot into your application. From there, you can issue two TFTP commands, set up a configuration table with LINUX_EFI_INITRD_MEDIA_GUID pointing to the start of initrd in memory (the memory has to have type LOADER_DATA), load the kernel, use LoadedImage::set_load_options to provide kernel parameters (init, loglevel, etc.), and finally call start_image.
Also went down a rabbit hole yesterday and ended up implementing a very basic DHCP client on top of bare SNP. For reference, SNP is essentially writing raw ethernet frames to the transmit buffer of a NIC. I didn't pursue TFTP or PXE protocols because those would be too much to implement myself. In any case, I successfully got an IP address assigned on real hardware.
The coolest part about Rust is that my DHCP implementation was taken from another of my Rust projects where I implemented a basic PXE server. All I had to do was copy-paste one file and rename a std::net import to core::net. That is where Rust truly feels like "cheating" when targetting no_std environments.