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: Fri, 9 Feb 2018 03:13: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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1518174731 15190 195.159.176.226 (9 Feb 2018 11:12:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 9 Feb 2018 11:12:11 +0000 (UTC) Cc: "Carlos O'Donell" , GNU C Library To: Florian Weimer Original-X-From: libc-alpha-return-90175-glibc-alpha=m.gmane.org@sourceware.org Fri Feb 09 12:12:06 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=Rj8n xj9OHMtZkzQ5N20sPeDjP2r5tAFOwQx5ANBGvszlWs4Nad5D+hWUOyiqRt+cXhYw g/HT9HvK7pp8+5tWXPSiXXYuoi2QPQgFHJO2HtT42QGjngs0nhMFSo8AT9w/REDc o85+m6ZWT3/sZf8VpoYuHDo2Td5OcgA31mJKwdo= 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=XBiNMqKOfh yfeW+QKuNMdRrav6U=; b=TBdkKDUdKnIyBHFewQh8PLCI/QZ9uJnKGgEg5eRCMJ ThmSdE0f4leY6WhU0LmaxKklgcE5LFdIhKIG6pkBi/qXVuuRRI04dtUjdRj1loDc 7QSXB4pNWSKCpPIi0pQXP13hzL8uv3jDI9wAN5EG2XFNZfV7+5mjeKBvyyUrVKC8 k= 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=-1.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,UNSUBSCRIBE_BODY autolearn=no version=3.3.2 spammy=Hx-spam-relays-external:209.85.218.65, H*RU:209.85.218.65 X-HELO: mail-oi0-f65.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=SpADeus3A7uzpq0+s7wJgmq/yjJsHJ283M6j1NaGSWM=; b=C8snzINHwI8f5Oda1q9ahANqCzPhomgumj8H2aspyaQKcTqnMVgVrgiCwH6bxoLXwk z/9HAiLOs9CVCuqNlvGthDPyke23Frdj2ldAVozSXS7u7vNgNtudMpeCgQP54I3B4b2/ cwxltdsHTUc0CmEr9oprws9L7Et+14NrCiVQaiPGubg/g+RpA4jVTs9KU5s192Fuc7WZ 5Lx049lGftdnqkHv9FJ5DOKu8YWAVOO1BLTxFOEdW2/tW7J5HVsAg3mTbqJe4MuKsSpp lTLYvALhQmOey6bouwKSiRJ+2+DmF5jyr/XqE3d4kt3rd9TxsGK5QVq9YaINmOQOjxtV 7K5Q== X-Gm-Message-State: APf1xPDteb1M788cL0C8yNI2uRZi2PHrCp/NkEf3L8AoQj5JaQ/EAMTL tufnubzLctC6nnM7pof0Zv+MnwuXF+GhG0lY2SX1gw== X-Google-Smtp-Source: AH8x224/P9CjFJxI8VfHzxAjD+Rj2GY5EVrL7fTgvI4NKaWe+lQYg2ymgsCELHtaHblHB1mXaKtKXfrdXt7lS2S5e58= X-Received: by 10.202.68.213 with SMTP id r204mr1632943oia.80.1518174824615; Fri, 09 Feb 2018 03:13:44 -0800 (PST) In-Reply-To: <87d11emoap.fsf@mid.deneb.enyo.de> Xref: news.gmane.org gmane.comp.lib.glibc.alpha:82523 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 1ek6ao-0002Qd-4o for glibc-alpha@blaine.gmane.org; Fri, 09 Feb 2018 12:11:46 +0100 Received: (qmail 55173 invoked by alias); 9 Feb 2018 11:13:48 -0000 Received: (qmail 55150 invoked by uid 89); 9 Feb 2018 11:13:47 -0000 On Fri, Feb 9, 2018 at 2:48 AM, Florian Weimer wrote: > * Carlos O'Donell: > >> In the truncated sigjmp_buf used by pthread cancellation we have only >> void * which is not large enough on x32, where you need a 64-bit >> shadow stack pointer. It would work on every other machine though. >> HJ has mentioned this problem already IIRC. >> >> Why would __pthread_register_cancel overwrite it? > > __pthread_unwind_buf_t is defined as: > > typedef struct > { > struct > { > __jmp_buf __cancel_jmp_buf; > int __mask_was_saved; > } __cancel_jmp_buf[1]; > void *__pad[4]; > } __pthread_unwind_buf_t __attribute__ ((__aligned__)); > > pthread_cleanup_push does this: > > # define pthread_cleanup_push(routine, arg) \ > do { \ > __pthread_unwind_buf_t __cancel_buf; \ > void (*__cancel_routine) (void *) = (routine); \ > void *__cancel_arg = (arg); \ > int __not_first_call = __sigsetjmp ((struct __jmp_buf_tag *) (void *) \ > __cancel_buf.__cancel_jmp_buf, 0); \ > if (__glibc_unlikely (__not_first_call)) \ > { \ > __cancel_routine (__cancel_arg); \ > __pthread_unwind_next (&__cancel_buf); \ > /* NOTREACHED */ \ > } \ > \ > __pthread_register_cancel (&__cancel_buf); \ > do { > > __pthread_register_cancel overwrites __cancel_buf.__pad. If > __sigsetjmp were to write to that memory area, it would not matter, as > long as we skip restoring the shadow stack pointer during unwinding > (which we do not need to do because we never return along the regular > execution path recorded on the shadow stack). That is true. > In short, the only thing need to ensure is that the over-write from > __sigsetjmp stays within __cancel_buf. Then we are good, without > changing the stack layout for cancellation. That is correct. > 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. > truncated jump buffer), and HJ's approach of storing the shadow stack > pointer in the signal save area of the non-truncated jump buffer. But > I think we can make it work. -- H.J.