mac-arm64: Cope with signal handling quirks

On x86_64, it’s impossible for a signal handler distinguish between
SIGBUS caused synchronously by a hardware fault and SIGBUS raised
asynchronously by software. This remains true on arm64, and is expanded
to include both SIGILL and SIGSEGV.

Bug: crashpad:345
Test: crashpad_util_test Signals.Raise_HandlerReraisesTo*
Change-Id: I181ea35121048dc0c666e2346340e698220ca650
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2386463
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>

Author: markmentovai

util/posix/signals.cc

@@ -189,22 +189,25 @@ bool Signals::WillSignalReraiseAutonomously(const siginfo_t* siginfo) {
   // pointer), will not reoccur on their own when returning from the signal
   // handler.
   //
-  // Unfortunately, on macOS, when SIGBUS is received asynchronously via kill(),
-  // siginfo->si_code makes it appear as though it was actually received via a
-  // hardware fault. See 10.12.3 xnu-3789.41.3/bsd/dev/i386/unix_signal.c
-  // sendsig(). Asynchronous SIGBUS will not re-raise itself autonomously, but
-  // this function (acting on information from the kernel) behaves as though it
-  // will. This isn’t ideal, but asynchronous SIGBUS is an unexpected condition.
-  // The alternative, to never treat SIGBUS as autonomously re-raising, is a bad
-  // idea because the explicit re-raise would lose properties associated with
-  // the the original signal, which are valuable for debugging and are visible
-  // to a Mach exception handler. Since SIGBUS is normally received
-  // synchronously in response to a hardware fault, don’t sweat the unexpected
-  // asynchronous case.
+  // Unfortunately, on macOS, when SIGBUS (on all CPUs) and SIGILL and SIGSEGV
+  // (on arm64) is received asynchronously via kill(), siginfo->si_code makes it
+  // appear as though it was actually received via a hardware fault. See 10.15.6
+  // xnu-6153.141.1/bsd/dev/i386/unix_signal.c sendsig() and 10.15.6
+  // xnu-6153.141.1/bsd/dev/arm/unix_signal.c sendsig(). Received
+  // asynchronously, these signals will not re-raise themselves autonomously,
+  // but this function (acting on information from the kernel) behaves as though
+  // they will. This isn’t ideal, but these signals occurring asynchronously is
+  // an unexpected condition. The alternative, to never treat these signals as
+  // autonomously re-raising, is a bad idea because the explicit re-raise would
+  // lose properties associated with the the original signal, which are valuable
+  // for debugging and are visible to a Mach exception handler. Since these
+  // signals are normally received synchronously in response to a hardware
+  // fault, don’t sweat the unexpected asynchronous case.
   //
-  // SIGSEGV on macOS originating from a general protection fault is a more
-  // difficult case: si_code is cleared, making the signal appear asynchronous.
-  // See 10.12.3 xnu-3789.41.3/bsd/dev/i386/unix_signal.c sendsig().
+  // SIGSEGV on macOS on x86[_64] originating from a general protection fault is
+  // a more difficult case: si_code is cleared, making the signal appear
+  // asynchronous. See 10.15.6 xnu-6153.141.1/bsd/dev/i386/unix_signal.c
+  // sendsig().
   const int sig = siginfo->si_signo;
   const int code = siginfo->si_code;
 

util/posix/signals_test.cc

@@ -51,7 +51,7 @@ bool CanCauseSignal(int sig) {
 #endif  // !defined(ARCH_CPU_ARM64)
 #if defined(ARCH_CPU_X86_FAMILY) || defined(ARCH_CPU_ARMEL)
          sig == SIGILL ||
-#endif  // defined(ARCH_CPU_X86_FAMILY) || defined(ARCH_CPU_ARMEL
+#endif  // defined(ARCH_CPU_X86_FAMILY) || defined(ARCH_CPU_ARMEL)
          sig == SIGPIPE ||
          sig == SIGSEGV ||
 #if defined(OS_APPLE)
@@ -466,12 +466,16 @@ TEST(Signals, Raise_HandlerReraisesToDefault) {
     }
 
 #if defined(OS_APPLE)
-    if (sig == SIGBUS) {
-      // Signal handlers can’t distinguish between SIGBUS arising out of a
-      // hardware fault and SIGBUS raised asynchronously.
-      // Signals::RestoreHandlerAndReraiseSignalOnReturn() assumes that SIGBUS
-      // comes from a hardware fault, but this test uses raise(), so the
-      // re-raise test must be skipped.
+    if (sig == SIGBUS
+#if defined(ARCH_CPU_ARM64)
+        || sig == SIGILL || sig == SIGSEGV
+#endif  // defined(ARCH_CPU_ARM64)
+       ) {
+      // Signal handlers can’t distinguish between these signals arising out of
+      // hardware faults and raised asynchronously.
+      // Signals::RestoreHandlerAndReraiseSignalOnReturn() assumes that they
+      // come from hardware faults, but this test uses raise(), so the re-raise
+      // test must be skipped.
       continue;
     }
 #endif  // defined(OS_APPLE)
@@ -493,12 +497,16 @@ TEST(Signals, Raise_HandlerReraisesToPrevious) {
     }
 
 #if defined(OS_APPLE)
-    if (sig == SIGBUS) {
-      // Signal handlers can’t distinguish between SIGBUS arising out of a
-      // hardware fault and SIGBUS raised asynchronously.
-      // Signals::RestoreHandlerAndReraiseSignalOnReturn() assumes that SIGBUS
-      // comes from a hardware fault, but this test uses raise(), so the
-      // re-raise test must be skipped.
+    if (sig == SIGBUS
+#if defined(ARCH_CPU_ARM64)
+        || sig == SIGILL || sig == SIGSEGV
+#endif  // defined(ARCH_CPU_ARM64)
+       ) {
+      // Signal handlers can’t distinguish between these signals arising out of
+      // hardware faults and raised asynchronously.
+      // Signals::RestoreHandlerAndReraiseSignalOnReturn() assumes that they
+      // come from hardware faults, but this test uses raise(), so the re-raise
+      // test must be skipped.
       continue;
     }
 #endif  // defined(OS_APPLE)