On 09.12.2017 23:41, David Young wrote:
> On Sat, Dec 09, 2017 at 03:46:42PM +0100, Kamil Rytarowski wrote:
>> I'm testing LLVM sanitizers. Right now, not every one is compatible
>> as-is, because there are linker issues. The sanitizers redefine symbols
>> for routines in libc like uname(3) in order to sanitize it with internal
>> logic. However there exist programs in the basesystem that shadow libc
>> symbol routines as well, for example ps(1):
>>
>> bin/ps/extern.h:void uname(struct pinfo *, VARENT *, enum mode);
>> bin/ps/keyword.c: VAR4("user", "USER", LJUST, uname),
>> bin/ps/print.c:uname(struct pinfo *pi, VARENT *ve, enum mode mode)
>
> Hi Kamil,
>
> I am curious where this redefinition occurs.
>
> For example, does an LLVM pass look for calls to `uname` and rewrite
> them to call `intercept_uname`? In that case, it seems like it could
> check the number & type of parameters and then skip the rewriting if
> there was not a match.
>
> Or does some symbol rewriting trickery---perhaps with objcopy, ld, or
> the moral equivalent---perform the rewriting?
>
> I was under the impression that at least part of the LLVM-tsan rewriting
> was done using the dlsym() tricks, but a badly out-of-date LLVM-tsan may
> have made that impression. :-) Or maybe you're talking about one of the
> other sanitizers.
>
> Dave
>
We add a local symbols that shadow the PLT ones from external libraries.
We call the locally defines ones directly. Sanitizers establish dlsym(3)
trickery on the first call to its libraries - intercepting all
invocations of for instance 'uname'. Some real (PLT) functions like
memcpy(3) are never called and are always shadowed by sanitizers as they
need them for functional dynamic linking features.
Attachment:
signature.asc
Description: OpenPGP digital signature