Processes killed by EXC_GUARD and fatal EXC_RESOURCE exceptions have a successful exit status instead of SIGKILL
| Originator: | mark | ||
| Number: | rdar://20467672 | Date Originated: | 2015-04-08 |
| Status: | Open | Resolved: | |
| Product: | OS X | Product Version: | 10.9.5 13F1066, 10.10.2 14C1514 |
| Classification: | Serious Bug | Reproducible: | Always |
Processes can be killed by an EXC_GUARD exception (GUARD_TYPE_MACH_PORT or GUARD_TYPE_FD) or an EXC_RESOURCE exception made fatal (RESOURCE_TYPE_CPU/FLAVOR_CPU_MONITOR_FATAL or RESOURCE_TYPE_WAKEUPS/FLAVOR_WAKEUPS_MONITOR when WAKEMON_MAKE_FATAL has been set). Although there are no public APIs to request these behaviors, Apple library code makes use of these features, so these violations can and do occur in user programs from third-party developers using only public APIs.
When a process is killed for any of these reasons, its exit status as returned to its parent by waitpid() or any other call in the wait() family should indicate that the process was killed. The exit status should not indicate success (0). Returning a successful exit status can mislead the killed process’ parent into believing that the killed process actually completed successfully. Normally, a process killed with prejudice will have an exit status reporting termination by signal SIGKILL.
Of these possible EXC_GUARD and fatal EXC_RESOURCE exceptions, only EXC_GUARD for GUARD_TYPE_FD properly causes a process to show termination by SIGKILL as its exit status. The other exceptions result in the process having a 0 exit status, indicating normal termination.
Steps to Reproduce:
The attached set of test programs triggers these exceptions. While they use non-public interfaces, this is just to establish the conditions under which the kernel will terminate them for a guard or resource violation. Ordinary user programs can experience termination for these reasons without using any non-public interfaces when system library code enables guards or resource monitors.
1. unzip exc_guard_and_resource.zip
2. cd exc_guard_and_resource
3. sh test.sh
Expected Results:
All of the tests result in an EXC_GUARD or fatal EXC_RESOURCE exception, and each should have an exit status indicating that it was killed by SIGKILL (9) with perhaps the WCOREFLAG bit set (SIGKILL | WCOREFLAG = 137).
$ unzip exc_guard_and_resource.zip
$ cd exc_guard_and_resource
$ sh test.sh
Compiling exc_guard_file_descriptor
Compiling exc_guard_mach_port
Compiling exc_resource_cpu_usage
Compiling exc_resource_wakeups
Running exc_guard_file_descriptor
test.sh: line 17: 234 Killed: 9 "./${test}"
Exit status from exc_guard_file_descriptor: 137 (good)
Running exc_guard_mach_port
test.sh: line 17: 235 Killed: 9 "./${test}"
Exit status from exc_guard_mach_port: 137 (good)
Running exc_resource_cpu_usage
test.sh: line 17: 236 Killed: 9 "./${test}"
Exit status from exc_resource_cpu_usage: 137 (good)
Running exc_resource_wakeups
test.sh: line 17: 237 Killed: 9 "./${test}"
Exit status from exc_resource_wakeups: 137 (good)
Actual Results:
Only exc_guard_file_descriptor, an EXC_GUARD violation for GUARD_TYPE_FILE_DESCRIPTOR, has the correct exit status. All other tests report an exit status of 0, indicating success, even though all of the tests are killed by the kernel.
$ unzip exc_guard_and_resource.zip
$ cd exc_guard_and_resource
$ sh test.sh
Compiling exc_guard_file_descriptor
Compiling exc_guard_mach_port
Compiling exc_resource_cpu_usage
Compiling exc_resource_wakeups
Running exc_guard_file_descriptor
test.sh: line 17: 123 Killed: 9 "./${test}"
Exit status from exc_guard_file_descriptor: 137 (good)
Running exc_guard_mach_port
Exit status from exc_guard_mach_port: 0 (bad)
Running exc_resource_cpu_usage
Exit status from exc_resource_cpu_usage: 0 (bad)
Running exc_resource_wakeups
Exit status from exc_resource_wakeups: 0 (bad)
Version:
This was tested and occurs on both 10.10.2 14C1514 and 10.9.5 13F1066.
Comments
Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!