From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-f67.google.com (mail-pj1-f67.google.com [209.85.216.67]) by sourceware.org (Postfix) with ESMTPS id 6AA34385BF83; Tue, 7 Apr 2020 06:10:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6AA34385BF83 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=maskray.me Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=emacsray@gmail.com Received: by mail-pj1-f67.google.com with SMTP id cp9so833780pjb.0; Mon, 06 Apr 2020 23:10:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=lGeyM76e103Yfl+qL3UsU9BWMWn+LDWLE95eNWa8LWE=; b=UvtH3yERYdi59HXDYGdupN/gflgfkLMVwFk8DbEUf/ldGmUdCi77j84rQU/osPYyHZ t6nlYLuirptrhOr1r7TYoLtrV1X2ntRMfn5HSf7iKlMy8vH/0OX1ZIz4WmqWlQHpIHgP d/W0m+y4jIVVMHOWig3szo+1d4HPGNjNSn+/KUcPvZv7k583L/QhJeIS2RDS6IU2UrhC qWtAs/k8c/FCNrtYdSYedqmfzfPaZHnxQVArz08va8DVrAXjiyQjIwFifvwzM+MBiiyB L3HHr8Q4dTifra6I0YrhMtL0VeDy4IMVniUmR+wibSju4FPBMNK57lURAfNvOAeGo+tl UDeA== X-Gm-Message-State: AGi0Pubs6zJ9SK4zSua7TotXQeQzD35PIRwxcsxiTI9j0ew8cr8fbYFD 6Oar5LMep8JJy4RRyLRwQG8= X-Google-Smtp-Source: APiQypLBSNMn1AMEctMh6OMoRoAFazLhZmiSHv/AtKL18UhdtezmBebC1pc18PCfOWxXMKOc2AEnPw== X-Received: by 2002:a17:902:6b86:: with SMTP id p6mr931883plk.315.1586239818446; Mon, 06 Apr 2020 23:10:18 -0700 (PDT) Received: from localhost ([2601:647:4b01:ae80::51fb]) by smtp.gmail.com with ESMTPSA id u3sm13388218pfb.36.2020.04.06.23.10.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Apr 2020 23:10:17 -0700 (PDT) Date: Mon, 6 Apr 2020 23:10:16 -0700 From: Fangrui Song To: Cary Coutant , Florian Weimer Cc: Binutils , gnu-gabi@sourceware.org Subject: Re: [ld] Allow custom sections to be under PT_GNU_RELRO Message-ID: <20200407061016.dkrfo4c5u37ck5qf@gmail.com> References: <20200328042257.3scmekcyrii527ta@gmail.com> <87lfnkdcbn.fsf@mid.deneb.enyo.de> <20200407025119.iapvp3gyck7ziilr@gmail.com> <20200407031817.jyqxtxdgnpqpsp72@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20200407031817.jyqxtxdgnpqpsp72@gmail.com> X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_INFOUSMEBIZ, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gnu-gabi@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gnu-gabi mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 06:10:21 -0000 On 2020-04-06, Fangrui Song wrote: >Drop Generic System V Application Binary Interface > >A non-subscribed email address will get a bounce. > > We're writing to let you know that the group you tried to contact (generic-abi) may not exist, or you may not have permission to post messages to the group. A few more details on why you weren't able to post: > * You might have spelled or formatted the group name incorrectly. > * The owner of the group may have removed this group. > * You may need to join the group before receiving permission to post. > * This group may not be open to posting. > If you have questions related to this or any other Google Group, visit the Help Center at https://groups.google.com/support/. > >On 2020-04-06, Fangrui Song wrote: >>On 2020-04-06, Cary Coutant wrote: >>>>>https://lists.llvm.org/pipermail/llvm-dev/2020-March/140395.html >>>>> >>>>>I understand the reason of having these conventions in linkers. On the >>>>>other hand, there already exists a format with the fixed ".rel.ro" >>>>>suffix for .data and .bss. Custom suffixes would also mean that the user >>>>>code would depend more on implementation-specific things, i.e. prefixes. >>>>>For example, one would wonder, should they annotate their data with >>>>>__attribute__((section(...))) for ".data.rel.ro.my_section" or >>>>>".bss.rel.ro.my_section"? >>>>> >>>>>What do you think of the magic ".rel.ro" idea? >>>> >>>>We could sacrifice a section flag for this. The feature may be >>>>sufficiently important for that. >>> >>>My first reaction was: Do you *really* need to use a new custom >>>section name? But after reading through the thread on the LLVM list, I >>>see why -- you want the RTTI-like sections to be contiguous within the >>>RELRO segment. >>> >>>The gold sources have this comment: >>> >>>// With -z relro, we have to recognize the special sections by name. >>>// There is no other way. >>> >>>String matching on the section name is ugly and a performance hit >>>whether it's a fixed section name (as it is now), a prefix, or a >>>suffix. Yes, it should have been done with a flag from the beginning. >>> >>>Theoretically, we might not even have needed a new flag. If the >>>compiler would mark RELRO sections as read-only, the linker could look >>>for read-only, non-executable sections with dynamic relocations, and >>>mark them as RELRO, or simply turn on SHF_WRITE for -z norelro. But >>>that would break under older linkers, so it was much better from a >>>compatibility standpoint to mark RELRO sections as writable, meaning >>>there has to be some other way of recognizing that they're really >>>read-only but for the relocations. It may also have made things >>>difficult for the linker, requiring a scan over the relocations before >>>deciding where to place the section (I haven't looked carefully to see >>>if that would be a problem in gold). >>> >>>Starting from where we are now, I'd say we need an SHF_RELRO flag, and >>>compilers should start setting that flag on .data.rel.ro and >>>.data.rel.ro.local sections. Linkers should treat all .data.rel.ro and >>>.data.rel.ro.local sections as if the flag were set, regardless. Maybe >>>in 10-20 years, we can finally take those strcmp's out. >>> >>>Any sections marked SHF_RELRO should also be marked SHF_WRITE, for >>>compatibility with older linkers and to make it simpler to ignore the >>>flag in the -z norelro case. I'd probably also want to require that >>>they NOT be SHF_EXECINSTR. >> >>Your SHF_RELRO scheme (implies SHF_WRITE; can't be used together with >>SHF_EXECINSTR) looks fine with me. >> >>I suppose we will assign 0x1000 to SHF_RELRO. It looks like GNU ld, gold >>and LLD all happily accept the unknown flag 0x1000 (.text .tdata .tbss >>...). GNU ld and gold will not keep 0x1000 from the output section >>flags, though. Hope Solaris/HP-UX toolchain experts can answer the >>question about their linkers. >> >>Should SHF_TLS imply SHF_RELRO? >> >>>That probably also means that we should graduate PT_GNU_RELRO to the >>>gABI level, as PT_RELRO. Or, alternatively, DT_RELRO and DT_RELROSZ >>>entries in the dynamic table. (I kind of prefer the dynamic table over >>>the program header table for things like this, since it's the dynamic >>>linker, not the kernel loader, that needs to know about it.) >>> >>>-cary >> >>I can foresee people's objection to depriving one value 0x6474e552 from >>the PT_LOOS~PT_HIOS range. (See a recent discussion >>https://groups.google.com/forum/#!msg/x86-64-abi/7sr4E6THl3g/zUU2UPHOAQAJ "RFC: Usefulness of SHT_X86_64_UNWIND") >> >> >>Your argument made me convinced that DT_RELRO/DT_RELROSZ is better than >>PT_RELRO. Though I also foresee people's objection that this will make >>the design not readily usable. Perhaps we should bite the bullet. The >>parties which are mostly interested in this feature may have a good >>control of their ld.so. >> >>So, for linker/loader implementations, when a SHF_RELRO is seen, >>DT_RELRO/DT_RELROSZ should be used and PT_GNU_RELRO should disappear. >> >>If we can reach progress on the proposal, I will be happy to implement >>the feature on LLD/clang integrated assembler/llvm-readobj/llvm-objdump side. > >Ali Bahrami rejected SHF_RELRO. >https://groups.google.com/d/msg/generic-abi/eXcc0_1KF98/vGbWuVdWCAAJ > >We can still do SHF_GNU_RELRO and DT_GNU_RELRO/DT_GNU_RELROSZ. Looks like neither Solaris nor HP-UX likes the generic SHF_RELRO (https://groups.google.com/forum/#!topic/generic-abi/eXcc0_1KF98) We can make it SHF_GNU_RELRO now. For that case, inventing new stuff DT_GNU_RELRO/DT_GNU_RELROSZ is not really meaningful. Rich Felker reminded me that this is about how segments are mapped/protected. PT_* (the current design) is more appropriate. We can define: SHF_GNU_RELRO = 0x100000 (under SHF_MASKOS)