3 ms·

What is the performance overhead for using these flags?

segfaultbuserr 8y ago
It's very hard to find solid numbers, because these flags are introduced and popularized at different times. But I'll try to give you my best summary. Long shory short, these flags are considered essentially and most web browsers and distributions have already enabled them without problems. Let's see... -D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS These two are considered very cheap. It enables some sanity checks for buffer overflow in glibc and glibc++, respectively. See https://access.redhat.com/blogs/766093/posts/3606481 https://access.redhat.com/blogs/766093/posts/3606481 and -fstack-protector-strong Also known as stack canary. The earliest version is simply called "-fstack-protector", but the coverage was bad (only "protects" <2% functions), there was also "-fstack-protector-full", adding checks to ALL functions, but the performance overhead is unacceptable. The "-strong" variant is an upgraded version, it uses a heuristic when determining if a function needs stack protectors, provides much better code coverage and a tradeoff between security and performance. It's relatively expensive, but is considered essential to prevent attackers from smashing the stack, and is enabled in most web browser engines. See https://lwn.net/Articles/584225/ https://lwn.net/Articles/584225/ -fstack-clash-protection stack clash protection Introduced in GCC 8.0 after the Stack Clash attack was discovered, see https://securingsoftware.blogspot.com/2017/12/stack-clash-protection-in-gcc.html https://securingsoftware.blogspot.com/2017/12/stack-clash-pr... -fPIE -pie better ASLR protection PIE is Position Independent-Executable, Address Space Layout Randomization needs it to achieve its full level of protection. It has been around for a long time, but only saw a mass adoption recently, possibly due to higher performance impact on 32-bit x86, but favorable on 64-bit systems. Red Hat has a performance analysis. * https://access.redhat.com/blogs/766093/posts/1975803 https://access.redhat.com/blogs/766093/posts/1975803 Arch Linux has also benchmarked its performance impact before deciding to enable it. * https://github.com/pid1/test-sec-flags/wiki https://github.com/pid1/test-sec-flags/wiki -Wl,-z,noexecstack don't allow code on stack It just disables the executable stack, no overhead. And normally the stack is NOT executable, unless under some special conditions like linking assembly code, due to bad default settings in GNU toolchains for historical reasons. This explicitly tells the linker: don't allow an executable stack, no matter what. -Wl,-z,relro ELF hardening -Wl,-z,now ELF hardening It marks the GOT table as readonly, and force the system to resolve all function references to shared libraries at startup time, instead of runtime. It has some impact on startup time, but mostly negligible. See https://blog.osiris.cyber.nyu.edu/exploitation%20mitigation%20techniques/exploitation%20techniques/2011/06/02/relro-relocation-read-only/ https://blog.osiris.cyber.nyu.edu/exploitation%20mitigation%....
- devereaux 8y ago
  Thanks! I like to know the consequences of enhancing security. not every program (or system) needs everything and the kitchensync.
- deleted 8y ago
  [deleted]

It's very hard to find solid numbers, because these flags are introduced and popularized at different times. But I'll try to give you my best summary. Long shory short, these flags are considered essentially and most web browsers and distributions have already enabled them without problems. Let's see... -D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS These two are considered very cheap. It enables some sanity checks for buffer overflow in glibc and glibc++, respectively. See https://access.redhat.com/blogs/766093/posts/3606481 https://access.redhat.com/blogs/766093/posts/3606481 and -fstack-protector-strong Also known as stack canary. The earliest version is simply called "-fstack-protector", but the coverage was bad (only "protects" <2% functions), there was also "-fstack-protector-full", adding checks to ALL functions, but the performance overhead is unacceptable. The "-strong" variant is an upgraded version, it uses a heuristic when determining if a function needs stack protectors, provides much better code coverage and a tradeoff between security and performance. It's relatively expensive, but is considered essential to prevent attackers from smashing the stack, and is enabled in most web browser engines. See https://lwn.net/Articles/584225/ https://lwn.net/Articles/584225/ -fstack-clash-protection stack clash protection Introduced in GCC 8.0 after the Stack Clash attack was discovered, see https://securingsoftware.blogspot.com/2017/12/stack-clash-protection-in-gcc.html https://securingsoftware.blogspot.com/2017/12/stack-clash-pr... -fPIE -pie better ASLR protection PIE is Position Independent-Executable, Address Space Layout Randomization needs it to achieve its full level of protection. It has been around for a long time, but only saw a mass adoption recently, possibly due to higher performance impact on 32-bit x86, but favorable on 64-bit systems. Red Hat has a performance analysis. * https://access.redhat.com/blogs/766093/posts/1975803 https://access.redhat.com/blogs/766093/posts/1975803 Arch Linux has also benchmarked its performance impact before deciding to enable it. * https://github.com/pid1/test-sec-flags/wiki https://github.com/pid1/test-sec-flags/wiki -Wl,-z,noexecstack don't allow code on stack It just disables the executable stack, no overhead. And normally the stack is NOT executable, unless under some special conditions like linking assembly code, due to bad default settings in GNU toolchains for historical reasons. This explicitly tells the linker: don't allow an executable stack, no matter what. -Wl,-z,relro ELF hardening -Wl,-z,now ELF hardening It marks the GOT table as readonly, and force the system to resolve all function references to shared libraries at startup time, instead of runtime. It has some impact on startup time, but mostly negligible. See https://blog.osiris.cyber.nyu.edu/exploitation%20mitigation%20techniques/exploitation%20techniques/2011/06/02/relro-relocation-read-only/ https://blog.osiris.cyber.nyu.edu/exploitation%20mitigation%....

devereaux 8y ago
Thanks! I like to know the consequences of enhancing security. not every program (or system) needs everything and the kitchensync.
deleted 8y ago
[deleted]