Skip to content
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

wiggle: adapt Wiggle strings for shared use #5264

Merged
merged 2 commits into from
Nov 14, 2022

Conversation

abrown
Copy link
Contributor

@abrown abrown commented Nov 14, 2022

This is an extension of #5229 for the &str and &mut str types. As documented there, we are attempting to maintain Rust guarantees for slices that Wiggle hands out in the presence of WebAssembly shared memory, in which case multiple threads could be modifying the underlying data of the slice.

This change changes the API of GuestPtr to return an Option which is None when attempting to view the WebAssembly data as a string and the underlying WebAssembly memory is shared. This reuses the UnsafeGuestSlice structure from #5229 to do so and appropriately marks the region as borrowed in Wiggle's manual borrow checker. Each original call site in this project's WASI implementations is fixed up to expect that a non-shared memory is used. (Note that I can find no uses of GuestStrMut in the WASI implementations).

This is an extension of bytecodealliance#5229 for the `&str` and `&mut str` types. As
documented there, we are attempting to maintain Rust guarantees for
slices that Wiggle hands out in the presence of WebAssembly shared
memory, in which case multiple threads could be modifying the underlying
data of the slice.

This change changes the API of `GuestPtr` to return an `Option` which is
`None` when attempting to view the WebAssembly data as a string and the
underlying WebAssembly memory is shared. This reuses the
`UnsafeGuestSlice` structure from bytecodealliance#5229 to do so and appropriately marks
the region as borrowed in Wiggle's manual borrow checker. Each original
call site in this project's WASI implementations is fixed up to `expect`
that a non-shared memory is used.  (Note that I can find no uses of
`GuestStrMut` in the WASI implementations).
@abrown abrown requested a review from alexcrichton November 14, 2022 18:58
Copy link
Member

@alexcrichton alexcrichton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks reasonable to me! Could UnsafeGuestSlice::{shared,mut}_str be implemented in terms of {shared,mut}_borrow, though? I think in both of those cases calling the prior method and processing the result should be usable and overall reduce the unsafe as well.

@github-actions github-actions bot added the wasi Issues pertaining to WASI label Nov 14, 2022
@github-actions
Copy link

Subscribe to Label Action

cc @kubkon

This issue or pull request has been labeled: "wasi"

Thus the following users have been cc'd because of the following labels:

  • kubkon: wasi

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

This change makes it possible to reuse the underlying logic in
`UnsafeGuestSlice` and the `GuestSlice*` implementations to continue to
expose the `GuestStr` and `GuestStrMut` types. These types now are
simple wrappers of their `GuestSlice*` variant. The UTF-8 validation
that distinguished `GuestStr*` now lives in the `TryFrom`
implementations for each type.
@abrown abrown marked this pull request as ready for review November 14, 2022 21:43
@alexcrichton alexcrichton enabled auto-merge (squash) November 14, 2022 22:21
@alexcrichton alexcrichton merged commit 060f125 into bytecodealliance:main Nov 14, 2022
abrown added a commit to abrown/wasmtime that referenced this pull request Nov 14, 2022
`wiggle` looks for an exported `Memory` named `"memory"` to use for its
guest slices. This change allows it to use a `SharedMemory` if this is
the kind of memory used for the export.

It is `unsafe` to use shared memory in Wiggle because of broken Rust
guarantees: previously, Wiggle could hand out slices to WebAssembly
linear memory that could be concurrently modified by some other thread.
With the introduction of Wiggle's new `UnsafeGuestSlice` (bytecodealliance#5225, bytecodealliance#5229,
 bytecodealliance#5264), Wiggle should now correctly communicate its guarantees through
its API.
abrown added a commit to abrown/wasmtime that referenced this pull request Nov 15, 2022
`wiggle` looks for an exported `Memory` named `"memory"` to use for its
guest slices. This change allows it to use a `SharedMemory` if this is
the kind of memory used for the export.

It is `unsafe` to use shared memory in Wiggle because of broken Rust
guarantees: previously, Wiggle could hand out slices to WebAssembly
linear memory that could be concurrently modified by some other thread.
With the introduction of Wiggle's new `UnsafeGuestSlice` (bytecodealliance#5225, bytecodealliance#5229,
 bytecodealliance#5264), Wiggle should now correctly communicate its guarantees through
