From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11765 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: possible bug in setjmp implementation for ppc64 Date: Mon, 31 Jul 2017 16:30:07 -0400 Message-ID: <20170731203007.GB1627@brightrain.aerifal.cx> References: <1501520360.0.593167188853569@go.bunnymail.go> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1501533020 3090 195.159.176.226 (31 Jul 2017 20:30:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 31 Jul 2017 20:30:20 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-11778-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jul 31 22:30:16 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1dcHKS-0000YV-9k for gllmg-musl@m.gmane.org; Mon, 31 Jul 2017 22:30:16 +0200 Original-Received: (qmail 15688 invoked by uid 550); 31 Jul 2017 20:30:20 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 15659 invoked from network); 31 Jul 2017 20:30:19 -0000 Content-Disposition: inline In-Reply-To: <1501520360.0.593167188853569@go.bunnymail.go> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:11765 Archived-At: On Mon, Jul 31, 2017 at 10:06:51PM +0200, felix.winkelmann@bevuta.com wrote: > Hi! > > I think I may have come across a bug in musl on PPC64(le), and the folks > on the #musl IRC channel directed me here. I'm not totally sure whether > the problem is caused by a my misunderstanding of C library functions or whether > it is a plain bug in the musl implementation of setjmp(3). > > In out project[1] we use setjmp to establish a global trampoline > and allocate small objects on the stack using alloca (see [2] for > more information about the compiliation strategy used). I was able to reduce > the code that crashes to the following: > > --- > #include > #include > #include > #include > #include > > jmp_buf jb; > > int foo = 99; > int c = 0; > > void bar() > { > c++; > longjmp(jb, 1); > } > > int main() > { > setjmp(jb); > char *p = alloca(256); > memset(p, 0, 256); > printf("%d\n", foo); > > if(c < 10) bar(); > > exit(0); > } > --- > > When executing the longjmp, the code that restores $r2 (TOC) after the call > to setjmp reads invalid data, because the memset apparently clobbered > the stack frame - i.e. the pointer returned be alloca points into a part > of the stack frame that is still in use. > > I tried this on arm, x86_64 and ppc64 with glibc and it seems to work fine, > but crashes when linked with musl (running Alpine Linux on a VM) > > If you need more information, please feel free to ask. You can also keep > me CC'd, since I'd be interested in knowing more about the details. It looks to me like we have a bug here, but it's one where I or someone else needs to read and understand the PPC64 ELFv2 ABI document to fully understand what's going on and make a fix. I'll try to get to it soon, or I'm happy if someone else wants to. I don't just want to cargo-cult whatever glibc is doing, though; a fix should be accompanied by an understanding of why it's right. Rich