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=-5.7 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 21537 invoked from network); 29 Nov 2023 13:46:11 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 29 Nov 2023 13:46:11 -0000 Received: (qmail 32117 invoked by uid 550); 29 Nov 2023 13:46:06 -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 32094 invoked from network); 29 Nov 2023 13:46:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1701265553; 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; bh=yhaiz2dSj87TgLDOTJjPRRNuoh6KRZitoFvHN9/qzCI=; b=AHZnCfMXpm0R8ek+oWYEO9WgRccLtX7E3Ybbobc4mmSWs9swUzoCAoiMZj+fCx0ahaQYWn v4t5q6CMAky1H0LSZuhvhdo79/jVJ0nPCdECyermcbr0P56aFwf1FGwvfFFuKZxtRgqgBB CUmUqvu4WfUTkQABUrLBx/3AyUdDkyA= X-MC-Unique: BIB6a7asNeiVHmO_bcRcXQ-1 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701265551; x=1701870351; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=yhaiz2dSj87TgLDOTJjPRRNuoh6KRZitoFvHN9/qzCI=; b=acM/oIDnX5VJ7i81u+GgTPHHB3YIdNUVhmWzavk0GVzKS9awww4JXj9QdxyXQXFcZL zU7EelnUqus7xc0dZUsSG23AWowA6HXzyPDEuRg1i33UiyK0TRga1Qv168lWfz+OU9F/ ORKa8aCF0dWLnZO1A4S0X/2Ip7iSzsBZrfRKdBe5b4vT+Rirt2+vXjEW0BTGt/SY5mxw EQ5J/cwk0MYS/kXu3t7KqiGANEU08njAyKWjk3+xBXGdE6hqUROra2FY+PlCMA/pfW2x bXrmRY0FSHvIkCOfAlVXBYKE0dzaUSNVtPnlNhtqgPTOvFHHoHk8Usez5mcPl12H/MRE p9NQ== X-Gm-Message-State: AOJu0YwCP74FuHopE5GT9ZgGMvoyQpmVfo9hFcD5E9klUR/AfI/Adrtp N0p/2Jgf3mBZpwxFI7srkTmubMmXTv6Bd28nzW72xM6OIRSRykhwEuzRxeqQxQWLZvIwdPPaG9T mKFdOvQdnyMdD7DrHWlQ2s6mEigdz83AJRDYKncJjAliH0LUjIB15cGf+ctHcwFnYN5IDY7nm0k Xv6A== X-Received: by 2002:ac8:7c45:0:b0:411:616a:4bde with SMTP id o5-20020ac87c45000000b00411616a4bdemr23685048qtv.18.1701265551426; Wed, 29 Nov 2023 05:45:51 -0800 (PST) X-Google-Smtp-Source: AGHT+IHEp4uSrF6Oc7w3NrYrH7hgDwU5S82YaVUKzfI3gMbp6Bbk9yi8oYQeSTJIDgO4+l/gJBThbA== X-Received: by 2002:ac8:7c45:0:b0:411:616a:4bde with SMTP id o5-20020ac87c45000000b00411616a4bdemr23685030qtv.18.1701265551072; Wed, 29 Nov 2023 05:45:51 -0800 (PST) Message-ID: Date: Wed, 29 Nov 2023 08:45:49 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 To: musl@lists.openwall.com, Fangrui Song , Eleanor Bartle Cc: Markus Wichmann References: <946a873e-9c02-4cd2-9460-f6dfa3aa5028@app.fastmail.com> <20231114031026.GV4163@brightrain.aerifal.cx> <5926c9d9-083e-4ee4-8c87-3f58aca2f428@app.fastmail.com> <20231115152042.GX4163@brightrain.aerifal.cx> From: Carlos O'Donell Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [musl] Care about Symbol Namespacing? On 11/28/23 00:17, Fangrui Song wrote: > GNU symbol versioning is actually a system that provides the import > file information: vn_file. However, glibc rtld does not utilize > vn_file to speed up symbol searches. In addition, > >> https://maskray.me/blog/2020-11-26-all-about-symbol-versioning#version-script >> vn_file is essentially ignored for symbol search since glibc 2.30 >> https://sourceware.org/bugzilla/show_bug.cgi?id=24741 . Previously >> during relocation resolving, after an object failed to provide a >> match, if it matched vn_file, rtld would report an error `symbol %s >> version %s not defined in file %s with link time reference`. This change in glibc was intentional. I agree with Rich here that static linking should be treated as a first class feature and glibc has moved towards ensuring that dynamic and static linking behaviour is more similar. The exception here is that in glibc the goal will be to give developers the option to disallow dlopen() from a statically linked application; thus providing the developer assurances that nothing else will be loaded (important when crossing namespace boundaries, particularly mount namespaces). -- Cheers, Carlos.