-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
Rust soundness fixes #7518
Rust soundness fixes #7518
Conversation
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
For context, the relevant rustsec issue is https://rustsec.org/advisories/RUSTSEC-2021-0122.html |
@CasperN I'll let you handle this one. |
@tustvold You'll need to sign the CLA as well |
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.
Thanks for this change! This is really impactful
Are we all ready to merge? |
I'm happy if you're happy 😄 I don't think I've missed anything... |
I think this is great. Thank you for this PR! @TethysSvensson @alamb any further comments? If not, I'll submit once the branch is up to date and CI is green |
I don't have any more comments right now. I might have time to take another look for unsoundness at a later stage. |
We need both a release of |
For my purposes we vendor the generated code, and so I would be happy with just a pre-release of the crate, we already have instructions for compiling flatc from source (as the versions in most distributions are incredibly old) |
Release in: https://github.com/google/flatbuffers/releases/tag/v22.9.29 Haven't pushed to crates.io since I don't have permissions yet. |
This has a number of substantial breaking changes, it probably needs to be a major release. Sorry i should have made that clear |
Hi @dbaileychess / @tustvold, Version v22.9.29 of |
I want #7553 to go in before pushing, but otherwise it can go in EoWeek |
No rush, but just wondering where we have got to with this? |
released! |
* Rust soundness fixes * Second pass * Make init_from_table unsafe * Remove SafeSliceAccess * Clippy * Remove create_vector_of_strings * More clippy * Remove deprecated root type accessors * More soundness fixes * Fix EndianScalar for bool * Add TriviallyTransmutable * Add debug assertions * Review comments * Review feedback
* Rust soundness fixes * Second pass * Make init_from_table unsafe * Remove SafeSliceAccess * Clippy * Remove create_vector_of_strings * More clippy * Remove deprecated root type accessors * More soundness fixes * Fix EndianScalar for bool * Add TriviallyTransmutable * Add debug assertions * Review comments * Review feedback
There are various internal APIs exposed by the flatbuffer crate, and in the code it generates that are unsound, in that they permit undefined behaviour through safe APIs. It is extremely unlikely any downstreams are actually making use of these APIs and even less likely that they are doing so in ways that result in UB, however, the medium of RUSTSEC is not very effective to convey this subtlety. I think it is a shame, not to mention unfair, that this crate gets labelled "unsafe" or "dangerous" as a result of this, and so I'd like to do something to help fix this. Part of this is a selfish desire to stop having the same discussions repeatedly.
As originally proposed by @CasperN (#6627 (comment)) this makes the methods taking unvalidated
&[u8]
unsafe. The result is that if users are only using safe APIs, which force validation to be performed, they should be protected from UB => the crate is soundI will endeavour to highlight the non-mechanical changes in the diff, but the major changes are:
Follow::follow
andPush::push
unsafeArray::new
,Table::new
,Vector::new
,VectorIter::from_slice
,VTable::init
unsafe*_buffer_has_identifier
and*_size_prefixed
will panic if given too small a bufferVector<'a, T>
instead of sometimes returning slicestype Scalar
to allow endianness conversions for non-trivially transmutable types such as enumerations