From nobody Fri May 16 12:22:52 2025 X-Original-To: current@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 4ZzR723tm2z5vcBv for ; Fri, 16 May 2025 12:22:54 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZzR723DXtz46P9; Fri, 16 May 2025 12:22:54 +0000 (UTC) (envelope-from avg@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747398174; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=LSDr80Yz4mR6wU2mntIBRA6PvsKdpwUdFX7ykXAbqSY=; b=szLWIUBUkt4e6I7p/o2AkGpMy/OKytpyBFukFurJ99Fo85dwjVoT5DWPQlkuZT8PCXTg+0 y8dESaJjXIxUPeSgi3hkdbz09z2Kco3l2c1A5gLzDJbz6ENvBN2uM3go6zYx2Fx1ZXV/Ew slBSn3PabUouUGuKatDzcsVSGz/EPNQAQCy2/ZzNcQoCps4B/MqeglZMxXl0qEGFBGzeUy bjK5wX65AEis4EcZsy3J7w4ioOhgCeMIaTcln9wariGFE/yImtVeYrQNa22MyJtT0UFli7 B1yLxey0i8O/NnPIyTG+aD30KDOS7n4IGoa0xn9wXAlvv4Bnhjdg66RmdIJCQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747398174; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=LSDr80Yz4mR6wU2mntIBRA6PvsKdpwUdFX7ykXAbqSY=; b=rx67VtBD3vVF31djJM43FKzJM2HoU0ZsZZWjzb1kEpjM20ZYkSZFBPuZUE7veKNzt8PF5O U2dv+CQw7XJP6qFoEwWtmBQvKUuFera4Op9iXvjc9MROBV8uigdty7tYQ4wNiabsBTKcKk +Ik98Om0pJ4iOC/eUpMGjz7FmQMXQCoPZDDQZ6ret1fT3sVCHiUvsbacF8SwTObof7ih23 4QCKlHmFzsgXorcSrWkgH+uYveRv9BT0xOrf2D3w+QN6XHY5ayTSmaAza1CRvRP+YwIq+D 3Ked1Dy/VOERC3v96UXFBd+4TfUm0rPxH3/2pTENtqZKDUsHKdfQgWVxbtDWDw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1747398174; a=rsa-sha256; cv=none; b=NOBu3tmA0YDVGHWk8mZs0yJcImZywUobVmHOBMeDPUZ05SwFNv79TwL5r5N+PC0rdRa/5M 70nRxZ5pnRsmx7RWraG0gvqtYEJtqIL8YKqG4J/sjaH3dTSFa8rKHqA3fv60g51Kw5zNey kT3jlnFMDX2nsJp09dsiDVvTzkijMOWIgiR2m7sudCu3HQM2+M48FzZ/JKHg/rn7p24qTY SidIDQPsXphGuiON9yyod2cAn68jBSd99g14tbChoF47mvDVEEjnOELEwdrQ4QQuGxFtnY g88HmDC3wM8vHWd76gJDDwbsjbwZD906oE9hZUeZOgls1JAmltIKSvaNlgrp3g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [192.168.0.88] (unknown [93.188.39.137]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZzR716Gzlzt0G; Fri, 16 May 2025 12:22:53 +0000 (UTC) (envelope-from avg@freebsd.org) Message-ID: <5b887290-a6aa-49ff-aa92-f335ed09b9a5@freebsd.org> Date: Fri, 16 May 2025 15:22:52 +0300 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Andriy Gapon Subject: Re: RTLD_DEEPBIND question To: Mark Johnston Cc: Konstantin Belousov , FreeBSD Current References: <0b3dda4e-53e4-40e5-9484-8b5ffb84e658@FreeBSD.org> <900c8521-559a-47b5-acaa-ae941f6852c4@freebsd.org> <7c4e1682-d797-493c-8326-08d51dde3359@FreeBSD.org> <59db8ace-770f-4f73-976f-411f6de0885a@FreeBSD.org> Content-Language: en-US Autocrypt: addr=avg@freebsd.org; keydata= xsDNBGcKrHEBDADRvwQOK0b/yo4ys5cs6bOQMhEh4xtfbaZ/CU00cpPgUip3sOZCdrtMWlRC g25z97prxE9pKueZi+HXDhIPpa9xl14ghqF4oYScuJ1i18HyiOH2y5Q3Vv/TtFiSzicd3EAu QgS3jVidpgDSPDdj2Yz3UxYpZ+PuFl6nOnvCvqOFcjUlzKCyPaiN2b86l1Nscmhnc+zQ/faB erUOEFEDQbWMA5YfXi8HrbeR16hfRfGt7E0aMDlIj9FIPIq71UWMN9CimPgs4+rbNr1MAlLa z4GxSDhVYZEY5rqtCzr+PLXboRQWnaUwXl0/biw9enf17NHdYv1SNAFTX2eC4dZ3qBVI74dS PgNprm+PMfz+6Hhs/dAv+Nan5nVhg3EFIjYTiy0MnjMSq8uI0v0ykpAGAcJJ5xl6d23aLxgN 6f0z6pJRCO0hGPgU7UzvFD0MxJxmbzqdT1R51KDan1oD41b+tjl2LMBuCDCoB0U44Pu0zLdp xMfFTxCXtwIYKIUxwd28jwMAEQEAAc0eQW5kcml5IEdhcG9uIDxhdmdARnJlZUJTRC5vcmc+ wsENBBMBCAA3FiEEmXvSmjiQFHPVOpLnzDOt5NLj67sFAmcKrHEFCQeEzgACGwMECwkIBwUV CAkKCwUWAgMBAAAKCRDMM63k0uPru5tSDACFK15LLbq89RSQ6QMnjiIm1t/wYJyumb519MHu Dhzxx1lbr8oghf0RHtF6kYRLQPaW2VdToi74pRobd3CN4bhZKDLSL6WfTn17RfavDjL6Njwp KBo30CkOeYKWq1mDmo0xEoQj8cc7ybEZnus+YScZOpj8Ti4EFwhRt6SHer7YDb161IHKL8m4 MsCxpFSGEjbKj8Iul3Ri/fTOO8w14ivcuEEQIvJt4/+4YV5Az8G23wKzL/3aJ7SOT3oYGmR9 atBTmVO3DlODjM+rZLegd8SfLSPTcBTHspWE5duemIzZbEX3BP77r3Qx4Fo5Tkit3bG1XVar yPQato+sFGFEGifdE9USBQoAoOaaeZevwAWjDU0TIuCT0CUe0sKtQuNP4LRq0n9EEHOXBu9a CfdMhFUSkAZnuE7miSVwgPvoVNJ1stA37EXLN/sVsWik7wslTQ5vF81VpdGFiwoQPOe2XEKh ogcwGSnXbwv1gD4x+Gz/7Y+kFyr1NY+4/nSaeXVcS2fOwM0EZwqscgEMAMQTe6ypAmQe/TFO HqKD2hfFKdksTptKi6uEh8xIwct8G/0FBldDWXo9eu8CGr/ZrDg0/bAwJxbaLRQCMH19Gq2Y hLvZ1QK5GQJVzZKcqfxbF2LiDUTs6WkdOBIhGpdDy7p1xFrvqCGCtNFYHuGYm067EozibBSF BWAPstKu2FQuVHZNMOfs7p3OIz3Yfqu9woXDeg3/8G2qVQJINe+8EwXKlhgh4CyDbq7nAZoA kIu1SE9z9u3WI5mcNy/0dFmVUsFxBqRC3ewbvzie8tKyZ9yFOlaZPT0Y4nRBXQTI3mLZ8zQ8 mtrWK5OOmrJ02kdeO9RBXe+OMaUUWMf92ZIoBFb4HP6N+B+4N1y1OwULousfl7JRoYxA4MRL ls7E2sSoJvrEBTJB3Pc34xu8rsJ1A5V3NgN6djX8yEZYpTRkcmrBeWy/ofDqZPVqneAx0LRm eldDS9msXDW4KXODyPZ+9unvmHAcoH0xaBYaSH44CDZDQDg4LNcmbOvuu1TEXBJhjQARAQAB wsD8BBgBCAAmFiEEmXvSmjiQFHPVOpLnzDOt5NLj67sFAmcKrHMFCQeEzgACGwwACgkQzDOt 5NLj67sUCAv5AXqgWnYN9EblapMbZjkiqL8pZQ0GNqh+Pg9FwbyULxjtRTO6rD4D0IxizByb ef+neeUNyYlagt5nfKMysEr0SU/gHKCi8vyTF/63ukMrGUNGmJJxrndl5ZYKC6j6eX7twrZF L1Uvlmn6FnQ22red5kHO93fDjG4zaDIZvHfwj7kzjZ4tpC7Byinf88s14mdZeScc0PnU2hj4 UGYju/wg2FF4YxaZYhcmdTiRYY0Wx85XSMZv19pnn78sadEuRvfRd4JTmw++j1xGXeqQGWzz /CTG5/Ex9GAkQ02hZbmi236byDXoet4G8TEyOph9QFVkV9bNd0jQZaFZPGEj4PSPUYGAF7s5 xJaNGgctC3aZ7WjEv1FBoo44XCU4xcjJ1wZQUrHxRhx6TW0Jtcl0U9qfKFW30TSPo6RyiXuj X4ltWKAtjoXB8nUmEJckaz7IRu2b4pXDeazZuz5JBygUs10yJjDxh2vFQZo0KaBAPx9MZlPn gpPTjT15L8xGftEjQXF6 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 27/04/2025 17:26, Mark Johnston wrote: > On Thu, Apr 24, 2025 at 08:56:44AM +0300, Andriy Gapon wrote: >> On 23/04/2025 21:56, Andriy Gapon wrote: >>> BTW, I've been wondering how illumos avoids the problem even though they >>> do not use any special dlopen flags. >>> It turns out that they link almost all system shared libraries with >>> -Bdirect option (which is Solaris/illumos specific). >>> It's somewhat similar to, but different from, -Bsymbolic. >>> https://docs.oracle.com/cd/E23824_01/html/819-0690/aehzq.html#scrolltoc >>> https://docs.oracle.com/cd/E36784_01/html/E36857/gejfe.html >> >> Oh, and it looks like there is an even better explanation for illumos. >> There is a version map file for libdtrace which explicitly lists API >> functions and makes everything else local. >> https://github.com/illumos/illumos-gate/blob/master/usr/src/lib/libdtrace/common/mapfile-vers >> >> I wonder why we didn't do the same when porting. >> Maybe we should do that now? > > I don't have any objection, but I believe adding a version map after the > fact doesn't accomplish much, assuming that we care deeply about ABI > stability in libdtrace.so (I'm not sure we do though). My primary goal here is not ABI stability, but hiding symbols that really should not be exported. See more at the end. At the same time I am not sure why it could be too late to start caring about ABI stability now. Assuming we actually would want to do that. And I don't want to single out libtrace here. It seems that the story is the same for all libraries that have been ported from illumos. E.g., libzfs_core was supposed to be a library that cares greatly about its API / ABI stability. >>> I think that on FreeBSD we should use symbol visibility attributes or a >>> symbol map to hide (make local) symbols that are not expected to be >>> interposed or have a high chance to be interposed by accident. >>> >>> IMO, yyparse should definitely get that treatment. >>> >>> I think that approach would be better than magic rtld tricks. >>> Especially because the tricks do not work with the current rtld. >>> I'd rather make a change to libdtrace.so than to rtld. >> >> This, while not as nice as the illumos solution, fixes my specific issue: >> diff --git a/cddl/lib/libdtrace/Makefile b/cddl/lib/libdtrace/Makefile >> index d086fffb07bc..58054d129b49 100644 >> --- a/cddl/lib/libdtrace/Makefile >> +++ b/cddl/lib/libdtrace/Makefile >> @@ -146,7 +146,8 @@ CFLAGS+= -fsanitize=address -fsanitize=undefined >> LDFLAGS+= -fsanitize=address -fsanitize=undefined >> .endif >> >> -LIBADD= ctf elf proc pthread rtld_db xo >> +VERSION_MAP= ${.CURDIR}/Symbol.map >> +LIBADD= ctf elf proc pthread rtld_db xo >> >> CLEANFILES= dt_errtags.c dt_names.c >> >> diff --git a/cddl/lib/libdtrace/Symbol.map b/cddl/lib/libdtrace/Symbol.map >> new file mode 100644 >> index 000000000000..89ee9de65209 >> --- /dev/null >> +++ b/cddl/lib/libdtrace/Symbol.map >> @@ -0,0 +1,4 @@ >> +{ >> + local: >> + yy*; >> +}; > > This just gives the lexer/parser symbols in libdtrace.so local > visibility? I think that's fine. Yes, that's the intention. I tested locally two versions of Symbol.map for libdtrace. The basic one quoted here and a more extended one based on illumos lib/libdtrace/common/mapfile-vers. The latter version does not define any symbol versions, its purpose is only to be a white-list of things to make public / global: https://people.freebsd.org/~avg/libdtrace-Symbol.map Comparing to illumos I only had to add 3 dtrace_oformat* symbols, Both versions worked equally well in my tests, but maybe I missed more of FreeBSD extensions. Which one would be better to get into the tree? Thank you. -- Andriy Gapon