From patchwork Mon Jul 10 17:34:14 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "H.J. Lu" X-Patchwork-Id: 21523 Received: (qmail 77304 invoked by alias); 10 Jul 2017 17:34:19 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 77187 invoked by uid 89); 10 Jul 2017 17:34:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.9 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM, SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:3670 X-HELO: mail-oi0-f53.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RPwbOP5pRs25eNZsMKbxeYA8rzf30PHVb38oH3LsSqE=; b=KsHl2QMWcN45Vx2ADQSFnk+RSdkVwi3SyNb1Ok/i4QlaHu75iyBrDOfsP1vsCQPelH /BAhQOPx0k9XKfxW3OrNkqbitif79yCqW+hahrcXaVdoUIAmj/Wq1dKeyc65eGMzfGzD OvmmHWkIusawqzt/YZfIXF5/kQt5UpHSkuuwKCSEIcrAN0reE6+C5WbDQk0KJxW2U2V5 w1kWu53WWDHuwMVghwiCKzUlzCnVHL4BJT0UQ0xe+pOEoq3T8Czyg/IOHIpbAkUEXm3i j1N7YUKOuDGfNRwniacpsqUyVX6lhecumj0s3eR+ReN/vkGtE4aGy/eR7oBcM+Dga9XX RpoQ== X-Gm-Message-State: AIVw113+UgehbZtuT5JDBDpdE5NpM8ZQfMja+P2XKTqoETkPCl0aaRpm +D1+IpqwctaAUFYiTTINn2+7cUFsKfYb X-Received: by 10.202.191.214 with SMTP id p205mr2391832oif.208.1499708055170; Mon, 10 Jul 2017 10:34:15 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <87shi4ju8l.fsf@esperi.org.uk> References: <20170709154233.GA10935@gmail.com> <87d198lg6d.fsf@esperi.org.uk> <20170710131401.GA15657@gmail.com> <87shi4ju8l.fsf@esperi.org.uk> From: "H.J. Lu" Date: Mon, 10 Jul 2017 10:34:14 -0700 Message-ID: Subject: Re: [PATCH] Remove debug/stack_chk_fail_local.c [BZ #21740] To: Nick Alcock Cc: Nick Alcock , GNU C Library On Mon, Jul 10, 2017 at 6:29 AM, Nick Alcock wrote: > On 10 Jul 2017, H. J. Lu said: >> On Mon, Jul 10, 2017 at 11:50:02AM +0100, Nick Alcock wrote: >>> If it passes a test build with --enable-stack-protector=all without >>> pulling junk into ld.so and exploding at ld.so link time, sure. (That's >>> what happened every time I tried to remove this stuff before, but I may >>> have failed to notice that this may not be necessary any more.) >> >> Here is the updated patch. tst-_dl_addr_inside_object should be >> linked with $(dummy-stack-chk-fail). Otherwise, __stack_chk_fail is >> undefined. OK for master branch? > > I presume this is because it's in $(all-nonlib)? Are other all-nonlib > things similarly affected? (If they are, is the code in Makerules > perhaps a better place to adjust this?) > > I guess the only affected nonlib things would be things that directly > link against objects that will otherwise end up in the shared libc or > ld.so, which means this is the only affected test (since only those > things reference the usually-hidden __stack_chk_fail). If so, I have no > objection to this patch, but maybe a comment explaining this would be a > good idea so that if more such tests turn up in future this unusual > piece of linking can be generalized a bit. > > Modulo that, I have no objections, but of course I also have no actual > right to ack anything whatsoever :) > >>> > -/* On some architectures, this helps needless PIC pointer setup >>> > - that would be needed just for the __stack_chk_fail call. */ >>> >>> Does anyone know what architectures these might be? Presumably x86-32... >>> >> >> config/i386/i386.c: __stack_chk_fail_local hidden function instead of calling > > I presume you tested a build on x86-32 :) I guess that will suffice... We must keep debug/stack_chk_fail_local.c for libc_nonshared.a. Here is the updated patch to add __stack_chk_fail_local alias only to libc.so. Tested on i686 and x86-64 with and without --enable-stack-protector=all. OK for master? From 217275043ad73f922d07f42e5fc1a4be70183209 Mon Sep 17 00:00:00 2001 From: "H.J. Lu" Date: Sun, 9 Jul 2017 08:39:17 -0700 Subject: [PATCH] Add __stack_chk_fail_local alias only to libc.so [BZ #21740] commit 524a8ef2ad76af8ac049293d993a1856b0d888fb Author: Nick Alcock Date: Mon Dec 26 10:08:57 2016 +0100 PLT avoidance for __stack_chk_fail [BZ #7065] Add a hidden __stack_chk_fail_local alias to libc.so, and make sure that on targets which use __stack_chk_fail, this does not introduce a local PLT reference into libc.so. unconditionally added strong_alias (__stack_chk_fail, __stack_chk_fail_local) Since libc.a and libc_nonshared.a has debug/stack_chk_fail_local.c, __stack_chk_fail_local alias should be limited to libc.so. Tested on x86-64 with --enable-stack-protector=all and got FAIL: elf/tst-env-setuid FAIL: elf/tst-env-setuid-tunables FAIL: stdlib/tst-secure-getenv which are the same as without this patch. [BZ #21740] * debug/stack_chk_fail.c (__stack_chk_fail_local): Add the alias only if SHARED is defined. --- debug/stack_chk_fail.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/debug/stack_chk_fail.c b/debug/stack_chk_fail.c index 4f73464..120d269 100644 --- a/debug/stack_chk_fail.c +++ b/debug/stack_chk_fail.c @@ -28,4 +28,8 @@ __stack_chk_fail (void) __fortify_fail ("stack smashing detected"); } +#ifdef SHARED +/* Some targets call __stack_chk_fail_local as a hidden function within + libc.so. */ strong_alias (__stack_chk_fail, __stack_chk_fail_local) +#endif -- 2.9.4