This Month in Rust OSDev (August 2020)

Welcome to a new issue of "This Month in Rust OSDev". In these posts, we will give a regular overview of notable changes in the Rust operating system development ecosystem.

This series is openly developed on GitHub. Feel free to open pull requests there with content you would like to see in the next issue. If you find some issues on this page, please report them by creating an issue.

Project Updates

In this section, we give an overview of notable changes to the projects hosted under the rust-osdev organization.

uefi-rs

The uefi-rs crate provides safe and performant wrappers for UEFI, the successor to the BIOS. In August, the crate received a large number of improvements:

• Add method to return (image_base, image_size) to LoadedImage
• Rename image_info to info
• Hide the MemoryMapIter type from the API
• Upstream two changes from Pebble's fork
• Update to new alloc API
• Publish new versions of the crates
• Make memory map iterator clonable
• Fix the text::Output::current_mode method
• Use exact size iterators where possible
• Use ExactSizeIterator in exit_boot_services

Thanks to @tomoyat1 for their contribution!

multiboot2

The multiboot2 crate provides abstraction types for the boot information of multiboot2 bootloaders. The most important change this month was the update to the latest release of the multiboot2 specification:

• Add support for multiboot2
• Improve usage of repr(packed)

Thanks to @Caduser2020 for these contributions and welcome to the multiboot2 team!

bootloader

The bootloader crate implements a custom Rust-based bootloader for easy loading of 64-bit ELF executables. We did not publish any changes to the bootloader crate this month, but we made good progress on the UEFI implementation. See these issue comments for a detailed status report.

The rewrite of the real mode and protected mode stages of the BIOS bootloader is also making progress. The goal is to replace as much of the existing assembly code with Rust as possible, in order to make the code more robust and easier to understand.

ansi_rgb

The ansi_rgb crate implements no_std-compatible support for colored terminal text using ANSI escape sequences. The crate is still in an early state, but it received lots of new features this month:

• More colors and some minor changes
• Demo using RGB and 3- and 4-bit colors
• Merge Foreground and Background traits
• Add 8-bit colors
• Combine WithForeground and WithBackground into Colored
• Document extension to other color types
• Add Color8 constructors for RGB and gray
• Fix bounds check for Color8::new_rgb
• Go back to WithForeground and WithBackground structs
• Fix (and document/test) nesting

Thanks to @hanmertens for their contributions!

bootimage

The bootimage tool allows the creation of bootable disk images for bootloader-based kernels. It also provides a runner executable for cargo to make cargo run and cargo test work using QEMU. In August, we changed the test behavior to fix a bug where a triple fault is interpreted as a test success. We also fixed a small bug related to the --version argument. The relevant pull requests are:

• Consider all other exit codes besides 'test-success-exit-code' as failures (published as v0.10.0)
  • Also runs tests with -no-reboot by default, configurable through a new test-no-reboot config key
  • This is technically breaking change, but it should not affect most people.
• Parse --version argument without subcommand (bootimage --version) (published as v0.10.1)

Thanks to @Freax13 for their contribution!

x86_64

The x86_64 crate provides various abstractions for x86_64 systems, including wrappers for CPU instructions, access to processor-specific registers, and abstraction types for architecture-specific structures such as page tables and descriptor tables.

This month, we added some functions for reading and writing the FS and GS segment base registers:

• Add rdfsbase, rdgsbase, wrfsbase, wrgsbase (published as v0.11.2)

Thanks to @haraldh for this contribution!

acpi

The acpi repository contains crates for parsing the ACPI tables – data structures that the firmware of modern computers use to relay information about the hardware to the OS. This month, support for more opcodes was added to the AML parser:

• Factor out value comparison code from DefLEqual
• Make all type-2 opcode parsers concrete to avoid type limit
• Implement some DefL* opcodes
• Only read from field if update rule is Preserve

spinning_top

The spinning_top crate provides a simple spinlock implementation based on the abstractions of the lock_api crate. This month, we added an optional feature to make the crate compatible with the owning_ref crate:

• Add owning_ref support (published as v0.2.2)

Thanks to @not-a-seagull for this contribution!

cargo-xbuild

The cargo-xbuild project provides cargo command wrappers to cross-compile the sysroot crates core and alloc. At the beginning of this month, we had to update the crate for the new rustc directory layout. The crate also received a small cleanup:

• Update cargo-xbuild to new rust directory layout (published as v0.6.0)
• Cleanup: Use eprintln! instead of writeln! with stderr

Thanks to @toku-sa-n for their contribution!

Even though we still maintain the cargo-xbuild crate, we recommend switching to cargo's own build-std feature that is always up-to-date with the latest Rust/Cargo changes. We wrote a short guide on how to switch to it, which is available in our Readme.

Personal Projects

In this section, we describe updates to personal projects that are not directly related to the rust-osdev organization. Feel free to create a pull request with the updates of your OS project for the next post.

phil-opp/blog_os

(Section written by @phil-opp)

I'm still mostly working on the new bootloader with UEFI support, so there were no major changes to the Writing an OS in Rust series this month. However, I'm making good progress on the bootloader as noted above and I hope to finish the rewrite soon.

If all goes well, the new version will no longer require the bootimage tool and instead let the users create a simple build script for the bootloader themselves. It will also set up a pixel based framebuffer, which means that we will be able to do display proper graphics instead of just VGA-based text. Unfortunately, I'm currently a bit blocked by limitations of cargo configuration files (our default target should not apply to our build script), but I hope that we can find a solution for this soon.

While I focused most of my time on the bootloader and the cargo config files, I also merged a few few minor improvements for my blog:

• Change rustup override add to rustup override set
• Add (initial) Japanese translation (see below)
• Increase double fault stack size in Double Faults post
  • The previous stack size was too small in debug mode since our double fault handler uses the rather stack-intensive core::fmt functions.
  • Since the dobule fault stack has no guard page, this stack overflow resulted in undefined behavior. For example, it caused the system to hang or lead to a triple fault.
  • The stack size increase only works around this problem, but is not a clear fix. I plan to introduce a proper stack allocation function in the upcoming post about threading, which will create stacks with a proper guard page so that stack overflows deterministically lead to a page fault.
• Use workflow dispatch event to trigger scheduled builds of code branches
  • Enables nightly builds of all post-XX branches, so that we can be sure that our code always builds with the latest Rust nightly versions.
• Update Zola to 0.11.0

Thanks to @RWOverdijk and @JohnTitor for their contributions!

Japanese translations

(Section written by @JohnTitor)

This month, we also added a Japanese translation newly. You can find the languages list in the sidebar and Japanese if you enable that language in your browser. Only one post is currently translated, but we'd like to translate more posts in the future. Want to participate in the translation or find a typo? Feel free to open a PR/issue on the repository (please use English in the description if possible)!

Join Us?

Are you interested in Rust-based operating system development? Our rust-osdev organization is always open to new members and new projects. Just let us know if you want to join! A good way for getting in touch is our Zulip chat.

Comments