Bugzilla

This is a sandboxing issue on macOS 10.15. I'm testing a fix and should have it out for review today or tomorrow. Details below.

The cause of the crash is that new code in 10.15 triggers a crash when the pthread function ````pthread_setname_np```` fails when called from some macOS internal library threads. The function fails in the RDD process because of sandboxing restrictions where the ````setcontrol```` variant of the ````process-info```` syscall is not allowed. We allow this in content, but not RDD only because it was not known to be needed. The fix for bug 1560368 exposed this problem.

With a debug build, this is the call to ````pthread_setname_np```` that fails and causes the crash.

````
frame #0: 0x00007fff70e8598c libsystem_pthread.dylib`pthread_setname_np
frame #1: 0x00007fff6cb901f9 caulk`caulk::mach::this_thread::set_name(char const*) + 9
frame #2: 0x00007fff6cb976df caulk`caulk::thread::attributes::apply_to_this_thread() + 35
frame #3: 0x00007fff6cb98b36 caulk`void* caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, void (caulk::concurrent::details::worker_thread::*)(), std::__1::tuple<caulk::concurrent::details::worker_thread*> > >(void*) + 15
frame #4: 0x00007fff70e87cce libsystem_pthread.dylib`_pthread_start + 125
frame #5: 0x00007fff70e8472b libsystem_pthread.dylib`thread_start + 15
````

But this is the actual crash stack after the exception handling.

````
libc++abi.dylib: terminating with uncaught exception of type std::__1::system_error: pthread_setname_np failed: Operation not permitted

frame #0: 0x00007fff70dca6ce libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x00007fff70e87691 libsystem_pthread.dylib`pthread_kill + 258
frame #2: 0x00007fff70d52a5c libsystem_c.dylib`abort + 120
frame #3: 0x00007fff6de63bc8 libc++abi.dylib`abort_message + 231
frame #4: 0x00007fff6de63d64 libc++abi.dylib`demangling_terminate_handler() + 238
frame #5: 0x00007fff6f94ad52 libobjc.A.dylib`_objc_terminate() + 104
frame #6: 0x00007fff6de70da7 libc++abi.dylib`std::__terminate(void (*)()) + 8
frame #7: 0x00007fff6de70b55 libc++abi.dylib`__cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 27
frame #8: 0x00007fff6de6234f libc++abi.dylib`__cxa_throw + 113
frame #9: 0x00007fff6cb902b0 caulk`check_posix_error(char const*, int) + 168
frame #10: 0x00007fff6cb976df caulk`caulk::thread::attributes::apply_to_this_thread() + 35
frame #11: 0x00007fff6cb98b36 caulk`void* caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, void (caulk::concurrent::details::worker_thread::*)(), std::__1::tuple<caulk::concurrent::details::worker_thread*> > >(void*) + 15
frame #12: 0x00007fff70e87cce libsystem_pthread.dylib`_pthread_start + 125
frame #13: 0x00007fff70e8472b libsystem_pthread.dylib`thread_start + 15
````

The reason the fix for bug 1560368 exposes the crash appears to be that it causes these macOS library threads to be spawned which use the ````caulk```` code. One thread is named "AMCP Logging Spool".

````
thread #11, name = 'AMCP Logging Spool'
frame #0: 0x00007fff70dc43d2 libsystem_kernel.dylib`semaphore_wait_trap + 10
frame #1: 0x00007fff6cb99eb6 caulk`caulk::mach::semaphore::wait() + 16
frame #2: 0x00007fff6cb95452 caulk`caulk::semaphore::timed_wait(double) + 106
frame #3: 0x00007fff6cb98a04 caulk`caulk::concurrent::details::worker_thread::run() + 30
frame #4: 0x00007fff6cb98b54 caulk`void* caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, void (caulk::concurrent::details::worker_thread::*)(), std::__1::tuple<caulk::concurrent::details::worker_thread*> > >(void*) + 45
frame #5: 0x00007fff70e87cce libsystem_pthread.dylib`_pthread_start + 125
frame #6: 0x00007fff70e8472b libsystem_pthread.dylib`thread_start + 15

thread #12
frame #0: 0x00007fff70dc43d2 libsystem_kernel.dylib`semaphore_wait_trap + 10
frame #1: 0x00007fff6cb99eb6 caulk`caulk::mach::semaphore::wait() + 16
frame #2: 0x00007fff6cb95452 caulk`caulk::semaphore::timed_wait(double) + 106
frame #3: 0x00007fff6cb98a04 caulk`caulk::concurrent::details::worker_thread::run() + 30
frame #4: 0x00007fff6cb98b54 caulk`void* caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, void (caulk::concurrent::details::worker_thread::*)(), std::__1::tuple<caulk::concurrent::details::worker_thread*> > >(void*) + 45
frame #5: 0x00007fff70e87cce libsystem_pthread.dylib`_pthread_start + 125
frame #6: 0x00007fff70e8472b libsystem_pthread.dylib`thread_start + 15
````

For the fix, we must add access to ````process-info-setcontrol (target setlf)```` in the utility sandbox (used by the RDD process). The utility sandbox has a ````(deny process-info*)```` rule which blocks access to all process_info syscall calls unless they are explicitly allowed. We should also add this to the GMP process to avoid this problem happening with GMP in the future. The web content and Flash plugin sandboxes already allow process-info-setcontrol.

