wasmtime
wasmtime copied to clipboard
bytecodealliance
Initial forward-edge CFI implementation
This pull request is meant to illustrate the RFC proposal to improve control flow integrity for compiled WebAssembly code by using the Branch Target Identification (BTI) extension to the Arm instruction set architecture (bytecodealliance/rfcs#17), so it is not ready to be merged yet.
P.S. The RFC proposal has now been merged, and the changes in this PR have been updated the reflect the final version of the proposal, so they are now ready.
Subscribe to Label Action
cc @peterhuene
Thus the following users have been cc'd because of the following labels:
- peterhuene: wasmtime:api
To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Subscribe to Label Action
cc @fitzgen
Thus the following users have been cc'd because of the following labels:
- fitzgen: fuzzing
To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.
Note that the region crate lacks support for BTI (reported in darfink/region-rs#21), so I have used a work-around - a direct call to libc::mprotect().
@alexcrichton I wanted to finish with the pointer authentication PR before coming back to this one:
* If a module is compiled with bti support and loaded into an engine that has bti support disabled, that's fine right? (since everything is a nop)
Yes, that is correct; we just have to make sure that we do not request the PROT_BTI memory protection mode from the kernel, since the system call is going to fail.
* If a module is not compiled with bti support, but is loaded into an engine with bti support, that's bad right? (in that none of the branches are protected but the page permissions say that all branches need protection?)
Yes, assuming that the engine applies PROT_BTI unconditionally to all executable memory pages.
The current implementation supports the full flexibility the BTI extension enables, so we have to decouple the following:
- whether the user passed
--cranelift-enable use_btion the Wasmtime command line - whether the environment (i.e. CPU and OS) supports BTI
- whether the module that the engine is trying to load has been compiled to use BTI instructions; also, if I am not mistaken, the engine could be trying to load several modules, which might not necessarily have been compiled with the same settings
We should add a target aarch64 use_bti to runtests/br_table.clif, we now use the cranelift-jit to run runtests so we can also test the cranelift-jit portion of this PR.
We don't yet support call's, but that's something I'm addressing in #4667, and can add some bti runtests there as well.
Ah sorry ok I see why this can't be an Engine-level thing. If that's the case though instead of ferrying a separate bool through the system could this get attached to CompiledModuleInfo somewhere internally?
@cfallin I think that I have resolved all of @alexcrichton's comments that are related to Wasmtime, so do you have any feedback on the Cranelift side of things?