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

Possible unsoundness in IntoOpaque to do with pointer provenance and Box/Arc #471

Closed
zRedShift opened this issue May 22, 2022 · 0 comments
Closed

Comments

@zRedShift
Copy link
Contributor

According to the alloc crate documentation, Arc::from_raw must be paired with a call to Arc::into_raw, otherwise pointer provenance may be violated (due to the ArcInner layout), and a slightly different issue with Box.

Regarding Arc, it could be solved by imitating Arc::from_raw and using Arc::as_ptr, as using the Deref::deref/AsRef::as_ref implementation might be problematic, but according to this comment, there's some extra ceremony required for Box due to the uniqueness requirement.

I'm proposing to switch the as_ptr method to into_ptr and take Self. With that, Box::into_raw and Arc::into_raw could be used directly. This requires a small extra step to avoid a partial move, and incompatible with !Sized, but the fat pointer metadata can't be stored in *mut c_void anyway, and would require double boxing anyway (e.g. Box<Box<dyn Trait>>).

duarten pushed a commit that referenced this issue Jun 17, 2022
…472)

See #471

For Arc, an alternative that doesn't break the existing code would be to leave as_ptr as is and use Arc::as_ptr(self), but the relevant Box methods take by self, so a more thorough analysis is required.
@duarten duarten closed this as completed Jun 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants