From owner-freebsd-toolchain@freebsd.org Mon Nov 25 03:50:18 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B9B1C1C6F8B for ; Mon, 25 Nov 2019 03:50:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 47LtNB4YJxz3PNt for ; Mon, 25 Nov 2019 03:50:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 9C2E81C6F8A; Mon, 25 Nov 2019 03:50:18 +0000 (UTC) Delivered-To: toolchain@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9BF5C1C6F89 for ; Mon, 25 Nov 2019 03:50:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47LtNB3jZXz3PNs for ; Mon, 25 Nov 2019 03:50:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 635136CAD for ; Mon, 25 Nov 2019 03:50:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id xAP3oI0l027754 for ; Mon, 25 Nov 2019 03:50:18 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id xAP3oIp3027753 for toolchain@FreeBSD.org; Mon, 25 Nov 2019 03:50:18 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 241905] SSP setup is not thread-safe ? Date: Mon, 25 Nov 2019 03:50:17 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kevans@freebsd.org X-Bugzilla-Flags: mfc-stable12? mfc-stable11? 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: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2019 03:50:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241905 --- Comment #10 from commit-hook@freebsd.org --- A commit references this bug: Author: kevans Date: Mon Nov 25 03:49:39 UTC 2019 New revision: 355080 URL: https://svnweb.freebsd.org/changeset/base/355080 Log: MFC r354669, r354672, r354689: move __stack_chk_guard constructor r354669: ssp: add a priority to the __stack_chk_guard constructor First, this commit is a NOP on GCC <=3D 4.x; this decidedly doesn't work cleanly on GCC 4.2, and it will be gone soon anyways so I chose not to du= mp time into figuring out if there's a way to make it work. xtoolchain-gcc, clocking in as GCC6, can cope with it just fine and later versions are al= so generally ok with the syntax. I suspect very few users are running GCC4.2 built worlds and also experiencing potential fallout from the status quo. For dynamically linked applications, this change also means very little. rtld will run libc ctors before most others, so the situation is approximately a NOP for these as well. The real cause for this change is statically linked applications doing almost questionable things in their constructors. qemu-user-static, for instance, creates a thread in a global constructor for their async rcu callbacks. In general, this works in other places- - On OpenBSD, __stack_chk_guard is stored in an .openbsd.randomdata secti= on that's initialized by the kernel in the static case, or ld.so in the dynamic case - On Linux, __stack_chk_guard is apparently stored in TLS and such a prob= lem is circumvented there because the value is presumed stable in the new thread. On FreeBSD, the rcu thread creation ctor and __guard_setup are both unmar= ked priority. qemu-user-static spins up the rcu thread prior to __guard_setup which starts making function calls- some of these are sprinkled with the canary. In the middle of one of these functions, __guard_setup is invoked= in the main thread and __stack_chk_guard changes- qemu-user-static is prompt= ly terminated for an SSP violation that didn't actually happen. This is not an all-too-common problem. We circumvent it here by giving the __stack_chk_guard constructor a solid priority. 200 was chosen because th= at gives static applications ample range (down to 101) for working around it if they really need to. I suspect most applications will "just work" as expected- the default/non-prioritized flavor of __constructor__ functions run last, and the canary is generally not expected to change as of this point at the very least. This took approximately three weeks of spare time debugging to pin down. r354672: ssp: rework the logic to use priority=3D200 on clang builds The preproc logic was added at the last minute to appease GCC 4.2, and kevans@ did clearly not go back and double-check that the logic worked out for clang builds to use the new variant. It turns out that clang defines __GNUC__ =3D=3D 4. Flip it around and che= ck __clang__ as well, leaving a note to remove it later. r354689: ssp: further refine the conditional used for constructor priority __has_attribute(__constructor__) is a better test for clang than defined(__clang__). Switch to it instead. While we're already here and touching it, pfg@ nailed down when GCC actua= lly introduced the priority argument -- 4.3. Use that instead of our hammer-guess of GCC >=3D 5 for the sake of correctness. PR: 241905 Changes: _U stable/11/ stable/11/lib/libc/secure/stack_protector.c _U stable/12/ stable/12/lib/libc/secure/stack_protector.c --=20 You are receiving this mail because: You are on the CC list for the bug.=