From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18824 invoked by alias); 17 Apr 2018 23:20:24 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 18805 invoked by uid 89); 17 Apr 2018 23:20:23 -0000 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,URIBL_RED 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=ofz/xH9Pb/xqZWOrGwL6qznPuguSXI7/yDMQu/hMfRY=; b=I2F41IYsH2f7IeJ/H1CvUzB7/4GN3W739kgNWSRlBpNI2hLvtYBr5KzD3KCxfp8GvB bkRkz1Nfesj9AOUZjAnutUFI3p+sJQwepyCnDg91CfiLtaJE/YMJGWLPlnqQPWaALaqW uBCfqq0BCm4b6yjU6qxPZQxURcOywkXrg/Kdg+JPa9PVCLf1sEHykjTBUC4csl6JxB+i 91YqxXaSs0bZ4eHMZUXsMKjoyiTMm+OY+W0vLc4LDMm08sLjVdHwfq1M2ePHHB6p13bX 4DHRSvFP2VrPmnagtgZuymqU9ogYgxoCfM5Jx8ezgHfrdjmYS7Jk0pTzIEk95K0ZklUd VhJQ== X-Gm-Message-State: ALQs6tCq95+nVQQTJTkCf488AwHWJFn7sr+U+kl+Ph81c1HgS7ZR8zak PctYhslau6qHpulpjd9Uiwve2ao/FxVpjLo3nog= X-Google-Smtp-Source: AIpwx48tc3TwXstcc2YiXaigGSmjXqPgTEJ6H6WYliKVfy91Ti65PwkC5VhQj0Zw61lvTpMDn1ZTPMUx7TZn/a+dssM= X-Received: by 2002:a9d:4479:: with SMTP id f54-v6mr2597632otj.125.1524007220256; Tue, 17 Apr 2018 16:20:20 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <61a5b452-e59e-dfef-4530-a94a60480961@redhat.com> From: "H.J. Lu" Date: Tue, 17 Apr 2018 23:20:00 -0000 Message-ID: Subject: Re: [PATCH] x86: Use pad in pthread_unwind_buf to preserve shadow stack register To: Joseph Myers Cc: "Carlos O'Donell" , Florian Weimer , "Tsimbalist, Igor V" , GNU C Library Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-04/txt/msg00295.txt.bz2 On Tue, Apr 17, 2018 at 1:02 PM, Joseph Myers wrote: > On Fri, 6 Apr 2018, H.J. Lu wrote: > >> https://github.com/hjl-tools/glibc/commit/9bf6aefa8fb45f8df140d42ce9cf890bb24076e1 >> >> It should be binary backward compatible. I will investigate if there is a way > > Increasing the size of a public type is always dangerous, because you can > end up with one part of a program expecting the new, larger size but > another part only allocating the old, smaller size. That is true. The allocated ucontext size must be no less than the size expected by ucontext consumer. > It might in some cases be compatible to the extent that existing linked > programs and shared libraries work with new glibc, if new glibc will never This is done by checking CET properties. Both linker and dynamic linker clear CET property bits if any module doesn't have CET bits set. Glibc should access new extended fields only if CET bits are set, which means the new ucontext is used in all .o files. That is why I want to extend ucontext before we have found a solution so that if an object file has CET bits set, it must use the new ucontext. > try to write into the unallocated part of such objects allocated by an > existing linked program or shared library. However, any such change would > need a careful analysis of how the type gets written to, and to what > extent external libraries have interfaces that depend on the size of the > type, and would need a NEWS entry explaining the change and discussing the > compatibility issues with it. > Agreed, -- H.J.