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

Fix unsoundness issues (mem::zeroed / ManuallyDrop -> MaybeUninit) #458

Merged
merged 16 commits into from Feb 12, 2020

Conversation

cynecx
Copy link
Contributor

@cynecx cynecx commented Jan 1, 2020

Several libs in crossbeam contain unsound code (eg. Block::new). This PR fixes them and requires a MSRV upgrade to 1.36.

@cynecx cynecx changed the title Fix unsoundness issues (mem::{zeroed, uninitialized} / ManuallyDrop -> MaybeUninit) Fix unsoundness issues (mem::zeroed / ManuallyDrop -> MaybeUninit) Jan 1, 2020
@ghost
Copy link

ghost commented Jan 6, 2020

Thank you for the PR! Is it still in progress? Looks good to merge to me :)

We also have some instances of uninitialized memory in bounded queues (files array.rs and array_queue.rs) where it would be good to use MaybeUninit.

@cynecx
Copy link
Contributor Author

cynecx commented Jan 6, 2020

@stjepang Well, the issue is the MSRV bump to 1.36 (MaybeUninit), that's why I've opened this as a draft. So you are saying that we should go ahead with the MSRV bump?

We also have some instances of uninitialized memory in bounded queues (files array.rs and array_queue.rs) where it would be good to use MaybeUninit.

Yes, I will update them shortly and mark this PR ready for review then :).

@cynecx
Copy link
Contributor Author

cynecx commented Jan 6, 2020

@stjepang There is a failure in crossbeam's array flavoured channel: travis.

---- drops stdout ----
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `9336`,
 right: `9338`', crossbeam-channel/tests/array.rs:533:9
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

The MaybeUninit unsoundness fix should be right, unless I am missing something?

EDIT:

nvm I think I missed something, pushing the fix in a moment.

@cynecx cynecx marked this pull request as ready for review January 6, 2020 20:51
@cynecx
Copy link
Contributor Author

cynecx commented Jan 6, 2020

@stjepang It's ready for review now.

@cynecx
Copy link
Contributor Author

cynecx commented Jan 9, 2020

This PR is ready now.

README.md Outdated Show resolved Hide resolved
@cynecx
Copy link
Contributor Author

cynecx commented Jan 17, 2020

Friendly neighborhood ping.

@taiki-e
Copy link
Member

taiki-e commented Jan 20, 2020

fyi: by using https://crates.io/crates/maybe-uninit crate, we can avoid the MSRV bump (like smallvec 0.6 did)

@spacejam
Copy link
Contributor

spacejam commented Jan 27, 2020

@taiki-e that seems really appealing to me. maybe-uninit seems like a pretty lightweight crate, 0 dependencies and over 1 million downloads since its fairly recent release in November 2019. Some pretty large projects rely on this crate and it's nice to avoid the transitive MSRV bump decision if they would otherwise be willing to update. This then allows a larger number of Rust users of unsafe code to make more progress when running miri. (that is actually what led me here - I want to use miri on more parts of sled).

@ghost
Copy link

ghost commented Jan 27, 2020

I think we should just bump the minimum Rust version and consider publishing crossbeam 1.0 soon. A lot of unsafe code in crossbeam is really dealing with uninitialized memory so it's important we start using MaybeUninit ASAP.

@spacejam
Copy link
Contributor

one final consideration, @stjepang mentioned to me yesterday that rayon lags by a year. bumping MSRV to 1.36 means they need to wait until July 4 2020 before they can reduce their reliance on the uninitialized usage here. By using the maybe-uninit crate as a stopgap measure until july 4, it's possible for crossbeam to do a non-breaking patch update that silently reduces risk for more users. but, I'm not the one maintaining this, so I'll duck out at this point. although, if using that crate is a desired solution, I'm happy to implement it real quick since I'm an unemployed hobo.

@cynecx
Copy link
Contributor Author

cynecx commented Jan 29, 2020

@spacejam’s reasoning is really convincing. ping @stjepang.

@jonhoo
Copy link
Contributor

jonhoo commented Jan 31, 2020

I would love to see this land so that miri will work on downstream crates like https://github.com/jonhoo/flurry too!

@jonhoo
Copy link
Contributor

jonhoo commented Feb 4, 2020

@jeehoonkang @stjepang what are next steps for this PR? I think we need your decision for who to best move forward. It'd probably be good to land this PR in one form or another sooner rather than later.

jonhoo added a commit to jonhoo/flurry that referenced this pull request Feb 4, 2020
This removes the patch that incorporates crossbeam-rs/crossbeam#458,
since that PR also bumps the version number, and 0.9 doesn't exist on
crates.io. This in turn means that the miri test has to be disabled for
this release in particular. I'll push a commit after release that
restores it and the crossbeam patch.

This commit also adds a changelog!
jonhoo added a commit to jonhoo/flurry that referenced this pull request Feb 4, 2020
This removes the patch that incorporates crossbeam-rs/crossbeam#458,
since that PR also bumps the version number, and 0.9 doesn't exist on
crates.io. This in turn means that the miri test has to be disabled for
this release in particular. I'll push a commit after release that
restores it and the crossbeam patch.

This commit also adds a changelog!
@jeehoonkang
Copy link
Contributor

I prefer maybe-uninit to bumping MSRV. It looks like a fine temporary measure we can take.

@jonhoo
Copy link
Contributor

jonhoo commented Feb 6, 2020

Thanks! @cynecx, do you have the time to update the PR to use maybe-uninit?

