rustBoot 
rustBoot is a standalone bootloader, written entirely in Rust, designed to run on anything from a microcontroller to a system on chip. It can be used to boot into bare-metal firmware or Linux.
Why build another bootloader?
So, how does rustBoot help?
rustBoot aims to offer an OS and micro-architecture agnostic (i.e. highly portable) secure bootloader which is standards-based, easy to integrate (into existing embedded software projects) and eliminates duplication of work for every project.
Goals and objectives:
A secure-bootloader is a complex project, despite its small size. The effort involved in developing/integrating one can be overwhelming. (key-management, code-safety, trust-chains, reliable back-ups etc.)
rustBoot's purpose is to help simplify the entire process. Some of its primary goals are
- Compliance with the IETF-SUIT standard i.e.
- one of its requirements is to not require the use of specific protocols or data link interfaces to transfer
updatesto a device. - transferring an
updateshould be delegated to the firmware/OS to avoidsize or computationallimitations (along with a drastic reduction in attack surface).
- one of its requirements is to not require the use of specific protocols or data link interfaces to transfer
- Reliable updates:
- rustBoot will perform swap operations via the
A/B or multi-slot partitioning methodto replace currently active firmware with a newly received update and at the same time store a back-up copy of it in a (passive) secondary partition.
- rustBoot will perform swap operations via the
- Predictablility over Performance:
- one of rustBoot's core design objectives is to keep it simple and avoid complexity. So, there will be little to no application of meta or async programming constructs.
- not that we need the extra performance, rustBoot can already hit sub-second secure boot-times as we've stripped it down to the bare-essentials.
- Zero-dynamic memory allocation:
- to make it highly portable, apart from its modular design, rustBoot relies on a zero dymnamic memory allocation architecture i.e. no heap required.
- Memory safety & type-state programming:
- the entire bootloader is written in rust's safe-fragment with a limited set of well-defined api(s) for unsafe HW access.
- as a consequence, it makes rustBoot immune to a whole host of memory safety bugs. ex: things like parsing image-headers (i.e. container-formats) in rustBoot is much safer.
- rustBoot takes advantage of rust's powerful type-system to make
invalid boot-states unrepresentable at compile timeand along with constructs such as sealed states, global singletons, it improves the overall security of the entire code-base.
- Formal guarantees: an aspirational goal at this point but we think its do-able
- property-based testing via symbolic execution: to formally verify rustBoot's parser.
- deductive verification: for critical sections of code (ex: swapping contents of boot and update partitions).
Project layout:
This project's folder structure is divided into 2 workspaces.
- core-bootloader:
- resides in its own folder called
rustBoot
- resides in its own folder called
- hardware abstraction layer
- the boards folder contains all hardware-specific code. It houses other neccessary folders
- rustBoot-hal: contains flash-hal (read/write/erase) impls for a specific board.
- rust-update: this crate/folder contains all of the board-agnostic A/B update logic.
- test_firmware: contains test firmware (i.e. blinky-led firmware) for the boot and update partitions for a specific board.
- test_impls: contains a test implementation of the bootoloader for a specific board.
- the boards folder contains all hardware-specific code. It houses other neccessary folders
Additionally, the project includes a folder called xtask to simplify the build-sign-flash process.
For detailed instructions on usage, you can take a look at the readme page for each board under - boards/test_impls/{board-name}
In short, you'll need 3 things:
- flash-api: implement the
FlashInterfacetrait for your board (abstracts out the necessary HW-specific flash operations such as writing/readin/erasing).- Note: I'm still contemplating switching to something like embedded-storage. Please feel free to chime-in if you have suggestions here.
- memory-layout: choose a suitable memory layout based on your board's micro-architecture and make.
- firmware-api: use the methods from the
UpdateInterfacetrait in your firmware to trigger and confirm firmware updates. (note - downloading and installing the update is to be handled by whatever firmware/OS you're running).
rustBoot's high-level design
Features:
- A/B or multi-slot partitioning of the flash device.
- elliptic curve cryptography for integrity and authenticity verification using RustCrypto
- a tiny hardware abstraction layer for non-volatile memory (i.e. flash) programming.
- anti-rollback protection via version numbering.
- a fully memory safe core-bootloader implementation with safe parsers and flash-update logic.
- power-interruptible firmware updates along with the assurance of fall-back availability.
Future roadmap:
- switch to a
rust-based KMIfor manifest-header creation, key-generation and firmware signing to improve scalability and security (currently the lone available example useswolfboot'spython implementation for this). - support for external flash devices and serial/console logging interfaces.
- support for ARM TrustZone-M and A and certified secure hardware elements -
microchip ATECC608a, NXP SE050, STSAFE-100 - support for a highly secure and efficient
firmware transportmethod over end-end mutually authenticated and encrypted channels via ockam-networking-libraries. - many more examples with
test implementationsfor a variety of boards.
Documentation:
[todo!] - rustBoot-book goes here.
Acknowledgment:
rustBoot's design was influenced by wolfBoot. It borrows wolfBoot's reliable-update design idea and builds on it with rust's memory safety guarantees, safer parsing libraries, compile-time state-transition checks and easy integration with crates (such as boards, HALs drivers etc.) developed by the embedded-rust community.
Support:
For questions, issues, feature requests, and other changes, please file an issue in the github project.
License:
rustBoot is licensed under
- MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)
Contributing:
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the MIT license, shall be dual licensed as above, without any additional terms or conditions.
314 Dec 18, 2022
190 Dec 21, 2022
56 Dec 15, 2022
25 Dec 21, 2022
69 Dec 6, 2022
34 Sep 13, 2022
16 Dec 1, 2022
79 Dec 5, 2022
5 Oct 12, 2022
10 Aug 16, 2022
10 Jun 17, 2022
4 Aug 6, 2022
5 Jun 21, 2022
5 Sep 17, 2021
173 Dec 17, 2022
3 Oct 23, 2022
2 Nov 8, 2021
1 Nov 15, 2021