From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 7A1E13940CEB; Sun, 15 Mar 2020 12:25:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7A1E13940CEB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1584275158; bh=NfTSXFU4kvYgmVxoSOOaah+p3OtU1292D5WnQ8LxJ50=; h=From:To:Subject:Date:In-Reply-To:References:From; b=E9dHfX5LoLAmKxhMC9UzdqZ3e8++wj97gvmsJ1RwkJujR/ZxDjFDal8rpan7By9ku n6gkJCu//7U0z6Z1LK9iOj3iMWjSsgZlHJyygkmiBdoomekdQo6FaUWlVD0NkwRbbp /qZwRj9pYf7BS8zR58R4h+5wftacpapaOXpjd54Q= From: "fw at deneb dot enyo.de" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/25680] ifuncmain9picstatic and ifuncmain9picstatic crash in IFUNC resolver due to stack canary (--enable-stack-protector=all) Date: Sun, 15 Mar 2020 12:25:58 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: 2.31 X-Bugzilla-Keywords: X-Bugzilla-Severity: minor X-Bugzilla-Who: fw at deneb dot enyo.de X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2020 12:25:58 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D25680 --- Comment #4 from Florian Weimer --- (In reply to Sergei Trofimovich from comment #3) > Does it mean --enable-stack-protector=3Dall is not really a supported opt= ion > for glibc? If' it's not I can hack a patch that complains loudly about the > option being experimental. It is supported in the sense that it is there and you can build glibc with = it, but some edge cases in the test suite have not been covered. (At this time,= I'm not sure if this is a test bug or a bug in the static initialization sequen= ce, though.) > My main worry is that resolver in ifuncmain9picstatic's source code only > happens to be a part of glibc. It could have been an external program. Any > external program might decide to enable -fstack-protector-all and will get > non-working resolver as a result. Is there a doc that describes this and > other limitations imposed on IFUNC resolves by glibc? I wonder what else = we > break by accident. It's a valid concern. We probably have to reorder the initialization sequen= ce because on some architecture (notably powerpc as of commit 67385a01d229751569b6aac067ffdcd813a15d7a ("powerpc: Add hwcap/hwcap2/platfo= rm data to TCB."), IFUNC resolvers are expected to access the TCB to choose the appropriate implementation. --=20 You are receiving this mail because: You are on the CC list for the bug.=