From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Carlos O'Donell Newsgroups: gmane.comp.lib.glibc.alpha Subject: Re: [PATCH 0/2] nptl: Update struct pthread_unwind_buf Date: Fri, 23 Feb 2018 21:46:16 -0800 Message-ID: <90d3ee18-c292-117f-a0c1-7822e340ca02@redhat.com> References: <20180201205757.51911-1-hjl.tools@gmail.com> <4abf9786-1879-f16c-5a01-3261cd718d63@redhat.com> <87inb7pug7.fsf@mid.deneb.enyo.de> <2a02aac9-6aa3-4dc6-b122-039ae85365e8@redhat.com> <87d11emoap.fsf@mid.deneb.enyo.de> <878tc2mkgr.fsf@mid.deneb.enyo.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1519451067 21754 195.159.176.226 (24 Feb 2018 05:44:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 24 Feb 2018 05:44:27 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 Cc: GNU C Library To: "H.J. Lu" , Florian Weimer Original-X-From: libc-alpha-return-90535-glibc-alpha=m.gmane.org@sourceware.org Sat Feb 24 06:44:23 2018 Return-path: Envelope-to: glibc-alpha@blaine.gmane.org DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=G/l+XHEZtiO6RWqo mldIVD90BsuQVwTuKPD/AdyOWQbFkFJdlkKVOCeVwJU+K5vwi6+vr+93k/+ANEpw xfNgY3mZeLqPI6Q2Ok+C4j1/SdPDF1+gsmwb0ApvJOzWRmM4njm0OoVEcsNbHx2k 0sYqhVpSzuD1uxl+A1gf1irnWxA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=kkBANbjYvmbx3AfDoe5R9f aVals=; b=nnUmYRt5LI6QLTYAnuHNTDpXU3nNuDdtaYfpjP2J2xcHv9ofHb3kNe eRZJZyBJRIHiRknBSYxwIWjsX2R1l2s5GSJJaUfdAvrjkyxMGzE0oT1AXxY8Mr8z 6jbGB7MFoXeP4jmuHRWGBFwyVn4X+1JHg9qXflWuEoNg7QZADEYsM= 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: , Original-Sender: libc-alpha-owner@sourceware.org Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=USER, realization X-HELO: mail-qk0-f196.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=QroVKb3TM6Wh3/rKJGKQBna89wFmK2EEYG3OHKZK9T8=; b=N39ROulQBcdZBSUxREo1kkADTyJBOgTu9PWlKT3cgReI3xsqtnHshFr/UPhJ+O+xbC FN1zd7ULI3O65vZ49jNRcdo7dVjZ0sl7/7aAGQfkyQp/R/Hyk5Wcvy/52Grl1AzPliSY jk1nJEVKs0f9BmJPdobN7NnRcuKyc2xR3V/Slm/y6iV3850g+FiW+B7UcTWceRegyrrP EiwuGyybHHzlcPH4+tuGAv33uxUbSouJ3zXmEQvXuY11KUfUxGkNTISUHk5LWMP3dE4a Z04euiyQkImESZBgot1VWVr0etTNotNaHhgkK7MQOk2vNcVbH9mIUNeKSWu5zcxjocLC T+bw== X-Gm-Message-State: APf1xPD3G75tMujnxLomDJRdxSV2uz6+q2Yky+sWgq80B2JeHT5pn5yx 648CZX4c4iM9V8AsAy7FHx4WQOEr3Ck= X-Google-Smtp-Source: AG47ELsOAzPzXJIHCZdTr4sLNj2/5ZTseHKGjIcbeHu1C6usrMDbTda2a+63CQtB4q2D6AY/wLS6/A== X-Received: by 10.55.204.195 with SMTP id n64mr6605594qkl.87.1519451180840; Fri, 23 Feb 2018 21:46:20 -0800 (PST) In-Reply-To: Xref: news.gmane.org gmane.comp.lib.glibc.alpha:82867 Archived-At: Received: from server1.sourceware.org ([209.132.180.131] helo=sourceware.org) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1epSdC-00057O-Hx for glibc-alpha@blaine.gmane.org; Sat, 24 Feb 2018 06:44:23 +0100 Received: (qmail 112032 invoked by alias); 24 Feb 2018 05:46:25 -0000 Received: (qmail 112015 invoked by uid 89); 24 Feb 2018 05:46:24 -0000 On 02/09/2018 04:34 AM, H.J. Lu wrote: > On Fri, Feb 9, 2018 at 4:11 AM, Florian Weimer wrote: >> * H. J. Lu: >> >>>> My proposal is still rather hackish, but so is the existing code (the >>> >>> A pointer to a buffer in user program is passed to libpthread. >>> There is a jmp buf in the buffer followed by other fields. Since >>> the size of jmp buf is increased in glibc 2.28, we need to know the >>> offset of other fields. Otherwise libpthread may write beyond the >>> buffer in user program. I don't see how symbol versioning can help >>> us here since the INTERNAL libpthread functions don't know the >>> layout of __pthread_unwind_buf_t of USER programs. >> >> I suggest *not* to increase the size of the jump buffer. > > Where do we save shadow stack pointer? typedef struct { struct { __jmp_buf __cancel_jmp_buf; int __mask_was_saved; } __cancel_jmp_buf[1]; void *__pad[4]; ^^^^^^^^^^^^^^^ Save the shadow stack pointer here. } __pthread_unwind_buf_t __attribute__ ((__aligned__)); Save the shadow stack pointer to __pad[4] by making the internal sigset_t smaller and moving it down. The key aspect of Florian's recommendation is a realization that a pthread_cleanup_pop can only restore you to the *same* function e.g. the earlier pthread_cleanup_push, and therefore does not need to change the shadow stack pointer. All subsequent unwinding will proceed from one jump buffer to the next, and through the unwinder, until it reaches pthread_create. When will we ever return via a normal return instruction and need to verify via the shadow stack? -- Cheers, Carlos.