Patina: a Rust implementation of UEFI firmware

https://github.com/OpenDevicePartnership/patina

by hasheddan • 10 months ago

142 23 10 months ago

github.com

treffer• 9 months ago

Interesting. But who is OpenDevicePartnership?

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

mariuolo• 9 months ago

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?

pjmlp• 9 months ago

Microsoft even has their own Rust project for UEFI.

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

7bit2• 9 months ago

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.

Luker88• 9 months ago

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

mjg59• 9 months ago

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.

p_l• 9 months ago

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

als0• 9 months ago

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

yencabulator• 9 months ago

Open as in "open for business".

shmerl2• 9 months ago

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

danudey2• 9 months ago

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...

shmerl2• 9 months ago

Nice!

Palomides• 9 months ago

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

danudey2• 9 months ago

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

koito172• 9 months ago

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

chironjit• 9 months ago

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

WhyNotHugo• 9 months ago

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.

koito172• 9 months ago

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.

Patina: a Rust implementation of UEFI firmware

Related Stories