uefi-rs – library to enable writing UEFI apps in Rust language

This library allows you to write UEFI applications in Rust. UEFI is the successor to the BIOS. It provides an early boot environment for OS loaders and other low-level applications. The objective of this library is to provide safe and performant wrappers for UEFI interfaces, and allow developers to write idiomatic Rust code. This crate’s documentation is fairly minimal, and you are encouraged to refer to the UEFI specification for detailed information. You can find some example code in the tests directory, as well as use the build.py script to generate the documentation. This repo also contains a x86_64-uefi.json file, which is a custom Rust target for 64-bit UEFI applications.[…]


biors – BIOS implementation in Rust language

Gabriel Majeri has created “biors”, a BIOS implementation written in Rust! It is only a few days old, does not appear to be ready for use yet.

biors – The Basic Input / Output Rust System

This repository contains an x86 platform firmware implementation – more commonly known as a BIOS. It is written in Rust, and is designed for modern x86_64 processors. Similarly to CoreBoot, it is designed to deliver a “payload” – this could be a PC-AT compatible BIOS, or a UEFI implementation. BIOS is pronounced “BY-oss”, this project is pronounced “BY-orss”.[…]


PS: Gabriel has also written C++ bindings for UEFI! 😉


Ian Santopietro of System76 has a Python-based tool called kernelstub, which boots Linux using the Linux Stub bootloader instead of an external bootloader.

Kernelstub is a basic program enabling booting from the kernel’s built-in EFI Stub bootloader. It keeps the ESP and NVRAM up to date automatically when the kernel updates and allows for modifying and setting the boot parameters/kernel options stored in NVRAM. Kernelstub is a basic program enabling booting from the kernel’s built-in EFI Stub bootloader. It keeps the ESP and NVRAM up to date automatically when the kernel updates and allows for modifying and setting the boot parameters/kernel options stored in NVRAM. It works by detecting certain information about the running OS, kernel, storage devices, and options, then combines all of that together into a unified entity, then calls efibootmgr to register the kernel with the NVRAM. It also copies the latest kernel, initrd.img to the EFI System Partition so that UEFI can find it. It will also store a copy of the kernel’s command line (/proc/cmdline) on the ESP in case of necessary recovery from an EFI shell.


He just gave a talk/demo of it at SeaGL:


His presentation mentioned this blog in the ‘more info’ slide! 🙂

SisyphOS: UEFI-based Rust kernel

sisyphos-kernel-uefi-x86_64: UEFI-based Rust kernel

A Rust kernel running on bare UEFI (no separate bootloader). Very early stage. Basically, the eventual goal is to build a non-opinionated microkernel that can load regular ELF64 programs as kernel “modules”. Actually, just fairly conventional processes, except running in kernel space (they are assumed to be written in Rust and reproducible, so that hardware protections are unnecessary, similar but unrelated to Microsoft’s Singularity project). The core micro/nano/whateverkernel will link up the loaded applications with a builtin dynamically linked library that exposes its functionality, moving the responsibility for higher-level problems (such as syscalls) into these loadable binaries, and also allowing simple emulation without virtualization for debugging purposes.[…]



Two new Rust/UEFI projects by Jiří Zárevúcky

Two new Rust/UEFI projects:

rust-efi-app: High-level bindings for writing UEFI applications in Rust. Currently in very early stages. The goal is that the library will make it easy and safe to write an application (e.g. an OS kernel) that is capable of functioning across call to ExitBootServices() without depending on the programmer’s judgement for safety, transparently dealing with issues like memory allocations and console output.


rust-efi-types:  Autogenerated Rust bindings for UEFI types and methods. Generated using bindgen from the headers distributed with gnu-efi. The headers are included. Only works on x86_64, and I don’t plan to extend it to other platforms, or clean it up in any way, because it’s all just a giant hack so that I don’t have to waste much time on proper bindings at this moment. Eventually, it will outlive its usefulness and be unceremoniously dumped into trash.



Baidu releases SGX SDK for Rust

Rust SGX SDK, v0.2.0 Release

This Rust SGX SDK helps developers write Intel SGX enclaves in Rust programming language. We are proud to have our v0.2.0 Rust SGX SDK released. It is now providing more threading functions, thread local storages, exception handling routines and supports unwind mechanism, as well as support of LARGE ENCLAVE MEMORY with the help of Intel SGX v1.9 (31.75 GB enclave memory tested). Please refer to release notes for further details. And we are working on a white paper for technical details about this project.[…]


Corrode: Rust to C translator

I wish UEFI Forum had bindings to languages other than C, such as Rust, which has multiple community implementations.

I also wish there was a Rust-to-C project for Tianocore. 😉




LibEnclave: create Intel SGX secure enclaves in Rust

Jethro Beekman has released libenclave, a Rust-based tool for Intel SGX’s SDK for Windows:

This guide will get you started building SGX secure enclaves in Rust using libenclave and sgxs-tools. […]


Rust for embedded use

There’s a new research paper out, on using the Rust programming language in embedded systems; the below blog post has more information as well.

Ownership is Theft: Experiences Building an Embedded OS in Rust
Amit Levy, Michael P Andersen, Bradford Campbell, David Culler, Prabal Dutta, Branden Ghena, Philip Levis, Pat Pannuto

Rust, a new systems programming language, provides compile-time memory safety checks to help eliminate runtime bugs that manifest from improper memory management. This feature is advantageous for operating system development, and especially for embedded OS development, where recovery and debugging are particularly challenging. However, embedded platforms are highly event-based, and Rust’s memory safety mechanisms largely presume threads. In our experience developing an operating system for embedded systems in Rust, we have found that Rust’s ownership model prevents otherwise safe resource sharing common in the embedded domain, conflicts with the reality of hardware resources, and hinders using closures for programming asynchronously. We describe these experiences and how they relate to memory safety as well as illustrate our workarounds that preserve the safety guarantees to the largest extent possible. In addition, we draw from our experience to propose a new language extension to Rust that would enable it to provide better memory safety tools for event-driven platforms.

Rust is apparently popular. I did one short post the other month[1], describing some existing Rust bindings for UEFI. Weeks later, that blog post is *still* one of the most-viewed posts every day.

More information:

[1] https://firmwaresecurity.com/2015/09/04/rust-and-uefi/

Rust and UEFI

Rust is a relatively new programming language.

Back in 2013, Eric Holk started adding UEFI support in Rust:

There’s also a 2014 UEFI Rust library by “project kernel”, which includes a UEFI boot loader, among other things:

Starting last month, there’s another Rust UEFI library, by William Kunkel:

I don’t know how to program in Rust yet, so I can’t say how usable Rust is with UEFI yet. The last library looks promising, perhaps more general-purpose than the previous projects, as far as I can tell. I guess I am going to have to learn Rust…

More Information: