This Month in Rust OSDev: March 2022

Welcome to a new issue of "This Month in Rust OSDev". In these posts, we 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 or using our comment form at the bottom of this page.

Project Updates

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

x86_64

Maintained by @phil-opp, @josephlr, @Freax13, and @rybot666

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 released version 0.14.9 of the x86_64 crate with lots of improvements:

New Features

• Add UCet and SCet registers
• Specific MSRV now noted in README
• Use rustversion to mark certain functions const fn on Rust 1.61
• Entry::handler_addr() is now public
• Increase packed structure alignment
• Make more address methods const fn
  • VirtAddr::as_ptr()
  • VirtAddr::as_mut_ptr()
  • PhysAddr::new()
  • PhysAddr::try_new()

Already merged last month:

• Remove all uses of external assembly
  • external_asm and inline_asm features are deprecated and now have no effect.
  • instructions feature (on by default) now requires Rust 1.59
• Implement core::iter::Step for VirtAddr and Page
  • This trait is only available on nightly.
  • Gated behind step_trait feature flag
• Address in VirtAddrNotValid and PhysAddrNotValid is now public
  • This field now contains the whole invalid address

Bug fixes and Documentation

• Fixed overflow bug in PageRangeInclusive
• Remove stabilized const_fn_fn_ptr_basics and const_fn_trait_bound features
• Don't set nomem in load_tss
• Correctly initialize TSS's IOPB to be empty
• Improve GlobalDescriptorTable::add_entry error handling)
• Update tss_segment documentation)

Thanks to @jarkkojs, @drzewiec, and @kevinaboos for contributing to this release!

v0.15

We also merged some breaking changes which will be published in the upcoming v0.15 release:

• Allow the GDT to be of any length
  • gdt: Check that MAX is in range
• VirtAddr improvements
• Remove software_interrupt! macro
• Remove usize trait impls
• Remove deprecated functions/flags
• Update "next" MSRV to 1.59

Special thanks to our co-maintainer @josephlr, who did a lot of great work this month!

uefi-rs

Maintained by @GabrielMajeri and @nicholasbishop

The uefi crate provides safe and performant wrappers for UEFI, the successor to the BIOS.

One of the pain points of developers building software using uefi-rs has been the Completion type, which is like an expanded Result type which also handles warnings (besides successes and errors). The RFC for the removal of the Completion type has been accepted and the corresponding changes have been merged in March: the Completion type has been removed and the crate has reverted to using more standard Results everywhere, by treating all warnings as errors.

We merged the following changes in March:

New features/protocols

• Implement the connect_controller/disconnect_controller methods
• Implement BootServices::locate_handle_buffer function
• Add rng protocol
• Add BootServices::load_image
• Add GptPartitionAttributes bitflags
• Add FileHandle convenience methods and new file system tests
• Add RuntimeServices::query_variable_info

Refactorings

• Make Error public
• Simplify uefi::Result type and remove Completion
• Improve Time struct

Bug fixes

• Fix alignment issues in file info types
• Update changelog for file info changes
• Make LoadedImage's load options API safer
• Fix status to Result conversions

CI & testing

• Add miri action to xtask and CI
• Don't run doctests with invalid pointers

Misc & chores

• Add package sections to changelog
• Remove some no-longer-needed unstable features
• Drop maintenance badges from the README
• Remove no-longer-needed allows for clippy lints
• Publish new versions of the crates

Thanks to @nicholasbishop, @sven-eliasen, @necauqua and @AtsukiTak for their contributions!

uart_16550

Maintained by @phil-opp

The uart_16550 crate provides basic support for serial port I/O for 16550-compatible UARTs. We merged the following changes this month:

• Remove stabilized nightly feature const_ptr_offset (published as v0.2.17)

Thanks to @tsatke for this contribution!

xhci

Maintained by @toku-sa-n

The xhci crate provides types of xHCI structures such as Contexts, Extended Capabilities, Registers, and TRBs. This month, we merged some cleanups:

• fix: clippy warnings
• ci(deps): enable dependabot

Call for Participation

Want to contribute to a Rust OSDev project, but don't know where to start? Pick up one of these outstanding issues in one of our projects and get started!

If you maintain a Rust project related to operating system development and are looking for contributors, especially for tasks suited to people getting started in this space, please create a PR against the next branch with the tasks you want to include in the next issue.

Other Projects

In this section, we describe updates to Rust OS 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.

phip1611/simple-chunk-allocator

(Section written by @phip1611)

Philipp Schuster recently released an initial version of his simple-chunk-allocator crate. It focuses on being a very simple-to-use general purpose allocator that "just works" for various workloads in no_std context. A bitmap is used for bookkeeping of used blocks/chunks. This enables a simple algorithm that is easy to understand. The allocator uses a combination of the strategies "next fit" and "best fit". It is usable as #[global_allocator] and operates on static memory, i.e., no paging mechanism involved. The crate is suited to manage the heap inside a kernel or in a similar no_std application. It is part of the roottask in Philipp's Diplom (Master) Thesis where he wrote a runtime system for a Microkernel in Rust.

phip1611/linux-libc-auxv

(Section written by @phip1611)

Philipp Schuster recently released an initial version of his linux-libc-auxv crate. The crate enables the creation and the parsing of the initial Linux stack layout. This layout is a special data structure that Linux prepares for applications before they start execution. The C runtime behind the _start symbol of a libc implementation uses this to find program arguments, environment variables, and the auxiliary vector. The layout is tricky to create because the creator must ensure that the layout is valid in the address space of the target. However, linux-libc-auxv found a way to cope with this.

You can write a "freestanding" binary, i.e., without libc, with this crate, run it under Linux and parse the stack layout yourself. This is similar to what the libc does, before Rust's runtime starts, that eventually calls the main function of a Rust program.

The crate is part of Philipp's Diplom (Master) Thesis where he wrote a runtime system for a Microkernel in Rust that can emulate Linux behaviour and run unmodified Linux applications.

phip1611/diplomarbeit-impl

(Section written by @phip1611)

Philipp Schuster submitted his Diplom (Master) Thesis at TU Dresden where he build a policy-free system-call layer for the Hedron microhypervisor. The project comes with a runtime system written in Rust for the microkernel and involves a roottask that enables the execution of unmodified Linux binaries through an OS personality/Linux emulation. The runtime system covers several interesting aspects of OS development, such as interaction with a kernel, system call emulation, and starting programs from ELF files.

phil-opp/blog_os

(Section written by @phil-opp)

We merged a new Korean translation of first post of Writing an OS in Rust blog this month. Thanks a lot to @JOE1994 for creating this translation and @QuqqU for reviewing it!

We also received lots of smaller fixes, by @MaxDesiatov, @alaincao, @Programatic, @ruhuang2001, @Hofer-Julian, @SilensAngelusNex, and @julien-me. Thank you all for your contributions!

Unfortunately I didn't have time to work on the new version of the bootloader crate for the upcoming third edition of the blog this month. However, there was some surprising development on the Rust side that should help us with the new build system: @bstrie created a Major Change Proposal to promote the x86_64-unknown-none target to Tier 2. This is a bare-metal target that should be compatible with our kernel, so we might not need -Zbuild-std anymore in the future. Instead, we could download a precompiled version of the core/alloc crates via rustup target add. The great news is that the proposal was already accepted and the corresponding implementation PR is ready for review too!

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