From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) by sourceware.org (Postfix) with ESMTPS id A6FB73858D33 for ; Mon, 15 Mar 2021 13:58:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A6FB73858D33 Received: by mail-qt1-x82d.google.com with SMTP id c6so9093794qtc.1 for ; Mon, 15 Mar 2021 06:58:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sgJcjnRjaTyAG9G4oZb6QuPK6PopQNDjjOwEk0xDi/0=; b=GibL/JVLCmmc4EHnTyWUV/1y7XIZ4Dbk0aFRLRQQAX/f+goS9kzGkuiYJc0Z72JPUq zFj3dFrqZkjfsn05qOdFZ0TxlF/fgAXKMSd3aaIvRxnHvrxLHl3K74IVeqRoYHVrRkV9 eaUueV6RExIQxZ9FpArYW0gIsSOwfaToMGk72/lxn2Pz7Hu0PIRhL3uVO8ElLdZ6JDpZ QTbl/GSgh+EfY1QtbJlyKQRUyYHP+x4E/zGbUDMlivOP/EW3MQt/Gb9cIS+NUsDP/lRF TpRvmQCglHAIp/fFITFh/0AlqxiUTE+YfKwHckdchxMMycPZcKzijW7MtIxSZGdc0Cpq ly9g== X-Gm-Message-State: AOAM530rBCxxqmJnhJnqEaqKG4wvYQTu0YO63tlLn1EWgbwLsggzRcQ8 zvC8bX+qg9RognrOzgW76+Mq2g== X-Google-Smtp-Source: ABdhPJyDvfeyc0ItvI2Xmi0pTqnuuYg8IlcrjLh3fcdcKZhl3imdkWBbce0C2GFBshhpugsEGPfADA== X-Received: by 2002:ac8:6a12:: with SMTP id t18mr7062452qtr.271.1615816717246; Mon, 15 Mar 2021 06:58:37 -0700 (PDT) Received: from [192.168.1.4] ([177.194.48.209]) by smtp.googlemail.com with ESMTPSA id j12sm10949251qtn.36.2021.03.15.06.58.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Mar 2021 06:58:36 -0700 (PDT) Subject: Re: [PATCH 1/3] Add inhibit_stack_protector to ifuncmain9 [BZ #25680] To: Siddhesh Poyarekar , libc-alpha@sourceware.org, Florian Weimer , Sergei Trofimovich References: <20210310101400.3904724-1-siddhesh@sourceware.org> <20210310101400.3904724-2-siddhesh@sourceware.org> <00d1c526-cff0-8b00-1009-a488695d1f86@linaro.org> <595c9ca3-a0d8-5958-2544-500812d2ecc3@sourceware.org> <93d85ab8-071f-50b0-f56c-cc10e6b6e206@linaro.org> <9cbc9860-8bf7-8ae2-6c57-a0f0cc21acff@sourceware.org> From: Adhemerval Zanella Message-ID: <0f058157-6d2d-0f0c-fc45-ca413283b6e9@linaro.org> Date: Mon, 15 Mar 2021 10:58:33 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <9cbc9860-8bf7-8ae2-6c57-a0f0cc21acff@sourceware.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2021 13:58:39 -0000 On 13/03/2021 03:07, Siddhesh Poyarekar wrote: > On 3/12/21 11:04 PM, Adhemerval Zanella via Libc-alpha wrote: >> Is it something preventing us to make x86 follows other architectures in this >> regard? > > AFAICT, just more work to get it done :)  There's also the general hairiness of the whole sequence and historical issues with ifunc interplay that doesn't add much confidence to any fix that may come in this place.  But that shouldn't prevent us from trying I guess. > >> Not sure if adding exceptions for specific cases is the best approach, >> the users would expect that such mitigations to work regardless of >> compilation/linking model (although some do require extra linker/runtime >> support).  My take is if we could fix on glibc we should aim for it. > > I'm kinda on the fence, but will likely hop on to your side if I figure out a fix. > >>> It's not the glibc build that's affected though, at least not to an extent that we ought to care.  What's broken is our support with binaries that were built with stack-protector-all *and* ifuncs.  This patch implies that we don't support it; all we need to do is document this somewhere and perhaps fix gcc to never emit the prologue/epilogue for ifunc resolvers. >> >> Yeah, I understood that and my concern is if users do start to use >> ifunc more profusely they will need to keep adding the >> inhibit_stack_protector on resolvers to work around this issue. >> >> Fixing the ifunc resolution order also might simplify the code >> and avoid adding the inhibit_stack_protector on multiples files. > > This is probably more work than I had bargained for, so I'm going to put it back in the interest of looking at the more urgent problems (e.g. the tunables breakage).  I'll pick it up again later.  In the meantime, would you object to me pushing 2/3 and 3/3?  2/3 disables stack protector on an early startup routine (I'll remove the inhibit_stack_protector in the test so that we can fix it alongside 1/3) and 3/3 is the SHARED cleanup that I had posted when you noticed these test failures.  The cleanup doesn't cause these failures and seems safe. Ok, they patches itself do look and I don't really want to block them. My idea of raising this issues is that besides glibc testsuite we should also focus on the consumers and it maybe it would be better to partially disable a functionally it is inherent broken in some corner cases. But if the idea is indeed to get back on this, I am ok with current approach.