In order for a bootloader to function, it must know how to find the kernel inside of a filesystem in the GUID Partition Table (GPT).

This task is to track finding the actual kernel binary in some way. It's possible, as a first version, this will be implemented without using a file-system, and instead just assuming that the first N bytes will be the kernel -- but will later transition into a proper filesystem implementation.

In order for a bootloader to be able to boot a kernel, it needs to be able to make sense of its binary format. This project will be leveraging the standard ELF format, and requires a parser to make sense of the various section headers.

The Makefile currently is hardcoded to create bootx64.efi files from the bootloader image. The name of the binary must be named specifically based on the architecture it's built from; for aarch64 builds, it should be named bootaa64.efi

Implement a text display-driver

UEFI defines a spec for "Secure boot", which can allow for the motherboard to have a signed key installed which is validated against a signed UEFI binary. This effectively allows a root of trust from the motherboard/hardware -> bootloader.

This task is to track implementing secure-booting.

The typical convention for bootloaders is that they live in isolated directories based on vendor distribution, e.g:

efi/
  boot/
    bootaa64.efi
    bootx64.efi
  grub/
    ...
  Microsoft/
    ...
  Fedora/
    ...

This project should do the same. This will effectively require a "shiv" bootloader that calls out to our custom vendor.

The vendor name is currently undecided, and will likely be left as a placeholder like untitled to begin with.

This is the primary tracking task for implementing the Bootloader.

Sub tasks

• #2
• #3
• #4
• #7
• #8
• #10

This project has a goal of being self-sufficient from other projects as much as possible, both so that byproducts of this project can contribute to the rest of the OSI community, but also so that upstream changes won't break downstream dependents.

There exists a decent pre-1.0 uefi crate that can be leveraged for the time being; however it should be relatively simple to implement this without a dependency. All it requires is a custom linker to efi_main that accepts two pointer arguments, and the UEFI spec is defined in terms of C structs that can be mapped to #[repr(C)] struct objects.