From nobody Tue Sep 30 14:33:18 2025 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cbgXV10Jjz69B0r; Tue, 30 Sep 2025 14:33:30 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cbgXT4YgFz3G5l; Tue, 30 Sep 2025 14:33:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 58UEXIYa071246; Tue, 30 Sep 2025 17:33:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 58UEXIYa071246 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 58UEXIjQ071245; Tue, 30 Sep 2025 17:33:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 30 Sep 2025 17:33:18 +0300 From: Konstantin Belousov To: John Baldwin Cc: Dag-Erling =?utf-8?B?U23DuHJncmF2?= , 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: References: <202509271707.58RH7ajb090983@gitrepo.freebsd.org> <86frc6bzcm.fsf@ltc.des.dev> List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cbgXT4YgFz3G5l 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 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.