[compiler-rt][rtsan] pathconf/fpathconf interception.

[devnexen]

No description provided.

[llvmbot]

@llvm/pr-subscribers-compiler-rt-sanitizer

Author: David CARLIER (devnexen)

Changes

---

Full diff: https://github.com/llvm/llvm-project/pull/134495.diff

2 Files Affected:

• (modified) compiler-rt/lib/rtsan/rtsan_interceptors_posix.cpp (+12)
• (modified) compiler-rt/lib/rtsan/tests/rtsan_test_interceptors_posix.cpp (+12)

diff --git a/compiler-rt/lib/rtsan/rtsan_interceptors_posix.cpp b/compiler-rt/lib/rtsan/rtsan_interceptors_posix.cpp
index e8cea21ddf9aa..7c7c7e138a652 100644
--- a/compiler-rt/lib/rtsan/rtsan_interceptors_posix.cpp
+++ b/compiler-rt/lib/rtsan/rtsan_interceptors_posix.cpp
@@ -712,6 +712,16 @@ INTERCEPTOR(mode_t, umask, mode_t cmask) {
   return REAL(umask)(cmask);
 }
 
+INTERCEPTOR(long, pathconf, const char *path, int name) {
+  __rtsan_notify_intercepted_call("pathconf");
+  return REAL(pathconf)(path, name);
+}
+
+INTERCEPTOR(long, fpathconf, int fildes, int name) {
+  __rtsan_notify_intercepted_call("fpathconf");
+  return REAL(fpathconf)(fildes, name);
+}
+
 // Concurrency
 #if SANITIZER_APPLE
 #pragma clang diagnostic push
@@ -1596,6 +1606,8 @@ void __rtsan::InitializeInterceptors() {
   INTERCEPT_FUNCTION(mkdir);
   INTERCEPT_FUNCTION(rmdir);
   INTERCEPT_FUNCTION(umask);
+  INTERCEPT_FUNCTION(pathconf);
+  INTERCEPT_FUNCTION(fpathconf);
   INTERCEPT_FUNCTION(ioctl);
 
   RTSAN_MAYBE_INTERCEPT_OSSPINLOCKLOCK;
diff --git a/compiler-rt/lib/rtsan/tests/rtsan_test_interceptors_posix.cpp b/compiler-rt/lib/rtsan/tests/rtsan_test_interceptors_posix.cpp
index 048da5858d665..dd55da54f8646 100644
--- a/compiler-rt/lib/rtsan/tests/rtsan_test_interceptors_posix.cpp
+++ b/compiler-rt/lib/rtsan/tests/rtsan_test_interceptors_posix.cpp
@@ -793,6 +793,18 @@ TEST_F(RtsanOpenedFileTest, FchmodDiesWhenRealtime) {
   ExpectNonRealtimeSurvival(Func);
 }
 
+TEST_F(RtsanFileTest, PathconfDiesWhenRealtime) {
+  auto Func = [this]() { pathconf(GetTemporaryFilePath(), _PC_LINK_MAX); };
+  ExpectRealtimeDeath(Func, "pathconf");
+  ExpectNonRealtimeSurvival(Func);
+}
+
+TEST_F(RtsanOpenedFileTest, FpathconfDiesWhenRealtime) {
+  auto Func = [this]() { fpathconf(GetOpenFd(), _PC_LINK_MAX); };
+  ExpectRealtimeDeath(Func, "fpathconf");
+  ExpectNonRealtimeSurvival(Func);
+}
+
 TEST(TestRtsanInterceptors, UmaskDiesWhenRealtime) {
   auto Func = []() { umask(0); };
   ExpectRealtimeDeath(Func, "umask");

[davidtrevelyan]

@devnexen is there a particular situation in which you see these interceptors being particularly helpful? I'm keen to understand the layers here - what is the route to these functions being called? Direct calls? Standard library?

[devnexen]

depends on the query. Ideally, most of them ought to be called at initialisation time. For non deterministic queries, e.g. _PC_NAME_MAX, mount points and metadata, it might not be safe to call can be flagged in rtsan context. wdyt ?

[davidtrevelyan]

depends on the query. Ideally, most of them ought to be called at initialisation time. For non deterministic queries, e.g. _PC_NAME_MAX, mount points and metadata, it might not be safe to call can be flagged in rtsan context. wdyt ?

Thanks for the info! For me it depends on whether these functions would realistically ever be accidentally called in a real-time context by someone doing real-time programming. Unfortunately there are many non-deterministic system functions and we're unlikely to be able to intercept them all, at least in the near term, until we have a better implementation with (perhaps) code generation to make it maintainable. I believe we should concentrate on the functions for which interception delivers most value to the real-time programmer.

Your helpful point about them being mostly initialisation-time use-cases is good - this makes me lean towards not intercepting them in this case. But I don't have strong feelings about it.