feat: handle SIGBUS / SIGSEGV only when originating from YARA's memory blocks

[secDre4mer]

YARA currently registers its own signal handler unless instructed otherwise with SCAN_FLAGS_NO_TRYCATCH. This is dangerous for several reasons:

• The current implementation is racy; when multiple threads scan simultaneously, the original signal handler may never be restored.
• If the calling application is multithreaded, and one thread scans with YARA while a signal occurs in another thread, then that signal is ignored by the current signal handler.
• If a callback from YARA causes a segmentation fault, YARA assumes this to be due to the data, potentially causing havoc if the caller (which may be unaware of YARA's signal handler) expects its own signal handler to be called.

This PR tries to improve this situation by adding several safety mechanisms when handling signals:

• Creating a signal handler in the (racy) POSIX way is now secured with a mutex
• Signals are only handled if the fault address lies within the currently inspected memory block
• Unhandled signals are forwarded to the signal handler that was installed before YARA (analogous to the Windows implementation, which uses EXCEPTION_CONTINUE_SEARCH)

[secDre4mer]

This is related to https://github.com/hillu/go-yara/pull/137, which tries to deal with these issues with an original signal handler (installed by the Golang runtime) versus YARA's signal handler. Thanks to @plusvic for initially identifying the problems with a process wide signal handler, and to @hillu for discussing possible solutions.

[vthib]

Looks nice! Would have allowed us to catch https://github.com/VirusTotal/yara/pull/2016 much more easily.

Not entirely related to your changes, but I wonder if there is actually a reason to catch SIGSEGV?

From my understanding, this signal handler is to handle issues that can arise when reading from an mmap'ed memory region. But afaik, those issues can only trigger SIGBUS signals (for example, mmap'ing a file, shortening it, then reading past the new end of the file), and are not supposed to trigger SIGSEGV. Are there expected scenarios where reading from a mmap region raises a SIGSEGV signal?

[secDre4mer]

Looks nice! Would have allowed us to catch #2016 much more easily.

Not entirely related to your changes, but I wonder if there is actually a reason to catch SIGSEGV?

From my understanding, this signal handler is to handle issues that can arise when reading from an mmap'ed memory region. But afaik, those issues can only trigger SIGBUS signals (for example, mmap'ing a file, shortening it, then reading past the new end of the file), and are not supposed to trigger SIGSEGV. Are there expected scenarios where reading from a mmap region raises a SIGSEGV signal?

SIGSEGV is caught, I believe, because it's used on FreeBSD / OpenBSD instead of SIGBUS in the scenario you described, see issue #551. I agree though that catching SIGSEGV on other POSIX systems is unnecessary. Maybe we can add a differentiation by OS so we only catch the signal that is necessary. Similarly, I don't think catching EXCEPTION_ACCESS_VIOLATION (which is the SIGSEGV equivalent) on windows is necessary - EXCEPTION_IN_PAGE_ERROR (the SIGBUS equivalent) should be sufficient.