From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 7111F3857827 for ; Thu, 14 Jan 2021 10:09:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7111F3857827 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-577-rRlDmJucMaiQJxH_j-Lu2Q-1; Thu, 14 Jan 2021 05:09:28 -0500 X-MC-Unique: rRlDmJucMaiQJxH_j-Lu2Q-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E57171926DA3; Thu, 14 Jan 2021 10:09:27 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-114-66.ams2.redhat.com [10.36.114.66]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3E66D60C64; Thu, 14 Jan 2021 10:09:27 +0000 (UTC) From: Florian Weimer To: =?utf-8?B?RsSBbmctcnXDrCBTw7JuZw==?= Cc: Fangrui Song via Libc-alpha Subject: Re: [PATCH] Unconditionally define __stack_chk_guard [BZ #26817] References: <20210111031210.4020603-1-maskray@google.com> <87h7nnrewa.fsf@oldenburg2.str.redhat.com> <87wnwjmkhm.fsf@oldenburg2.str.redhat.com> Date: Thu, 14 Jan 2021 11:09:25 +0100 In-Reply-To: (=?utf-8?B?IkbEgW5nLXJ1w6wgU8OybmciJ3M=?= message of "Mon, 11 Jan 2021 23:58:57 -0800") Message-ID: <8735z3sucq.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, 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: 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: Thu, 14 Jan 2021 10:09:33 -0000 * F=C4=81ng-ru=C3=AC S=C3=B2ng: > On Mon, Jan 11, 2021 at 9:50 AM Florian Weimer wrote= : >> >> * F=C4=81ng-ru=C3=AC S=C3=B2ng: >> >> > On Mon, Jan 11, 2021 at 1:39 AM Florian Weimer wr= ote: >> >> >> >> * Fangrui Song via Libc-alpha: >> >> >> >> > This makes -mstack-protector-guard=3Dglobal work even if >> >> > -mstack-protector-guard=3Dtls is the default. >> >> >> >> It's unclear how you intend this to work. Is it just for building >> >> glibc? Or also for user code? >> > >> > It is for user applications. >> > >> > gcc -fstack-protector -mstack-protector-guard=3Dglobal a.c >> > or >> > clang -fstack-protector -mstack-protector-guard=3Dglobal a.c (clang 12= ) >> > >> > Currently there is an undefined symbol error. This patch fixes the pro= blem. >> >> And we really want to use a global data symbol for this? Nothing else >> works at the moment, but it seems rather wasteful. > > https://sourceware.org/bugzilla/show_bug.cgi?id=3D22850 > For a new thread, nptl/allocatestack.c allocates a memory region, places = the > static TLS block at the end, and uses the remaining space as the thread s= tack. > The stack pointer may be just a few hundred bytes below the canary addres= s > (%fs:0x28 on x86-64) and a large out-of-bounds write can potentially > override it. Is this the only reason? We need to change the TCB allocation anyway. Unlike LinuxThreads, there is no technical requirement to have the TCB at the top of the stack. > This patch will make -mstack-protector-guard=3Dglobal work, with very > little overhead (a word) in ld.so. On the other hand, it may discourage people from enabling the stack protector because the overhead encountered by instrumented functions increases. Perhaps we should add new relocation types and use a hidden, per-DSO symbol. The canary value does not have to be the same for all functions. I believe OpenBSD does this already. >> >> In the latter case, we either need to provide a way to initialize a >> >> hidden __stack_chk_guard symbol (probably with new relocations), or >> >> export __stack_chk_guard from glibc, under a GLIBC_2.33 symbol versio= n >> >> for architectures that were missing it before. >> > >> > In elf/Versions, __stack_chk_guard is already exported as >> > __stack_chk_guard@@GLIBC_2.4 >> >> GLIBC_2.4 is done and dusted, we can't add symbols to it. New symbols >> must have symbol version GLIBC_2.33 or later, while preserving the old >> symbol versions for the ports that already export it. >> >> If you run =E2=80=9Dmake check=E2=80=9D, you'll see abilist comparison f= ailures for most >> ports. You need to fix those as well. > > OK. Added %include "tls.h" to get THREAD_SET_STACK_GUARD, > > https://github.com/MaskRay/glibc/tree/stack_chk_guard > I can post it here if it looks good. It builds and produces the expected ABI, but the %ifdef kludges are quite ugly. Thanks, Florian --=20 Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'N= eill