Hi,
According to [nolibc] Disable the GCC stack protector when building sanitizer runt… · llvm/llvm-project@5829a98 · GitHub
the sanitizers are compiled with -fno-stack-protector to avoid introducing a libc dependency.
Is this still necessary? Are there any other reasons why sanitizers cannot be compiled with
stack protector enabled?
-Tom
Hi Tom,
Before we try to answer “are there any other reasons to not do X”,
(and I don’t know the answer off the top of my head)
I’d like to hear your “reasons to do X”.
Bundling -fno-stack-protector with e.g. ASAN serves no purpose that I can see.
-fno-stack-protector is a production feature.
It is a (weak but useful) security mitigation, it doesn’t help to find bugs.
ASAN (and other sanitizers) are testing tools, not commonly used in production.
They find stack buffer overflows much better than fno-stack-protector does.
The exception is perhaps UBSAN with minimal run-time or in trap mode.
This one is commonly used in production and it would be reasonable to allow it together with -fno-stack-protector.
–kcc
Hi Tom,
Before we try to answer "are there any other reasons to not do X",
(and I don't know the answer off the top of my head)
I'd like to hear your "reasons to do X".
I don't have a specific reason to compile the sanitizers with -fstack-protector,
I'm just wondering if it was safe to do so (e.g. the sanitizers can still work properly
with -fsatck-protector enabled). We run a security scan on our builds and it flagged
the sanitizer libraries and also any application built with -fsanitize=safe-stack
as missing -fstack-protector, so I would like to either enable -fstack-protector or
be able to document why it is disabled.
-Tom