On 10.12.2017 14:13, Robert Elz wrote:
> Date: Sun, 10 Dec 2017 12:17:18 +0100
> From: Martin Husemann <martin%duskware.de@localhost>
> Message-ID: <20171210111718.GB1141%mail.duskware.de@localhost>
>
> | I very well understand your POV here, but it is important to fully
> | understand the problem before changing random things
>
> Let's not over react, the change was harmless, and the alternate reason
> that Kamil gave in one of the messages ...
>
>>> I think that reusing symbol names of well-known standard functions from
>>> libc is at least misleading and shouldn't happen - so the process of
>>> renaming such functions is improving the situation.
>
> would have been fine, no-one would have complained about that - and none
> of us would (today) use a function "uname" for anything other than the
> system call (ps is just SO old).
>
> After looking at the sources a bit, I would probably have picked euname()
> as the revised function name, ps also has runame (which it uses to print
> the "real" user name, and "svuname" which it uses to print the saved user
> name - the "uname" function was used to print the effective user name
> ("user name" in these cases being what comes from converting a uid to
> the associated string from /etc/passwd.)
>
> But these things are just names, and as long as they don't cause problems,
> and are not irrational, who cares?
>
> None of this means that the sanitizers shouldn't be fixed, by someone
> (I expecty not Kamil - just file a bug report with whoever maintains it
> upstream.)
>
> kre
>
I think I know how to address it long term. There is an option to
manually edit the GOT table and reinitialize it to wrappers for libc
functions. There is still need to bootstrap the sanitizers early before
the constructos will be fired so this is not that straightforward solution.
Short term (and currently realistic) goal is to get the sanitizers
functional on par with Linux. And this is what I'm heading now.
There is another aspect of the basesystem sanity. Can we call libc
functions from the internal namespace always? This is currently kind of
inconsequential. There are symbols in libc that are executed through PLT
with their original (public) names, e.g.:
- strlen
- memcpy
- memcmp
- memset
- wcslen
- wcschr
- malloc
- etc.
I prefer to focus on intercepting only the public functions and not
introspecting internals of libc when not needed.
Attachment:
signature.asc
Description: OpenPGP digital signature