From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by sourceware.org (Postfix) with ESMTPS id 40FE53858C2D for ; Thu, 12 May 2022 04:56:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 40FE53858C2D Received: by mail-pj1-x1030.google.com with SMTP id a15-20020a17090ad80f00b001dc2e23ad84so6767882pjv.4 for ; Wed, 11 May 2022 21:56:27 -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=zheGVpMF+4reJ7aoYb/WsnCFFWdYwHmfC8umMY/cAfI=; b=YSrleA8rAFAMkXwXyiMOaf+09SfO95wdw5zGsBWLxjD+7JG4v5gFo2dzk8tuMfsJ7L g7p5SqxJyUqn29Ildpo1mBtl5b/a2grO6sOPV7dI/nn4l4vqXBzo1E85NxRrbDD5RX77 RcnHFwr96PYznWX+oB2CJZRciJgL0ZQmEfS9iepAZUI54tmfbd5cn8sds5EoY5BYlMnX 1BQD0SXZVLMFAFQjsk/xv7hHl2GCQoDFl/J4e6VT63GRcEDvhM5s/7SWG1l9Co8AovPr Fnc3sRr7d2l9t52QFJE3H6cOLpwsKBqIanJFs/cawSX5zAC7QlVdo/Ia/TcYEpTzCHBn WbBw== X-Gm-Message-State: AOAM5323qdOr0mA6iAQeaWoD9bth6wGO5PmF7ofEcJ1xkugET6T4ailA +XsA4ejSkDiBVp8rrsg8aUL9jg== X-Google-Smtp-Source: ABdhPJzePnAoyyThfwFWbhY5fbqyQWQtEXptEtCbpDwk4qEAGkaTPcMJSLTE7gKhOZhX2yesnIvFgg== X-Received: by 2002:a17:90a:8b91:b0:1be:db25:eecd with SMTP id z17-20020a17090a8b9100b001bedb25eecdmr8901944pjn.10.1652331386105; Wed, 11 May 2022 21:56:26 -0700 (PDT) Received: from google.com ([2620:15c:2ce:200:e892:f9c7:57f5:14db]) by smtp.gmail.com with ESMTPSA id v128-20020a626186000000b0050dc76281dbsm2666990pfb.181.2022.05.11.21.56.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 May 2022 21:56:25 -0700 (PDT) Date: Wed, 11 May 2022 21:56:23 -0700 From: Fangrui Song To: "H.J. Lu" Cc: GNU C Library , Adhemerval Zanella , Szabolcs Nagy Subject: Re: [PATCH 0/3] Simplify ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA and revert aarch64/arm's extern protected data handling Message-ID: <20220512045623.gpub7ojtmilf6b6v@google.com> References: <20220501060615.1694317-1-maskray@google.com> <20220510074231.wteewlruwa2uuv3r@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=-27.3 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, 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: Thu, 12 May 2022 04:56:29 -0000 On 2022-05-10, H.J. Lu wrote: >On Tue, May 10, 2022 at 12:42 AM Fangrui Song wrote: >> >> On 2022-05-09, H.J. Lu wrote: >> >On Sat, Apr 30, 2022 at 11:06 PM Fangrui Song via Libc-alpha >> > wrote: >> >> >> >> Say both a.so and b.so define protected var and the executable copy >> >> relocates var. ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA has strange >> >> semantics: a.so accesses the copy in the executable while b.so accesses >> >> its own. This behavior requires that (a) the compiler emits >> >> GOT-generating relocations (b) the linker produces GLOB_DAT instead of >> >> RELATIVE. >> >> >> >> Without the ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA code, b.so's GLOB_DAT >> >> will bind to the executable (normal behavior). >> >> >> >> For aarch64/arm it makes sense to restore the original behavior and don't >> >> pay the ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA cost. The behavior is very >> >> unlikely used by anyone. >> >> >> >> * Clang code generation treats STV_PROTECTED the same way as STV_HIDDEN: >> >> no GOT-generating relocation in the first place. >> >> * gold and lld reject copy relocation on a STV_PROTECTED symbol. >> >> * Nowadays -fpie/-fpic modes are popular. GCC/Clang's codegen uses >> >> GOT-generating relocation when accessing an default visibility >> >> external symbol which avoids copy relocation. >> >> >> >> Fangrui Song (3): >> >> elf: Remove ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA check for >> >> non-DL_EXTERN_PROTECTED_DATA ports >> >> Revert "[AArch64][BZ #17711] Fix extern protected data handling" >> >> Revert "[ARM][BZ #17711] Fix extern protected data handling" >> >> >> >> elf/dl-lookup.c | 46 ++++++++++++------------------------ >> >> sysdeps/aarch64/dl-machine.h | 13 +++++----- >> >> sysdeps/aarch64/dl-sysdep.h | 2 -- >> >> sysdeps/arm/dl-machine.h | 10 +++----- >> >> sysdeps/arm/dl-sysdep.h | 2 -- >> >> 5 files changed, 24 insertions(+), 49 deletions(-) >> >> >> >> -- >> >> 2.36.0.464.gb9c8b46e94-goog >> >> >> > >> >Given that protected symbols never work properly with copy relocation, >> >can we change protected symbol handling to simply warn copy relocation >> >against protected data symbol and non-zero symbol values of undefined >> >symbols against protected function symbols? >> >> "protected symbols never work properly with copy relocation" generally >> applies to all non-x86 architectures (arm/aarch64 has some guarantee, >> but not reliable). My goal is indeed to remove relevant code for all >> non-x86 architectures. They should not even bother testing >> STV_PROTECTED. > >Even on x86, protected symbols don't work as intended. They don't >provide any performance benefits. I think we should move away from >copy relocation on protected symbols. We can either issue a warning >or an error. > >> On x86 there is some guarantee. The gcc>=5 -fpie >> HAVE_LD_PIE_COPYRELOC behavior makes the problem trigger in some cases. >> Having a warning in x86 specific files (e.g. >> sysdeps/x86_64/dl-machine.h R_X86_64_COPY) seems appropriate. How about adding a warning for R_X86_64_COPY like the following, then removing all code paths of (ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA!=0)? From 3f905ff283178396840861a965acf35bd21cf5f0 Mon Sep 17 00:00:00 2001 From: Fangrui Song Date: Wed, 11 May 2022 21:54:02 -0700 Subject: [PATCH] x86: Warn for copy relocations on a protected symbol --- sysdeps/x86_64/dl-machine.h | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/sysdeps/x86_64/dl-machine.h b/sysdeps/x86_64/dl-machine.h index c70af7ab1e..48f08ecc0b 100644 --- a/sysdeps/x86_64/dl-machine.h +++ b/sysdeps/x86_64/dl-machine.h @@ -474,6 +474,12 @@ and creates an unsatisfiable circular dependency.\n", break; memcpy (reloc_addr_arg, (void *) value, MIN (sym->st_size, refsym->st_size)); + if (ELFW(ST_VISIBILITY) (sym->st_other) == STV_PROTECTED) + { + fmt = "\ +%s: Protected symbol `%s' is incompatible with copy relocations\n"; + goto print_err; + } if (__glibc_unlikely (sym->st_size > refsym->st_size) || (__glibc_unlikely (sym->st_size < refsym->st_size) && GLRO(dl_verbose)))