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: Thu, 8 Feb 2018 22:29:32 -0800 Message-ID: <2a02aac9-6aa3-4dc6-b122-039ae85365e8@redhat.com> References: <20180201205757.51911-1-hjl.tools@gmail.com> <4abf9786-1879-f16c-5a01-3261cd718d63@redhat.com> <87inb7pug7.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 1518157693 21327 195.159.176.226 (9 Feb 2018 06:28:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 9 Feb 2018 06:28:13 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 Cc: "H.J. Lu" , libc-alpha@sourceware.org To: Florian Weimer Original-X-From: libc-alpha-return-90170-glibc-alpha=m.gmane.org@sourceware.org Fri Feb 09 07:28:09 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=pXfrPlMjeoodjCwC ghMUZWhAnVoPokommI0wZK0ghZtwW0zYAzGEWJqbRkJ/IS/+giJT9EngJf3cM3kp xU7UYYse2iFVvc5AYJzBmvKRXsX6176bM8KYxy57V8DYRK/UoLxoyqUgpkNC0tZn gZI3mZirx0tAMU9VGn9DZaOr6P0= 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=ctDEVHPILXiKGkKNv8AB7M urZno=; b=M4pjLDlBzXTrTpDXL0AXR6qAyZz6lGxlPpzRtUtmhFpDd35WGWNSS6 TSxbAz8p7uQc9UdFT+DXgtw3M9vW+39g9hZiCzAg5YjJiMbXmOWS73SI3ZRBbEgV IgcWt77AY7birbqpa3Q/cTdMagyAMWyG1Ks2OoXK9quBOMjxpJ0oI= 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.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=quality X-HELO: mail-qt0-f193.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=xMFG8IDp87AXA8FzJPMm7mTG3jxO3dLVmoBBFCQKimc=; b=rSVKFGaHzdKFnYV+H4hso74t9rMI4a1BAl34nk+SkJS6LO1m9ApsCBijDpvw/gt9O/ r+fiYgirTQo2/sf2qoDp5rLLuw71zAsTICDKPD4Ovf+Wz7iVRE7LN3Rc2R5qYuZYYFsq 66AaTiKHoMWW5fUtFXZNgWqxp2EX3vqGEiRWA+iqKNHlmoNSPXHUjhgcTai+0s9DdmoN FHpqNsNBV5JuTnQYRw21rrA7FFCf9xWE8s8lDtR+6mZhYmsZEXBqOtAxUQQytcetleRH T+KxhcDSBUanzM1IxD9fVJITY58m3LnD4dA6WrZp7A+fZcCBubAhHjN+BQ5SmY174Bcj Wxbg== X-Gm-Message-State: APf1xPBxKVsriQucGp6mvWrhnlIG2nh9kVtlEm03WXtQcIqHNXL0j8/D Sx0OIonK9wFmMwtAPNLFgcupwC51mWk= X-Google-Smtp-Source: AH8x2259VGbs4teOCmjyI5pKSJJj+MUBjUJy9VaA+2jegNdbItGaKwDm+lWyVtz/c0JX8cxqevpzxw== X-Received: by 10.200.18.6 with SMTP id x6mr2980185qti.109.1518157776394; Thu, 08 Feb 2018 22:29:36 -0800 (PST) In-Reply-To: <87inb7pug7.fsf@mid.deneb.enyo.de> Xref: news.gmane.org gmane.comp.lib.glibc.alpha:82518 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 1ek29r-0003Q2-17 for glibc-alpha@blaine.gmane.org; Fri, 09 Feb 2018 07:27:39 +0100 Received: (qmail 118626 invoked by alias); 9 Feb 2018 06:29:40 -0000 Received: (qmail 118617 invoked by uid 89); 9 Feb 2018 06:29:40 -0000 On 02/08/2018 03:55 AM, Florian Weimer wrote: > * Carlos O'Donell: > >> I would like to see an argument made for CET markup against versioning >> __pthread_register_cleanup. > > I don't think __pthread_register_cleanup. It's __sigsetjmp. We would > have to version __sigsetjmp. Changing the name would be ideal, but > this will be difficult because of its returns-twice nature. I'm looking for a solution that yields a clearly diagnosable failure when users mix a compiler which emits CET markup and a glibc which has the smaller sized cancellation jump buffer. If we version __sigsetjmp, we need to decide the semantics of the old and new version. A naive old version would not save the shadow stack pointer to the reclaimed space after the newer smaller internal __sigset_t, and a newer version would save the shadow stack pointer. This leads to sigsegv when a user mixes as above by accident, and they will have no warning about the problem. The CET markup will be present in all objects they have, but when run with a newer glibc it will crash by corrupting the stack when it writes the shadow stack pointer. My suggestion with __pthread_register_cancel et.al. (and yes we would have to version all the interfaces) was to basically data version the structure, but my original idea revolved around the idea of shifting __pad[3] up to the start of the structure and use it for versioning. However, your idea to version __sigsetjmp has reminded me that __saved_mask need only be non-zero to work properly and we could store a version cookie there, which could allow us to do the following: * Version __sigsetjmp, and store a version cookie in __saved_mask indicating the version of the structure. * Have the old __sigsetjmp disable CET since it clearly indicates that we have the wrong sized structure regardless of CET flags. * Adjust the unwinder to look at __saved_mask version cooke to decide which sized structure it is dealing with. Is this feasible? It would give high quality diagnostics and potentially allow us to extend the cancellation jump buffer with more data in the future. > I also don't have a problem with requiring -fexceptions for > cancellation handlers with CET support. For additional safety, we > could change sigsetjmp to write the shadow stack pointer before the > kernel signal mask, so that it will still be in bounds for legacy > cancellation handler allocation. __pthread_register_cleanup will > overwrite it, but I don't think we ever need to restore it, so that > shouldn't be a problem. 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? -- Cheers, Carlos.