Transparent pointer safety: Rust to Lua to OS Components
Lead Research Organisation:
University of Kent
Department Name: Sch of Computing
Abstract
The Digital Security by Design (DSbD) challenge builds a software ecosystem atop Morello, an ARM processor extended with capabilities. Capabilities combine a pointer to memory with permissions and bounds information that Morello processors use to enforce memory safety at run time, halting programs in error when safety is violated. This project develops a vertical stack in the DSbD ecosystem in three parts: a Rust compiler, an implementation of Lua in Rust, and integration of this Lua interpreter into FreeBSD, replacing a core component of the FreeBSD bootloader with software built in DSbD tech.
Rust maximises the guarantees provided by capabilities with a memory-saftey-first design, and Lua is a high-level language used for joining systems components together, with the details of memory management safely automated. We will support this vertical with a theoretical development. In our Lua interpreter, we anticipate allocation and reclamation requiring unsafe Rust code, and we will verify that these components cannot produce capability errors. We will raise this to memory safety of the whole interpreter by proving that safe Rust code should never exhibit capability errors.
Rust is a systems language from academia with substantial industrial use. Rust is proposed as the second language of the Linux kernel after C, with support from the creator of Linux. Rust excludes the vast majority of pointer misuse - ensuring memory safety - with a static (compile time) check, and a fall-back run-time check for complex cases. Our Rust compiler port will, as a consequence, port all safe Rust code to Morello, and typical Rust programmers may target Morello with no change to their working practices.
Sometimes a Rust programmer must subvert the type system, e.g. to interface with hardware or C OS components. These regions of code must be declared as unsafe, enabling a limited set of additional operations that the compiler cannot check, forgoing the automatic guarantees afforded to safe code. This segregation of unsafe code offers a model for programming capability hardware: Rust ensures safe code cannot exhibit capability errors, and unsafe code highlights regions where verification tools can be targeted.
Lua is a safe managed language that is used to set up the FreeBSD bootloader. We will port the Lua interpreter to Rust, integrate it into FreeBSD and establish that the garbage collector cannot capability fault.
We offer Rust, memory-safe Lua and OS components, together with a theoretical case study that demonstrates scalable security reasoning enabled by the new capability features.
Rust maximises the guarantees provided by capabilities with a memory-saftey-first design, and Lua is a high-level language used for joining systems components together, with the details of memory management safely automated. We will support this vertical with a theoretical development. In our Lua interpreter, we anticipate allocation and reclamation requiring unsafe Rust code, and we will verify that these components cannot produce capability errors. We will raise this to memory safety of the whole interpreter by proving that safe Rust code should never exhibit capability errors.
Rust is a systems language from academia with substantial industrial use. Rust is proposed as the second language of the Linux kernel after C, with support from the creator of Linux. Rust excludes the vast majority of pointer misuse - ensuring memory safety - with a static (compile time) check, and a fall-back run-time check for complex cases. Our Rust compiler port will, as a consequence, port all safe Rust code to Morello, and typical Rust programmers may target Morello with no change to their working practices.
Sometimes a Rust programmer must subvert the type system, e.g. to interface with hardware or C OS components. These regions of code must be declared as unsafe, enabling a limited set of additional operations that the compiler cannot check, forgoing the automatic guarantees afforded to safe code. This segregation of unsafe code offers a model for programming capability hardware: Rust ensures safe code cannot exhibit capability errors, and unsafe code highlights regions where verification tools can be targeted.
Lua is a safe managed language that is used to set up the FreeBSD bootloader. We will port the Lua interpreter to Rust, integrate it into FreeBSD and establish that the garbage collector cannot capability fault.
We offer Rust, memory-safe Lua and OS components, together with a theoretical case study that demonstrates scalable security reasoning enabled by the new capability features.
Organisations
| Description | The Digital Security by Design (DSbD) challenge builds a software ecosystem above Morello, an ARM processor extended with capabilities. Capabilities combine a pointer to memory with permissions and bounds information that Morello processors use to enforce memory safety at run time, halting programs in error when safety is violated. This project extends from the previous DSbD project CapC, continuing the strands of that project. In the first strand, we developed a Rust compiler for the Morello platform. Rust is a systems language whose type system ensures memory safety properties similar to those provided by the Morello architecture. We pursued an implementation of this compiler that was more complete and usable than would be typical of an academic team. Indeed our compiler has been recognised by Google: they have provided follow-on support through a philanthropic donation to continue development of the complier and to port it to CHERI RISC-V platforms. DASA also provided support for a variant of the compiler targeting embedded platforms. The second strand of work is an extremely hard-fought step forward on the 'thin-air' problem. Compiled concurrent languages like C++ and Rust admit relaxed behaviours where concurrent accesses on multiple threads allow highly unintuitive concurrent executions. Some of these behaviours are a reasonable consequence of the combination of compiler optimisation and the underlying hardware behaviours, and some are not. Specifications of programming languages like C++ are currently broken: they allow too much behaviour and make it impossible to reason about code. Refining the specification to fix this without ruling out optimisations that are done in practice is extremely difficult. Indeed this problem has been open from at least 2008. Over the term of this grant we solved this problem, with publication of our solution secured in 2025. This effort took place in conversation with the international standards organisation, who are primed to consider our solution. |
| Exploitation Route | We have a philanthropic gift from Google to continue development of the Rust complier. We are members of the CHERI Alliance, and we will seek adoption of the Rust compiler there. We are attending ISO meetings to promote our solution to the longstanding thin-air problem. We will pursue changes in the Rust specification as mainstream CHERI hardware becomes available. |
| Sectors | Aerospace Defence and Marine Digital/Communication/Information Technologies (including Software) Security and Diplomacy |
| URL | https://www.cs.kent.ac.uk/people/staff/mjb211/rust/index.htm |
| Description | We have ported the Rust complier to the Morello architecture. We are members of the CHERI Alliance, and we will seek adoption of the Rust compiler there. |
| First Year Of Impact | 2024 |
| Sector | Aerospace, Defence and Marine,Digital/Communication/Information Technologies (including Software),Security and Diplomacy |
| Impact Types | Economic |
| Title | Rust for Morello |
| Description | This is a fork of Rust which adds experimental support for Morello. Morello is an experimental processor architecture that adds CHERI protections to ARM (AArch64). This repository contains the compiler, standard library, and documentation. As of time of writing (2024-01-12), this compiler should be fully functional, but has bugs and contains some dirty hacks we haven't fixed yet. Expect things to break. This fork is not built or maintained by the Rust project proper, please don't complain to them if you have issues with it, they will not be able to help. We can be contacted via email or GitHub issues but don't really have the capacity to offer much support. |
| Type Of Technology | Software |
| Year Produced | 2023 |
| Open Source License? | Yes |
| Impact | We have had correspondence with many other projects in the Digital Security by Design project explaining that they are trialing, using and inspecting the code of our Rust compiler including Oxford, Cambridge, Embecosm, Google and defence companies. The Defence and Security Accelerator (DASA) funded us to extend our compiler to bare metal platforms like microcontrollers, enabling the compiler to be used in the embedded setting. Building the compiler led us to make a Rust pre-RFC: a bid to change the language definition to support ARM's prototype Morello architecture. |
| URL | https://www.cs.kent.ac.uk/people/staff/mjb211/rust/index.htm |
| Title | Rust for Morello: Always-on Memory Safety, Even in Unsafe Code |
| Description | This artefact is a virtual machine setup with a build of our Rust compiler targetting purecap Morello, and built copy of the QEMU Morello emulator running CHERIBSD. Username: ecoop23 Password: ecoop23 |
| Type Of Technology | Software |
| Year Produced | 2022 |
| Open Source License? | Yes |
| URL | https://zenodo.org/record/7422056 |
| Title | Rust for Morello: Always-on Memory Safety, Even in Unsafe Code |
| Description | This artefact is a virtual machine setup with a build of our Rust compiler targetting purecap Morello, and built copy of the QEMU Morello emulator running CHERIBSD. Username: ecoop23 Password: ecoop23 |
| Type Of Technology | Software |
| Year Produced | 2022 |
| Open Source License? | Yes |
| URL | https://zenodo.org/record/7422057 |
| Description | Rust pre-RFC |
| Form Of Engagement Activity | A formal working group, expert panel or dialogue |
| Part Of Official Scheme? | No |
| Geographic Reach | International |
| Primary Audience | Industry/Business |
| Results and Impact | Our Rust compiler for ARMs memory-safe prototype Morello architecture requires changing the Rust specification to remove assumptions about the size of pointers. We engaged with the process for changing the specification by writing a 'pre-RFC' (a suggested Request For Comments, the first step in changing the language). This led to discussion within the community that resolved the opinions of key language maintainers on the point we raised. There is much support for our approach, but our change has not been progressed because no commercially available Morello hardware exists yet. That is changing, and we have gathered and presented stronger evidence that our change is good. This attempt at impact is still in play and we will push again when hardware becomes available in 2024. |
| Year(s) Of Engagement Activity | 2023,2024 |
| URL | https://www.cs.kent.ac.uk/people/staff/mjb211/rust/usize-pre-rfc.htm |
