From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id AB6A824174 for ; Thu, 9 May 2024 14:35:10 +0200 (CEST) Received: (qmail 30108 invoked by uid 550); 9 May 2024 12:35:04 -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 30070 invoked from network); 9 May 2024 12:35:03 -0000 Date: Thu, 9 May 2024 08:35:16 -0400 From: Rich Felker To: Maxim Blinov Cc: musl@lists.openwall.com Message-ID: <20240509123516.GQ10433@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] IFUNC support On Thu, May 09, 2024 at 12:04:28PM +0100, Maxim Blinov wrote: > Hi all, > > I just wanted to clarify the current status on IFUNCs, specifically > when generated by the compiler when using the `target_clones` c > function attribute. > > Am I correct that this is not currently supported by musl? If so, > would musl ever support this feature, or is it rejected as a matter of > principle? And lastly, if it is possible, what would it take to > support this feature? > > I googled around for some previous discussions on the subject and > found https://www.openwall.com/lists/musl/2022/08/23/7, and also > https://www.openwall.com/lists/musl/2014/11/11/2, which reports IFUNCs > as "One feature musl intentionally does not yet support", but I > suppose I wanted to ask again since this was from 2014 and perhaps > something has changed since then. If anything, exclusion of IFUNC is more definite now than in 2014. They keep showing up as vectors for things to break or even for disguising backdoors, and none of the prior reasons for excluding it are really resolvable, nor does it have any performance value over doing things portably with function pointers. > I originally stumbled on this issue by observing that the musl dynamic > linker, for x86_64, currently errors out on IFUNC symbols with > > ``` > unknown relocation 37 > ``` > > And on RISC-V it throws up with > > ``` > unsupported relocation type 58 > ``` > > which corresponds with the R_RISCV_IRELATIVE relocation. It sounds like you have an XY problem: wanting target_clones to work. If GCC was built correctly targeting musl, it should not support ifunc generation at all; you shouldn't end up with unknown relocations in an output binary because the compiler should never have emitted them. I'm not sure, but I think GCC has mechanisms to make this functionality work in the absence of ifunc. If not, maybe it could be enhanced to do so. Rich