From patchwork Sat Feb 20 10:23:46 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nix X-Patchwork-Id: 10963 Received: (qmail 19358 invoked by alias); 20 Feb 2016 10:25:02 -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 18681 invoked by uid 89); 20 Feb 2016 10:24:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL, BAYES_00, KAM_LAZY_DOMAIN_SECURITY, RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=Parts, Hx-languages-length:2219, sans X-HELO: mail.esperi.org.uk From: Nix To: libc-alpha@sourceware.org Cc: carlos@redhat.com Subject: [PATCH 12/12] Avoid stack-protecting certain functions called from assembly. Date: Sat, 20 Feb 2016 10:23:46 +0000 Message-Id: <1455963826-21885-13-git-send-email-nix@esperi.org.uk> In-Reply-To: <1455963826-21885-1-git-send-email-nix@esperi.org.uk> References: <1455963826-21885-1-git-send-email-nix@esperi.org.uk> From: Nick Alcock This is the problematic part. Without -fno-stack-protector on these two files, or more specifically on __pthread_mutex_cond_lock_adjust() and __pthread_mutex_unlock_usercnt(), nptl/tst-cond24 and nptl/tst-cond25 receive a NULL mutex at unlock time and segfault. However... I don't understand why. It is the callee's responsibility both to add the stack canary and to initialize it, just like any other local variable. It has to be, or the ABI for stack-protected code would be incompatible with that for non-protected code. But the fact remains that sysdeps/unix/sysv/linux/i386/pthread_cond_timedwait.S both explicitly mentions the stack frame layout and calls this function, and this call goes wrong if we stack-protect it. Looking at this, I'm now wondering how many other places GCC does calls into C from assembler that break the rules in the same way. It can't be all of them, or nothing would work -- but what about sysdeps/x86_64/setjmp.S, which sibcalls into setjmp/sigjmp.c? This works and does not appear to need any -fstack-protector of any kind at all -- but it also has no local variables, so I might be escaping by luck rather than judgement... So this is somewhere where I need someone to tell me what's special about sysdeps/unix/sysv/linux/i386/pthread_cond_timedwait.S (and in particular special about priority-inheritance mutexes: everything else works), before I can be confident that this is even remotely the right thing to do. --- nptl/Makefile | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/nptl/Makefile b/nptl/Makefile index a1d52a2..95240c7 100644 --- a/nptl/Makefile +++ b/nptl/Makefile @@ -330,6 +330,10 @@ endif ifeq ($(have-ssp),yes) # Parts of nptl-init.c are called before the stack guard is initialized. CFLAGS-nptl-init.c += -fno-stack-protector +# Parts of these files are called from assembler, with a hand-made stack, +# sans canary. +CFLAGS-pthread_mutex_cond_lock.c += -fno-stack-protector +CFLAGS-pthread_mutex_unlock.c += -fno-stack-protector endif modules-names = tst-atfork2mod tst-tls3mod tst-tls4moda tst-tls4modb \