From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2, URIBL_BLACK autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 27006 invoked from network); 29 Jul 2022 06:19:45 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 29 Jul 2022 06:19:45 -0000 Received: (qmail 26615 invoked by uid 550); 29 Jul 2022 06:19:42 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 26580 invoked from network); 29 Jul 2022 06:19:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mac.com; s=1a1hai; t=1659075569; bh=Q4fyNGtihfaGqCrPKKp+9xRTYPtAi7d953JHdq3jyHM=; h=From:Content-Type:Mime-Version:Subject:Date:To:Message-Id; b=syFyIpwLd/OAApRRg4niwPRP4f4RWpIguM14tj7DYHFoHM/yYWGUjqcMTCOXIKwKq +080Iw1I+Q1VS9ZLhvwVYFYXSyPQ9FpPAQfloPrTgRbkuKVHoeXb2xFVNCHH7owz1Q HWdGatqsTygQ1Fc/MY5hwdzM8dT+fbsvuc1lZnd2XDU7Ruxw5fGyzwi3C4JIhGxl/G 2a56UdAPTa28l0oR379+ZKZQHQqGe+GshO6nXGiYTA9rRsJRNAB1UwIRYS+Kg6LoeU ny/fCMZ6cs9ERnaHCNfC4Ye1raWgyTyeK2MC+xbYxmiJ+2CUGSpuu3kP1c6JkFcYyP KXaQ0mfwryE4g== From: Christopher Sean Morrison Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Fri, 29 Jul 2022 02:19:28 -0400 References: <43e9ad2b-d53c-5fd5-0211-766f946c90f9@landley.net> <48546934-5ccd-0b1e-bf2b-306133101c6b@landley.net> <03A11083-A7D8-409E-BA70-AC42F52FF7B2@mac.com> <20220728091827.GD1320090@port70.net> <20220729000735.GN7074@brightrain.aerifal.cx> To: musl@lists.openwall.com In-Reply-To: <20220729000735.GN7074@brightrain.aerifal.cx> Message-Id: <80B01176-DCB8-4186-A543-15D9C895170B@mac.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Proofpoint-GUID: z4xq1ZP1xdR6ndThpk05hx3PBktfbC49 X-Proofpoint-ORIG-GUID: z4xq1ZP1xdR6ndThpk05hx3PBktfbC49 X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?= =?UTF-8?Q?2903e8d5c8f:6.0.517,18.0.572,17.0.605.474.0000000_definitions?= =?UTF-8?Q?=3D2022-06-21=5F01:2022-06-21=5F01,2020-02-14=5F11,2020-01-23?= =?UTF-8?Q?=5F02_signatures=3D0?= X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 mlxlogscore=999 suspectscore=0 adultscore=0 phishscore=0 mlxscore=0 spamscore=0 bulkscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000 definitions=main-2207290025 Subject: Re: [musl] dynamic linker is capturing "reserved" library names erroneously Hi Rich, > On Jul 28, 2022, at 8:07 PM, Rich Felker wrote: >=20 > As others have noted, the behavior of -lrt is defined as linking the = standard library for realtime interfaces, not a user-defined library by = that name. Others have not stated that or I would have called the specific claim = into scrutiny. Unless my junk mail filter is being aggressive, = there=E2=80=99s been only one reply prior. As to the claim, though, = that behavior is only mentioned in regards to the c99 utility and its = compile-time link editor resolution. There is no issue raised with = regards to the c99 utility or compile-time symbol resolution. Both gcc and clang indeed resolve symbols on musl at compile time = without issue and consistent with their behavior on other platforms. My = example showed that intentionally. The dynamic linker is what=E2=80=99s = at issue and the standard says absolutely nothing about it from what I = can see. > The specification goes so far as to say, regarding use of -L to try to = override that: >=20 > If a directory specified by a -L option contains files with names > starting with any of the strings "libc.", "libl.", "libpthread.", > "libm.", "librt.", "libtrace.", "libxnet.", or "liby.", the results > are unspecified. Again, you've quoted the =E2=80=98c99=E2=80=99 man page, yes? As = already mentioned, that page does not prescribe or imply any behavior on = the dynamic linker or runtime resolution. If defines how the c99 = utility is to behave. Moreover, if that=E2=80=99s to be taken as = universal, it=E2=80=99s inconsistent with the =E2=80=98fort77=E2=80=99 = man page that only calls out -L with a libf.a as being unspecified. My = example could just as well created librt using fort77 and still observed = the same result. The dynamic linker cannot satisfy both man pages = without being inconsistent with one of them. =20 > You may think it seems like it should be okay to use the name = =E2=80=9Clibrt" if you're not linking the standard -lrt I do, and it=E2=80=99s been done successfully for over 40 years now = across nearly every desktop and server platform in existence=E2=80=A6 = The magnitude and implications of that timespan and portability exposure = really seems to get lost on folks. :) > but imagine what would happen if you were on an implementation where = some of the standard functions were defined in a discrete librt.so = rather than all integrated in libc.so like musl does: We don=E2=80=99t have to imagine as that was a common library = configuration through the late 90=E2=80=99s and early 00=E2=80=99s. As = already mentioned, most issues are managed through path ordering (or one = is intentionally overriding a library). > This would cause very bad things to happen if someone copied the glibc = versions of those libraries around with a glibc-linked program they were = trying to use with ABI-compat, not aware that they were actually part of = glibc and not third-party libraries the application needed. This is a valid concern, though I would expect such a glibc-linked = program to have an rpath set such that it=E2=80=99s not simply = defaulting to DT_RUNPATH, ldconfig, or default paths. Modern versions = of GNU ld in fact require rpaths be set for relocation to work. I think = you=E2=80=99ve also described a situation where someone system-installed = rather carelessly =E2=80=94 installing an overriding librt/libm/libc/etc = into /usr/lib is going to result in bad things happening on just about = any platform and is not what=E2=80=99s being suggested. Bad things will = happen today on just about any Linux system if you copy an incompatible = glibc from one system to another and install it in a location where it = takes precedence. It seems like the conflict in play is wanting glibc-compiled = applications to just work when run on musl, hence the main reason why it = appears to aggressively resolve the various libs at runtime regardless = of the set rpath. If you removed the dynamic override outright then one = couldn=E2=80=99t just copy an executable over and expect it to work = (would need to be recompiled or have their glibc installed for rpath to = resolve), but that=E2=80=99s true today on other platforms. It would = behave like GNU ld. It=E2=80=99s just convenient that glibc has been = mostly ABI-compatible for a while, but that=E2=80=99s certainly not = always the case and shouldn=E2=80=99t ever be assumed (imho). > There is something of a long-term direction to decouple the ABI-compat = stuff from musl, and I'm not sure if it would make sense to unreserve = the names at the same time. A proposal to do this, like any proposal for = supporting nonstandard functionality that could have unforseen = consequences, would need to involve research into what those = consequences might be, if any. It might end up being okay to do = something like first hardening protection against loading glibc-linked = libraries by those names (assuming they're the corresponding parts of = the standard library from glibc) and then doing like you said, only = using them as fallbacks after search. I certainly wasn=E2=80=99t expecting this to be a quick and easy can of = worms, but appreciate the consideration. I maintain a simple = expectation (these days) that users should be able to compile and link = against libraries named anything, hence the simple program and library = example. The example demonstrably works on linux, mac windows, hpux, = *bsd, haiku, etc.. and with good reason and implications. This was = mostly about opening a dialog for feedback. Thanks for receiving and = responding to the report. Cheers! Sean p.s. for anyone finding this thread in the future couple workarounds are = LD_PRELOAD or specify full paths when linking. for cmake, set CMP0060 to = NEW.