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