[HN Gopher] Patina: a Rust implementation of UEFI firmware
___________________________________________________________________
Patina: a Rust implementation of UEFI firmware
Author : hasheddan
Score : 126 points
Date : 2025-10-10 21:02 UTC (12 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| treffer wrote:
| Interesting. But who is OpenDevicePartnership?
|
| Looking at the members on the repository this seems to be a
| Microsoft project?
| mariuolo wrote:
| 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 wrote:
| Microsoft even has their own Rust project for UEFI.
|
| https://microsoft.github.io/mu/
| zang0 wrote:
| 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.
| CaptainOfCoit wrote:
| Are you somehow related to either projects? You seem to
| have a good understanding of both pieces :)
| 7bit wrote:
| 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.
| BonusPlay wrote:
| 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.
| zamadatix wrote:
| 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.
| Luker88 wrote:
| Most of the top contributors are @microsoft.com so I would
| say it's a bit more than just "in the loop".
| mjg59 wrote:
| 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 wrote:
| 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
| shmerl wrote:
| Can this be an alternative to TianoCore for qemu/kvm set ups?
| danudey wrote:
| 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...
| shmerl wrote:
| Nice!
| Palomides wrote:
| I couldn't find a list anywhere, does this currently run on any
| hardware?
| danudey wrote:
| It's not there yet, but there are projects to build/run it for
| qemu: https://github.com/OpenDevicePartnership/patina-dxe-core-
| qem...
| koito17 wrote:
| 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
___________________________________________________________________
(page generated 2025-10-22 23:01 UTC)