From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bumble.maple.relay.mailchannels.net (bumble.maple.relay.mailchannels.net [23.83.214.25]) by sourceware.org (Postfix) with ESMTPS id E02823938C1C for ; Fri, 12 Mar 2021 08:53:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E02823938C1C X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 11CE6402B3F; Fri, 12 Mar 2021 08:52:59 +0000 (UTC) Received: from pdx1-sub0-mail-a11.g.dreamhost.com (100-96-10-172.trex.outbound.svc.cluster.local [100.96.10.172]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 3E88C4027DC; Fri, 12 Mar 2021 08:52:58 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from pdx1-sub0-mail-a11.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.96.10.172 (trex/6.1.1); Fri, 12 Mar 2021 08:52:58 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Supply-Fearful: 3a33b69741ac958b_1615539178607_187282008 X-MC-Loop-Signature: 1615539178607:1150326385 X-MC-Ingress-Time: 1615539178607 Received: from pdx1-sub0-mail-a11.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a11.g.dreamhost.com (Postfix) with ESMTP id 04BC47EF76; Fri, 12 Mar 2021 00:52:58 -0800 (PST) Received: from [192.168.1.111] (unknown [1.186.101.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a11.g.dreamhost.com (Postfix) with ESMTPSA id 20A767E685; Fri, 12 Mar 2021 00:52:51 -0800 (PST) Subject: Re: [PATCH 1/3] Add inhibit_stack_protector to ifuncmain9 [BZ #25680] To: Adhemerval Zanella , libc-alpha@sourceware.org, Florian Weimer , Sergei Trofimovich References: <20210310101400.3904724-1-siddhesh@sourceware.org> <20210310101400.3904724-2-siddhesh@sourceware.org> <00d1c526-cff0-8b00-1009-a488695d1f86@linaro.org> X-DH-BACKEND: pdx1-sub0-mail-a11 From: Siddhesh Poyarekar Message-ID: <595c9ca3-a0d8-5958-2544-500812d2ecc3@sourceware.org> Date: Fri, 12 Mar 2021 14:22:46 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <00d1c526-cff0-8b00-1009-a488695d1f86@linaro.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3487.1 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_NONE, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NEUTRAL, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2021 08:53:02 -0000 On 3/10/21 6:20 PM, Adhemerval Zanella via Libc-alpha wrote: >=20 >=20 > On 10/03/2021 07:13, Siddhesh Poyarekar via Libc-alpha wrote: >> From: David Hughes >> >> Enabling --enable-stack-protector=3Dall causes the following tests to = fail: >> >> FAIL: elf/ifuncmain9picstatic >> FAIL: elf/ifuncmain9static >> >> Nick Alcock (who committed the stack protector code) marked the IFUNC >> resolvers with inhibit_stack_protector when he done the original work = and >> suggested doing so again @ BZ #25680. This patch adds >> inhibit_stack_protector to ifuncmain9. >> >> After patch is applied, --enable-stack-protector=3Dall does not fail t= he >> above tests. >=20 > The BZ#25680 report makes me wonder if would be better to just disable > --enable-stack-protector=3Dall on architecture with IFUNC for now. > This fix the issue on glibc testsuite, but it might still trigger > by users if this same trick is not used (as noted by Sergei). The general problem is that it is at best pointless to add stack=20 protector prologue/epilogue to ifunc resolver functions in static=20 binaries. On x86_64 it is visible because it results in a crash due to=20 TLS segment register %fs not being set up but elsewhere, the stack chk=20 guard is zero, which makes the dereference safe, but useless. On=20 ppc64le, the TLS setup happens first, thus avoiding the crash and=20 behaving like the other non-TLS stack_chk_guard architectures. One way to make it not crash on x86_64 could be to delay ifunc=20 resolution (which would then mean making sure that TLS doesn't use=20 ifunc'd functions, e.g. memcpy) and bring it on par with the rest of the=20 architectures. I'm also considering proposing that gcc skips over ifunc resolvers for=20 stack protection, at least in the static case. The dynamic case happens=20 to work somehow, I am yet to conclude that it's by design. > Florian stated on comment #2 that =E2=80=9Call=E2=80=9D is very unlikel= y to add > additional protection and this basically adds *another* undocumented > ifunc restriction. And it seems likely that distributions like Gentoo > will just use 'strong' instead of 'all'. AFAICT Gentoo decided to use 'strong' instead of 'all' because of=20 Florian's comment. > So, what would be the implications of limiting stack protection to > 'strong' instead of 'all' for ABIs with ifunc? Is this issue only > redistricted to some ABIs (the reported indicates that only x86_64 > is affected)? It's not the glibc build that's affected though, at least not to an=20 extent that we ought to care. What's broken is our support with=20 binaries that were built with stack-protector-all *and* ifuncs. This=20 patch implies that we don't support it; all we need to do is document=20 this somewhere and perhaps fix gcc to never emit the prologue/epilogue=20 for ifunc resolvers. Siddhesh