Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Not sure I understand this.
If opendir() calls strlen(), which we already intersept, won't we see the access w/o this interceptor?
Not sure I understand this.
If opendir() calls strlen(), which we already intersept, won't we see the access w/o this interceptor?
I thought that glibc usually forces references to it's own functions to be linked internally (to avoid PLT costs). So ASan interceptor may not be called.
So the difference in observable behavior is we start detecting uninit in the opendir() argument? Why is this freebsd-specific?
Also, there should be a test.
If opendir() calls strlen(), which we already intersept, won't we see the access w/o this interceptor?
The point is that FreeBSD's opendir() calls strlen() for inspecting related internal structures and not the file path passed (the comment should mention it; my mistake). Then given we don't intercept opendir(), we indeed do catch poisoned file paths, but we also generate false positives on these internal structures. Since COMMON_INTERCEPTOR_ENTER() includes the declaration for interceptor scope, it suppresses the checks for whatever the real opendir() relies on.
- The opendir() interceptor moved to Msan so it doesn't interfere with the Tsan's one;
- The comment fixed to mention internal structures that cause false positives;
- A test added.
Got it.
This interceptor is beneficial on linux, too - it adds check for opendir() path.
Also, we've been moving interceptors to sanitizer_common, not the other way around. Please move it back, and merge the TSan bits into it (see COMMON_INTERCEPTOR_FD_ACQUIRE).
Looks ok, but I dislike the use of Dir2addr() in common interceptors, which is only valid in TSan and looks completely out of context. Maybe wrap it into COMMON_INTERCEPTOR_ACQUIRE_DIR?
Dmitry?
Perhaps COMMON_INTERCEPTOR_DIR_ACQUIRE, for similarity with FD_ACQUIRE / FD_RELEASE and MUTEX_LOCK / MUTEX_UNLOCK.