Aeneas (pronunced [Ay-nay-as]) is a verification toolchain for Rust programs. It relies on a translation from Rusts’s MIR
internal language to a pure lamdba calculus. It is intended to be used in combination with
Charon, which compiles Rust programs to an intermediate
representation called LLBC. It currently has backends for F*,
Coq, HOL4 and LEAN.
If you want to contribute or ask questions, we strongly encourage you to join the Zulip.
src: the OCaml sources. Note that we rely on Dune
to build the project.
backends: standard libraries for the existing backends (definitions for
arithmetic operations, for standard collections like vectors, theorems, tactics, etc.)
tests: files generated by applying Aeneas on some of the test files of Charon,
completed with hand-written files (proof scripts, mostly).
Moreover, Aeneas uses the Charon project and library.
For Aeneas to work, ./charon must contain a clone of the Charon
repository, at the commit specified in ./charon-pin. The easiest way to set this up is to call
make setup-charon
(this uses either rustup or nix to build Charon, depending on which one is installed).
In case of version mismatch, you will be instructed to update Charon.
If you’re also developing on Charon, you can instead set up ./charon to be a symlink to your local version:
ln -s PATH_TO_CHARON_REPO charon. In this case, the scripts will not check that your Charon
installation is on a compatible commit. When you pull a new version of Aeneas, you will occasionally
need to update your Charon repository so that Aeneas builds and runs correctly.
Finally, building the project simply requires running make in the top
directory.
You can also use make test and make verify to run the tests, and check
the generated files. As make test will run tests which use the Charon tests,
you will need to regenerate the .llbc files. To do this, run make setup-charon before make test. Alternatively, call REGEN_LLBC=1 make test-... to regenerate only the needed files.
If you run make, you will generate a documentation accessible from [doc.html]!(./doc.html).
Additionally, a tutorial for using the Aeneas Lean backend is available [here]!(./tests/lean/Tutorial/); the original Rust file can be found [here]!(./tests/src/tutorial/src/lib.rs).
It requires a working installation of Lean.
You should first generate the serialized .llbc file by calling Charon from inside
(similarly to cargo) the crate you want to translate. Important: you should call
Charon with the following option:
Terminal window
charoncargo--preset=aeneas
The Aeneas binary is in bin; you can run: ./bin/aeneas -backend {fstar|coq|lean|hol4} [OPTIONS] LLBC_FILE,
where LLBC_FILE is an .llbc file generated by Charon.
Aeneas provides a lot of flags and options to tweak its behaviour: you can use --help
to display a detailed documentation.
[!IMPORTANT]
There are additional steps for the Lean backend. Files generated by the Lean backend
import the Aeneas package from Aeneas. To use those files in Lean:
Create a new Lean package using lake new.
Overwrite the lean-toolchain with the one inside ./backends/lean.
If you don’t have Aeneas cloned locally, you can specify the dependency using
the GitHub repository. If you opt for this method, consider adding a specific
commit hash to ensure that future updates do not break your project.
Aeneas currently functionalizes a subset of safe Rust, and we are in the process
of extending the functional model with reasoning based on separation logic to
support unsafe code and concurrent code.
We currently have the following limitations on the safe subset, that we plan to address
one by one:
loops: return inside nested loops, or break/continue to outer loops
are not supported yet (e.g., 'a : loop { loop { break 'a; } } ). This is a
technical limitation, not a fundamental issue, that we plan to address in the
near future and that we can prioritize depending on our users’ needs.
no nested borrows in function signatures: ongoing work, coming very soon, starting
with nested shared borrows.
no functions pointers/closures: ongoing work. We currently have support for traits
and will have support for function pointers and closures soon.
The following limitations will be lifted by the ongoing work on separation logic:
unsafe code
interior mutability
concurrency
Feel free to contact the team or join the Zulip if you need some specific features or if
you’re interested iun contributing.
We currently support F*, Coq, HOL4 and Lean. We would be interested in having an Isabelle
backend. Our most mature backends are Lean and HOL4, for which we have in particular
support for partial functions and extrinsic proofs of termination (see
./backends/lean/Base/Diverge/Elab.lean and ./backends/hol4/divDefLib.sig for instance)
and tactics specialized for monadic programs (see
./backends/lean/Base/Progress/Progress.lean and ./backends/hol4/primitivesLib.sml).
Adding Models of Rust Definitions to the Lean Backend
When translating a crate which requires external definitions (i.e., definitions
coming from external dependencies such as the Rust standard library), we advise using the
-split-files option. With -split-files, Aeneas will generate template files listing
the missing definitions for which the user will have to provide hand-written models.
For instance, it can lead to the following structure in Lean:
FunsExternal.lean // hand-written file maintained by the user (not overwritten during the translation)
Funs.lean // automatically generated file which imports FunsExternal.lean
Rather than adding models to the TypesExternal.lean, FunsExternal.lean, etc. files it
is possible to port the models to the Aeneas standard library, so that all client projects
can benefit from them. When doing so, it is important to make Aeneas aware of those new
models. This is done by annotating the Lean models with the appropriate attribute
(rust_type, rust_const, rust_fun, rust_trait or rust_trait_impl) then running the
command make extract-lean-builtins. This command will build the Lean library for Aeneas,
collect those definitions, and regenerate the src/extract/ExtractBuiltinLean.ml file,
which provides information about those models.
Note that Aeneas automatically introduces the rust_type, etc. attributes when
listing the missing external definitions in the TypesExternal.lean, etc. files:
the user just needs to copy/paste those definitions and fill in the holes. Also note that
those attributes have quite a few options to tweak the behavior of the extraction: we
invite the users to read their docstrings for more information.