Handle targets that implement signal handlers

[oliverchang]

Targets that install their own SIGALRM/SIGSEGV/SIGABRT etc handlers may prevent libFuzzer/sanitizers from reporting timeouts/crashes in a way that ClusterFuzz understands.

#671 is an example -- libreoffice targets fail quickly on a timeout, but because there's a SIGALRM handlers that exit silently our logs show that the target just exits after some time without any indication why.

We should explore if there is a good way to prevent this situation.

[kcc]

Ughhh...
@vitalybuka has made a change recently where we stopped blocking users from redefining asan's sig handlers by default.

        handle_segv
                - Controls custom tool's SIGSEGV handler (0 - do not registers the handler, 1 - register the handler and allow user to set own, 2 - registers the handler and block user from changing it). 
        handle_sigbus
                - Controls custom tool's SIGBUS handler (0 - do not registers the handler, 1 - register the handler and allow user to set own, 2 - registers the handler and block user from changing it). 
        handle_abort
                - Controls custom tool's SIGABRT handler (0 - do not registers the handler, 1 - register the handler and allow user to set own, 2 - registers the handler and block user from changing it). 
        handle_sigill
                - Controls custom tool's SIGILL handler (0 - do not registers the handler, 1 - register the handler and allow user to set own, 2 - registers the handler and block user from changing it). 
        handle_sigfpe
                - Controls custom tool's SIGFPE handler (0 - do not registers the handler, 1 - register the handler and allow user to set own, 2 - registers the handler and block user from changing it). 

so, for those signals the simplest is to set all these flags to 2

As for SIGALRM... Hmmm. asan has nothing to do with SIGALRM.
libFuzzer needs to have it's own SIGALRM but it has no way to block the user from redefining it.

[kcc]

we can also add a code to libFuzzer to report a timeout if a single input took more than X seconds
even if the ALRM did not fire. This will work against slow inputs (that take > X but eventuall finish), but won't work against infinite loops (i.e. it's a partial solution)

[kcc]

here is a proposal:

• support SIGALRM interception in sanitizers
• by default, set handle_alrm to 0
• on handle_alrm > 0, install a handler that calls a user-provided callback (via __sanitizer_set_sigalrm_callback)

@vitalybuka WDYT?

[vitalybuka]

Why not in libFuzzer? It looks very libFuzzer specific.

[kcc]

sanitizers have the interception machinery, which is too hairy to have it re-implemented in libFuzzer

[oliverchang]

Re handle_signal=2, which llvm revision introduced it?

For our current builds with ASAN_OPTIONS=help=1, I'm not seeing "2" in the documentation:

        handle_segv
                - Controls custom tool's SIGSEGV handler (0 - do not registers the handler, 1 - register the handler).

Will it break if we set handle_signal=2 before we pick up the llvm change?

[vitalybuka]

It was introduced in r303941

[vitalybuka]

before r303941 you can set allow_user_segv_handler=0

[kcc]

See also https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=1916#c7
where our recent changes in asan are causing trouble (sorry!)

I wonder if we can bump the llvm revision manually.
Since recently we started following the chrome's clang revision,
but maybe we should simply ping a revision of our own and periodically bump it?

[oliverchang]

I wonder if we can bump the llvm revision manually.
Since recently we started following the chrome's clang revision,
but maybe we should simply ping a revision of our own and periodically bump it?

It looks chromium llvm just got a bump to r305281: https://chromium.googlesource.com/chromium/src/+/3a26e05c70e63815c7c18284e5e006b9d0ac75af

I'm guessing this is why the bug got marked as fixed just today? (because we don't have handle_signal=2) ?

Let's explore pinning our own revision if this keeps coming up.. clang bumps in Chrome are usually done after a bunch of tests, so it would be nice if we could just piggy back off that.

[kcc]

One alternative: bump the revisions manually, but only to the revisions tested by Chrome (unless there is a urgency like this one)

[vitalybuka]

Actually I don't see this as revision issues.
Here manual replacing handle_signal=1 to handle_signal=2 was required anyway.
So it's rather my fault to notify oss-fuzz and chromium. I am very sorry for that.

[oliverchang]

argh, unfortunately we cannot just set handle_signal=2 everywhere, since we still need to run older builds for regression and fixed testing, and setting handle_signal=2 isn't backwards compatible and will break those things..... is there anything that can be done on the sanitizers side to make this feature more backwards compatible?

For now we may need to roll back the clang revision, or wait for libFuzzer to be less aggressive about installing signal handlers.

[oliverchang]

Discussed offline with @vitalybuka

We need sanitizer options to be backwards compatible across builds. with handle_signal=2 unfortunately if we pass it to an older build we get a hard failure:

ERROR: Invalid value for bool option: '2'
ERROR: Flag parsing failed.

Adding new flags should be fine, because if we pass it to an older build we don't get a hard failure.

@vitalybuka said he will make a compatibility fix soon

Tracking this issue chromium side in https://bugs.chromium.org/p/chromium/issues/detail?id=731130#c10. If we don't get a revert there I'll manually pin our revision to the previous one.

[inferno-chromium]

What is the plan here ?

[nsajko]

Is the solution for this not for libFuzzer to do either of these things (that require POSIX signal.h and time.h) instead of using SIGALRM or other common signals:

• use SIGEV_THREAD with timer_create and timer_settime

• look for available signals (after the fuzzer starts) in the range SIGRTMIN:SIGRTMAX using sigaction and use what you find

• use a couple signals on the edge of the SIGRTMIN:SIGRTMAX range and then adjust that range with an interceptor function (like AddressSanitizer uses for malloc, etc.)