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 48B323955CAB for ; Tue, 10 May 2022 15:03:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 48B323955CAB Received: by mail-pj1-x1030.google.com with SMTP id x88so4569061pjj.1 for ; Tue, 10 May 2022 08:03:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=f2tSf0X32s3JO7pnZzwObFsbbjqIqaLJrE+jozXWDPY=; b=pyxA3Y53fYF6ZUpPknd9ecXXemEQW8XWDsSitMpa8slJtpKPu6Svg8WEu37BnlpJrl i2E2Ygypkujky4YaLXFm7b/+btjlfsOjRhxhSv2u7wbb6IhtpLO2y5HIsG00MGK6AAmI Tv1y03f9Igb0tfLn973HjL9HiM+VHzg8ODH7TAJ16Fodo1GI+InWMsZbletUAWu+UAI5 3OFYm0QHf2t7lzzhCM4ZYLJJNDftB/SLUzocHk0vunwrk1xtEK5if8pQewd6E7uZo+lG Bt5+fjLGFuK9HDgY42oO6H8KUe1e8tBwgxdmq2GB0OKVRky5R1Fv+pDLPN1rtfrXJ6s4 T9cw== X-Gm-Message-State: AOAM530xsYVRPECcRnblB4me868NLCo5FvePzp86BBskLmATErT7JoTO nfRpSlBSQM1LlC4RZHOnLy26ToAWDEtQNYd0x54x97R2 X-Google-Smtp-Source: ABdhPJyzuTeWn23e9hT+k6JiMqqYy+9uTViuxErwDN0G6yyJpASAW5/NP4hCSrLu/N9q0bRsng1ZKVm1rCXs8N3DIWY= X-Received: by 2002:a17:902:8f8d:b0:15b:7b98:22e6 with SMTP id z13-20020a1709028f8d00b0015b7b9822e6mr21140727plo.102.1652195009384; Tue, 10 May 2022 08:03:29 -0700 (PDT) MIME-Version: 1.0 References: <20220501060615.1694317-1-maskray@google.com> <20220510074231.wteewlruwa2uuv3r@google.com> In-Reply-To: <20220510074231.wteewlruwa2uuv3r@google.com> From: "H.J. Lu" Date: Tue, 10 May 2022 08:02:53 -0700 Message-ID: Subject: Re: [PATCH 0/3] Simplify ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA and revert aarch64/arm's extern protected data handling To: Fangrui Song Cc: GNU C Library , Adhemerval Zanella , Szabolcs Nagy Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3019.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Tue, 10 May 2022 15:03:33 -0000 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. -- H.J.