An experimental x86 bootloader written in Rust and inline assembly.
Written for the second edition of the Writing an OS in Rust series.
When you press the power button the computer loads the BIOS from some flash memory stored on the motherboard. The BIOS initializes and self tests the hardware then loads the first 512 bytes into memory from the media device (i.e. the cdrom or floppy disk). If the last two bytes equal 0xAA55 then the BIOS will jump to location 0x7C00 effectively transferring control to the bootloader. At this point the CPU is running in 16 bit mode, meaning only the 16 bit registers are available. Also since the BIOS only loads the first 512 bytes this means our bootloader code has to stay below that limit, otherwise we’ll hit uninitialised memory! Using Bios interrupt calls the bootloader prints debug information to the screen. For more information on how to write a bootloader click here. The assembler files get imported through the global_asm feature. The assembler syntax definition used is the one llvm uses: GNU Assembly.
stage1.s This stage initializes the stack, enables the A20 line, loads the rest of the bootloader from disk, and jumps to stage2.
stage_2.s This stage sets the target operating mode, loads the kernel from disk, creates an e820 memory map, enters protected mode, and jumps to the third stage.
stage3.s This stage performs some checks on the CPU (cpuid, long mode), sets up an initial page table mapping (identity map the bootloader, map the P4 recursively, map the kernel blob to 4MB), enables paging, switches to long mode, and jumps to stage4.
The file .cargo/config defines an llvm target file called x86_64-bootloader.json.
This file defines the architecture sets freestanding flags and tells llvm to use the linker script linker.ld.
The linker script tells the linker at which offsets the sections should be mapped to. In our case it tells the linker that the bootloader asm files stage_0-3.s should be mapped to the very beginning of the executable. Read more about linker scripts here
Another important role plays the file build.rs.
Placing a file named build.rs in the root of a package will cause
Cargo to compile that script and execute it just before building the package.
You can read more about it here.
The build.rs file execute the llvm tools you installed with rustup component add llvm-tools-preview
in this order:
Check size of .text section of the kernel if it's too small throw an error
bash
llvm-size "../../target/x86_64-os/debug/svm_kernel"
Strip debug symbols from kernel to make loading faster
bash
llvm-objcopy "--strip-debug" "../../target/x86_64-os/debug/svm_kernel" "target/x86_64-bootloader/debug/build/bootloader-c8df27c930d8f65a/out/kernel_stripped-svm_kernel"
--binary-architecture flag creates three synthetic symbols
_binary_objfile_start, _binary_objfile_end, _binary_objfile_size..
These symbols use the project / binary name which is why we have to rename them to something more generic
to be able to reference them.
bash
llvm-objcopy "-I" "binary" "-O" "elf64-x86-64" "--binary-architecture=i386:x86-64" "--rename-section" ".data=.kernel" "--redefine-sym" "_binary_kernel_stripped_svm_kernel_start=_kernel_start_addr" "--redefine-sym" "_binary_kernel_stripped_svm_kernel_end=_kernel_end_addr" "--redefine-sym" "_binary_kernel_stripped_svm_kernel_size=_kernel_size" "target/x86_64-bootloader/debug/build/bootloader-c8df27c930d8f65a/out/kernel_stripped-svm_kernel" "target/x86_64-bootloader/debug/build/bootloader-c8df27c930d8f65a/out/kernel_bin-svm_kernel.o"
bash
llvm-ar "crs" "bootloader/target/x86_64-bootloader/debug/build/bootloader-c8df27c930d8f65a/out/libkernel_bin-svm_kernel.a" "target/x86_64-bootloader/debug/build/bootloader-c8df27c930d8f65a/out/kernel_bin-svm_kernel.o"
Afterwards build.rs tells cargo to use the newly created static library to link against your kernel, with the help of the linker script everything gets placed correctly in the
resulting elf file.
The last step is to strip away the elf header from the resulting elf binary so that the bios can jump directly to the bootloader stage_1.s. This is done with:
bash
cargo objcopy -- -I elf64-x86-64 -O binary --binary-architecture=i386:x86-64 \
target/x86_64-bootloader/release/bootloader target/x86_64-bootloader/release/bootloader.bin
The bootloader exposes a few variables which can be configured through the Cargo.toml of your kernel:
```toml [package.metadata.bootloader]
kernel-stack-address = "0xFFFFFF8000000000"
kernel-stack-size = 128
map_physical_memory feature of the crate is enabled.physical-memory-offset = "0xFFFF800000000000"
boot-info-address = "0xFFFFFFFF80000000" ```
Note that the addresses must be given as strings (in either hex or decimal format), as TOML does not support unsigned 64-bit integers.
You need a nightly Rust compiler and cargo xbuild. You also need the llvm-tools-preview component, which can be installed through rustup component add llvm-tools-preview.
The simplest way to use the bootloader is in combination with the bootimage tool. This crate requires at least bootimage 0.7.7. With the tool installed, you can add a normal cargo dependency on the bootloader crate to your kernel and then run bootimage build to create a bootable disk image. You can also execute bootimage run to run your kernel in QEMU (needs to be installed).
To compile the bootloader manually, you need to invoke cargo xbuild with two environment variables:
* KERNEL: points to your kernel executable (in the ELF format)
* KERNEL_MANIFEST: points to the Cargo.toml describing your kernel
For example:
KERNEL=/path/to/your/kernel/target/debug/your_kernel KERNEL_MANIFEST=/path/to/your/kernel/Cargo.toml cargo xbuild
As an example, you can build the bootloader with example kernel from the example-kernel directory with the following commands:
cd example-kernel
cargo xbuild
cd ..
KERNEL=example-kernel/target/x86_64-example-kernel/debug/example-kernel KERNEL_MANIFEST=example-kernel/Cargo.toml cargo xbuild --release --features binary
The binary feature is required to enable the dependencies required for compiling the bootloader executable. The command results in a bootloader executable at target/x86_64-bootloader.json/release/bootloader. This executable is still an ELF file, which can't be run directly.
To run the compiled bootloader executable, you need to convert it to a binary file. You can use the llvm-objcopy tools that ships with the llvm-tools-preview rustup component. The easiest way to use this tool is using cargo-binutils, which can be installed through cargo install cargo-binutils. Then you can perform the conversion with the following command:
cargo objcopy -- -I elf64-x86-64 -O binary --binary-architecture=i386:x86-64 \
target/x86_64-bootloader/release/bootloader target/x86_64-bootloader/release/bootloader.bin
You can run the bootloader.bin file using QEMU:
qemu-system-x86_64 -drive format=raw,file=target/x86_64-bootloader/release/bootloader.bin
Or burn it to an USB drive to boot it on real hardware:
dd if=target/x86_64-bootloader/release/bootloader.bin of=/dev/sdX && sync
Where sdX is the device name of your USB stick. Be careful to choose the correct device name, because everything on that device is overwritten.
Set a breakpoint at address 0x7c00. Disassemble instructions with gdb:
bash
qemu-system-x86_64 -drive format=raw,file=target/x86_64-bootloader/release/bootloader.bin -s -S
(gdb) target remote: 1234
(gdb) b *0x7c00
(gdb) x/i $rip
If you use the -enable-kvm flag you need to use hardware breakpoints hb.
The bootloader crate can be configured through some cargo features:
vga_320x200: This feature switches the VGA hardware to mode 0x13, a graphics mode with resolution 320x200 and 256 colors per pixel. The framebuffer is linear and lives at address 0xa0000.recursive_page_table: Maps the level 4 page table recursively and adds the recursive_page_table_address field to the passed BootInfo.map_physical_memory: Maps the complete physical memory in the virtual address space and passes a physical_memory_offset field in the BootInfo.sse enables sse instruction supportphysical-memory-offset field in the kernel's Cargo.toml, as explained in Configuration.See these guides for advanced usage of this crate:
Licensed under either of
at your option.
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.