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.
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
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.
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.
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
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?
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
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.
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.
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 :)
Most of the top contributors are @microsoft.com so I would say it's a bit more than just "in the loop".
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...
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!