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 06:13:43 -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 1518185514 10414 195.159.176.226 (9 Feb 2018 14:11:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 9 Feb 2018 14:11:54 +0000 (UTC) Cc: "Carlos O'Donell" , GNU C Library To: Florian Weimer Original-X-From: libc-alpha-return-90181-glibc-alpha=m.gmane.org@sourceware.org Fri Feb 09 15:11:50 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=qeRN 8O7INk7x6myXgI0se0Xc46gkTb7GxfFQhwJ18dyqac7y9kvIdXPW4Gl32In/TP9A 9AGz+emugSr8p41LikXGM9hotbL34YqMHDgxBMmBjwjoa7UuD+pM0PYUTnwGVdbh YeCgvL7P/jYTBQDSAYhyEjmIODRPlgVzKN3i060= 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=5TX35TKVCo hd2BBAFsm/nPnwiDw=; b=V2Ugagg3s7TsDOZQHJTgCuoaJ5ISnRweK1hOhyIm7H ouBdKHF9MU6FLcc5QunaBtDaLueEgJAplq6OI7xnthdbsUhQyLZuAj4TEkRie61Y 2m+FD256VTCeqUslW8+U+rvusyuK1TMtGN27Zj1mNFUdrJXjPsWNBaPLYT86wBB0 A= 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=-0.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,LIKELY_SPAM_BODY,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=ecosystem X-HELO: mail-ot0-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:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rjDQjBD8eqzsegexB68ovSlT42Rjf6hXkEOG0jgXX28=; b=PNXb7jk/pLc7WXvb8SurorIQLj24SLWOHbRnznQzvKs7wPitxACjg33c7AZcLU+4Ld JQoFbO4kCLl67GYZYlYl1ubUobALYPDQoFekzEV/NB5VHRI8xwhGdexEJXGiEAAFQakK MdO8S4xka+UTfEvRMEtkfNh0QKi/5LCcbTtn2HorvZvsQRlj6KdP8aU1G7mJEG2lEi0s +ELXiSGovc0TJU9ghLmzjmVvYklETeMlqjcagrXxZes3VWhIJpcQoxRXl1vNQt11GtDc 8dSYLkuFfAQ3Gv5rmdQcJk4q9G4wXwaOY9TcspkV/DHagQLT13k3VNvvsoypq01jXS78 2tHw== X-Gm-Message-State: APf1xPDzYHhr1ysVkA3g7OhfaRyeOxHC94UG/Pc4xVfesEqqeo9Vj+Ax pgRzDu8G8IfU1y618UyErvATVYs1BX6KSLoLUdE= X-Google-Smtp-Source: AH8x227i3Tcjh99LPzkK3gzuNUD3LDVU32rX3ef2IjGF0OrdYQsq600X3mcePXnlPhnhph/Rtp5v1kT6B1o+CwjXXWc= X-Received: by 10.157.21.119 with SMTP id z52mr2167251otz.234.1518185624281; Fri, 09 Feb 2018 06:13:44 -0800 (PST) In-Reply-To: Xref: news.gmane.org gmane.comp.lib.glibc.alpha:82529 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 1ek9P1-0002Ec-2p for glibc-alpha@blaine.gmane.org; Fri, 09 Feb 2018 15:11:47 +0100 Received: (qmail 78462 invoked by alias); 9 Feb 2018 14:13:48 -0000 Received: (qmail 78452 invoked by uid 89); 9 Feb 2018 14:13:47 -0000 On Fri, Feb 9, 2018 at 4: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? > >> 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. > > I built glibc master with gcc-8.0.1 -mcet -fcf-protection. Some object files do get CET marker as expected. But static executable isn't: [hjl@gnu-skx-1 build-x86_64-linux]$ readelf -n elf/sln.o Displaying notes found in: .note.gnu.property Owner Data size Description GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0 Properties: x86 feature: IBT, SHSTK [hjl@gnu-skx-1 build-x86_64-linux]$ readelf -n elf/sln Displaying notes found in: .note.ABI-tag Owner Data size Description GNU 0x00000010 NT_GNU_ABI_TAG (ABI version tag) OS: Linux, ABI: 3.2.0 Displaying notes found in: .note.gnu.build-id Owner Data size Description GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring) Build ID: ab9587f0ef16086b740923f72bc1a024b6185b06 [hjl@gnu-skx-1 build-x86_64-linux]$ My CET ecosystem design prevents what you worried from happening. -- H.J.