All Projects → gurry → efi

gurry / efi

Licence: MIT license
Ergonomic Rust framework for writing UEFI applications.

Programming Languages

rust
11053 projects

Projects that are alternatives of or similar to efi

uefi-elf-bootloader
UEFI ELF Bootloader example
Stars: ✭ 40 (-9.09%)
Mutual labels:  uefi, bootloader, efi
Veracrypt Dcs
VeraCrypt EFI Bootloader for EFI Windows system encryption (LGPL)
Stars: ✭ 81 (+84.09%)
Mutual labels:  uefi, bootloader, efi
sicherboot
Unmaintained systemd-boot integration with secure boot support; consider https://github.com/Foxboron/sbctl instead.
Stars: ✭ 31 (-29.55%)
Mutual labels:  uefi, bootloader, efi
UEFI-Utilities-2016
Various UEFI utilities built against UDK2015
Stars: ✭ 37 (-15.91%)
Mutual labels:  uefi, uefi-development, uefi-application
systemboot
SystemBoot is a LinuxBoot distribution that works as a system firmware + bootloader, based on u-root
Stars: ✭ 103 (+134.09%)
Mutual labels:  dhcp, uefi, bootloader
Hackintosh-ASUS-A455LF-Notebook
EFI Folder for ASUS A455LF-WX039D Notebook Series with Clover/OpenCore Legacy or UEFI
Stars: ✭ 27 (-38.64%)
Mutual labels:  uefi, bootloader, efi
Efifs
EFI FileSystem drivers
Stars: ✭ 272 (+518.18%)
Mutual labels:  uefi, efi
Aio Boot
AIO Boot is an All-in-One bootable software for USB and HDD. Is one of the best Multiboot USB Creator for Windows.
Stars: ✭ 300 (+581.82%)
Mutual labels:  uefi, bootloader
meta-secure-core
OpenEmbedded layer for the use cases on secure boot, integrity and encryption
Stars: ✭ 80 (+81.82%)
Mutual labels:  uefi, efi
Rust Uefi Runtime Driver
Template for UEFI runtime drivers written in Rust with serial logging and debugging support.
Stars: ✭ 21 (-52.27%)
Mutual labels:  uefi, efi
Minimal
Minimal Linux Live (MLL) is a tiny educational Linux distribution, which is designed to be built from scratch by using a collection of automated shell scripts. Minimal Linux Live offers a core environment with just the Linux kernel, GNU C library, and Busybox userland utilities.
Stars: ✭ 1,014 (+2204.55%)
Mutual labels:  uefi, efi
Multibootusb
Create multiboot live Linux on a USB disk...
Stars: ✭ 1,042 (+2268.18%)
Mutual labels:  uefi, efi
edk2-nightly
Unofficial EDK2 nightly build
Stars: ✭ 20 (-54.55%)
Mutual labels:  uefi, efi
efi-clang
Build UEFI applications with the Clang compiler and LLD linker.
Stars: ✭ 40 (-9.09%)
Mutual labels:  uefi, efi
Efiguard
Disable PatchGuard and DSE at boot time
Stars: ✭ 601 (+1265.91%)
Mutual labels:  uefi, efi
UEFI-Boot
Boot Linux directly from UEFI firmware (without any bootloader)
Stars: ✭ 38 (-13.64%)
Mutual labels:  uefi, bootloader
efi
efi headers
Stars: ✭ 24 (-45.45%)
Mutual labels:  uefi, efi
Refind Minimal
A stunningly clean theme for the rEFInd UEFI boot manager.
Stars: ✭ 1,585 (+3502.27%)
Mutual labels:  uefi, bootloader
Hekate
hekate - A GUI based Nintendo Switch Bootloader
Stars: ✭ 3,286 (+7368.18%)
Mutual labels:  uefi, bootloader
rename-efi-entry
A Bash script to rename EFI boot entries
Stars: ✭ 45 (+2.27%)
Mutual labels:  uefi, efi

efi

Crates.io

A framework for writing UEFI applications in Rust. Acts like Rust standard library on the UEFI platform with support for things like:

  • Console I/O
  • Containers such as Vec and String via a custom allocator
  • Macros like println!, write!, format! etc.
  • Rust I/O primitives as Read and Write traits and the related types
  • UDP and TCP sockets similar to those in stdlib
  • Implementation of IpAddr and its supporting types
  • Domain name resolution so that you can connect sockets using a hostname

Also offers an ergonomic API for UEFI-specific functionality such as:

  • Loading and starting images
  • DHCP
  • PXE
  • Device paths

