Hypervisor 101 in Rust: a fuzzing hypervisor and the course that teaches it

What the repository actually is

This repository holds the materials of the Hypervisor 101 in Rust class, a one-day course, designed to quickly teach hardware-assisted virtualization technology and its application for high-performance fuzzing on Intel and AMD processors.

The specific origin is given. The materials come from the class held at Global Cybersecurity Camp 2023 in Singapore, and the repository contains a fuzzing hypervisor for UEFI on Intel and AMD processors, lecture and hands-on exercise materials, and sample corpus and target files.

That combination is what makes the repository more than slides. A course about virtualization that includes a hypervisor you can compile and run, with a corpus to fuzz and targets to fuzz, gives you something to read and something to execute. The course itself is published as a website at the project's GitHub Pages site.

The top level of the repository shows the three parts. There is a `course/` directory with the class materials, a `hypervisor/` directory holding the source code along with a detailed description of the fuzzing hypervisor, and a `BUILDING.md` for building and running the hypervisor with the sample files under `tests/`.

The project is MIT licensed, the primary language is Rust, the default branch is main, and the last push was on 2026-10-11. There are no GitHub releases, so the repository is a snapshot of a course rather than a published tool with a version history.

The course format, and the honest warning about it

There is a paragraph in the README that is unusual to find and worth quoting in full, because it tells you what kind of material this is before you start.

The class materials are designed for an interactive classroom setting and are less effective for self-learning due to light explanations. The author decided to publish it because it would still be useful to some. And if you are interested in the interactive class with the author, the README points at the schedule of the next public class at System Programming Lab.

That is a genuinely useful thing to be told up front. Course notes written for a room where the instructor can fill in the gaps are not a substitute for the course, and a lot of projects that publish their training material do not say so. Here the author says the explanations are light, says the material is less effective alone, and then points at where to get the real thing.

So the practical way to use this repository is as the code and exercises from a class, with the prose as a map of what was covered. The `hypervisor/` directory is described as holding not only the source but a detailed description of the fuzzing hypervisor, which suggests that is where the self-serve value is concentrated.

The acknowledgement section is also informative about the lineage. Andrew Burkett and Rich Seymour are thanked for mentoring the author about Rust, Karsten König and Amir Bazine for encouraging the look into using hypervisors for fuzzing, and Brandon Falk for his inspirational work on Falkvisor, which is the better known predecessor in this space.

The supported platforms, and the x64 assumption that is not there

The platform support is split in two, host and target, and the split is the right way to think about a hypervisor project because the two sides have different constraints.

The host, which is the class and development environment, supports Windows with WSL, macOS and Ubuntu. It also supports Apple Silicon based macOS, ARM64 based Windows and ARM64 based Ubuntu, and the README states that no x64 system is required.

That last line is the interesting one for a virtualization course, because hypervisors are usually associated with the x86 VT-x and AMD-V extensions, and a reader arriving with that assumption will expect to need an Intel or AMD machine. The supported platform list says otherwise, and the reason is in the target side.

The test, or target, environment is hardware. Bochs is listed, as are VMware Fusion or Workstation Pro if the host has Intel or AMD processors, and select bare metal models. And all of these run with UEFI.

So the architecture of the exercise is a hypervisor that runs a UEFI environment, and the UEFI environment is where the fuzzing happens. Running the target under Bochs or a virtual machine gives you a repeatable, disposable environment for fuzzing firmware, and the bare metal models are there for when you need the real thing.

The practical consequence for a learner is that a machine without Intel or AMD extensions can still run the course, as long as it can run the host side, because the target is emulated. That is a much lower barrier to entry than owning a machine with the right extensions.

The workspace, and the lint policy as a quality signal

The Rust workspace is small, with two members, `hypervisor` and `xtask`, and a resolver of version 2. The `xtask` member is the conventional Rust pattern for build automation, a binary in the workspace that other tasks can invoke.

The workspace metadata is where the real content is, because the lint configuration is extensive and it tells you what the project considers unacceptable.

[workspace.lints.rust]
future_incompatible = "warn"
let_underscore = "warn"
nonstandard_style = "warn"
rust_2018_compatibility = "warn"
rust_2018_idioms = "warn"
rust_2021_compatibility = "warn"
rust_2024_compatibility = "warn"
unused = "warn"

