document that extern statics may be bigger than the declared size - #2334
document that extern statics may be bigger than the declared size#2334RalfJung wants to merge 2 commits into
Conversation
rustbot
added
the
S-waiting-on-review
|
|
||
| r[items.extern.static.size] | ||
| The actual memory that the extern static resolves to must have *at least* the size and alignment of the type that it was declared with in the extern block. | ||
| If the actual memory is bigger, then it is permitted to access that extra memory by creating a raw pointer to the extern static and then doing appropriate pointer arithmetic. |
There was a problem hiding this comment.
Perhaps be more explicit about the need to use &raw (and avoid an intermediate reference)?
There was a problem hiding this comment.
I have removed the &raw requirement, anticipating #2338. I don't think we want subobject provenance to get in the way here, so this should be fine (if the static is big enough to read element N):
extern { static mut X: (); }
let ptr = &X as *const () as *const i32;
ptr.add(N).read();This is a bad idea because of aliasing rules (the pointer gets invalidated on writes), but we already lint against that.
3a54061 to
45fbcfe
Compare
|
This would formally resolve/answer rust-lang/unsafe-code-guidelines#259 and maybe some of rust-lang/unsafe-code-guidelines#546 right? |
|
The latter has already been resolved by #1657. And this does resolve the former, yes. Thanks for digging that up. |
| * Incorrect use of inline assembly. For more details, refer to the [rules] to follow when writing code that uses inline assembly. | ||
|
|
||
| r[undefined.extern-static] | ||
| * Declaring an `extern static` with some size/alignment/mutability, when the actual symbol this resolves to is smaller / less aligned / less mutable. |
There was a problem hiding this comment.
This new kind of UB is kind of remarkable in that it does not require any code to trigger. But I don't see an alternative...
ad86228 to
ec8f4ef
Compare
|
|
||
| r[items.extern.static.size] | ||
| The actual memory that the extern static resolves to [must have][extern-static-ub] *at least* the size and alignment of the type that it was declared with in the extern block. | ||
| If the actual memory is bigger, then it is permitted to access that extra memory. |
There was a problem hiding this comment.
For dynamic libraries that may be used by a PIE executable, the size given by the symbol must be exact given that the PIE executable will emit a copy relocation that copies a block with exactly the size the symbol had at link time to memory the executable image has reserved for this and redirect all accesses to the static to this copy. This way the executable can avoid GOT indirection, which is a slight perf win. And yes, this means adding elements to a static array in a dylib (or otherwise changing the size) is an ABI breaking change on Linux.
There was a problem hiding this comment.
Uh... I understand like maybe half of those words. (Can I have some 🥧 please? :D )
"Copying" sounds wrong, statics are places and if you copy them, well, you have two copies so that can't be right?
But it sounds like you are saying linkme and inventory are unsound? IIRC they rely on extern statics that are bigger than declared, filled in by the linker.
traviscross
added
the
I-lang-docs-nominated
6 participants
I am fairly sure we discussed at some point whether it's okay to access memory beyond the declared size of an
extern static, and @nikic confirmed that this is fine. But I couldn't find any official place where we document this. So, let's add it to the Reference.I wondered if we also need the converse on the UB page: it is UB to even start the program if an extern static ends up being backed by memory that is smaller or less-aligned than the declared type. What do you think?
Cc @rust-lang/opsem
Fixes rust-lang/unsafe-code-guidelines#259
Fixes rust-lang/unsafe-code-guidelines#622