From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) by sourceware.org (Postfix) with ESMTPS id E7A313853554 for ; Wed, 8 Jun 2022 03:42:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E7A313853554 Received: by mail-pg1-x52f.google.com with SMTP id h192so10957373pgc.4 for ; Tue, 07 Jun 2022 20:42:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=FSOal56130vh8d8Dpo3RHQs4RSCXTdkE8JFoMZFu0a4=; b=6AGb3wVBDY00wG5NZDK3DQUsj3RS/bp1l0u3mXUqQOYWCWiPGXXUsH7v70X/3ZUr7z Vy/YP6sRzKQMcmsjjBGCvruNTE2Pv7QKMZDF/tBySmlix5trfH/3ov9q4CBHHrrOE0rG R8+dcFP626weMUZVjlNaFes40Vhmfwq6CxFaWu2Ye7E8owltoCacVucpVCuiQIAP5pze ENKEuVhJzAHkZ5IHvtrzgXU7KFI4yFzAEo1vFlFCwUGr8oiZ0T02h0ofY2t5Kx/ZHaGY J4O4dIrwlwsODX3fP/niOdHrnXDYUdsTG/W+AEa+a1BHV07L5qxP5aMuHb0yOPeaWQSe pROg== X-Gm-Message-State: AOAM530OwDmY8i7nntc1a76Ol9ypinwkVM5Lp1c4plByGxGxAEp+2Ezj qou+2rHSuRThHnG61BR3/3Eh9w== X-Google-Smtp-Source: ABdhPJx19PDV04OUGr8B7R8mHvuvqwt/JihiYUT0rBiY1CZTzSJ6rrS2pLndqdvFnCY33skftOKAeQ== X-Received: by 2002:a63:5610:0:b0:3f2:7e19:1697 with SMTP id k16-20020a635610000000b003f27e191697mr27946621pgb.74.1654659769675; Tue, 07 Jun 2022 20:42:49 -0700 (PDT) Received: from google.com ([2620:15c:2ce:200:dfe:1f0f:4f14:c886]) by smtp.gmail.com with ESMTPSA id w9-20020a17090a028900b001e325b9a809sm15324086pja.38.2022.06.07.20.42.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jun 2022 20:42:48 -0700 (PDT) Date: Tue, 7 Jun 2022 20:42:44 -0700 From: Fangrui Song To: "H.J. Lu" Cc: Szabolcs Nagy , GNU C Library Subject: Re: [PATCH v3] elf: Remove ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA Message-ID: <20220608034244.ww4h3dnysylyypro@google.com> References: <20220601175633.2407189-1-maskray@google.com> <20220607182135.3ahsg3mu6nxh3pee@google.com> <20220607200005.7bz5bln6ogadenlh@google.com> <20220607235720.dd6xsxyb32hwwnrb@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-26.9 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, GIT_PATCH_0, KAM_INFOUSMEBIZ, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Wed, 08 Jun 2022 03:42:53 -0000 On 2022-06-07, H.J. Lu wrote: >On Tue, Jun 7, 2022 at 4:57 PM Fangrui Song wrote: >> >> >> On 2022-06-07, H.J. Lu wrote: >> >On Tue, Jun 7, 2022 at 1:00 PM Fangrui Song wrote: >> >> >> >> On 2022-06-07, H.J. Lu wrote: >> >> >On Tue, Jun 7, 2022 at 11:21 AM Fangrui Song wrote: >> >> >> >> >> >> On 2022-06-07, H.J. Lu wrote: >> >> >> >On Tue, Jun 7, 2022 at 6:25 AM Szabolcs Nagy via Libc-alpha >> >> >> > wrote: >> >> >> >> >> >> >> >> The 06/01/2022 10:56, Fangrui Song wrote: >> >> >> >> > If an executable has copy relocations for extern protected data, that >> >> >> >> > can only work if the library containing the definition is built with >> >> >> >> > assumptions (a) the compiler emits GOT-generating relocations (b) the >> >> >> >> > linker produces R_*_GLOB_DAT instead of R_*_RELATIVE. Otherwise the >> >> >> >> > library uses its own definition directly and the executable accesses a >> >> >> >> > stale copy. Note: the GOT relocations defeat the purpose of protected >> >> >> >> > visibility as an optimization, but allow rtld to make the executable and >> >> >> >> > library use the same copy when copy relocations are present, but it >> >> >> >> > turns out this never worked perfectly. >> >> >> >> > >> >> >> >> > ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA has strange semantics when both >> >> >> >> > a.so and b.so define protected var and the executable copy relocates >> >> >> >> > var: b.so accesses its own copy even with GLOB_DAT. The behavior change >> >> >> >> > is from commit 62da1e3b00b51383ffa7efc89d8addda0502e107 (x86) and then >> >> >> >> > copied to nios2 (ae5eae7cfc9c4a8297ff82ec6b794faca1976ecc) and arc >> >> >> >> > (0e7d930c4c11de896fe807f67fa1eb756c9c1e05). >> >> >> >> > >> >> >> >> > Without ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, b.so accesses the copy >> >> >> >> > relocated data like a.so. >> >> >> >> > >> >> >> >> > ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA has another effect in the absence >> >> >> >> > of copy relocations: when a protected data symbol is defined in multiple >> >> >> >> > objects, the code tries to bind the relocation locally. Without >> >> >> >> > ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, STV_PROTECTED is handled in the >> >> >> >> > same way as STV_DEFAULT: if ld produces GLOB_DAT (some ports of GNU ld), >> >> >> >> > the relocation will bind to the first definition; otherwise (e.g. >> >> >> >> > ld.lld) ld does the binding locally and ld.so doesn't help. >> >> >> >> > >> >> >> >> >> >> >> >> i think we should not change the interposition semantics. >> >> >> >> we should go back to the old behaviour where only copy >> >> >> >> relocs were broken (and there was an expensive workaround >> >> >> >> to deal with protected symbol interposition). >> >> >> >> >> >> >> >> i think you want to revert the elf/dl-lookup.c changes of >> >> >> >> >> >> >> >> commit 62da1e3b00b51383ffa7efc89d8addda0502e107 >> >> >> >> Author: H.J. Lu >> >> >> >> CommitDate: 2015-03-31 05:16:57 -0700 >> >> >> >> >> >> >> >> Add ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA to x86 >> >> >> >> >> >> >> > >> >> >> >I am OK to remove support of copy relocation against protected >> >> >> >symbols since it doesn't work properly. >> >> >> >> >> >> Thanks. >> >> >> >> >> >> >My only question is if >> >> >> >ld.so should issue a warning or an error when seeing a copy >> >> >> >relocation against a protected symbol. Copy relocation against >> >> >> >protected symbol defeats the purpose of protected symbol. >> >> >> >> >> >> The check already exists (_dl_check_protected_symbol) but currently >> >> >> relies on GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS (only implemented >> >> >> for x86, and adoption is low on x86). >> >> >> >> >> >> For ELF_RTYPE_CLASS_COPY, I think the GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS >> >> >> check can be removed. >> >> > >> >> >Will removal of GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS >> >> >check cause many run-time errors? >> >> >> ( >> >> >> Since GCC 5, x86-64 -fpie has HAVE_LD_PIE_COPYRELOC. >> >> >> When neither -m[no]direct-extern-access is specified, HAVE_LD_PIE_COPYRELOC takes effect. >> >> >> The executable does not have GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS >> >> >> but the incompatibility exists. >> >> >> It just kinda works because GCC and GNU ld cooperate to produce a GLOB_DAT in the DSO. >> >> >> ) >> >> >> >> >> >> For ELF_RTYPE_CLASS_PLT, the pointer equality does not matter much in >> >> >> practice: >> >> >> >> >> >> * protected visibility adoption is very low due to various problems. >> >> >> * Taking a function address in the executable and expecting it to match the address in a DSO is rare. >> >> >> * Many users use ICF and by and large don't care about function addresses to some extent. >> >> >> >> >> >> I think having the warning under GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS is fine. >> >> >> ( >> >> >> * x86-32 -fno-pic uses R_386_PC32 as a jump instruction, which is >> >> >> indistinguishable from an address-taken operation >> >> >> https://maskray.me/blog/2021-01-09-copy-relocations-canonical-plt-entries-and-protected#branch-instructions-on-x86 >> >> >> ) >> >> > >> >> >An error with GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS >> >> >and a warning without? >> >> >> >> This plan sounds good, when we create a separate patch enhancing the >> >> diagnostics. >> >> Created >> https://sourceware.org/pipermail/libc-alpha/2022-June/139552.html >> ([PATCH] elf: Refine direct extern access diagnostics to protected symbol). >> >> >> x86-32 may need a exception (i.e. no warning) for ELF_RTYPE_CLASS_PLT to handle R_386_PC32. >> > >> >Linker sets non-zero symbol values for undefined function symbols in >> >executable only when their addresses are taken. R_386_PC32 shouldn't >> >matter. >> >> OK, I believe GNU ld distinguishes branch/address-taken usages of >> R_386_PC32 by poking at the instruction opcode. That works. >> ld.lld doesn't check the opcode, and just reports "error: cannot preempt >> symbol:" in an example I crafted. > >Does lld always set non-zero symbol values for undefined function symbols? For a direct access relocation which is neither a link-time constant nor a dynamic relocation (e.g. R_386_32 in a writable section), lld always sets non-zero st_value for an undefined symbol referencing STT_OBJECT. lld doesn't know R_386_PC32 may be used with call/jmp. It simply conservatively treats all R_386_PC32 as possibly address-taking. BTW: This was why I opened https://sourceware.org/bugzilla/show_bug.cgi?id=27169 (i386: Emit R_386_PLT32 instead of R_386_PC32 for `call/jmp foo`) but I can accept that we keep it unchanged. >> >> >> >> > It's extremely unlikely anyone relies on the >> >> >> >> > ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA behavior, so let's remove it: this >> >> >> >> > removes a check in the symbol lookup code. >> >> >> >> > >> >> >> >> > -- >> >> >> >> > Changes from v1: >> >> >> >> > * Reword commit message as suggested by Szabolcs Nagy >> >> >> >> > >> >> >> >> > Changes from v2: >> >> >> >> > * Explain interposition behavior >> >> >> >> > --- >> >> >> >> > elf/dl-lookup.c | 90 ------------------------------------- >> >> >> >> > sysdeps/arc/dl-sysdep.h | 21 --------- >> >> >> >> > sysdeps/generic/ldsodefs.h | 12 +---- >> >> >> >> > sysdeps/i386/dl-machine.h | 3 +- >> >> >> >> > sysdeps/nios2/dl-sysdep.h | 21 --------- >> >> >> >> > sysdeps/x86/dl-lookupcfg.h | 4 -- >> >> >> >> > sysdeps/x86_64/dl-machine.h | 8 +--- >> >> >> >> > 7 files changed, 4 insertions(+), 155 deletions(-) >> >> >> >> > delete mode 100644 sysdeps/arc/dl-sysdep.h >> >> >> >> > delete mode 100644 sysdeps/nios2/dl-sysdep.h >> >> >> >> > >> >> >> >> > diff --git a/elf/dl-lookup.c b/elf/dl-lookup.c >> >> >> >> > index a42f6d5390..41d108e0b8 100644 >> >> >> >> > --- a/elf/dl-lookup.c >> >> >> >> > +++ b/elf/dl-lookup.c >> >> >> >> ... >> >> >> >> > @@ -854,43 +801,6 @@ _dl_lookup_symbol_x (const char *undef_name, struct link_map *undef_map, >> >> >> >> > return 0; >> >> >> >> > } >> >> >> >> > >> >> >> >> > - int protected = (*ref >> >> >> >> > - && ELFW(ST_VISIBILITY) ((*ref)->st_other) == STV_PROTECTED); >> >> >> >> > - if (__glibc_unlikely (protected != 0)) >> >> >> >> > - { >> >> >> >> > - /* It is very tricky. We need to figure out what value to >> >> >> >> > - return for the protected symbol. */ >> >> >> >> > - if (type_class == ELF_RTYPE_CLASS_PLT) >> >> >> >> > - { >> >> >> >> > - if (current_value.s != NULL && current_value.m != undef_map) >> >> >> >> > - { >> >> >> >> > - current_value.s = *ref; >> >> >> >> > - current_value.m = undef_map; >> >> >> >> > - } >> >> >> >> > - } >> >> >> >> > - else >> >> >> >> > - { >> >> >> >> > - struct sym_val protected_value = { NULL, NULL }; >> >> >> >> > - >> >> >> >> > - for (scope = symbol_scope; *scope != NULL; i = 0, ++scope) >> >> >> >> > - if (do_lookup_x (undef_name, new_hash, &old_hash, *ref, >> >> >> >> > - &protected_value, *scope, i, version, flags, >> >> >> >> > - skip_map, >> >> >> >> > - (ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA >> >> >> >> > - && ELFW(ST_TYPE) ((*ref)->st_info) == STT_OBJECT >> >> >> >> > - && type_class == ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA) >> >> >> >> > - ? ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA >> >> >> >> > - : ELF_RTYPE_CLASS_PLT, NULL) != 0) >> >> >> >> > - break; >> >> >> >> > - >> >> >> >> > - if (protected_value.s != NULL && protected_value.m != undef_map) >> >> >> >> > - { >> >> >> >> > - current_value.s = *ref; >> >> >> >> > - current_value.m = undef_map; >> >> >> >> > - } >> >> >> >> > - } >> >> >> >> > - } >> >> >> >> > - >> >> >> >> >> >> >> >> i think we should keep this part without the >> >> >> >> ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA bit. >> >> >> > >> >> >> > >> >> >> > >> >> >> >-- >> >> >> >H.J. >> >> > >> >> > >> >> > >> >> >-- >> >> >H.J. >> > >> > >> > >> >-- >> >H.J. > > > >-- >H.J.