Those are the lint groups. The list continues with the individual lints that are not enabled by default or covered by a group, and it is an instructive list for a systems project: `macro_use_extern_crate`, `meta_variable_misuse`, `missing_abi`, `missing_copy_implementations`, `missing_debug_implementations`, `missing_docs`, `non_ascii_idents`, `noop_method_call`, `single_use_lifetimes`, `trivial_numeric_casts`, `unreachable_pub`, `unsafe_op_in_unsafe_fn`, `unused_crate_dependencies`, `unused_import_braces`, `unused_lifetimes`, `unused_qualifications` and `unused_results`.

Several of those are exactly right for this kind of project. `missing_abi` matters for code that crosses the FFI boundary, `unsafe_op_in_unsafe_fn` matters for code that manipulates hardware, `unreachable_pub` keeps the public surface of a `no-std` crate honest, and `unused_results` catches the silently ignored return value that a fuzzing harness would care about.

[workspace.lints.clippy]
pedantic = "warn"
cargo = "warn"

The clippy configuration enables the pedantic group and the cargo group, and the rustdoc section enables `missing_crate_level_docs`, `private_doc_tests` and `invalid_html_tags`.

The no-std categorisation and what the toolchain files say

The workspace package metadata carries a few details that describe the project more precisely than the README does.

The version is 0.1.0, the edition is 2021, and the description is the research fuzzing hypervisor. The keywords are fuzzing, UEFI and hypervisor, and the categories are `development-tools::testing` and `no-std`.

That `no-std` category is the informative one. A hypervisor that runs as a host and loads a guest environment is the kind of program where the standard library may not be available, or where the boot environment expects a specific memory layout, and the classification tells you the code is written with that constraint in mind.

The repository also carries the toolchain files. There is a `rust-toolchain.toml`, which pins the compiler version so that everyone building the project uses the same one, a `rustfmt.toml` for formatting configuration, and a `.cargo/` directory for Cargo settings such as linker flags or target configuration that a hypervisor build usually needs.

The project is by Satoshi Tanda, and the licence is MIT. The `Cargo.lock` is committed, which for a repository that builds a hypervisor is the right call, because the build has to be reproducible for a course.

The `tests/` directory holds the sample corpus and target files, and `BUILDING.md` covers building and running the hypervisor with them, so the repository is arranged as a complete, runnable workshop rather than a set of fragments.

Where Hypervisor 101 in Rust is the wrong thing to reach for

The first wrong case is a self-learner who wants a complete tutorial. The README says the material has light explanations and is less effective for self-learning, and it points at the next public class with the author. A learner who cannot get that will find a lot of code and not much explanation of why the code is shaped that way, and the `hypervisor/` description is the part that carries the argument.

The second is someone looking for a production fuzzing hypervisor. The version is 0.1.0, the description calls it a research fuzzing hypervisor, and it was built as course material for a single day. Nothing in the repository presents it as a maintained tool, and there are no releases.

The third is a team that needs UEFI fuzzing at scale on modern hardware and expects a drop-in harness. What is here is a corpus and a set of targets from 2023, with a documented way to build and run them, not a maintained fuzzing infrastructure with continuous integration over a growing corpus.

The fourth is a developer on macOS with Apple silicon who expects the same experience as on x86. The README says no x64 system is required for the host, which is a genuine convenience, but the VMware option in the target list is explicitly conditional on the host having Intel or AMD processors, so the test environment on an ARM Mac is the emulated one.

The fifth is a project that wants a general-purpose hypervisor. The word in the description is specific, and the entire design, the UEFI target, the corpus and the exercises, is oriented at one job.

What the repository gives you is a rare thing: a working, buildable hypervisor that fuzzes firmware, with the teaching material that explains it, in a language whose lint configuration shows how careful the author is about the parts that touch hardware.

Editorial conclusion

Hypervisor 101 in Rust suits a developer who wants to learn hardware-assisted virtualization by reading and running working code, or who wants a research-grade fuzzing hypervisor for UEFI to build on, and who is prepared to follow a course designed for a classroom. It does not suit a self-learner who needs a polished tutorial, because the README says the material has light explanations and is less effective without an instructor. Before starting, read `BUILDING.md` for the build and run instructions, confirm your host is one of the listed platforms, and check whether the test environment you have, Bochs, VMware on Intel or AMD, or a bare metal model, matches what the exercises expect.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. tandasat/Hypervisor-101-in-Rust on GitHub