@cynecx
Copy link
Contributor Author

cynecx commented Feb 6, 2020

@jonhoo Sure :) The changes should be up in an hour(-ish)!

@cynecx
Copy link
Contributor Author

cynecx commented Feb 6, 2020

A question though, instead of adding maybe-uninit to each crate, should I just put it in crossbeam-utils and export a type-alias (MaybeUninit)? This would have a benefit, that future updates would simply have to change the type-alias in order to change the underlying MaybeUninit implementation. Also most of the affected crates are already having crossbeam-utils as a dependency, so that we just have to add the maybe-uninit dependency in crossbeam-utils. Thoughts?

@jonhoo
Copy link
Contributor

jonhoo commented Feb 6, 2020

I would keep it separate, since (I think) it's weird for crossbeam-utils crate to publicly expose that type alias. If it could expose it just to other crossbeam crates, then sure, but I don't think that's really an option.

@cuviper
Copy link
Contributor

cuviper commented Feb 6, 2020

If you reexport it, it becomes part of the public API, including the fact that it's identical to maybe-uninit's type. You'd have to wrap it in a newtype to avoid that equality, to let you freely change the impl.

@cynecx
Copy link
Contributor Author

cynecx commented Feb 10, 2020

I hope it's okay if I force-push now to address the merge-conflict? Because that will mess-up the review for sure xD.

Whatever, seems like the review boxed are marked outdated anyway.

@jeehoonkang
Copy link
Contributor

Thanks!

bors r+

bors bot added a commit that referenced this pull request Feb 12, 2020
458: Fix unsoundness issues (mem::zeroed / ManuallyDrop -> MaybeUninit) r=jeehoonkang a=cynecx

Several libs in crossbeam contain unsound code (eg. `Block::new`). This PR fixes them and requires a MSRV upgrade to 1.36.



Co-authored-by: cynecx <me@cynecx.net>
@bors
Copy link
Contributor

bors bot commented Feb 12, 2020

Build succeeded

@bors bors bot merged commit 8903df8 into crossbeam-rs:master Feb 12, 2020
@jonhoo
Copy link
Contributor

jonhoo commented Feb 12, 2020

@jeehoonkang Nice, thanks! What's the plan for next release between this and #466 ? Would be good to land something soon to get those out.

bors bot added a commit that referenced this pull request Feb 17, 2020
474: Patch release for all crossbeam crates. r=jeehoonkang a=jonhoo

This bumps the patch version for all sub-crates and the top-level crate and updates the changelogs with references to PRs where applicable. As far as I can tell, there are no breaking changes. The top-level crate has not change at all, though I bumped `rand` to `0.7` in all the crates, which I guess technically requires a patch bump if we do another release.

Fixes #473.
Closes #472.
Closes #468.
Closes #409.
Not sure if this also solves #347 by virtue of #458?

Co-authored-by: Jon Gjengset <jon@thesquareplanet.com>
bors bot added a commit that referenced this pull request Feb 17, 2020
474: Patch release for all crossbeam crates. r=jeehoonkang a=jonhoo

This bumps the patch version for all sub-crates and the top-level crate and updates the changelogs with references to PRs where applicable. As far as I can tell, there are no breaking changes. The top-level crate has not change at all, though I bumped `rand` to `0.7` in all the crates, which I guess technically requires a patch bump if we do another release.

Fixes #473.
Closes #472.
Closes #468.
Closes #409.
Not sure if this also solves #347 by virtue of #458?

Co-authored-by: Jon Gjengset <jon@thesquareplanet.com>
bors bot added a commit that referenced this pull request Feb 22, 2020
474: Patch release for all crossbeam crates. r=jeehoonkang a=jonhoo

This bumps the patch version for all sub-crates and the top-level crate and updates the changelogs with references to PRs where applicable. As far as I can tell, there are no breaking changes. The top-level crate has not change at all, though I bumped `rand` to `0.7` in all the crates, which I guess technically requires a patch bump if we do another release.

Fixes #473.
Closes #472.
Closes #468.
Closes #409.
Not sure if this also solves #347 by virtue of #458?

Co-authored-by: Jon Gjengset <jon@thesquareplanet.com>
BurntSushi added a commit to BurntSushi/ripgrep that referenced this pull request Mar 15, 2020
This adds one new dependency, maybe-uninit, which is brought in by
crossbeam-channel[1]. This is to apparently fix some unsound code
without bumping the MSRV. Since ripgrep uses the latest stable release
of Rust, the maybe-uninit crate should compile down to nothing and just
re-export std's `MaybeUninit` type.

[1] - crossbeam-rs/crossbeam#458
@jonhoo jonhoo mentioned this pull request May 19, 2020
bors bot added a commit that referenced this pull request Jan 22, 2022
774: Reduce unsafe code in array queue/bounded channel r=taiki-e a=taiki-e

Before #458, since destructors could be called on elements, the correct way was to convert the Vec to a pointer, save it, and then [deallocate it as a Vec with zero length](https://github.com/crossbeam-rs/crossbeam/blob/28ad2b7e015832b47db7e389dd9ebce3e94b3adb/crossbeam-channel/src/flavors/array.rs#L549-L552). However, after #458, destructors of the elements wrapped by MaybeUninit are not called, so there is no need to save the Vec/boxed slice as a pointer. This removes the unsafe code that has caused several (potential) unsoundnesses in the past (#500, #533, #763).


Co-authored-by: Taiki Endo <te316e89@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants