From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: "H.J. Lu" Newsgroups: gmane.comp.lib.glibc.alpha Subject: Re: [PATCH 0/2] nptl: Update struct pthread_unwind_buf Date: Sat, 24 Feb 2018 07:19:44 -0800 Message-ID: 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> <90d3ee18-c292-117f-a0c1-7822e340ca02@redhat.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1519485472 1819 195.159.176.226 (24 Feb 2018 15:17:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 24 Feb 2018 15:17:52 +0000 (UTC) Cc: Florian Weimer , GNU C Library To: "Carlos O'Donell" Original-X-From: libc-alpha-return-90552-glibc-alpha=m.gmane.org@sourceware.org Sat Feb 24 16:17:48 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:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; q=dns; s=default; b=CpK8 M0q9SFKtSAjLs/bqs39A59BayjgtM3FiauvvcqAxRh8TnUObLz6im8/WZ1sE5bcg SSrOKl3L+2wyYT21FseGSKB0ffZcvof/kcWvuzMbNXSu8nBF4D04m2vR0805UO8q fRHHkGmYsqsqOgHahB5LMu5k6b9TJUczKWpvPDs= 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:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; s=default; bh=9zilIcoa0q 2AoXwXIiXXfLzUkR4=; b=iPGYAW/+9VEKPV8AzRW/fzBOArD21l+yQtjZM++TjM hP/e2FsIzCgNDCW1zjxmTWSOgd1zFlG0vRFpbIzJWhMRX8EZPwLknuKOlwwvacTt Bvx1tN05THUqKZGuilangLXBK7lQbjAZhPHSnyS/PN200sSH2aws6J47chfX2OJT g= 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=-7.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_2,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=USER, realization X-HELO: mail-oi0-f68.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UHOV8j6NizyE9Rl4cD4MoP4udpQ3aCXRmv97s0OcywU=; b=PkxkzLIwKMTGkVIxUsK/09EGz10RLUZct+7BlQy+Bek7shoHQQZ5DSyJunhe4oip/1 sd1M/RJN0J7DIMTELSmRRlurzFb5ylrP0BaGzD6xDNKwe2ZYNQib5cg+LtCxbHO1jQKA kwdur463NA/IQD+DFDn+VsDiRmjoS8StnIgB9cC/3EE47xA9aWy+LrCwWRZELO5bMmZs SKq6lCwZivss9l4rYqnWvRnDZA1hjOzndZpPgbZwZK+nTIXX1Tp/SkyvLEuI8QydDo2S InfsjcX4jM5rGl8hzaYpbWfyZ7fohuTnnZyP58BmCNqgyrW4S56aFjXpLYwrikub3K43 6j0w== X-Gm-Message-State: APf1xPCk7ca4CY2D26i+3nLS0ptCNwuhMc+QO8tAd5hEmnWA+0d1A80E M75IMW9bdcnYC7a4IgL1b8n/lXrYLd/jvq6NYeo= X-Google-Smtp-Source: AG47ELsnsdWxngPwQYgls+LwJMnJ/E4FaxqKKQDaW4YxLi9ZJ6f7GKAHTV2FUpr+FyqhDEJKs77es37ILeC2j3eaefw= X-Received: by 10.202.253.135 with SMTP id b129mr3387543oii.100.1519485585026; Sat, 24 Feb 2018 07:19:45 -0800 (PST) In-Reply-To: <90d3ee18-c292-117f-a0c1-7822e340ca02@redhat.com> Xref: news.gmane.org gmane.comp.lib.glibc.alpha:82884 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 1epba5-0008DH-Ps for glibc-alpha@blaine.gmane.org; Sat, 24 Feb 2018 16:17:46 +0100 Received: (qmail 13195 invoked by alias); 24 Feb 2018 15:19:48 -0000 Received: (qmail 13181 invoked by uid 89); 24 Feb 2018 15:19:48 -0000 On Fri, Feb 23, 2018 at 9:46 PM, Carlos O'Donell wrote: > 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. PLEASE take a closer look: Yes, there are void *__pad[4]; But the name is misleading. It isn't real padding. This is an opaque array: /* Private data in the cleanup buffer. */ union pthread_unwind_buf_data { /* This is the placeholder of the public version. */ void *pad[4]; struct { /* Pointer to the previous cleanup buffer. */ struct pthread_unwind_buf *prev; /* Backward compatibility: state of the old-style cleanup handler at the time of the previous new-style cleanup handler installment. */ struct _pthread_cleanup_buffer *cleanup; /* Cancellation type before the push call. */ int canceltype; } data; }; Only the last element in __pad[4] is unused. There is --- Note: There is an unused pointer space in pthread_unwind_buf_data. But it isn't suitable for saving and restoring shadow stack register since x32 is a 64-bit process with 32-bit software pointer and kernel may place x32 shadow stack above 4GB. We need to save and restore 64-bit shadow stack register for x32. --- in my commit log to explain why it isn't suitable for shadow stack. -- H.J.