maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity

[DOCS] Add more detail to stack protector documentation 

The Clang -fstack-protector documentation mentions what functions are considered
vulnerable but does not mention the details of the implementation such as the use
of a global variable for the guard value. This brings the documentation more in
line with the GCC documentation at:
https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html
and gives someone using the option more idea about what is protected.

This partly addresses https://bugs.llvm.org/show_bug.cgi?id=42764

Differential Revision: https://reviews.llvm.org/D85239
This commit is contained in:
Peter Smith 2020-08-05 12:47:54 +01:00
parent 40506d5e2f
commit 839d974ee0
2 changed files with 10 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
clang/docs/ClangCommandLineReference.rst
View File

@ -2136,7 +2136,7 @@ Enable stack clash protection
.. option:: -fstack-protector, -fno-stack-protector
Enable stack protectors for some functions vulnerable to stack smashing. This uses a loose heuristic which considers functions vulnerable if they contain a char (or 8bit integer) array or constant sized calls to alloca, which are of greater size than ssp-buffer-size (default: 8 bytes). All variable sized calls to alloca are considered vulnerable
Enable stack protectors for some functions vulnerable to stack smashing. This uses a loose heuristic which considers functions vulnerable if they contain a char (or 8bit integer) array or constant sized calls to alloca , which are of greater size than ssp-buffer-size (default: 8 bytes). All variable sized calls to alloca are considered vulnerable. A function witha stack protector has a guard value added to the stack frame that is checked on function exit. The guard value must be positioned in the stack frame such that a buffer overflow from a vulnerable variable will overwrite the guard value before overwriting the function's return address. The reference stack guard value is stored in a global variable.
.. option:: -fstack-protector-all

13
clang/include/clang/Driver/Options.td
View File

@ -1801,10 +1801,15 @@ def fstack_protector_strong : Flag<["-"], "fstack-protector-strong">, Group<f_Gr
"as well as any calls to alloca or the taking of an address from a local variable">;
def fstack_protector : Flag<["-"], "fstack-protector">, Group<f_Group>,
HelpText<"Enable stack protectors for some functions vulnerable to stack smashing. "
"This uses a loose heuristic which considers functions vulnerable "
"if they contain a char (or 8bit integer) array or constant sized calls to "
"alloca, which are of greater size than ssp-buffer-size (default: 8 bytes). "
"All variable sized calls to alloca are considered vulnerable">;
"This uses a loose heuristic which considers functions vulnerable if they "
"contain a char (or 8bit integer) array or constant sized calls to alloca "
", which are of greater size than ssp-buffer-size (default: 8 bytes). All "
"variable sized calls to alloca are considered vulnerable. A function with"
"a stack protector has a guard value added to the stack frame that is "
"checked on function exit. The guard value must be positioned in the "
"stack frame such that a buffer overflow from a vulnerable variable will "
"overwrite the guard value before overwriting the function's return "
"address. The reference stack guard value is stored in a global variable.">;
def ftrivial_auto_var_init : Joined<["-"], "ftrivial-auto-var-init=">, Group<f_Group>,
Flags<[CC1Option, CoreOption]>, HelpText<"Initialize trivial automatic stack variables: uninitialized (default)"
" | pattern">, Values<"uninitialized,pattern">;