-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wasmtime: support a notion of "custom code publisher". #9778
Conversation
4056d14
to
6390b84
Compare
Updated, thanks! |
6390b84
to
7f976c4
Compare
In some `no_std` environments, virtual memory usage is *generally* prohibited for performance-predictability reasons, but the MMU hardware is still in use for permissions (e.g., `W^X` write-xor-execute). Occasional changes to page mapping permissions are thus necessary when new modules are loaded dynamically, and are acceptable in that context. Wasmtime needs a way to support "publishing" code (making it executable) in such environments. Rather than try to segment the `signals-based-traps` divide further, and piece out the code-publishing parts from the heap parts, and backdoor a path to `mprotect` in an otherwise `no_std` build, in this PR I have opted to add a trait an impl of which the embedder can provide to the `Config` to implement custom actions for "code publish". This otherwise operates properly in a no-`signals-based-traps` environment, e.g., the module backing memory itself is regularly allocated rather than mmap'd (but is now aligned to the degree requested by the trait impl).
7f976c4
to
3545eee
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be possible to add a test exercising this trait as well? Perhaps x86_64-linux-specific to avoid rewriting a bunch of logic to make things executable or something like that.
Label Messager: wasmtime:configIt looks like you are changing Wasmtime's configuration options. Make sure to
To modify this label's message, edit the To add new label messages or remove existing label messages, edit the |
fbdfd49
to
46514e7
Compare
46514e7
to
84bd6dd
Compare
Updated, thanks for feedback! Added a test that uses |
2dd2b8c
to
d5f4864
Compare
In some
no_std
environments, virtual memory usage is generally prohibited for performance-predictability reasons, but the MMU hardware is still in use for permissions (e.g.,W^X
write-xor-execute). Occasional changes to page mapping permissions are thus necessary when new modules are loaded dynamically, and are acceptable in that context. Wasmtime needs a way to support "publishing" code (making it executable) in such environments.Rather than try to segment the
signals-based-traps
divide further, and piece out the code-publishing parts from the heap parts, and backdoor a path tomprotect
in an otherwiseno_std
build, in this PR I have opted to add a trait an impl of which the embedder can provide to theConfig
to implement custom actions for "code publish". This otherwise operates properly in a no-signals-based-traps
environment, e.g., the module backing memory itself is regularly allocated rather than mmap'd (but is now aligned to the degree requested by the trait impl).