From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13195 invoked by alias); 24 Feb 2018 15:19:48 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 13181 invoked by uid 89); 24 Feb 2018 15:19:48 -0000 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) MIME-Version: 1.0 In-Reply-To: <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> <90d3ee18-c292-117f-a0c1-7822e340ca02@redhat.com> From: "H.J. Lu" Date: Sat, 24 Feb 2018 15:46:00 -0000 Message-ID: Subject: Re: [PATCH 0/2] nptl: Update struct pthread_unwind_buf To: "Carlos O'Donell" Cc: Florian Weimer , GNU C Library Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-02/txt/msg00698.txt.bz2 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.