This is a sandboxing issue on macOS 10.15. I'm testing a fix and should have it out for review today or tomorrow. Details below.

The cause of the crash is that new code in 10.15 triggers a crash when the pthread function ````pthread_setname_np```` fails when called from some macOS internal library threads. The function fails in the RDD process because of sandboxing restrictions where the ````setcontrol```` variant of the ````proc_info```` syscall is not allowed. We allow this in content, but not RDD only because it was not known to be needed. The fix for bug 1560368 exposed this problem.

With a debug build, this is the call to ````pthread_setname_np```` that fails and causes the crash.

````
frame #0: 0x00007fff70e8598c libsystem_pthread.dylib`pthread_setname_np
frame #1: 0x00007fff6cb901f9 caulk`caulk::mach::this_thread::set_name(char const*) + 9
frame #2: 0x00007fff6cb976df caulk`caulk::thread::attributes::apply_to_this_thread() + 35
frame #3: 0x00007fff6cb98b36 caulk`void* caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, void (caulk::concurrent::details::worker_thread::*)(), std::__1::tuple<caulk::concurrent::details::worker_thread*> > >(void*) + 15
frame #4: 0x00007fff70e87cce libsystem_pthread.dylib`_pthread_start + 125
frame #5: 0x00007fff70e8472b libsystem_pthread.dylib`thread_start + 15
````

But this is the actual crash stack after the exception handling.

````
libc++abi.dylib: terminating with uncaught exception of type std::__1::system_error: pthread_setname_np failed: Operation not permitted

frame #0: 0x00007fff70dca6ce libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x00007fff70e87691 libsystem_pthread.dylib`pthread_kill + 258
frame #2: 0x00007fff70d52a5c libsystem_c.dylib`abort + 120
frame #3: 0x00007fff6de63bc8 libc++abi.dylib`abort_message + 231
frame #4: 0x00007fff6de63d64 libc++abi.dylib`demangling_terminate_handler() + 238
frame #5: 0x00007fff6f94ad52 libobjc.A.dylib`_objc_terminate() + 104
frame #6: 0x00007fff6de70da7 libc++abi.dylib`std::__terminate(void (*)()) + 8
frame #7: 0x00007fff6de70b55 libc++abi.dylib`__cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 27
frame #8: 0x00007fff6de6234f libc++abi.dylib`__cxa_throw + 113
frame #9: 0x00007fff6cb902b0 caulk`check_posix_error(char const*, int) + 168
frame #10: 0x00007fff6cb976df caulk`caulk::thread::attributes::apply_to_this_thread() + 35
frame #11: 0x00007fff6cb98b36 caulk`void* caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, void (caulk::concurrent::details::worker_thread::*)(), std::__1::tuple<caulk::concurrent::details::worker_thread*> > >(void*) + 15
frame #12: 0x00007fff70e87cce libsystem_pthread.dylib`_pthread_start + 125
frame #13: 0x00007fff70e8472b libsystem_pthread.dylib`thread_start + 15
````

The reason the fix for bug 1560368 exposes the crash appears to be that it causes these macOS library threads to be spawned which use the ````caulk```` code. One thread is named "AMCP Logging Spool".

````
thread #11, name = 'AMCP Logging Spool'
frame #0: 0x00007fff70dc43d2 libsystem_kernel.dylib`semaphore_wait_trap + 10
frame #1: 0x00007fff6cb99eb6 caulk`caulk::mach::semaphore::wait() + 16
frame #2: 0x00007fff6cb95452 caulk`caulk::semaphore::timed_wait(double) + 106
frame #3: 0x00007fff6cb98a04 caulk`caulk::concurrent::details::worker_thread::run() + 30
frame #4: 0x00007fff6cb98b54 caulk`void* caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, void (caulk::concurrent::details::worker_thread::*)(), std::__1::tuple<caulk::concurrent::details::worker_thread*> > >(void*) + 45
frame #5: 0x00007fff70e87cce libsystem_pthread.dylib`_pthread_start + 125
frame #6: 0x00007fff70e8472b libsystem_pthread.dylib`thread_start + 15

thread #12
frame #0: 0x00007fff70dc43d2 libsystem_kernel.dylib`semaphore_wait_trap + 10
frame #1: 0x00007fff6cb99eb6 caulk`caulk::mach::semaphore::wait() + 16
frame #2: 0x00007fff6cb95452 caulk`caulk::semaphore::timed_wait(double) + 106
frame #3: 0x00007fff6cb98a04 caulk`caulk::concurrent::details::worker_thread::run() + 30
frame #4: 0x00007fff6cb98b54 caulk`void* caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, void (caulk::concurrent::details::worker_thread::*)(), std::__1::tuple<caulk::concurrent::details::worker_thread*> > >(void*) + 45
frame #5: 0x00007fff70e87cce libsystem_pthread.dylib`_pthread_start + 125
frame #6: 0x00007fff70e8472b libsystem_pthread.dylib`thread_start + 15
````

For the fix, we must add access to ````process-info-setcontrol (target setlf)```` in the utility sandbox (used by the RDD process). The utility sandbox has a ````(deny process-info*)```` rule which blocks access to all proc_info syscall calls unless they are explicitly allowed. We should also add this to the GMP process to avoid this problem happening with GMP in the future. The web content and Flash plugin sandboxes already allow process-info-setcontrol.