From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 91A681F5AE for ; Fri, 18 Jun 2021 00:07:47 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1FEB7399C893 for ; Fri, 18 Jun 2021 00:07:46 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1FEB7399C893 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1623974866; bh=hv7OcrXH4y+FUaD+JUVfhSMDao6mq0wsubWrQPI/LjY=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=spEfGrweVteN3+AbCXy/L0EbTku/L8IADsXA9tVcf4zgn4DDxU/gpxS1cHzJjz1nk dm92LltMtIKksXu31CvSmtj4bEAlCBp9yPiMdfz1N8cHyb5jCGWSn82wVrAJz7Xz5T d8Fn12GXOmcdtCYpPbGdtJxFz+d0ygv+VOQ/V/OQ= Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) by sourceware.org (Postfix) with ESMTPS id 17C0F383B83E for ; Fri, 18 Jun 2021 00:06:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 17C0F383B83E Received: by mail-pj1-x1036.google.com with SMTP id z3-20020a17090a3983b029016bc232e40bso4818739pjb.4 for ; Thu, 17 Jun 2021 17:06:06 -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:content-transfer-encoding :in-reply-to; bh=hv7OcrXH4y+FUaD+JUVfhSMDao6mq0wsubWrQPI/LjY=; b=Ku0H4hb7FGMd56diR77tqZhELer0wAXrl0JdpPfWUIus+jMwLPt1Rr8A+DZmhTSsCA HFKO5YpAMfITbQGGAAYrLifjoutaVwYoDwyLroi9kC0F7X4wj2q3nvllh6qau+cs92bq N5JyaG/LKr77dFWZNbN9xOeKDP/VDxfpvGC6v5ZNVBuXn/MlBhnEhvUCkAXzFI8SDX0c H0eFbcqPzQV8xtvSKE/BOytnypP1rhoCLXZ/9ZyW88KY3oOJqZPRqFuGkjF+qLCTDfMU Gw3F3lg1mlkt9+eroC6eROf7WtyqnQ1E1jvODvQhQ5CV2zpzUqI61H/N/ZCnJxgpN4cj rLdg== X-Gm-Message-State: AOAM531xgDHvz4S7JDCGbzBN3UviRMp44RRFQocCK36rE5ByCG0Kc3fO HKcuvz3HY3C14no8Ft1x/JZMlQ== X-Google-Smtp-Source: ABdhPJz84dmY9bP5NAQmdxJAYbTgyrWRO5c/0yB+2gPYTrCKWoBc8Y9wbasV3cVtbjJIeywe+YJ3wg== X-Received: by 2002:a17:902:968a:b029:11d:6448:1352 with SMTP id n10-20020a170902968ab029011d64481352mr2077287plp.59.1623974764942; Thu, 17 Jun 2021 17:06:04 -0700 (PDT) Received: from google.com ([2620:15c:2ce:200:c340:a8ac:3002:293c]) by smtp.gmail.com with ESMTPSA id f7sm6120066pfk.191.2021.06.17.17.06.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Jun 2021 17:06:04 -0700 (PDT) Date: Thu, 17 Jun 2021 17:06:00 -0700 To: "H.J. Lu" Subject: Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX Message-ID: <20210618000600.c7yh6twgbukmyouj@google.com> References: <20210617193825.zzjyoybttajksw5x@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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: , From: =?utf-8?q?F=C4=81ng-ru=C3=AC_S=C3=B2ng_via_Libc-alpha?= Reply-To: =?utf-8?B?RsSBbmctcnXDrCBTw7JuZw==?= Cc: llvm-dev@lists.llvm.org, GCC Development , GNU C Library , GNU gABI gnu-gabi , Binutils Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On 2021-06-17, H.J. Lu wrote: >On Thu, Jun 17, 2021 at 1:25 PM Fāng-ruì Sòng wrote: >> >> On Thu, Jun 17, 2021 at 12:46 PM H.J. Lu wrote: >> > >> > On Thu, Jun 17, 2021 at 12:38 PM Fangrui Song wrote: >> > > >> > > On 2021-06-17, H.J. Lu via llvm-dev wrote: >> > > >On Thu, Jan 21, 2021 at 7:02 AM H.J. Lu wrote: >> > > >> >> > > >> On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu wrote: >> > > >> > >> > > >> > 1. GNU_PROPERTY_UINT32_AND_LO..GNU_PROPERTY_UINT32_AND_HI >> > > >> > >> > > >> > #define GNU_PROPERTY_UINT32_AND_LO 0xb0000000 >> > > >> > #define GNU_PROPERTY_UINT32_AND_HI 0xb0007fff >> > > >> > >> > > >> > A bit in the output pr_data field is set only if it is set in all >> > > >> > relocatable input pr_data fields. If all bits in the the output >> > > >> > pr_data field are zero, this property should be removed from output. >> > > >> > >> > > >> > If the bit is 1, all input relocatables have the feature. If the >> > > >> > bit is 0 or the property is missing, the info is unknown. >> > > >> > > How to use AND in practice? >> > > Are you going to add .note.gnu.property to all of crt1.o crti.o >> > > crtbegin.o crtend.o crtn.o and miscellaneous libc_nonshared.a object >> > > files written in assembly? >> > > >> > > >> > 2. GNU_PROPERTY_UINT32_OR_LO..GNU_PROPERTY_UINT32_OR_HI >> > > >> > >> > > >> > #define GNU_PROPERTY_UINT32_OR_LO 0xb0008000 >> > > >> > #define GNU_PROPERTY_UINT32_OR_HI 0xb000ffff >> > > >> > >> > > >> > A bit in the output pr_data field is set if it is set in any >> > > >> > relocatable input pr_data fields. If all bits in the the output >> > > >> > pr_data field are zero, this property should be removed from output. >> > > >> > >> > > >> > If the bit is 1, some input relocatables have the feature. If the >> > > >> > bit is 0 or the property is missing, the info is unknown. >> > > >> > >> > > >> > The PDF is at >> > > >> > >> > > >> > https://gitlab.com/x86-psABIs/Linux-ABI/-/wikis/uploads/0690db0a3b7e5d8a44e0271a4be54aa7/linux-gABI-and-or-2021-01-13.pdf >> > > >> > >> > > >> > -- >> > > >> > H.J. >> > > >> >> > > >> Here is the binutils patch to implement it. >> > > >> >> > > > >> > > >If there are no objections, I will check it in tomorrow. >> > > >> > > If the use case is just ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, it'd be >> > > very kind of you if you can collect more use cases before generalizing >> > > this into a non-arch-specific GNU PROPERTY. >> > > >> > > The "copy relocations on protected data symbols" thing is x86 specific >> > > and only applies with gcc+GNU ld+glibc. >> > > Non-x86 architectures don't have this thing. >> > > gold doesn't have this thing. >> > > clang doesn't have this thing. >> > >> > It will be used to remove copy relocation and implement canonical function >> > pointers, which will benefit protected data and function. >> >> The action items in >> https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8#note_593822281 >> can be applied without a GNU PROPERTY. >> >> If we want to enforce the link-time check that a shared object is no longer >> compatible with copy relocations, just make the shared object's non-weak >> definitions protected, and add a GNU ld diagnostic like gold >> (https://sourceware.org/bugzilla/show_bug.cgi?id=19823) >> >> --- >> >> For functions, >> >> On x86-64, gcc -fpic has been using leaq addr()(%rip), %rax since at least >> 4.1.2 (oldest gcc I can find on godbolt): >> >> __attribute__((visibility("protected"))) >> void *addr() { return (void*)addr; } >> >> // a protected non-definition declaration is the same. >> >> // while asm(".protected addr") can use GOT, it is super rare if ever exists >> // outside glibc elf/vis*.c >> >> I have checked all of binutils 2.11, 2.16, 2.20, 2.24, 2.35. The have >> the same diagnostic: >> >> relocation R_X86_64_PC32 against protected function `addr' can not >> be used when making a shared object >> >> I think we can assert that taking the address of a protected function >> never works with GNU ld. >> So no compatibility concern. >> Fixing it (https://sourceware.org/pipermail/binutils/2021-June/116985.html) >> doesn't need any GNU PROPERTY. >> >> --- >> >> For variables, if an object file/archive member does not have GNU PROPERTY, do >> you consider it incompatible with "single global definition"? That is why I >> mentioned crt1.o crti.o crtbegin.o crtend.o crtn.o and libc_nonshared.a members >> written in assembly. >> >> If you consider such an object compatible with "single global definition", I >> don't see why a GNU PROPERTY is needed. >> >> If you consider such an object incompatible with "single global definition", I >> don't see how "single global definition" benefits can be claimed giving so many >> prebuilt object files without GNU PROPERTY. > >Please see the slides in > >https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8 > >which includes > >Dynamic Linker for Single Global Definition >• Check the single global definition marker on all components, the executable >and its dependency shared libraries. >• Issue an error/warning if the marker is not consistent on all components. This is not appealing from a compatibility point of view. It is common that a system has mixed shared objects: -fsingle-global-definition => a.so (marker value 1) no -fsingle-global-definition => b.so (marker value 0 or no marker) Issuing a warning will be annoying. If glibc x86 wants to deprecate copy relocations support, just fix the compilers(*)/GNU ld. -fno-pic dynamically linked executables are becoming rarer on modern Linux distributions, When the toolchain support is sufficiently mature (e.g. ld has warned/errored), add an opt-opt `LD_` style environment variable and let glibc ld.so warn, then gradually make it an error. * I can fix Clang -fno-pic at any time. I haven't done that just to be compatible with gcc -fno-pic. >• Disallow copy relocation against definition in the shared library with the >marker. >• For systems without function descriptor: >• Disallow function pointer reference in executable without the marker to the >definition with the STV_PROTECTED visibility in a shared library with >the marker. >• Use the address of the function body as function pointer on functions with the >STV_PROTECTED visibility, which are defined in shared libraries with the marker. I have provided the solutions in my previous message. >This provides the capability to detect the ABI change at run-time as well as >optimize for STV_PROTECTED symbol lookup. STV_PROTECTED symbols should not need a compiler option or a GNU PROPERTY to work (efficiently). As my previous message mentioned (gcc 4.1.2~now; GNU ld 2.11~now), protected function addresses in a shared object likely never work, at least for the past 20 years. For protected data, x86 copy relocations did not work prior to circa 2015. It never works on non-x86, gold, clang, or non-glibc. And I doubt any project uses protected data given that its sole purpose is for optimization while GCC 5 added unneeded indirection. Ulrich Drepper did add elf/vis* tests into glibc in 2000, but they use artificial inline asm .protected which does not reflect any reality. GNU ld -shared for a protected symbol * x86-64: broken direct access relocation, unneeded GLOB_DAT * aarch64: broken direct access relocation, unneeded GLOB_DAT * arm: unneeded GLOB_DAT for STT_OBJECT * ppc32: unneeded GLOB_DAT for STT_OBJECT * ppc64le: good, no GLOB_DAT * mips64el: good, no GLOB_DAT * riscv64: good, no GLOB_DAT Perhaps for binutils in 2000, more ports had unneeded dynamic relocations which made the elf/vis* tests more plausible. But the fragile support (acked by multiple glibc maintainers, including Adhemerval/Carlos/Szabolcs) is definitely largely irrelevant nowadays. >My linker implementation is at > >https://gitlab.com/x86-binutils/binutils-gdb/-/tree/users/hjl/property/master > >I will implement the dynamic linker change. > >> If we still want "absolutely no copy relocation for -fno-pic", just use GOT for >> default visibility external data access >> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112) >> Some architectures may not like it (i386/ppc32), just leave them behind. >> Modern architectures can do it. When things get matured, add a ld warning, >> then add a ld.so warning. When things get more matured, change the warnings to >> errors. >> >> Such changes should use a mechanism similar to glibc LD_DYNAMIC_WEAK (weak can >> preempt global) and Solaris LD_BREADTH (breadth-first order based dependency >> order) and LD_NODIRECT (direct bindings). At some point, introduce a behavior >> change. I don't think how an explicit marker can improve the compatibility >> story. The conceived compatibility issues likely don't really exist for > >The compatibility issue does exist. Please see the linker tests I added. ld-x86-64/protecte-func-* are artificial assembly which do not match the reality. They are cases where never work or aren't really promised to work before. >> functions. For copy relocations, I think we may need to wait an extended period >> of time. > >That is what the single global definition marker is used for. See my first paragraph why a GNU PROPERTY may not be a good compatibility solution.