For now, xdrrec_create is only intercepted Linux as its signature
is different on Solaris.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
compiler-rt/lib/sanitizer_common/sanitizer_common_interceptors.inc | ||
---|---|---|
5803 | I would not do this, we unpoison *xdrs in some places, but its probably better not to rely on it. | |
5880 | There is a handle parameter, you can use it wrap both read and write by passing a pointer to {real_handle, ctx, real_write, real_read} as the new handle. |
compiler-rt/test/sanitizer_common/TestCases/Linux/xdrrec.cpp | ||
---|---|---|
4 | This line is unnecessary. |
compiler-rt/lib/sanitizer_common/sanitizer_common_interceptors.inc | ||
---|---|---|
5880 | I used that originally, but I was concerned the handle parameter might be saved somewhere inside the XDR struct in a user-accessible way. I actually went with the thread local data because these callbacks are used beyond the stack frame of just this function, so allocating such a struct on the stack would cause problems. |
compiler-rt/lib/sanitizer_common/sanitizer_common_interceptors.inc | ||
---|---|---|
5880 | Would not thread-local storage cause even bigger problems in that case? Imagine
|
This solution isn't super ideal but I couldn't think of a way around it.
We can't just allocate a handle on the heap in xdrrec_create and leave it at that, since there'd be no way to free it later. This is because it doesn't seem to be possible to access handle from the XDR struct, which is the only argument to xdr_destroy.
On the other hand, the callbacks don't have a way to get at the x_private field of XDR, which is what I chose for the HashMap key. So we need to wrap the handle parameter of the callbacks. But we can't just pass x_private as handle (as it hasn't been set yet). We can't put the wrapper struct into the HashMap and pass its pointer as handle, as the key we need (x_private again) hasn't been set yet.
So I allocate the wrapper struct on the heap, pass its pointer as handle, and put it into the HashMap so xdr_destroy can find it later and destroy it.
I would not do this, we unpoison *xdrs in some places, but its probably better not to rely on it.
This is terrible API and the less we do with it, the better.
Remove these three interceptors.