Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp1387984pxb; Fri, 27 Aug 2021 07:50:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwELoXse0CJJoEUsXkUaOAj81g/3D+2pbhYm9PEJ3SCG4tVVsBOCqH3oWmDniJf3eLpLkZ6 X-Received: by 2002:a5e:c609:: with SMTP id f9mr7487762iok.127.1630075843827; Fri, 27 Aug 2021 07:50:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630075843; cv=none; d=google.com; s=arc-20160816; b=NHTt458TcLRnB+10X9mrWDLTZsB/JfERhW5PZWJ6AFcTH8wp2DRGaXozUb35YYo/bg ig51FQL2v3V4TIsd+xzXAGPZaEyqamU56VUW9LDThgSDMhPXTsrr4+fcU6HQGaSs77HF CFN/w7RfErgxytIfJHQw6+yCoEba0LywoYCenFttx9K8a7n31u5VMzetCX2tl/i9KTIg ecyyS3F0gyO5SgV8PBbHtgUnuhe15U5mT2upSoHWmCICKqoWEa3cISQ10T9k/b8EmZqo NccTHvtM30KT6DIStYqcz7LQTN+pX4SeuZElogLSOxIhwL19hmiArwgTWWhP/FzJOgYR 8Gvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=G7LfMZmcJP20ZcML1C3FoJMIxVGRvpjeNeUhnlPc9/4=; b=fyb7BJvDX2XZ8fFmd1gqfz/1a0EQtD8B/vWJF03nxk+roSimeCGeiUIFRcCvrVE2L3 nvYN10NLWcnVMo+EnUScpLufBECpMz5l0Wh6HUFQjYH/yc/MhYeF3OhLjjqFFqEE0X7z H7J4bvZBuUMnR2gFnFRa0D8IdJqgqUaf80jAMWbzp27EYkNw0inqO2MaC0eWBVJkRj6d n4aSRgNwx/AAUI8Z7ywcJHHEdnaCabk1mTFPcn8hUXErUsuH5+/DhtQf9aW7/pLuLoPl QP5hDvfpMFX/VDL1ZfmSUmSjF7V3GROeG257gzwqScwlrpY3ihpnxvW3/pLr1YjXeEi1 xQcw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w13si6391033ilo.15.2021.08.27.07.50.31; Fri, 27 Aug 2021 07:50:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232477AbhH0OtW (ORCPT + 99 others); Fri, 27 Aug 2021 10:49:22 -0400 Received: from gate.crashing.org ([63.228.1.57]:57533 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233308AbhH0OtR (ORCPT ); Fri, 27 Aug 2021 10:49:17 -0400 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 17REemKD003680; Fri, 27 Aug 2021 09:40:48 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 17REel3N003679; Fri, 27 Aug 2021 09:40:47 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 27 Aug 2021 09:40:47 -0500 From: Segher Boessenkool To: =?utf-8?B?RsSBbmctcnXDrCBTw7JuZw==?= Cc: Daniel Axtens , Nick Desaulniers , linux-kernel@vger.kernel.org, Nathan Chancellor , clang-built-linux@googlegroups.com, Paul Mackerras , Bill Wendling , linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH] ppc: add "-z notext" flag to disable diagnostic Message-ID: <20210827144047.GN1583@gate.crashing.org> References: <20210812204951.1551782-1-morbo@google.com> <87sfzde8lk.fsf@linkitivity.dja.id.au> <20210813200508.7bqehxgd6ruerds5@google.com> <20210814125812.GC1583@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi! On Sat, Aug 14, 2021 at 12:34:15PM -0700, Fāng-ruì Sòng wrote: > On Sat, Aug 14, 2021 at 5:59 AM Segher Boessenkool > wrote: > > > > On Fri, Aug 13, 2021 at 01:05:08PM -0700, Fangrui Song wrote: > > > Text relocations are considered very awful by linker developers. > > > > By very few linker developers. > https://groups.google.com/g/generic-abi/c/Ckq19PfLxyk/m/uW29sgkoAgAJ > Ali Bahrami: "My opinion is that no one wants text relocations, but > not labeling them if they do exist doesn't seem right. I find the > presence of DF_TEXTREL very interesting when diagnosing various > issues." I don't know who that is, and that post has no context. > https://gcc.gnu.org/legacy-ml/gcc/2016-04/msg00138.html > ( "So why not simply create 'dynamic text relocations' then? Is that > possible with a pure linker change?" ) > Cary Coutant: "Ugh. Besides being a bad idea from a performance point > of view, it's not even always possible to do. Depending on the > architecture, a direct reference from an executable to a variable in a > shared library may not have the necessary reach." That is about a very specific kind of relocation. > binutils-gdb commit "Add linker option: --warn-shared-textrel to > produce warnings when adding a DT_TEXTREL to a shared object." > Nick Clifton That does not say text relocations are bad. Of course you want to know if they are there, for various reasons, like, if they are disallowed on some systems. > https://www.openwall.com/lists/musl/2020/09/26/3 > Szabolcs Nagy: "nice. and gcc passes -z text for static pie code so > that case should not end up with text rels." That does not say text relocations are bad. > Someone wrote "Overall, the overhead of processing text relocations > can cause serious performance degradation." in Solaris' Linker and > Libraries Guide. In process startup, sure. And it can make those processes run faster as well. That is the tradeoff with *all* relocations; you can make any code without any relocations. Relocations are a tradeoff, like most things. > > How would this be a benefit to security? > > https://flameeyes.blog/2016/01/16/textrels-text-relocations-and-their-impact-on-hardening-techniques/ This means that those "hardening techniques" have some serious weaknesses, that is all. And hardening is not part of security anyway; it is impact mitigation. > FWIW I contributed a glibc patch allowing TEXTREL to co-exist with ifunc. > It requires temporary mapping the text segment W^X. What does W^X mean here? It normally means no mapping is both writable and executable at the same time. > > > There are no text relocations, therefore no need for -z notext. > > > > This is a choice by the compiler, nothing more. It saves some process > > startup time, and allows slightly more maps to be shared by processes > > that run the same images. But it is a tradeoff, so it might change; and > > of course it is not an ABI requirement. > Text relocations are generally awful. Great arguments, thanks! :-P > GNU ld and gold's traditional "add DF_TEXTREL on-demand" behavior made > such user errors easy to make. That has no bearing on if text relocations are useful or not. > I understand that kernels are special applications where we apply > relocations once and many user-space objection can be less of a > concern/ignored. > However, the Linux kernel is already in a position where many linker > options are controlled and thus should specify -z notext to make > the intention explicit, or fix the problems (I think x86-64 is good; > that said, powerpc > has a higher cost using PC-relative instructions so pay the oneshot relocation > time cost probably isn't a bad choice) I have no idea what you mean. Segher