Most active commenters

    Patina: a Rust implementation of UEFI firmware

    (github.com)
    130 points hasheddan | 19 comments | 10 Oct 25 21:02 UTC | HN request time: 1.496s | source | bottom
    1. treffer ◴[11 Oct 25 10:25 UTC] No.45547992[source]▶
    Interesting. But who is OpenDevicePartnership?

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

    replies(1): >>45548383 #
    2. mariuolo ◴[11 Oct 25 11:45 UTC] No.45548383[source]▶
    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?

    replies(5): >>45551246 #>>45551954 #>>45670901 #>>45672708 #>>45674194 #
    3. pjmlp ◴[11 Oct 25 18:05 UTC] No.45551246{3}[source]▶
    Microsoft even has their own Rust project for UEFI.

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

    replies(1): >>45584339 #
    4. 7bit ◴[11 Oct 25 19:29 UTC] No.45551954{3}[source]▶
    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.
    replies(1): >>45671044 #
    5. zang0 ◴[14 Oct 25 20:22 UTC] No.45584339{4}[source]▶
    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.

    replies(1): >>45670088 #
    6. shmerl ◴[22 Oct 25 14:53 UTC] No.45670050[source]▶
    Can this be an alternative to TianoCore for qemu/kvm set ups?
    replies(1): >>45671386 #
    7. CaptainOfCoit ◴[22 Oct 25 14:55 UTC] No.45670088{5}[source]▶
    Are you somehow related to either projects? You seem to have a good understanding of both pieces :)
    8. ◴[22 Oct 25 15:12 UTC] No.45670391[source]▶
    9. Palomides ◴[22 Oct 25 15:19 UTC] No.45670503[source]▶
    I couldn't find a list anywhere, does this currently run on any hardware?
    replies(1): >>45671394 #
    10. Luker88 ◴[22 Oct 25 15:45 UTC] No.45670901{3}[source]▶
    Most of the top contributors are @microsoft.com so I would say it's a bit more than just "in the loop".
    11. BonusPlay ◴[22 Oct 25 15:54 UTC] No.45671044{4}[source]▶
    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.
    replies(1): >>45671887 #
    12. danudey ◴[22 Oct 25 16:15 UTC] No.45671386[source]▶
    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...

    replies(1): >>45672689 #
    13. danudey ◴[22 Oct 25 16:16 UTC] No.45671394[source]▶
    It's not there yet, but there are projects to build/run it for qemu: https://github.com/OpenDevicePartnership/patina-dxe-core-qem...
    14. zamadatix ◴[22 Oct 25 16:51 UTC] No.45671887{5}[source]▶
    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.
    15. shmerl ◴[22 Oct 25 17:50 UTC] No.45672689{3}[source]▶
    Nice!
    16. mjg59 ◴[22 Oct 25 17:51 UTC] No.45672708{3}[source]▶
    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.
    17. p_l ◴[22 Oct 25 19:45 UTC] No.45674194{3}[source]▶
    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

    18. koito17 ◴[22 Oct 25 19:48 UTC] No.45674232[source]▶
    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