[fuzzer] Add Windows Visual C++ exception intercept

[jopletch]

Summary

Adds a new option, handle_winexcept to try to intercept uncaught
Visual C++ exceptions on Windows. On Linux, such exceptions are handled
implicitly by std::terminate() raising SIBABRT. This option brings the
Windows behavior in line with Linux.

Unfortunately this exception code is intentionally undocumented, however
has remained stable for the last decade. More information can be found
here: https://devblogs.microsoft.com/oldnewthing/20100730-00/?p=13273

[kcc]

please no #ifdefs.
please add a test.

[jopletch]

Removed if defs.

For the test, the following code demonstrates the issue:

extern "C" int LLVMFuzzerTestOneInput(const std::uint8_t *data, size_t size) {
    std::vector<uint8_t> v;
    v.reserve(static_cast<uint64_t>(-1));

    return 0;
}

But I'm not sure how best to integrate this -- are there existing crashing tests somewhere I should add this to?

[kcc]

But I'm not sure how best to integrate this -- are there existing crashing tests somewhere I should add this to?

compiler-rt/test/fuzzer

[metzman]

This change was a bit hard to review since it doesn't include full context (See https://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface).

compiler-rt/lib/fuzzer/FuzzerUtilWindows.cpp

64

nit: include link to https://devblogs.microsoft.com/oldnewthing/20100730-00/?p=13273 and end sentence with period please.

69

nit: "Handle"

[jopletch]

Address review comments, apologies for the delay and incorrectly formatted patch. Should have a test added shortly, but I'm running into some problems executing the test suite on Windows. Are failures expected on Windows, or is it more likely there are problems with my environment? Specifically the testing suite seems to be expecting bash-like environment. Is it expected to run ninja from wsl or cygwin?

[metzman]

In D89755#2358475, @jopletch wrote:

Address review comments, apologies for the delay and incorrectly formatted patch. Should have a test added shortly, but I'm running into some problems executing the test suite on Windows. Are failures expected on Windows, or is it more likely there are problems with my environment? Specifically the testing suite seems to be expecting bash-like environment. Is it expected to run ninja from wsl or cygwin?

Have you installed GnuWin32?
These are necessary for running the tests under Windows and sound like the missing thing here.

[metzman]

In D89755#2358475, @jopletch wrote:

Address review comments, apologies for the delay and incorrectly formatted patch. Should have a test added shortly, but I'm running into some problems executing the test suite on Windows. Are failures expected on Windows, or is it more likely there are problems with my environment? Specifically the testing suite seems to be expecting bash-like environment. Is it expected to run ninja from wsl or cygwin?

Overall, failures should not happen under Windows.
Most of the tests that need gnu-like tools work with gnuwin32, the ones that don't are explicitly disabled on Win.
So if you get failures running the tests under Win without making any changes first, it probably is something wrong with your environment.

[jopletch]

Add test.

[jopletch]

In D89755#2358899, @metzman wrote:

In D89755#2358475, @jopletch wrote:

Address review comments, apologies for the delay and incorrectly formatted patch. Should have a test added shortly, but I'm running into some problems executing the test suite on Windows. Are failures expected on Windows, or is it more likely there are problems with my environment? Specifically the testing suite seems to be expecting bash-like environment. Is it expected to run ninja from wsl or cygwin?

Have you installed GnuWin32?
These are necessary for running the tests under Windows and sound like the missing thing here.

Yeah, this is in fact what I was missing, thanks! FWIW, the testing scripts also work with the bash-like utilities that ship with git (e.g. C:\Program Files\Git\usr\bin), which is probably more likely to be install on a developer machine these days :)

[jopletch]

Oops, didn't realize those comments were individually resolvable.

[metzman]

compiler-rt/test/fuzzer/uncaught-exception.test

1

Just confirming, on Windows, v.reserve(static_cast<uint64_t>(-1)); throws 0xE06D7363 ?

[metzman]

compiler-rt/test/fuzzer/uncaught-exception.test

1

I'll approve if this is the case.

[jopletch]

Yes, without this patch and with windbg set as the jit debugger if you run this testcase you'll see the following:

