Bug 1604834 - Assign thread names during the sandbox launch process. r=gcp

We've had some bugs where the sandboxed child process and/or the chroot
helper process deadlocks during launch, often reported by end users,
and it's confusing to have the mysterious hanging task inherit the name
of the launching thread; this patch fixes that by giving them more
informative names.

`prctl(PR_SET_NAME, ...)` is used directly, instead of via one of our
wrappers for it, to avoid the possibility of async signal unsafe
operations.

This doesn't name the pre-exec child process in the cases where regular
`fork()` is used, but as far as I know we haven't had any bugs (yet?)
where that would matter.

Differential Revision: https://phabricator.services.mozilla.com/D68134

--HG--
extra : moz-landing-system : lando

security/sandbox/linux/launch/SandboxLaunch.cpp

@@ -10,6 +10,7 @@
 #include <sched.h>
 #include <setjmp.h>
 #include <signal.h>
+#include <sys/prctl.h>
 #include <sys/socket.h>
 #include <sys/syscall.h>
 #include <unistd.h>
@@ -591,6 +592,7 @@ pid_t SandboxFork::Fork() {
   // WARNING: all code from this point on (and in StartChrootServer)
   // must be async signal safe.  In particular, it cannot do anything
   // that could allocate heap memory or use mutexes.
+  prctl(PR_SET_NAME, "Sandbox Forked");
 
   // Clear signal handlers in the child, under the assumption that any
   // actions they would take (running the crash reporter, manipulating
@@ -620,6 +622,7 @@ void SandboxFork::StartChrootServer() {
   if (pid > 0) {
     return;
   }
+  prctl(PR_SET_NAME, "Chroot Helper");
 
   LinuxCapabilities caps;
   caps.Effective(CAP_SYS_CHROOT) = true;