its API.
alexcrichton pushed a commit that referenced this pull request Nov 15, 2022
`wiggle` looks for an exported `Memory` named `"memory"` to use for its
guest slices. This change allows it to use a `SharedMemory` if this is
the kind of memory used for the export.

It is `unsafe` to use shared memory in Wiggle because of broken Rust
guarantees: previously, Wiggle could hand out slices to WebAssembly
linear memory that could be concurrently modified by some other thread.
With the introduction of Wiggle's new `UnsafeGuestSlice` (#5225, #5229,
 #5264), Wiggle should now correctly communicate its guarantees through
its API.
abrown added a commit to abrown/wasmtime that referenced this pull request Dec 9, 2022
Previous Wiggle changes (bytecodealliance#5229, bytecodealliance#5264) made it possible to access slices
of WebAssembly linear memory from Wiggle but limited the interface so
that slices of shared memory could only be accessed either `unsafe`-ly
or via copying (`GuestPtr::to_vec`). This change modifies `fd_write` to
unconditionally copy the bytes to be written before passing them to
Rust's standard library in an `IoSlice`. This is likely not the optimal
solution but enables further `wasi-threads` development. In the future
this commit should probably change to conditionally copy the bytes when
shared memory is detected and expand to fix up all the `expect` errors
of the same kind in `preview_1.rs`.
@abrown abrown added the wasm-proposal:threads Issues related to the WebAssembly threads proposal label Dec 12, 2022
abrown added a commit to abrown/wasmtime that referenced this pull request Dec 13, 2022
Previous Wiggle changes (bytecodealliance#5229, bytecodealliance#5264) made it possible to access slices
of WebAssembly linear memory from Wiggle but limited the interface so
that slices of shared memory could only be accessed either `unsafe`-ly
or via copying (`GuestPtr::to_vec`). This change modifies `fd_write` to
unconditionally copy the bytes to be written before passing them to
Rust's standard library in an `IoSlice`. This is likely not the optimal
solution but enables further `wasi-threads` development. In the future
this commit should probably change to conditionally copy the bytes when
shared memory is detected and expand to fix up all the `expect` errors
of the same kind in `preview_1.rs`.
abrown added a commit to abrown/wasmtime that referenced this pull request Dec 15, 2022
Previous Wiggle changes (bytecodealliance#5229, bytecodealliance#5264) made it possible to access slices
of WebAssembly linear memory from Wiggle but limited the interface so
that slices of shared memory could only be accessed either `unsafe`-ly
or via copying (`GuestPtr::to_vec`). This change modifies `fd_write` to
unconditionally copy the bytes to be written before passing them to
Rust's standard library in an `IoSlice`. This is likely not the optimal
solution but enables further `wasi-threads` development. In the future
this commit should probably change to conditionally copy the bytes when
shared memory is detected and expand to fix up all the `expect` errors
of the same kind in `preview_1.rs`.
abrown added a commit to abrown/wasmtime that referenced this pull request Dec 19, 2022
Previous Wiggle changes (bytecodealliance#5229, bytecodealliance#5264) made it possible to access slices
of WebAssembly linear memory from Wiggle but limited the interface so
that slices of shared memory could only be accessed either `unsafe`-ly
or via copying (`GuestPtr::to_vec`). This change modifies `fd_write` to
unconditionally copy the bytes to be written before passing them to
Rust's standard library in an `IoSlice`. This is likely not the optimal
solution but enables further `wasi-threads` development. In the future
this commit should probably change to conditionally copy the bytes when
shared memory is detected and expand to fix up all the `expect` errors
of the same kind in `preview_1.rs`.
abrown added a commit to abrown/wasmtime that referenced this pull request Dec 20, 2022
Previous Wiggle changes (bytecodealliance#5229, bytecodealliance#5264) made it possible to access slices
of WebAssembly linear memory from Wiggle but limited the interface so
that slices of shared memory could only be accessed either `unsafe`-ly
or via copying (`GuestPtr::to_vec`). This change modifies `fd_write` to
unconditionally copy the bytes to be written before passing them to
Rust's standard library in an `IoSlice`. This is likely not the optimal
solution but enables further `wasi-threads` development. In the future
this commit should probably change to conditionally copy the bytes when
shared memory is detected and expand to fix up all the `expect` errors
of the same kind in `preview_1.rs`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wasi Issues pertaining to WASI wasm-proposal:threads Issues related to the WebAssembly threads proposal
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants