Date: Tue, 30 Sep 2025 17:33:18 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: Dag-Erling =?utf-8?B?U23DuHJncmF2?= <des@freebsd.org>, src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: d58339f39874 - main - tzcode: Drop libc namespace Message-ID: <aNvqLseKDu8ZRqhC@kib.kiev.ua> In-Reply-To: <b59650c6-92ab-4e53-bf66-47ff1d3e0b29@FreeBSD.org> References: <202509271707.58RH7ajb090983@gitrepo.freebsd.org> <aNhIKDCDJKWZbTqt@kib.kiev.ua> <86frc6bzcm.fsf@ltc.des.dev> <aNnZ1yPIMwzlyxCt@kib.kiev.ua> <b59650c6-92ab-4e53-bf66-47ff1d3e0b29@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Sep 30, 2025 at 09:56:06AM -0400, John Baldwin wrote: > 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 <kostikbel@gmail.com> 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. I thought about using the protected visibility in libc more, meantime. The case that is not fixed just by applying protected to exported functions is the use of that functions in related system libraries. E.g. we do want that call to exit() from libthr was directed to libc exit() and not to a user interposer. So we still need some symbol exported in the private version space, for use in libthr (or libm, or some other libraries: the scope needs to be defined), to ensure that no legal interposers are involved.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?aNvqLseKDu8ZRqhC>