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 04:34:07 -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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1518179558 2298 195.159.176.226 (9 Feb 2018 12:32:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 9 Feb 2018 12:32:38 +0000 (UTC) Cc: "Carlos O'Donell" , GNU C Library To: Florian Weimer Original-X-From: libc-alpha-return-90177-glibc-alpha=m.gmane.org@sourceware.org Fri Feb 09 13:32:34 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=E3Ux itZP3ST0QpXG+Cdk2pSQ+d3VYGngwgzF+viascKPccQau/fqmpu75LevPfgp2xyE k1I9NEXR9EVRjTdDVmaxgQ+n0d6cwMNEv+TbjYJ1DnWdGdY4acBuGSqvPG+hmL4K CI9u4Y8Icft9SR+b16DpPGhcmpZZ8ywLoc4nihE= 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=z0yq+XEsYv 6vGnaMz2/mz9jxRn4=; b=x26U/Fx4keU0bsiZG85W1VedAnBtRWTLINY5iDZ51H NYSn6VBRAAyFMMX3PJ7D9vQDCS9KdWCy7RBo3WQcaNdoh6r3vaQih4v+T+NVQL9q OPxnxMT/XH58i3D4RWvwIj8u2VxiHlfbAVLufX9XYI8ISLMmXrIqAt6FArfJOXXG 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=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-ot0-f170.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=7bbNWqN83FKMw9wdwWRgHtZ/bDGgUNAaafOWmDFgmGQ=; b=rierTS+abjGkuT5KdB6RNgLRhNg+crniA+vpbsyk4usRu9vQhWPGLyEV4xwAXbvK5w TutsQQRAbBqlKKDGHTT8cnyt9j4yIAdaES7OZMQP6rWWAxwzbLCvkOQ2H2Jfk8UYz8Iq SxVdR23yuMcZREy5OQgKVz7wIGWaiwu7A5NfeysFPBlfS4u2DEUH59PCd49c6KZjmsG9 gFeFOwokZ2KjnL+xyrllPuf5sgj6+XlXVih06idiUmZoYCshTMZgD9Kv+XEQKiGD4LEA Ve18lT53p9ejy97bNT9t4+0zgV8Le4tVmNrnmyDUGBR0TOwOly7WcBzg20hdoT0OitrX wPAg== X-Gm-Message-State: APf1xPCEEXcpnaAnn3nltNGv6mK1OeHB/8VU2LV8I6lSRxae02UpEP4D GfBGwK8rvwv7+Uhv4ek3Mw77iZoZlPkjjS9rhqI= X-Google-Smtp-Source: AH8x2253DXf64396XKaRZCxSNDOmiHMXhJikQnnMe3HZqssK+kjymdtx7TBkR2joTGaqXpb7LPqW+XHGxPKqjDbvAQg= X-Received: by 10.157.67.122 with SMTP id y55mr1944610oti.229.1518179647477; Fri, 09 Feb 2018 04:34:07 -0800 (PST) In-Reply-To: <878tc2mkgr.fsf@mid.deneb.enyo.de> Xref: news.gmane.org gmane.comp.lib.glibc.alpha:82525 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 1ek7qb-0007Mp-MT for glibc-alpha@blaine.gmane.org; Fri, 09 Feb 2018 13:32:10 +0100 Received: (qmail 73985 invoked by alias); 9 Feb 2018 12:34:11 -0000 Received: (qmail 73951 invoked by uid 89); 9 Feb 2018 12:34:10 -0000 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? > CET markup will not be correct for static libraries compiled against > 2.27 or earlier with a CET-enabled toolchain, so this is the only > completely safe approach. I don't believe so. As long as there is a single input .o file which isn't marked with CET, the output static binary won't be marked with CET. If what you said is true, please file a glibc bug report. -- H.J.