Details
- Reviewers
eugenis
Diff Detail
Event Timeline
Please don't add new interceptors to msan_interceptors.cc. That just creates future work to move them to sanitizer_common.
lib/sanitizer_common/sanitizer_common_interceptors.inc | ||
---|---|---|
3076 | We should probably fix this also in sanitizer_common_syscalls.inc, then. |
lib/sanitizer_common/sanitizer_common_interceptors.inc | ||
---|---|---|
3076 | Also, I'm fairly sure res > 0 implies list != NULL. |
Dima has removed tsan_stat.*, hasn't he?
The file is there but it no longer has interceptor stats.
lib/sanitizer_common/sanitizer_common_interceptors.inc | ||
---|---|---|
3076 | Ok, looking at the man page it actually says: "An empty buffer of _size_ zero can be passed into these calls to return the current size of the list of extended attribute names" So we should not attempt to unpoison if size == 0. (The way this is formulated still doesn't allow list == 0, but it's probably best to check.) |
BTW, the code duplication between sanitizer_common_syscalls.inc and sanitizer_common_interceptors.inc is abhorrent. I think we should be able to reuse the PRE and POST hooks from sanitizer_common_syscalls.inc in sanitizer_common_interceptors.inc, since a lot of intercepted functions are simple syscall wrappers. Anyone disagree?
It would be nice to reuse some code, but we must be careful. A lot of syscalls have subtle difference in semantics with libc wrappers, especially in return value.
Looks like your wrappers are still incorrect. As I understood from man pages, these functions return the desired buffer size, which may be larger than allocated size. The wording is not clear, please verify. In that case we need to write max(size, res), or something like that.
In general, we write interceptors defensively, verifying that arguments make sense even if the doc says they must. Man pages are not specs, they are often wrong; and not everyone codes to specs.
It might be a good idea to move checks inside INTERCEPTOR_WRITE_RANGE / INTERCEPTOR_READ_RANGE in another refactoring CL.
In that case we need to write max(size, res), or something like that.
This would attempt to unpoison more memory than we actually have.
I think the wording is clear: if a buffer of zero size is passed, then the desired size is returned. Nothing is written to the buffer, it just tells us what kind of buffer is wanted. So no need to unpoison anything in this case.
This will fail if libattr is not installed. I think we need to check it either in configure/cmake or in this test, and pass if not found.