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=-3.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI,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 1590 invoked from network); 14 Nov 2023 03:02:47 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 14 Nov 2023 03:02:47 -0000 Received: (qmail 7930 invoked by uid 550); 14 Nov 2023 03:02:41 -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 7951 invoked from network); 14 Nov 2023 02:33:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eleanor-nb.com; h=cc:content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:sender:subject:subject:to:to; s=fm2; t=1699929210; x=1700015610; bh=GrqKmR/2sXJtpja2JuZ073Tud nD87VHt69tjhrULJlQ=; b=NeOM5op1VFtwxS3dkzD/2gNXXhYkz44Vf2HL+dzV/ McelF/PT7NwGn0qOE/St5xwAn90Z8SHu2uXoah2qH6cjWI288ScHrDKPGvTinlqY KiOsFKQb3FiXH7V0dBP5m9RH+16O/oB8ZavbS2xNwg/EyKpuZHApmgO088yg1MOZ Nl3WuqRu1O9hRrIGauiu8iQRXdKl7kUGeocyxqY7/7vUlQ2lYYaXexuXQza+Dai+ 2KLBfkwLer7a8Ka2phtrs7UqhZd1NoM2F7EJdAbVMhaZRozxWRpODXCnVfUyNAL4 6YqND5L+JgplhEkbuQwT+zJtojXb96jloMmt7QtOMTezA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1699929210; x=1700015610; bh=GrqKmR/2sXJtpja2JuZ073TudnD87VHt69t jhrULJlQ=; b=XkREG4DeVyTz/Qw5dd9mIEyP3bZaLvh/Fx6NhCa/nsQQ+dwUPYy pn9t3rZupnwTykFksqG0IBaIqlcgNPyBMQijSTAOi2hm2vsg5vhcCs1r14tNU3/j f71Su9IDv8kLGSIHlN9YIGsla66LULq4QwCb+N9EC0ZB7aw8QAqEMr6MSXzOteCL KNzmvFH0hakIewdAnzKU/BFtmxRaPSMByKR7BjTLEbFp0TvfS872x+j3EhH8KyIA VIF9VTpYUwIuoKMR+OKoZlVTQGqv8dnQhfI5knF3qp5d4EOnsIkaKtbmVMG9aPfa ui4defM+J8MO+RnfP3LQ49IN2oqGF1jPySQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudefuddggeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedfgfhlvggrnhhorhcuuegrrhhtlhgvfdcuoegvlhgvrghnohhr segvlhgvrghnohhrqdhnsgdrtghomheqnecuggftrfgrthhtvghrnhepkeevuedthfeije ekffffkeegleffjefgtdeggedvheejiefhhfethfekhefhheehnecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvghlvggrnhhorhesvghlvggrnh horhdqnhgsrdgtohhm X-ME-Proxy: Feedback-ID: i5b0147a0:Fastmail X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-1108-g3a29173c6d-fm-20231031.005-g3a29173c MIME-Version: 1.0 Message-Id: <946a873e-9c02-4cd2-9460-f6dfa3aa5028@app.fastmail.com> Date: Tue, 14 Nov 2023 13:32:02 +1100 From: "Eleanor Bartle" To: musl@lists.openwall.com Content-Type: multipart/alternative; boundary=7c3b8e9a51184c51bf16a108169f072a Subject: [musl] Care about Symbol Namespacing? --7c3b8e9a51184c51bf16a108169f072a Content-Type: text/plain [please cc] ELF doesn't have a standard equivalent of Mach-O's Two-Level Namespace, but one can be grafted on, as Solaris does with Direct Binding. I've inquired about this on IRC and the objections raised against it concern moving symbols between or coalescing shared objects without breaking dependent binaries. What I'm wondering is, is it worth thinking about a symbol namespacing system that accounts for this? Would the robustness benefits of such a system be worth the specification complexity? To be clear, I don't have such a proposal on hand, and it would take me a while to get one ready (and a while more to work out all the kinks I'll inevitably miss); I have the ghost of an idea involving components specifying interface names rather than filenames, which ld.so could then map to shared objects potentially non-injectively, but I don't know the fine details of implementation. This message is mainly to gauge if leadership is at all interested in the broad idea, to determine if even thinking about it is worth my time. --7c3b8e9a51184c51bf16a108169f072a Content-Type: text/html Content-Transfer-Encoding: quoted-printable
[please cc]

ELF doesn't have a standard equivalent of Mach-O's= Two-Level Namespace, but one can be grafted on, as Solaris does with Di= rect Binding. I've inquired about this on IRC and the objections raised = against it concern moving symbols between or coalescing shared objects w= ithout breaking dependent binaries. What I'm wondering is, is it worth t= hinking about a symbol namespacing system that accounts for this? Would = the robustness benefits of such a system be worth the specification comp= lexity?

To be clear, I don't have such a pr= oposal on hand, and it would take me a while to get one ready (and a whi= le more to work out all the kinks I'll inevitably miss); I have the ghos= t of an idea involving components specifying interface names rather than= filenames, which ld.so could then map to shared objects potentially non= -injectively, but I don't know the fine details of implementation. This = message is mainly to gauge if leadership is at all interested in the bro= ad idea, to determine if even thinking about it is worth my time.
--7c3b8e9a51184c51bf16a108169f072a--