-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
do not allow ABI mismatches inside repr(C) types #119037
Conversation
r? @thomcc (rustbot has picked a reviewer for you, use r? to override) |
The Miri subtree was changed cc @rust-lang/miri |
Nominating due to the relatively tight timeline for T-lang at least. |
We had a brief discussion in the (sparsely-attended) lang meeting today. Everyone agreed that if there's concerns about a guarantee, we might as well retract it for now since we can always add it back again later. @bors r+ rollup=never |
☀️ Test successful - checks-actions |
Finished benchmarking commit (5ac4c8a): comparison URL. Overall result: ❌✅ regressions and improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Bootstrap: 672.918s -> 672.809s (-0.02%) |
That must be noise, this is a docs-and-tests-only change.
|
In #115476 we allowed ABI mismatches inside
repr(C)
types. This wasn't really discussed much; I added it because from how I understand calling conventions, this should actually be safe in practice. However I entirely forgot to actually allow this in Miri, and in the mean time I have learned that too much ABI compatibility can be a problem for CFI (it can reject fewer calls so that gives an attacker more room to play with).So I propose we take back that part about ABI compatibility in
repr(C)
. It is anyway something that C and C++ do not allow, as far as I understand.In the future we might want to introduce a class of ABI compatibilities where we say "this is a bug and it may lead to aborting the process, but it won't lead to arbitrary misbehavior -- worst case it'll just transmute the arguments from the caller type to the callee type". That would give CFI leeway to reject such calls without introducing the risk of arbitrary UB. (The UB can still happen if the transmute leads to bad results, of course, but it wouldn't be due to ABI weirdness.)
#115476 hasn't reached beta yet so if we land this before Dec 22nd we can just pretend this all never happened. ;) Otherwise we should do a beta backport (of the docs change at least).
Cc @rust-lang/opsem @rust-lang/types