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:40:24 -0800 Message-ID: <31c5f7cf-fe1b-5dc7-133c-6c10a3ae678f@redhat.com> References: <20180201205757.51911-1-hjl.tools@gmail.com> <4abf9786-1879-f16c-5a01-3261cd718d63@redhat.com> 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 1518158342 6894 195.159.176.226 (9 Feb 2018 06:39:02 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 9 Feb 2018 06:39:02 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 Cc: GNU C Library To: "H.J. Lu" Original-X-From: libc-alpha-return-90171-glibc-alpha=m.gmane.org@sourceware.org Fri Feb 09 07:38:57 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=PXoEIqK+Rb7knNoe OvDSEqHPSRd96Si8nYeXBGEaRzAd1yHw9Mo269yXIrfGXahsKRNygpEMIQZVErt1 rLurVA5vzFH1p7lV+UsiJaHZ2pQB9CHCxJkA3I1B+mwMYUiULtNV/buuSv7cnyAW RI9qC1YziS9zSLNStunZbzwd3Xg= 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=Q1AZ71FXHkr/G/KrxvkvOE uhNJs=; b=w+Z14C3amb/IFq5oDPhsiuPqejz/uk7jTTNad9W+Pj5XHe2sCaAS16 /wdw8lR+Jk5AFXIl1F1IxBLzuP3bnZXbXFRJ8SQfORihSyf7Ap8ZUJuVOWF0DOok IDYFrYc3WnB493jXNE+QGw7ye2/64vHG+23R1GEgTH21mzQ4v7hoQ= 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=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=bullet X-HELO: mail-qt0-f195.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=svv4TfpDJIOK2kyf6hOzEiTySAowF//d3EvV/xF7we4=; b=qzRkS03NKkFfcORM7NOM5NfgmNxPA5eceiivoF5VBghhrImiJKqEFfEzqzCVPJXwzw D1DD0Gym6LS6PYZS0AzI7/yjsBT6Duy3C2y5RY4rYWjboh0EVGZ+6uN+t/p8roNi4llQ NWUhcoRP7LOG+LdeuDsHH9GZTMq/xvXfff1gEvs1y3KvlhYQB7v8khWvfH+ov91xwS/L 1dN7tj7YN8uwOxrk1om568rOU2bPyoPg+xlGtXRGvIukGW0QLoBO7tOFnDLGzPDI9FpI VRVQTQhN0x+VsmJoFKLZwR+WV6I2j9PRNIgrE0iEfJcAgKCoYf4UJNmKFNEX2+S+bN6l 9p0Q== X-Gm-Message-State: APf1xPBLMSzgAAaOUp7tN1IykwKkCBfRxbqC2Cg9DSYXq0nJ0i7F13Dt ycmvUeendo+H+rd0Uxu1zq4Y9OnaNtU= X-Google-Smtp-Source: AH8x227vRtC4wee0YctA9YUi0M8FMDCPo6sQ177ArWRiq1v9v2J4SuTbfhmkdKfvvLBv9JYrnTdYdA== X-Received: by 10.200.56.151 with SMTP id f23mr2603080qtc.243.1518158427737; Thu, 08 Feb 2018 22:40:27 -0800 (PST) In-Reply-To: Xref: news.gmane.org gmane.comp.lib.glibc.alpha:82519 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 1ek2KL-0008CR-7O for glibc-alpha@blaine.gmane.org; Fri, 09 Feb 2018 07:38:29 +0100 Received: (qmail 122263 invoked by alias); 9 Feb 2018 06:40:31 -0000 Received: (qmail 122253 invoked by uid 89); 9 Feb 2018 06:40:31 -0000 On 02/08/2018 05:27 AM, H.J. Lu wrote: > On Thu, Feb 8, 2018 at 1:25 AM, Carlos O'Donell wrote: >> Again, I would like to see an argument made for CET markup against versioning >> __pthread_register_cleanup. > > Symbol versioning works well when only opaque data pointers are used. > A pointer of struct pthread_unwind_buf is passed to libpthread from user > programs. Within libpthread, we need to know the exact layout of struct > pthread_unwind_buf. It is next to impossible to use symbol versioning here. My worry is about incorrectly marked up objects which use the wrong unwind buffer size resulting in difficult to diagnose crashes. The exact issue would be users using a gcc and binutils which marks up binaries with CET notes, but glibc headers which are not CET enabled. This will happen when we ship Developer Toolset with a gcc and binutils that has CET support, but the system glibc is still < 2.28. Then users will take these binaries and try to run them on systems with glibc >= 2.28 because we allow this backwards compatibility, and this will segfault because we are turning on CET, but mixing different sized unwind buffers. Please tell me if you think my worries are unfounded, or of sufficiently low risk that they will not be a problem, or that we can somehow say that what was done was unsupported e.g. saying that Developer Toolset used with Intel CET flags to build anything on any system with glibc < 2.28 generates unsupported binaries. My suggestion in the other email is that we briefly investigate what it would take version the data in the unwind buffer such that we *can* handle different sized objects properly, and enable us to potentially grow the unwind data we have in the future. To reiterate from my other email: * 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. The third bullet point is effectively what you are *already* doing with the CET flags, but using the flags in a coarse way to decide which of 2 sizes of unwind buffers we are using. This has the problems that I outline above which is that it is error prone. While the symbol version mechanism will always tell us exactly which sized object was used when the TU was compiled. -- Cheers, Carlos.