Lastly, also exposes the raw underlying API to do FFI with the UEFI platform. Itself uses the same FFI API to implement above functionality.

Limitations

  • Is a work in progress. API surface can change without notice.
  • Currently only x64 architecture is supported.
  • Tested to compile only with Rust nightly version nightly-2023-01-12. May not compile with others. You must force this version using a rust-toolchain file (as shown in the following section)

Writing a UEFI Application

To write a UEFI application using this framework follow the below steps:

  1. Create a new crate for your application by running cargo new my_efi_app, where "my_efi_app" is the name of the application
  2. Add efi = "0.2" under [dependencies] in Cargo.toml
  3. Add a file named "rust-toolchain" containing the text nightly-2023-01-12 at the root of the crate. This will ensure that the crate is always built with nightly-2023-01-12.
  4. Add the below code in my_efi_app/src/main.rs. Comments in the code explain each part:
#![no_std] // Indicates to the Rust compiler that the app does not depend on the standard library but is a 'standalone' application.
#![no_main] // Indicates that this application does not have a "main" function typically found in a Linux or Windows application (although it does have its own "main" function "efi_main" as declared below)
#![feature(alloc_error_handler)] // Needed for the alloc error handler function declared below since this feature is unstable.

// Externs for efi and alloc crates (alloc crate is the one that contains definitions of String and Vec etc.)
#[macro_use] extern crate efi;
#[macro_use] extern crate alloc;


// EFI entrypoint or main function. UEFI firmware will call this function to start the application.
// The signature and the name of this function must be exactly as below.
#[no_mangle]
pub extern "win64" fn efi_main(image_handle: efi::ffi::EFI_HANDLE, sys_table : *const efi::ffi::EFI_SYSTEM_TABLE) -> isize {
    efi::init_env(image_handle, sys_table); // Call to init_env must be the first thing in efi_main. Without it things like println!() won't work

    println!("Welcome to UEFI");

    // Your business logic here

    0
}

// A handler to respond to panics in the code. Required by the Rust compiler
#[panic_handler]
fn panic(_: &core::panic::PanicInfo) -> ! {
    loop {}
}

// A handler to respond to allocation failures. Required by the Rust compiler
#[alloc_error_handler]
fn alloc_error(_: core::alloc::Layout) -> ! {
    loop {}
}

Building

Build the application by running cargo build -Z build-std=core,alloc --target x86_64-unknown-uefi. When the build completes the resulting EFI application my_efi_app.efi will be found in target\x86_64-unknown-uefi\debug\

Running

Run the UEFI appliction in a qemu virtual machine by following the below steps:

  1. Download and install qemu
  2. Google for ovmf.fd and download that binary (This is the OVMF firmware under which we will run the application)
  3. Start qemu by running this commandline: <path where qemu is installed>/qemu-system-x86_64 -pflash <path where you downloaded ovmf.fd>/ovmf.fd -hda fat:rw:<path to your uefi application crate>/target/x86_64-unknown-efi/debug
  4. Qemu will boot into ovmf.fd firmware and start the EFI shell
  5. Wait for EFI shell command prompt. When it appears enter the application's name my_efi_app.efi and press ENTER
  6. The application will run and print "Welcome to UEFI" on the qemu screen

Example Application

For a sample application see examples/sample_efi_app.rs. Build it by running cargo build -Z build-std=core,alloc --target x86_64-unknown-uefi --example sample_efi_app. The resulting binary sample_efi_app.efi will be found in target/x86_64-unknown-uefi/debug/examples.

The application performs DHCP at the start to obtain an IP address and then makes an HTTP request to a specified server. So to run it you need to follow the below steps:

  1. Ensure that a DHCP server is running in your network and can give out IP addresses.
  2. On the machine on which you will run the application, install a TAP adapter of your choice and note its name.
  3. Connect the TAP adapter to the same LAN as the DHCP server above. If they are not on the same LAN the application will not receive an IP address.
  4. Run qemu with the following commandline: <path where qemu is installed>/qemu-system-x86_64 -pflash <path where you downloaded ovmf.fd>/ovmf.fd -hda fat:rw:<path to your uefi application crate>/target/x86_64-unknown-efi/debug/examples -net tap,ifname=<name of your TAP adapter> -net nic. With the two -net options at the end this commandline tells qemu to use the TAP adapter you installed above. Ensure that the name you specify after ifname= is that of the TAP adapter which you noted above.

The application will start, perform DHCP, get an IP address, prompt you for the name of an HTTP server and then make a GET request to that server.

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].