From owner-freebsd-current@freebsd.org Sun Oct 29 17:25:07 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 79F3DE47B76 for ; Sun, 29 Oct 2017 17:25:07 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailrelay115.isp.belgacom.be (mailrelay115.isp.belgacom.be [195.238.20.142]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "relay.skynet.be", Issuer "GlobalSign Organization Validation CA - SHA256 - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AED24C97; Sun, 29 Oct 2017 17:25:06 +0000 (UTC) (envelope-from tijl@freebsd.org) X-Belgacom-Dynamic: yes IronPort-PHdr: =?us-ascii?q?9a23=3AJZngwhUe4H4QmQLUralCSpvlsYTV8LGtZVwlr6E/?= =?us-ascii?q?grcLSJyIuqrYYxeGt8tkgFKBZ4jH8fUM07OQ6PGwHzRYqb+681k6OKRWUBEEjc?= =?us-ascii?q?hE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i764jEdAAjwOhRo?= =?us-ascii?q?LerpBIHSk9631+ev8JHPfglEnjSwbLdxIRmssQndqtQdjJd/JKo21hbHuGZDdf?= =?us-ascii?q?5MxWNvK1KTnhL86dm18ZV+7SleuO8v+tBZX6nicKs2UbJXDDI9M2Ao/8LrrgXM?= =?us-ascii?q?TRGO5nQHTGoblAdDDhXf4xH7WpfxtTb6tvZ41SKHM8D6Uaw4VDK/5KptVRTmij?= =?us-ascii?q?oINyQh/W/ZisJ+kr9VrhGjqBxxzIHbfI6bOeFifq7fYd8WWXZNUtpPWyFHH4iy?= =?us-ascii?q?b5EPD+0EPetAsYf9plkOrR+jDgSyA+PvzSRIiWHz3aIg1eQhChzN0Qs8H9IPsn?= =?us-ascii?q?TUqM74OqcIUe+r0qbF0CjNYf1M1Tf68ojIfQksrPeRVrxzacrc0UoiGx/fglmO?= =?us-ascii?q?tYDpIymZ2+UJvmSB8uZsS+yihmg6oA9ruDev3N0jiozRi4IQzVDL6Dt2zZ4uJd?= =?us-ascii?q?29VE57edmkEIZMty2CN4t5XMciQ2ZwtSY50LIGvZ+7fC0Ux5Q9wB7TceCHc4mK?= =?us-ascii?q?4hLnTuqePTB4hHV+eL2hgha9606gyvbmWsmzylZKoTJJktjKtn8Tyxze8suKRu?= =?us-ascii?q?dn8ku/xTqDyxrf5+BALEwuiKbXNZAszqY1lpUJsETDGiH2mF/xjK+Tbkgk5umo?= =?us-ascii?q?6+bjYrj9qJ+cLZF7hR/lPaQ1h8OzG+M4MhIBX2SD4+SzyKXj/VHlQLVNlvA2ka?= =?us-ascii?q?7ZsIvGJcQapa62GBFa0oI45hawCjepytUYnX0dIF1ZfxKHituhB1abA/f+Fuu2?= =?us-ascii?q?hUitln9ByvTBI6bmHN2ZLX/YjLbid7t5w0FZwQs3i9tY4sQHJKsGJafPW031/P?= =?us-ascii?q?ffCQQ0NgWy2K6zFNR/0qswQ2+CKJS1dqTIvgnbtaoUP+CQadpN637GIP8/6qu2?= =?us-ascii?q?gA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2C0CQBhDvZZ/3tFyFBbHAEBBAEBCgEBF?= =?us-ascii?q?wEBBAEBCgEBgzREEH4njw+OHAEBgXsyAYgcjXOCEYFSg3MChEpCFgEBAQEBAQE?= =?us-ascii?q?BAQEBaiiCOCKCQwEBAQECAScTHCMFCwsOBAYJJQ8SGBAOBhOKCwMNDKlxOoctD?= =?us-ascii?q?YNAAQEBAQEFAQEBASSDLohtgmqCJ4V2BaFHPJADhGyBAJI6SIxQijEmBC2BaFU?= =?us-ascii?q?yCIMtglwcgWhANokPKoIaAQEB?= X-IPAS-Result: =?us-ascii?q?A2C0CQBhDvZZ/3tFyFBbHAEBBAEBCgEBFwEBBAEBCgEBgzR?= =?us-ascii?q?EEH4njw+OHAEBgXsyAYgcjXOCEYFSg3MChEpCFgEBAQEBAQEBAQEBaiiCOCKCQ?= =?us-ascii?q?wEBAQECAScTHCMFCwsOBAYJJQ8SGBAOBhOKCwMNDKlxOoctDYNAAQEBAQEFAQE?= =?us-ascii?q?BASSDLohtgmqCJ4V2BaFHPJADhGyBAJI6SIxQijEmBC2BaFUyCIMtglwcgWhAN?= =?us-ascii?q?okPKoIaAQEB?= Received: from 123.69-200-80.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([80.200.69.123]) by relay.skynet.be with ESMTP; 29 Oct 2017 18:23:53 +0100 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.15.2/8.15.2) with ESMTP id v9THNqUc006216; Sun, 29 Oct 2017 18:23:52 +0100 (CET) (envelope-from tijl@FreeBSD.org) Date: Sun, 29 Oct 2017 18:23:51 +0100 From: Tijl Coosemans To: Konstantin Belousov Cc: freebsd-current@FreeBSD.org, gerald@FreeBSD.org Subject: Re: Segfault in _Unwind_* code called from pthread_exit Message-ID: <20171029182351.502f53cf@kalimero.tijl.coosemans.org> In-Reply-To: <20170826184034.GR1700@kib.kiev.ua> References: <20170823163707.096f93ab@kalimero.tijl.coosemans.org> <20170824154235.GD1700@kib.kiev.ua> <20170824180830.199885b0@kalimero.tijl.coosemans.org> <20170825173851.09116ddc@kalimero.tijl.coosemans.org> <20170825234442.GO1700@kib.kiev.ua> <20170826202813.1240a1ef@kalimero.tijl.coosemans.org> <20170826184034.GR1700@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 17:25:07 -0000 On Sat, 26 Aug 2017 21:40:34 +0300 Konstantin Belousov wrote: > On Sat, Aug 26, 2017 at 08:28:13PM +0200, Tijl Coosemans wrote: >> I did consider using >> a CFI directive (see patch below) and it works, but it's architecture >> specific and it's inserted after the function prologue so there's still >> a window of a few instructions where a stack unwinder will try to use >> the return address. >> >> Index: lib/libthr/thread/thr_create.c >> =================================================================== >> --- lib/libthr/thread/thr_create.c (revision 322802) >> +++ lib/libthr/thread/thr_create.c (working copy) >> @@ -251,6 +251,7 @@ create_stack(struct pthread_attr *pattr) >> static void >> thread_start(struct pthread *curthread) >> { >> + __asm(".cfi_undefined %rip"); >> sigset_t set; >> >> if (curthread->attr.suspend == THR_CREATE_SUSPENDED) > > I like this approach much more than the previous patch. What can be > done is to provide asm trampoline which calls thread_start(). There you > can add the .cfi_undefined right at the entry. > > It is somewhat more work than just setting the return address on the > kernel-constructed pseudo stack frame, but I believe this is ultimately > correct way. You still can do it only on some arches, if you do not > have incentive to code asm for all of them. Ok, but then there are two ways to implement the trampoline: 1) movq $0,(%rsp) jmp thread_start 2) subq $8,%rsp call thread_start /* NOTREACHED */ With 1) you're setting the return address to zero anyway, so you might as well do that in the kernel like my first patch. With 2) you're setting up a new call frame, basically redoing what the kernel already did and on i386 this also means copying the function argument. Do you have any preference (or better alternatives), because I think I still prefer my first patch. It's the caller's job to set up the call frame, in this case the kernel. And if the kernel handles it then it also works with (hypothetical) implementations other than libthr. > Also crt1 probably should get the same treatment, despite we already set > %rbp to zero AFAIR. I haven't checked but I imagine the return address of the process entry point is always zero because the stack is all zeros.