[cfe-dev] stack overflow detection?
Kostya Serebryany
kcc at google.com
Thu Oct 3 21:58:07 PDT 2013
Meanwhile, could you try to reverse the order of these two call
in asan/asan_rtl.cc and see if it helps?
InstallSignalHandlers();
AsanTSDInit(AsanThread::TSDDtor);
--kcc
On Fri, Oct 4, 2013 at 8:56 AM, Kostya Serebryany <kcc at google.com> wrote:
>
>
>
> On Fri, Oct 4, 2013 at 2:00 AM, Greg Fitzgerald <garious at gmail.com> wrote:
>
>> Have you guys had any luck with the "use_sigaltstack=1" on Android?
>> I've attempted to use it two versions: the latest clang/compiler-rt
>> and clang 3.3. In both cases, the ASan runtime doesn't catch the
>> stack overflow. Turning on verbosity=1 reports "tsd_key_inited != 0".
>>
>
> I've seen such assertion failure on Linux some time ago, but then it
> turned into another failure.
> The issue is tracked here:
> https://code.google.com/p/address-sanitizer/issues/detail?id=224
>
> --kcc
>
>
>
>> Here's the full log:
>>
>> ==28386==Parsed ASAN_OPTIONS: use_sigaltstack=1:verbosity=1
>> ==28386==AddressSanitizer: libc interceptors initialized
>> || `[0x20000000, 0xffffffff]` || HighMem ||
>> || `[0x04000000, 0x1fffffff]` || HighShadow ||
>> || `[0x00040000, 0x03ffffff]` || ShadowGap ||
>> MemToShadow(shadow): 0x00000000 0x00000000 0x00800000 0x03ffffff
>> red_zone=16
>> quarantine_size=64M
>> malloc_context_size=30
>> SHADOW_SCALE: 3
>> SHADOW_GRANULARITY: 8
>> SHADOW_OFFSET: 0
>> ==28386==AddressSanitizer CHECK failed:
>> llvm/projects/compiler-rt/lib/asan/asan_posix.cc:110
>> "((tsd_key_inited)) != (0)" (0x0, 0x0)
>> #0 0x40298bbf in $a _asan_rtl_
>> #1 0x4029cb37 in __sanitizer::CheckFailed(char const*, int, char
>> const*, unsigned long long, unsigned long long) ??:0
>> #2 0x40294343 in __asan::AsanTSDGet() ??:0
>> #3 0x4029a6f3 in __asan::GetCurrentThread() ??:0
>> #4 0x4029a9ab in __asan::GetCurrentTidOrInvalid() ??:0
>> #5 0x40293deb in __asan::SetAlternateSignalStack() ??:0
>> #6 0x40293f5b in __asan::InstallSignalHandlers() ??:0
>> #7 0x402984ff in __asan_init_v3 ??:0
>>
>>
>> I'm running on Android JellyBean and building with NDK r9.
>>
>> -Greg
>>
>>
>> On Wed, Sep 18, 2013 at 10:51 AM, Greg Fitzgerald <garious at gmail.com>
>> wrote:
>> > Minor correction (environment variable is for the runtime, not
>> compile-time).
>> >
>> > was:
>> > $ ASAN_OPTIONS=use_sigaltstack=1 clang -g -fsanitize=address -o test
>> > test.c && ./test
>> >
>> > should be:
>> > $ clang -g -fsanitize=address -o test test.c &&
>> > ASAN_OPTIONS=use_sigaltstack=1 ./test
>> >
>> > -Greg
>> >
>> > On Wed, Sep 18, 2013 at 10:39 AM, Greg Fitzgerald <garious at gmail.com>
>> wrote:
>> >> Perfect! I can confirm this works exactly as described using clang
>> >> 3.3 running on Ubuntu 12.04 on x86. Here's what I did:
>> >>
>> >> $ export ASAN_SYMBOLIZER_PATH=`which llvm-symbolizer`
>> >> $ clang --version
>> >> clang version 3.3 (tags/RELEASE_33/final)
>> >> Target: x86_64-unknown-linux-gnu
>> >> Thread model: posix
>> >>
>> >> $ cat test.c
>> >> static void loop() {
>> >> loop();
>> >> }
>> >>
>> >> int main() {
>> >> loop();
>> >> return 0;
>> >> }
>> >>
>> >> $ clang -g -o test test.c && ./test
>> >> Segmentation fault
>> >>
>> >> $ clang -g -fsanitize=address -o test test.c && ./test
>> >> Segmentation fault
>> >>
>> >> $ ASAN_OPTIONS=use_sigaltstack=1 clang -g -fsanitize=address -o test
>> >> test.c && ./test
>> >>
>> >> ==12279==ERROR: AddressSanitizer: SEGV on unknown address
>> >> 0x7fffb5066960 (pc 0x00000042d4a7 sp 0x7fffb5066940 bp 0x7fffb5067970
>> >> T0)
>> >> AddressSanitizer can not provide additional info.
>> >> #0 0x42d4a6 in loop test.c:1
>> >> #1 0x42d4db in loop test.c:3
>> >> #2 0x42d4db in loop test.c:3
>> >> #3 0x42d4db in loop test.c:3
>> >> ...
>> >>
>> >> I agree that this option should be enabled by default. This is useful
>> stuff!
>> >>
>> >> -Greg
>> >>
>> >> On Wed, Sep 18, 2013 at 1:19 AM, Kostya Serebryany <kcc at google.com>
>> wrote:
>> >>>
>> >>>
>> >>>
>> >>> On Wed, Sep 18, 2013 at 2:18 AM, Greg Fitzgerald <garious at gmail.com>
>> wrote:
>> >>>>
>> >>>> Thanks for the quick replies!
>> >>>>
>> >>>>
>> >>>> > If you want dynamic detection, then Address Sanitizer (which is
>> built
>> >>>> > into Clang) or SAFECode
>> >>>>
>> >>>> Dynamic detection. I tried with Address Sanitizer and no luck
>> >>>
>> >>>
>> >>> AddressSanitizer does not try to detect stack overflow (not to be
>> mixed with
>> >>> stack-buffer-overflow).
>> >>> The reason is simple: when stack overflow happens it is already
>> detected
>> >>> (you get a SEGV).
>> >>> However, by default when stack overflow happens the SEGV kills the
>> process
>> >>> silently because
>> >>> the signal handler has no stack to run on.
>> >>> This can be solved with sigaltstack() and AddressSanitizer does this
>> under a
>> >>> separate
>> >>> (experimental) flag ASAN_OPTIONS=use_sigaltstack=1
>> >>>
>> >>> # Running with default 8Mb stack
>> >>> % clang -g -fsanitize=address -O
>> >>>
>> ~/llvm/projects/compiler-rt/lib/asan/lit_tests/TestCases/deep_call_stack.cc
>> >>> ; ./a.out
>> >>> [40000] ptr: (nil)
>> >>> ...
>> >>> [00000] ptr: 0x7fff0b7c4140
>> >>> # Passed
>> >>>
>> >>> # Running with a small stack
>> >>> % (ulimit -s 1000; ./a.out; echo $? )
>> >>> [40000] ptr: (nil)
>> >>> ...
>> >>> [33000] ptr: 0x7fff0e155120
>> >>> 139 # FAILED
>> >>>
>> >>> # Running with a small stack and with sigaltstack
>> >>> % (ulimit -s 1000; ASAN_OPTIONS=use_sigaltstack=1 ./a.out; echo $? )
>> 2>&1 |
>> >>> head
>> >>> ASAN:SIGSEGV
>> >>> =================================================================
>> >>> ==1543==ERROR: AddressSanitizer: SEGV on unknown address
>> 0x7fffa383bfe0 (pc
>> >>> 0x000000456d38 sp 0x7fffa383bfe0 bp 0x7fffa383c050 T0)
>> >>> AddressSanitizer can not provide additional info.
>> >>> #0 0x456d37 in RecursiveFunc(int, int*)
>> >>>
>> /home/kcc/llvm/projects/compiler-rt/lib/asan/lit_tests/TestCases/deep_call_stack.cc:8
>> >>> #1 0x456dbc in RecursiveFunc(int, int*)
>> >>>
>> /home/kcc/llvm/projects/compiler-rt/lib/asan/lit_tests/TestCases/deep_call_stack.cc:14
>> >>>
>> >>>
>> >>> hth,
>> >>>
>> >>> --kcc
>> >>>
>> >>>
>> >>>
>> >>>> out-of-the-box. I think it can detect stack-buffer-overflow (aka
>> >>>> stack corruption), but not stack overflow. I also tried running the
>> >>>> code with ASan inside a pthread with heap-allocated memory for its
>> >>>> stack, but since the pthread library itself is not instrumented, it
>> >>>> did not detect the heap-buffer-overflow when the thread's stack
>> >>>> overflows.
>> >>>>
>> >>>>
>> >>>> > or SAFECode
>> >>>>
>> >>>> Can you point me to an example?
>> >>>>
>> >>>>
>> >>>> Eli Friedman wrote:
>> >>>> > No such support exists at the moment.
>> >>>>
>> >>>> Is anyone aware of another C compiler that adds instrumentation for
>> >>>> stack overflow detection?
>> >>>>
>> >>>> Thanks,
>> >>>> Greg
>> >>>>
>> >>>> On Tue, Sep 17, 2013 at 3:03 PM, John Criswell <
>> criswell at illinois.edu>
>> >>>> wrote:
>> >>>> > On 9/17/13 4:57 PM, Greg Fitzgerald wrote:
>> >>>> >>
>> >>>> >> Does clang offer any tools for detecting when a program is about
>> to
>> >>>> >> segfault due to stack overflow?
>> >>>> >
>> >>>> >
>> >>>> > If you want dynamic detection, then Address Sanitizer (which is
>> built
>> >>>> > into
>> >>>> > Clang) or SAFECode (which has its own version of Clang into which
>> it is
>> >>>> > integrated) will do the trick.
>> >>>> >
>> >>>> > If you're asking about the Clang static analyzer, then I do not
>> know.
>> >>>> >
>> >>>> > -- John T.
>> >>>> >
>> >>>> >>
>> >>>> >> Thanks,
>> >>>> >> Greg
>> >>>> >> _______________________________________________
>> >>>> >> cfe-dev mailing list
>> >>>> >> cfe-dev at cs.uiuc.edu
>> >>>> >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>> >>>> >
>> >>>> >
>> >>>> _______________________________________________
>> >>>> cfe-dev mailing list
>> >>>> cfe-dev at cs.uiuc.edu
>> >>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>> >>>
>> >>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131004/f8befb9c/attachment.html>
More information about the cfe-dev
mailing list