On 9/28/25 20:59, Konstantin Belousov wrote:
On Sun, Sep 28, 2025 at 01:17:29PM +0200, Dag-Erling Smørgrav wrote:
Konstantin Belousov <[email protected]> writes:
It does change the behavior. Now a user-provided open/fstat/pthread_*
functions can interpose the system functions, making tz code doing something
that was not intended.
In other words, namespacing guaranteed that tzcode was not affected by
the app playing with libc namespace.
That is a side effect of namespace.h but not its original purpose, which
was to allow libc to call pthread functions, which would be stubbed out
when libc_r was not loaded. This is no longer needed, and namespace.h
has bitrotted and is missing a bunch of syscalls and functions
(including nearly every *at() system call, with the sole exception of
openat()).
Well, this is same as the biology: most features current uses have nothing
to do with the cause of its appearance.
But still, I think we should decide if we want to keep this guarantee of
the libc semantic in presence of user interposing. Then we can either
fix the missing overrides or drop the feature altogether.
For ELF, I believe that we can implement this resilience to interposing
much cleaner using protected symbol visibility for symbols exported by
libc. But still, we need to decide what we do.
The only trick with protected symbols is that copy relocations don't work
correctly, but that only matters for data symbols not functions. FWIW,
after my linker talk at EuroBSDCon a few days ago, multiple folks mentioned
to me that protected symbols should be used more. One suggested that ELF
should even default to "protected" instead of "default" visibility requiring
overridable-symbols to be marked as such explicitly.
However, protected symbols for functions is a fairly clean fix that doesn't
depend on namespace mangling or inline assembly hacks, etc.
--
John Baldwin
