-
-
Notifications
You must be signed in to change notification settings - Fork 14.9k
Stabilize stack-protector #146369
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
base: main
Are you sure you want to change the base?
Stabilize stack-protector #146369
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
|
@@ -279,18 +279,19 @@ impl CodegenBackend for LlvmCodegenBackend { | |||||||||
| Generate stack canaries in all functions. | ||||||||||
|
|
||||||||||
| strong | ||||||||||
| Generate stack canaries in a function if it either: | ||||||||||
| - has a local variable of `[T; N]` type, regardless of `T` and `N` | ||||||||||
| - takes the address of a local variable. | ||||||||||
|
|
||||||||||
| (Note that a local variable being borrowed is not equivalent to its | ||||||||||
| address being taken: e.g. some borrows may be removed by optimization, | ||||||||||
| while by-value argument passing may be implemented with reference to a | ||||||||||
| local stack variable in the ABI.) | ||||||||||
|
|
||||||||||
| basic | ||||||||||
| Generate stack canaries in functions with local variables of `[T; N]` | ||||||||||
| type, where `T` is byte-sized and `N` >= 8. | ||||||||||
| Generate stack canaries for all functions, unless the compiler | ||||||||||
| can prove these functions can't be the source of a stack | ||||||||||
| buffer overflow (even in the presence of undefined behavior). | ||||||||||
|
|
||||||||||
| This provides similar security guarantees to Clang's | ||||||||||
| `-fstack-protector-strong`. | ||||||||||
|
|
||||||||||
| The exact rules are unstable and subject to change, but | ||||||||||
| currently, it generates stack protectors for functions that, | ||||||||||
| *post-optimization*, contain LLVM allocas (which | ||||||||||
| include all stack allocations - including fixed-size | ||||||||||
| allocations - that are used in a way that is not completely | ||||||||||
| determined by static control flow). | ||||||||||
|
Comment on lines
+293
to
+294
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think the parenthetical is slightly misplaced, feel free to ignore if I'm wrong 🙂
Suggested change
|
||||||||||
|
|
||||||||||
| none | ||||||||||
| Do not generate stack canaries. | ||||||||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I know it's not widely used by Clang/Gcc, but should we add why the basic mode/strategy is not applicable to Rust and thus not available in case people look for it for matching build configurations?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think that outside of rustc it's always called
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, agreed. I actually meant mainly in the markdown docs, but left the comment in the wrong place. Something like:
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sure, will do that soon-ish. |
||||||||||
|
|
||||||||||
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -695,6 +695,43 @@ Note that all three options are supported on Linux and Apple platforms, | |||||
| Attempting to use an unsupported option requires using the nightly channel | ||||||
| with the `-Z unstable-options` flag. | ||||||
|
|
||||||
| ## stack-protector | ||||||
|
|
||||||
| The option `-C stack-protector` (currently also supported in the | ||||||
| old style `-Z stack-protector`) controls the generation of | ||||||
| stack-protector canaries. | ||||||
|
|
||||||
| This flag controls stack smashing protection strategy. | ||||||
|
|
||||||
| Supported values for this option are: | ||||||
| - `none` (default): Disable stack canary generation | ||||||
| - `strong`: Generate stack canaries in all functions, unless the compiler | ||||||
| can prove these functions can't be the source of a stack | ||||||
| buffer overflow (even in the presence of undefined behavior). | ||||||
|
|
||||||
| This provides similar security guarantees to Clang's | ||||||
| `-fstack-protector-strong`. | ||||||
|
|
||||||
| The exact rules are unstable and subject to change, but | ||||||
| currently, it generates stack protectors for functions that, | ||||||
| *post-optimization*, contain LLVM allocas (which | ||||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. same thing here and on lines 719 & 720 as above |
||||||
| include all stack allocations - including fixed-size | ||||||
| allocations - that are used in a way that is not completely | ||||||
| determined by static control flow). | ||||||
| - `all`: Generate stack canaries in all functions | ||||||
|
|
||||||
| rustc does not have a mode equivalent to Clang's (or GCC's) | ||||||
| plain `-fstack-protector` - `-fstack-protector` is an older heuristic | ||||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nit
Suggested change
|
||||||
| designed for C, that only protects functions that allocate a | ||||||
| `char buf[N];` buffer on the stack, making it prone to buffer overflows | ||||||
| from length miscalculations. This heuristic is poorly suited for Rust | ||||||
| code. Even in C codebases, `-fstack-protector-strong` is nowadays | ||||||
| preferred because plain `-fstack-protector` misses many stack | ||||||
| buffer overflows. | ||||||
|
|
||||||
| Stack protectors are not supported on many GPU targets, use of stack | ||||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sort of sounds like they're not supported only on GPU targets but I don't know why that would be the case (there could be other targets or future targets that also do not support them).
Suggested change
|
||||||
| protectors on these targets is an error. | ||||||
|
|
||||||
| ## strip | ||||||
|
|
||||||
| The option `-C strip=val` controls stripping of debuginfo and similar auxiliary | ||||||
|
|
||||||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -62,7 +62,7 @@ equivalent. | |
| | Stack clashing protection | Yes | Yes | 1.20.0 (2017-08-31) | | ||
| | Read-only relocations and immediate binding | Yes | Yes | 1.21.0 (2017-10-12) | | ||
| | Heap corruption protection | Yes | Yes | 1.32.0 (2019-01-17) (via operating system default or specified allocator) | | ||
| | Stack smashing protection | Yes | No, `-Z stack-protector` | Nightly | | ||
| | Stack smashing protection | Yes | No, `-C stack-protector` | ??? | | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Leaving a reminder we should adjust this just before r+ 🙂 |
||
| | Forward-edge control flow protection | Yes | No, `-Z sanitizer=cfi` | Nightly | | ||
| | Backward-edge control flow protection (e.g., shadow and safe stack) | Yes | No, `-Z sanitizer=shadow-call-stack,safestack` | Nightly | | ||
|
|
||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.
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.
nit: can we re-word this to not mention LLVM specifically? It seems like this flag should be easily supportable by cg_gcc so I think it would be best to avoid documenting the behavior in an overly LLVM-specific way.
View changes since the review