Skip to content

wiggle: Refactor with fewer raw pointers#5268

Merged
alexcrichton merged 2 commits into
bytecodealliance:mainfrom
alexcrichton:unsafe-wiggle-internals
Nov 15, 2022
Merged

wiggle: Refactor with fewer raw pointers#5268
alexcrichton merged 2 commits into
bytecodealliance:mainfrom
alexcrichton:unsafe-wiggle-internals

Conversation

@alexcrichton
Copy link
Copy Markdown
Member

@alexcrichton alexcrichton commented Nov 15, 2022

This commit refactors the internals of wiggle to have fewer raw pointers and more liberally use &[UnsafeCell<_>]. The purpose of this refactoring is to more strictly thread through lifetime information throughout the crate to avoid getting it wrong. Additionally storing UnsafeCell<T> at rest pushes the unsafety of access to the leaves of modifications where Rust safety guarantees are upheld. Finally this provides what I believe is a safer internal representation of WasmtimeGuestMemory since it technically holds onto &mut [u8] un-soundly as other &mut T pointers are handed out.

Additionally generated GuestTypeTransparent impls in the wiggle macro were removed because they are not safe for shared memories as-is and otherwise aren't needed for WASI today. The trait has been updated to indicate that all bit patterns must be valid in addition to having the same representation on the host as in the guest to accomodate this.

This commit refactors the internals of `wiggle` to have fewer raw
pointers and more liberally use `&[UnsafeCell<_>]`. The purpose of this
refactoring is to more strictly thread through lifetime information
throughout the crate to avoid getting it wrong. Additionally storing
`UnsafeCell<T>` at rest pushes the unsafety of access to the leaves of
modifications where Rust safety guarantees are upheld. Finally this
provides what I believe is a safer internal representation of
`WasmtimeGuestMemory` since it technically holds onto `&mut [u8]`
un-soundly as other `&mut T` pointers are handed out.
@alexcrichton alexcrichton requested a review from abrown November 15, 2022 02:26
@github-actions github-actions Bot added the wasi Issues pertaining to WASI label Nov 15, 2022
@github-actions
Copy link
Copy Markdown

Subscribe to Label Action

cc @kubkon

Details 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.

Copy link
Copy Markdown
Member

@abrown abrown left a comment

Choose a reason for hiding this comment

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

Makes sense to me. I think there are some additional changes here beyond the &[UnsafeCell<T>] one that might be worth documenting; e.g., it isn't clear to me exactly why we are removing validate here and in the future it might be good to remember the "why". Perhaps some reasoning in the squashed commit message would help?

@alexcrichton
Copy link
Copy Markdown
Member Author

Ah yes indeed sorry about that. The wiggle-generated implementations of GuestTypeTransparent were all unsafe in the face of shared memories since they do raw pointer reads/writes and needed treatment somehow. One option would be to switch to atomic loads as was done for primitive integers, but I opted instead to change the definition of GuestTypeTransparent to require "all bits valid" and then I went ahead and removed the auto-generated implementations. I don't think anything needs GuestTypeTransparent, or at least not in WASI today, and it otherwise represents the ambitions-at-the-time which have since been eclipsed by the component model.

@alexcrichton alexcrichton merged commit 6dcdabf into bytecodealliance:main Nov 15, 2022
@alexcrichton alexcrichton deleted the unsafe-wiggle-internals branch November 15, 2022 17:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

wasi Issues pertaining to WASI

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants