-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Randomize the ordering of struct fields when compiling in debug mode #38550
Comments
I know there's code out there in the wild that will be broken by this, especially if it affects the stdlib. Perhaps a Crater run and an early warning for the affected crates is in order. |
@abonander We ran Crater for #37249 and saw no instances of legitimate breakage, though of course what I'm proposing here is more radical and also Crater only catches a subset of errors. This is definitely a conversation that we need to have with the broader community so that people are aware of what Rust actually guarantees (i.e. "less than you think if you're not using repr(C)"), which is part of the reason why I've proposed this. It's true that maybe we could just have this as a dev option for the moment solely for the purpose of teasing out how much would break on Crater. |
Unanswered question: if a user does reveal a bug thanks to Rust reordering struct fields randomly (which, in correct code, should never trigger bugs), how do we help the user reproduce that bug deterministically? |
Probably some compiler flag that prints the seed for randomization for each struct, and/or prints the final ordering of the fields for a given struct given the seed. |
This will probably end up being a flag that does it both in debug and release. Se this thread. I wish the three related discussions were centralized. |
Just thought of something else. The seed for the reordering can be a hash of the path to the struct, thus producing a stable ordering until such time as the struct is moved or renamed. This should be really easy to implement. |
@camlorn Read your article and came to think of something. For this one:
Could this optimisation change the order of |
Nope. I didn't go into it because the article was already pretty lengthy, but @eddyb provided magic code that I am not going to even pretend to understand which can tell us whether or not we can move the last field. |
It's not just the last field but you can't reorder the prefix differenly between those types, the cast is safe. |
We could at least randomize the order of the fields that share an alignment, using the "def path hash" of the Similarly, I just realized we could do something similar for function calls, though it's harder to know what to key on, there. |
Now that it looks like #28951 will be addressed via #37429 , we may have a further obligation to ensure to do what we can to ensure that this doesn't bite people. One way that we could help out would be to randomize the order of struct fields by default when compiling in debug mode. This would only apply to structs that are not tagged with a
#repr
, and would effectively act as the#[repr(random)]
proposed by @petrochenkov at #37429 (comment) (actually adding explicit#[repr(random)]
would probably require an RFC, and so is not a prereq for this issue).The text was updated successfully, but these errors were encountered: