Patina: a Rust implementation of UEFI firmware | Hacker News Reader

Patina: a Rust implementation of UEFI firmware

github.com

142 pointshasheddan23 comments

Pretty cool project. Given that someone else in this thread mentioned it serves as an alternative to TianoCore, does this (theoretically) mean that one may interface with this firmware through uefi-rs in the future?

---

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

Just so happened to be fiddling with the uefi-rs crate too today. So if I understand this correctly, Patina is the part that runs on the hardware side, ie, the firmware? Uefi-rs based on what I read/tried seems to be the software side, building apps that work before the OS is loaded (I assume for things such as boot loader, firmware updaters, etc) but I'm not sure if it also covers the hardware side

I wrote a Linux UEFI stub loader (Candyboot) using uefi-rs. The devs behind it have done a great job, I didn’t need to worry about the low level details of UEFI, just use the API based on the documentation.

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.

I did a very similar thing, but without secure boot, and only for PXE booting Linux kernels that are EFI stubs.

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.

Interesting. But who is OpenDevicePartnership?

Looking at the members on the repository this seems to be a Microsoft project?

Can one even do UEFI firmware projects without at least keeping Microsoft in the loop?

As far as I remmeber, they control the issuance of keys for bootloaders. Or is this project supposed to do away with that?

Microsoft even has their own Rust project for UEFI.

https://microsoft.github.io/mu/

Patina is a significant evolution of 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.

Are you somehow related to either projects? You seem to have a good understanding of both pieces :)

Already today you can remove the Microsoft keys from most mein board's UEFI and enroll your own. You can perfectly make your own UEFI implementation without Microsoft.

Except that many component manufacturers release their efi capsules signed with Microsoft PKI. So no, you can't fully remove them if you want to verify updates.

While "So no, you can't fully remove them if you want to verify updates" is a valid point, it's also an answer to a different question than the one asked.

You're completely missing the point here.

Most of the top contributors are @microsoft.com so I would say it's a bit more than just "in the loop".

If you want to implement UEFI secure boot and verify existing signed objects then you need to incorporate Microsoft-issued certificates into your firmware, but that's very different from needing Microsoft to be in the loop - the certificates are public, you can download them and stick them in anything.

It's not that Microsoft controls the issuance, it's that their keys are pretty much guaranteed to be installed and thus getting your keys signed with their CA means you can use the pre-existing trust roots.

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

It's not open. It's not really about devices. And it's certainly not a partnership.

Open as in "open for business".

Can this be an alternative to TianoCore for qemu/kvm set ups?

Yep! See here[0] and here[1] for patina-qemu-related repositories/projects!

[0] https://github.com/OpenDevicePartnership/patina-qemu

[1] https://github.com/OpenDevicePartnership/patina-dxe-core-qem...

Nice!

I couldn't find a list anywhere, does this currently run on any hardware?

It's not there yet, but there are projects to build/run it for qemu: https://github.com/OpenDevicePartnership/patina-dxe-core-qem...

Reply on news.ycombinator.com