[compiler-rt] [compiler-rt][rtsan] ptrace interception on Linux. (PR #123941)

[Chris Apple via llvm-commits]

================
@@ -1319,6 +1323,39 @@ INTERCEPTOR(ssize_t, process_vm_writev, pid_t pid,
 #define RTSAN_MAYBE_INTERCEPT_PROCESS_VM_WRITEV
 #endif
 
+#if SANITIZER_INTERCEPT_PTRACE
+#if SANITIZER_MUSL
+INTERCEPTOR(long, ptrace, int request, ...) {
+#else
+INTERCEPTOR(long, ptrace, enum __ptrace_request request, ...) {
+#endif // SANITIZER_MUSL
+  __rtsan_notify_intercepted_call("ptrace");
+  va_list args;
+
+  // A handful of ptrace requests need an additional argument on Linux/sparc
+  // (e.g. PTRACE_READDATA) but we only intercept the standard calls at the
+  // moment. We might need to rework all if rtsan is supported on BSD,
+  // interfaces differ vastly, data is read in word size on Linux vs large
+  // chunks on freebsd and so on ...
+  va_start(args, request);
+  pid_t pid = va_arg(args, pid_t);
----------------
cjappl wrote:

I think my concern with merging this is it's complexity.

I agree this call is real-time unsafe, but with the va_args and all this wrangling of them we have to ask "What are the odds this detects a real-time safety violation in user code?" vs "What if we inadvertently mess up and break someones code in an insidious way?"

This call and `prctl` (https://github.com/llvm/llvm-project/pull/124880) both are on the side of the complexity outweighing the benefit for me. I think we are more likely to introduce a bug than detect something in users code.

The more common a call is, and the easier to intercept it, the more we should lean towards intercepting.

That's my 2c, @davidtrevelyan any thoughts?

https://github.com/llvm/llvm-project/pull/123941