forked from bytecodealliance/wasmtime
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Provenance preparation for Pulley (bytecodealliance#10043)
* Provenance preparation for Pulley This commit is an internal refactoring of Wasmtime's runtime to prepare to execute Pulley in MIRI. Currently today this is not possible because Pulley does not properly respect either strict or permissive provenance models. The goal of this refactoring is to enable fixing this in a future commit that doesn't touch everything in the codebase. Instead everything is touched here in this commit. The basic problem with Pulley is that it is incompatible with the strict provenance model of Rust which means that we'll be using "exposed provenance" APIs to satisfy Rust's soundness requirements. In this model we must explicitly call `ptr.expose_provenance()` on any pointers which are exposed to compiled code. Arguably we should also be already doing this for natively-compiled code but I am not certain about how strictly this is required. Currently in Wasmtime today we call `ptr.expose_provenance()` nowhere. It also turns out, though, that we share quite a few pointers in quite a few places with compiled code. This creates a bit of a problem! The solution settled on in this commit looks like: * A new marker trait, `VmSafe`, is introduced. This trait is used to represent "safe to share with compiled code" types and enumerates some properties such as defined ABIs, primitives wrappers match primitive ABIs, and notably "does not contain a pointer". * A new type, `VmPtr<T>`, is added to represent pointers shared with compiled code. Internally for now this is just `SendSyncPtr<T>` but in the future it will be `usize`. By using `SendSyncPtr<T>` it shouldn't actually really change anything today other than requiring a lot of refactoring to get the types to line up. * The core `vmctx_plus_offset*` methods are updated to require `T: VmSafe`. Previously they allowed any `T` which is relatively dangerous to store any possible Rust type in Cranelift-accessible areas. These three fundamental changes were introduced in this commit. All further changes were refactoring necessary to get everything working after these changes. For example many types in `vmcontext.rs`, such as `VMFuncRef`, have changed to using `VmPtr<T>` instead of `NonNull<T>` or `*mut T`. This is a pretty expansive change which resulted in touching a lot of places. One premise of `VmPtr<T>` is that it's non-null. This was an additional refactoring that updated a lot of places where previously `*mut T` was used and now either `VmPtr<T>` or `NonNull<T>` is used. In the end the intention is that `VmPtr<T>` is used whenever pointers are store in memory that can be accessed from Cranelift. When operating inside of the runtime `NonNull<T>` or `SendSyncPtr<T>` is preferred instead. As a final note, no provenance changes have actually happened yet. For example this doesn't fix Pulley in MIRI. What it does enable, though, is that the future commit to fix Pulley in MIRI will be much smaller with this having already landed. * Run the full test suite in PR CI prtest:full * Minor CI issues * Fix no_std build * Fix miri build * Don't use `VmPtr` in FFI function signatures Use `NonNull` or `*mut u8` as appropriate for function signatures instead. It shouldn't be required to use `VmPtr` during the handoff to compiled code as we've already annotated the pointer going out. * Fix rebase conflict * Review comments
- Loading branch information
1 parent
e4699f7
commit b86b968
Showing
45 changed files
with
707 additions
and
375 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.