Verified RISC-V Bootloader Integrity Project

ISEF Category: Systems Software

Subcategory: Languages and Operating Systems  ·  Difficulty: Advanced  ·  Setup: University Lab  ·  Time: Full Year

The Hook

A bootloader is the first code your computer trusts. If that tiny slice breaks, everything after it can be fake. You can turn that trust problem into a research project by proving that a RISC-V bootloader still behaves correctly, even when you simulate tampering.

What Is It?

A bootloader is the program that starts an operating system. Think of it like the first link in a relay race. If the first runner slips, the whole race goes off track. In this project, you build a bootloader for a RISC-V system and prove, with formal methods, that it meets specific safety rules before it runs.

Formal verification means you use math to check that code follows a spec. F* and Coq are proof systems that help you write those specs and prove them. Extraction to C means the proof-backed code can become real C code that runs in a target environment, such as QEMU, which is a computer emulator. Reproducible-build attestations add another layer, because they let you show that the same source code leads to the same build output, which helps detect hidden changes.

Why This Is a Good Topic

This topic is a strong science fair project because you can test a clear claim, whether proof-backed boot code stays correct under controlled tampering scenarios. You also connect to a real problem, trusted startup code for operating systems and secure devices. Even if you do not build a full production system, you can still study a narrow part of the problem, such as invariant checking, build reproducibility, or fault injection at boot time. That makes the project deep enough for original research and structured enough for a student to manage with guidance.

Research Questions

• How does simulated tampering during boot change the verified bootloader's ability to preserve integrity checks?
• What is the effect of different proof scopes, such as memory safety versus full boot-state correctness, on the number of failures caught?
• Does reproducible-build metadata help detect hidden build drift across repeated QEMU builds?
• To what extent does proof extraction to C preserve the behavior stated in the formal specification?
• Which tampering patterns, such as altered memory, changed binaries, or modified boot flags, are most likely to bypass weaker checks?
• How does the bootloader's verification time change when you add more proof obligations?

Basic Materials

• Laptop or desktop computer with enough RAM to run QEMU and proof tools.
• RISC-V QEMU target image or emulator setup.
• F* or Coq development environment.
• C compiler toolchain, such as GCC or Clang.
• Git for version control.
• Text editor or IDE with syntax highlighting.
• Checksum tool, such as sha256sum.
• Spreadsheet software for tracking test runs and outcomes.

Advanced Materials

• University workstation or lab computer with strong CPU and memory.
• QEMU with a RISC-V firmware and boot image setup.
• F* or Coq, plus extraction toolchain.
• SMT solver support, such as Z3, if needed by the proof system.
• Binary analysis tools, such as objdump and readelf.
• Reproducible-build tooling for environment capture and artifact comparison.
• Scriptable test harness for boot tampering experiments.
• Versioned storage for proof artifacts, build logs, and hashes.

Software & Tools

• QEMU: Emulates a RISC-V target so you can test boot behavior without special hardware.
• Coq: Lets you write machine-checked proofs about boot code and invariants.
• F*: Helps you specify security properties and extract verified code to C.
• Git: Tracks proof files, source code, and build changes across experiments.
• Python: Automates repeated builds, log parsing, and result comparison.

Experiment Steps

1. Define the boot property you want to prove, such as code integrity, state consistency, or failure handling.
2. Choose one boot path to verify first, then narrow the scope to a tractable subsystem.
3. Map the formal specification to the extracted C code and the QEMU target behavior.
4. Design a tampering model that changes one boot input at a time, so you can isolate failure modes.
5. Plan a reproducible-build workflow that records hashes, build inputs, and proof artifacts.
6. Set up a comparison method that links proof results, build outputs, and boot outcomes in a single dataset.

Common Pitfalls

• Trying to prove the whole boot chain at once, which usually makes the project too large to finish.
• Confusing a passing QEMU run with a proven property, which mixes testing with formal verification.
• Letting the proof specification drift away from the extracted C behavior, which breaks the link between math and code.
• Changing build environments between runs, which makes reproducible-build results hard to trust.
• Using tampering tests that are too broad or random, which hides which integrity check actually failed.

What Makes This Competitive

A stronger project goes beyond proving that code compiles and runs. You would compare multiple proof scopes, test multiple tampering models, and measure how each design changes the bootloader's trust guarantees. You could also study where reproducible builds and formal proofs agree, and where they still leave gaps. That kind of careful analysis looks much more like original systems research than a simple demo.

Project Variations

• Verify only the earliest boot stage, then compare its guarantees against a larger multi-stage chain.
• Test whether two different proof tools, F* and Coq, produce different assurance levels for the same boot property.
• Compare behavior under reproducible builds with and without injected source or environment changes.

Learn More

• MIT OpenCourseWare: Search for courses on operating systems, programming languages, and formal methods to learn the theory behind verified systems.
• Coq Documentation: Read the official manual and standard library docs for proof development and extraction details.
• F Project Resources: Find tutorials, papers, and documentation on the official F site.
• RISC-V Specifications: Use the official RISC-V documentation to understand the target architecture and boot assumptions.
• QEMU Documentation: Read the emulator manual to learn how to run and inspect a RISC-V target.
• PubMed: Search for review articles on software verification methods if you want a broader research context, even though most technical sources will come from computer science venues.