From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id 63D6A384841B for ; Mon, 14 Jun 2021 14:03:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 63D6A384841B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 5D22D2195A; Mon, 14 Jun 2021 14:03:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1623679426; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=86GaaiYRNIdQolBTtU6w9E3S+LuiuYU9zYn49hkjb8Y=; b=kTWm1ZvU1olxYHNaDOQSlsbC973efl0laHZwI3WhcikGrnEi6lcUU+EGfPNX88HWNDjx/p Kb3B/3sPIeUS4PjkeVJ+rsDtJe5NPAuZiBneteJtDKeoIQPVelXSLUdr76YItx64S0Cbse K3FhxQUyFvEmbtgUESwXENfGxOZA+oo= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1623679426; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=86GaaiYRNIdQolBTtU6w9E3S+LuiuYU9zYn49hkjb8Y=; b=6F44J2ftBn5b7CaWx9rYyOu60YhDDSQAzPkukEZAm82dnBXhgryRb9V2pdavruPNPbWDIL shj9dSPfYAIW4IDA== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 516AEA3B89; Mon, 14 Jun 2021 14:03:46 +0000 (UTC) Received: by wotan.suse.de (Postfix, from userid 10510) id 4468B62AE; Mon, 14 Jun 2021 14:03:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by wotan.suse.de (Postfix) with ESMTP id 430DE623D; Mon, 14 Jun 2021 14:03:46 +0000 (UTC) Date: Mon, 14 Jun 2021 14:03:46 +0000 (UTC) From: Michael Matz To: Alan Modra cc: Fangrui Song , Florian Weimer , Szabolcs Nagy , binutils@sourceware.org Subject: Re: [PATCH] Allow direct access relocations referencing a protected function symbol In-Reply-To: Message-ID: References: <20210613215400.261932-1-maskray@google.com> User-Agent: Alpine 2.22 (LSU 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2021 14:03:48 -0000 Hello, On Mon, 14 Jun 2021, Alan Modra via Binutils wrote: > On Sun, Jun 13, 2021 at 02:54:00PM -0700, Fangrui Song via Binutils wrote: > > This fixes the bogus "relocation R_* against protected symbol `foo' > > can not be used when making a shared object" for function symbols for > > at least aarch64/i386/x86-64. > > > > The controversial "copy relocations on protected data symbols" (which has some > > fragile glibc support) is irrelevant to function symbols. > > No, this patch doesn't do that. What you are doing here will disable > dynamic relocations on protected function symbols in shared libraries. > That will break function pointer comparison for architectures that > implement non-pic executables, where a function that is undefined in > the executable is given a fixed address in the executable, that of its > plt call code. Correct. But I'm oscillating between thinking that this would be a problem and thinking the opposite :-/ One could always say that function addresses of protected functions aren't comparable. Taking an address and using it as indirect call target will always work, you just wouldn't be able to compare them usefully. Or one could require address references from outside components to a protected (function) symbol to always be via a GOT(-like structure). Or (the other extremum of my oscillations) one says that function address comparisons absolutely need to work even in absence of indirection-via-GOT, at which point we basically talk about the same problem like protected data symbols and copy relocations. If you then don't have relocations differing between calls and address taking, you effectively throw out the usefullness of protected visibility. The problem with the latter stance is that it's not really justifiable from the ELF gABI: nothing says that getting at "the" function address must be possible without a GOT indirection. (Adding to that is that what actually works in practice changed over time and depends on the architecture (and well, yeah, compiler and linker) so that now it's impossible to say "look there, that's how it should work and how everyone expects it to work" :-/ ) Ciao, Michael.