This Month in Rust OSDev (November 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.
In this section, we give an overview of notable changes to the projects hosted under 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. In November, we started fuzzing the AML parser to
help find inputs that crash it and we found
We even found a case where
we'd misinterpreted the spec. This is an important task for the project, as the AML parser will often run in
kernelspace, and so should not panic from any input, however invalid (some more work is needed to make this the
Lexicographic comparison was also implemented for
String AML objects,
which means we should now be able to perform all comparisons tables are allowed to make (bar some object
conversions, which still need some work).
The changes this month, as well as some made in December that should improve compile speed a little, have been
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.
In November, we merged the following updates:
Thanks to @toku-sa-n for their contribution!
multiboot2 crate provides abstraction types for the boot information of multiboot2 bootloaders. We merged the following updates this month:
- Access to non-available memory areas (published as
- Fix a few warnings (published as
Thanks to @CalebLBaker for their contribution!
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.
(Section written by @IsaacWoods)
Between university and work on
acpi, I haven't had a huge amount of time to work on Pebble for the last couple of
months, but in November I:
- Implemented a basic form of TLS for userspace tasks. Pebble
doesn't have threads, but an Address Space can have multiple Tasks running from the same image, each of which
need their copy of the master TLS record. TLS support is also needed very early in Rust's
std, so this was the next step in creating a
stdimplementation for Pebble.
- Tried to fix a bug in Pebble's UEFI bootloader, where we crash if memory allocated to Boot Services is unmapped
ExitBootServices. This may be a bug in OVMF - please get in touch if you've come across something similar and know what's going on!
- Continued work on the USB XHCI driver
- Improved detection of Intel microarchitectures - we can now differentiate Kaby Lake and Coffee Lake processors
based on their
(Section written by @phil-opp)
In November, we merged the following changes to the Writing an OS in Rust blog:
- Add Right-to-Left support for template
- Add Persian translation for posts of
- Show all available languages
- Emphasize moving code
Behind the scenes, I'm still working on the upcoming revision of the blog with UEFI and framebuffer support. One fundamental problem of the new build approach planned for this revision is that we can no longer use
.cargo/config files for specifying defaults. See my comment on GitHub for more details on the problem.
To solve this issue, I created a proposal on the Rust internals forum to move some cargo config settings to
Cargo.toml. While it is still not implemented yet, the great news is that the proposal was approved by the Cargo team 🎉! Now I (or someone else) just needs to find the time to implement this, then the last remaining blocker for the new build system should be resolved.
(Section written by @lucis-fluxum)
This is a new library I created to provide OS kernels with low-level access to the PS/2 controller and devices. It uses a poll-based approach with a timeout to read and write data to the IO ports.
While some of the library's functionality won't work on modern devices due to differing implementations of PS/2 emulation between manufacturers, it should be enough to get initialized and receiving scancodes and mouse events. Theoretically, it should work with PS/2-compatible keyboards all the way back to the IBM Model M!
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 gitter channel.