(431c.1fcc): C++ EH exception - code e06d7363 (!!! second chance !!!)
*** WARNING: Unable to verify checksum for E:\libfuzzer\llvm-project\build\projects\compiler-rt\test\fuzzer\X86_64DefaultWindowsConfig\Output\uncaught-exception.test.tmp-UncaughtException
KERNELBASE!RaiseException+0x69:
00007ff9`db093e49 0f1f440000      nop     dword ptr [rax+rax]
0:000> .exr -1
ExceptionAddress: 00007ff9db093e49 (KERNELBASE!RaiseException+0x0000000000000069)
   ExceptionCode: e06d7363 (C++ EH exception)
  ExceptionFlags: 00000001
NumberParameters: 4
   Parameter[0]: 0000000019930520
   Parameter[1]: 0000006f0c50edf0
   Parameter[2]: 00007ff7bc6f3368
   Parameter[3]: 00007ff7bc4a0000

[jopletch]

Ping.

[metzman]

Sorry, didn't notice your response.
Do you need me to merge this for you?

[jopletch]

No problem -- yes, if you wouldn't mind that would be fantastic.

Thanks for the assistance in cleaning this up!

[morehouse]

LGTM

[wolfgangp]

The test seems to fail on some Linux buildbots, see here. Please review.

[jopletch]

Looking at these failures, they all appear to happen on platforms where programs can get ASAN allocation too large errors which doesn't include Windows or vanilla Linux x64. The fast solution is adding REQUIRE: windows to the test, but as the original intent was to bring the behavior in line with Linux we'd obviously lose the xplat testing aspect. However, I also don't think there's a REQUIRE keyword for "platform does not have an ASAN allocation size limit" (is there?), and adding one for this test seems a bit much. Happy to take guidance on what you'd prefer here.

As a procedural question, should whatever fix be added onto this changeset or a separate one?

[dyung]

The fix would normally be put in a separate change. If it is a small change, you could probably just do a post-commit review. We would like to get this either fixed or reverted so that we can get our internal build bot green again.

[morehouse]

Does setting ASAN_OPTIONS=allocator_may_return_null=1 help at all? I think it would cause std::bad_alloc on these platforms, which should also crash.

[metzman]

In D89755#2397497, @morehouse wrote:

Does setting ASAN_OPTIONS=allocator_may_return_null=1 help at all? I think it would cause std::bad_alloc on these platforms, which should also crash.

Trying this here: https://github.com/llvm/llvm-project/commit/a3be1287091463f4099cdb1710883645329cda7e

[metzman]

Looks like my fix broke windows.
http://lab.llvm.org:8011/#/builders/127/builds/1548
I'm going to undo my Win fix and disable it on Linux for now (https://github.com/llvm/llvm-project/commit/91703085f53428ea6305770d41db148e0ebbdea7)
I'll try again if http://lab.llvm.org:8011/#/builders/112/builds/1191 passes since I think it contains https://github.com/llvm/llvm-project/commit/a3be1287091463f4099cdb1710883645329cda7e
The problem is, I don't really know how I can set an env var in a way that works on Linux but doesn't cause failure on Win.
I have both platforms to test though

[metzman]

Disabling on Linux was right call as http://lab.llvm.org:8011/#/builders/112/builds/1191/steps/5/logs/stdio is failing with ASAN_OPTIONS fix.

compiler-rt/lib/fuzzer/FuzzerDriver.cpp

#endif // LIBFUZZER_EMSCRIPTEN
   Options.HandleFpe = Flags.handle_fpe;
   Options.HandleIll = Flags.handle_ill;
   Options.HandleInt = Flags.handle_int;
   Options.HandleSegv = Flags.handle_segv;
   Options.HandleTerm = Flags.handle_term;
   Options.HandleXfsz = Flags.handle_xfsz;
   Options.HandleUsr1 = Flags.handle_usr1;
   Options.HandleUsr2 = Flags.handle_usr2;
+  Options.HandleWinExcept = Flags.handle_winexcept;
+
   SetSignalHandler(Options);
 
   std::atexit(Fuzzer::StaticExitCallback);
 
   if (Flags.minimize_crash)
     return MinimizeCrashInput(Args, Options);
 
   if (Flags.minimize_crash_internal_step)

compiler-rt/lib/fuzzer/FuzzerFlags.def

 FUZZER_FLAG_INT(handle_abrt, 1, "If 1, try to intercept SIGABRT.")
 FUZZER_FLAG_INT(handle_ill, 1, "If 1, try to intercept SIGILL.")
 FUZZER_FLAG_INT(handle_fpe, 1, "If 1, try to intercept SIGFPE.")
 FUZZER_FLAG_INT(handle_int, 1, "If 1, try to intercept SIGINT.")
 FUZZER_FLAG_INT(handle_term, 1, "If 1, try to intercept SIGTERM.")
 FUZZER_FLAG_INT(handle_xfsz, 1, "If 1, try to intercept SIGXFSZ.")
 FUZZER_FLAG_INT(handle_usr1, 1, "If 1, try to intercept SIGUSR1.")
 FUZZER_FLAG_INT(handle_usr2, 1, "If 1, try to intercept SIGUSR2.")
+FUZZER_FLAG_INT(handle_winexcept, 1, "If 1, try to intercept uncaught Windows "
+    "Visual C++ Exceptions.")
 FUZZER_FLAG_INT(close_fd_mask, 0, "If 1, close stdout at startup; "
     "if 2, close stderr; if 3, close both. "
     "Be careful, this will also close e.g. stderr of asan.")
 FUZZER_FLAG_INT(detect_leaks, 1, "If 1, and if LeakSanitizer is enabled "
     "try to detect memory leaks during fuzzing (i.e. not only at shut down).")
 FUZZER_FLAG_INT(purge_allocator_interval, 1, "Purge allocator caches and "
     "quarantines every <N> seconds. When rss_limit_mb is specified (>0), "
     "purging starts when RSS exceeds 50% of rss_limit_mb. Pass "

compiler-rt/lib/fuzzer/FuzzerOptions.h

struct FuzzingOptions {
   bool HandleFpe = false;
   bool HandleIll = false;
   bool HandleInt = false;
   bool HandleSegv = false;
   bool HandleTerm = false;
   bool HandleXfsz = false;
   bool HandleUsr1 = false;
   bool HandleUsr2 = false;
+  bool HandleWinExcept = false;
 };
 
 }  // namespace fuzzer
 
 #endif  // LLVM_FUZZER_OPTIONS_H

compiler-rt/lib/fuzzer/FuzzerUtilWindows.cpp

switch (ExceptionInfo->ExceptionRecord->ExceptionCode) {
     case EXCEPTION_FLT_OVERFLOW:
     case EXCEPTION_FLT_STACK_CHECK:
     case EXCEPTION_FLT_UNDERFLOW:
     case EXCEPTION_INT_DIVIDE_BY_ZERO:
     case EXCEPTION_INT_OVERFLOW:
       if (HandlerOpt->HandleFpe)
         Fuzzer::StaticCrashSignalCallback();
       break;
-    // TODO: handle (Options.HandleXfsz)
+    // This is an undocumented exception code corresponding to a Visual C++
+    // Exception.
+    //
+    // See: https://devblogs.microsoft.com/oldnewthing/20100730-00/?p=13273
+    case 0xE06D7363:
+      if (HandlerOpt->HandleWinExcept)
+        Fuzzer::StaticCrashSignalCallback();
+      break;
+      // TODO: Handle (Options.HandleXfsz)
   }
   return EXCEPTION_CONTINUE_SEARCH;
 }
 
 BOOL WINAPI CtrlHandler(DWORD dwCtrlType) {
   switch (dwCtrlType) {
     case CTRL_C_EVENT:
       if (HandlerOpt->HandleInt)
if (Options.HandleInt || Options.HandleTerm)
     if (!SetConsoleCtrlHandler(CtrlHandler, TRUE)) {
       DWORD LastError = GetLastError();
       Printf("libFuzzer: SetConsoleCtrlHandler failed (Error code: %lu).\n",
         LastError);
       exit(1);
     }
 
   if (Options.HandleSegv || Options.HandleBus || Options.HandleIll ||
-      Options.HandleFpe)
+      Options.HandleFpe || Options.HandleWinExcept)
     SetUnhandledExceptionFilter(ExceptionHandler);
 
   if (Options.HandleAbrt)
     if (SIG_ERR == signal(SIGABRT, CrashHandler)) {
       Printf("libFuzzer: signal failed with %d\n", errno);
       exit(1);
     }
 }

compiler-rt/test/fuzzer/UncaughtException.cpp

+#include <cstdint>
+#include <vector>
+
+extern "C" int LLVMFuzzerTestOneInput(const std::uint8_t *data, size_t size) {
+  std::vector<uint8_t> v;
+  // Intentionally throw std::length_error
+  v.reserve(static_cast<uint64_t>(-1));
+
+  return 0;
+}

compiler-rt/test/fuzzer/uncaught-exception.test

+# Test that throws a C++ exception and doesn't catch it. Should result in a
+# crash
+RUN: %cpp_compiler %S/UncaughtException.cpp -o %t-UncaughtException
+
+RUN: not %run %t-UncaughtException 2>&1 | FileCheck %s
+
+CHECK: ERROR: libFuzzer: deadly signal
+CHECK: Test unit written to ./crash