UEFI-rs: Write UEFI applications in Rust | Hacker News Reader

UEFI-rs: Write UEFI applications in Rust

github.com

144 pointsmmastrac14 comments

I've seen a lot of interesting UEFI articles recently, but even before they made it on to HN it was always something you could only play with in QEMU. Is there any open hardware yet?

If I'm reading this correctly, at least this repository is about writing applications that run on top of UEFI rather than building the platform itself, in which case the resulting applications should probably work on any normal computer provided secure boot doesn't get in your way.

You make a bootup disc (or USB) like your typical dual booting procedure. Then go into BIOS (I am using the legacy name for the modern UEFI menu) and boot up from there. It is the same as any OS development except that UEFI provides you with a number of APIs including a mini filesystem, a primitive shell, a graphics API, and some other stuff. To make it easier, you can think of your computer running pure UEFI apps as a giant, overpowered Arduino.

https://wiki.osdev.org/UEFI_Bare_Bones

Until recently, almost every UEFI app had to be written in C/C++.

Quite a number of the arm boards have open UEFI ports. Tianocore edk-platforms https://github.com/tianocore/edk2-platforms/tree/master/Plat... has a number that are maintained together. Others can be found in various places on github and/or a vendors site.

Of note, the rpi3/4 are both supported. The hardware isn't particularly open, but they have been reverse engineered to the point where even the videocore firmware has a open source project ongoing to replace it.

There are also various tutorials for getting inexpensive jtag probes working with openocd on the rpi3/4 so its possible to have a fully opensource firmware development stack.

Edit: There are a couple intel ports as well, if that is one's preferred platform.

You can still port EDK2 to the hardware of your choice. Most people can have a quick play on it on Raspberry Pi >= 3.

Also yes, EDK2 is a faithful implementation of UEFI standard and so if you do target EDK2 it should run on your typical amd64-based computer without issue.

By the way the UEFI platform is actually a partial OS itself! Memory allocation and paging is handled and there are even partial event system support, making it possible to run asynchronous code in Rust-based UEFI firmware. However one caveat is that UEFI itself is split into Runtime services and Boot services and their memory is not shared after the transition. uefi-rs exploited the borrow checker to cleverly mitigate this issue.

Sadly uefi-rs doesn’t have most of the UEFI API wrappers. I tried porting some of it but it’s just too complicated and I don’t really have the time to churn on it.

The difficulty seemed to me to be actually getting the board to run your UEFI code. I'll give it a try on an RPi. Thanks for the input.

And yes, I'm aware of most of that, it has always bugged me that my mobo's UEFI is typically larger than the kernel it runs.

You can load your own modules on your own hardware, so certain level of play is still available for you. Worst case you will have to put a custom bootloader setup that can be as simple as shell with autostart script, that for example loads your modules as drivers.

It will require some storage (local EFI filesystem) or network location to load them from, but that's it.

On some computers you can take apart an existing UEFI image, add/remove your own modules, then flash the modified image. https://github.com/theopolis/uefi-firmware-parser

Very cool.. curious how many of the major cloud providers support a self-made VM image, and UEFI based images to boot from. Could be an effective means of app-as-os for virtualized environments (or raw environment, iot etc).

I think Vultr does?

Sounds interesting.

What are the use-cases?

Do the things listed in first paragraph of page linked.

This crate makes it easy to both:

* Write UEFI applications in Rust. It (UEFI) provides an early boot environment for OS loaders, hypervisors and other low-level applications.

* Call UEFI functions from an OS (usually built with a custom target)

Those are not use cases, those are features.

"This device can cook an apple into a perfect plasma." (feature)! Yeah but who needs it (use case)? Beings from the 5th dimension who eat plasma for breakfast.

But even then you would still owe to show the relevance of the use case.

b̵o̵o̵t̵k̵i̵t̵ ̵

Reply on news.ycombinator.com