From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) by sourceware.org (Postfix) with ESMTPS id 4CF6C385734E for ; Wed, 1 Jun 2022 07:34:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4CF6C385734E Received: by mail-pg1-x52c.google.com with SMTP id 129so1151852pgc.2 for ; Wed, 01 Jun 2022 00:34:28 -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=pUE0yPW5aEexpEpD/MUh9t1DohGN2or/kScYklgjDp4=; b=FsVXApQUuXMczyLZq/dqZMRscVZP8JzUcVC/6GVPb4Fqf3mK6evPjCjnyLgsQl+Cp8 VKJRuqfGgfAhPiVutc0wHd7oybxYOMpmuCqZEhnW6EMiftLXnio6wpnCrP/CIJZ68xXB fix8i5zvQwQh6D5a2gRITR2zssTc/PzZEBEWinUkFkwyOcTM9v/UuEQcVrfR+DXLvvoK knAufMFOELcBdArXSiFGRlDgP5Q/BIX5PdugmXoqh/0VlTrPahK4Sm2rn6upra5uW1K8 dHhuCrehPn2M5zshTDl/Zo9ISxLOJZtZuCG2lNiwoakLaYr5S17fNqjXZPocxDkVXuP4 0pbg== X-Gm-Message-State: AOAM532oHb3MjKfD6qG0SrRKIRKIFCXcMR9GH0t6nV5cB8eQ50tj69J4 MQhjBiJmpWJ3JkH9TaG7RXvixNYkWwM17g== X-Google-Smtp-Source: ABdhPJy5Kq6mv3nbc25B+E6cjbYXXQRyMycUEGxEvLYY4Gn6bOSIRakvW4wDsk/7VilxMU8XuVheTQ== X-Received: by 2002:a63:f95e:0:b0:3fa:5855:9a3a with SMTP id q30-20020a63f95e000000b003fa58559a3amr39738680pgk.468.1654068867049; Wed, 01 Jun 2022 00:34:27 -0700 (PDT) Received: from google.com ([2620:15c:2ce:200:d5a8:eb1:a3e6:329f]) by smtp.gmail.com with ESMTPSA id w22-20020a170902d71600b0015f4b7a012bsm781264ply.251.2022.06.01.00.34.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jun 2022 00:34:26 -0700 (PDT) Date: Wed, 1 Jun 2022 00:34:23 -0700 From: Fangrui Song To: Szabolcs Nagy Cc: libc-alpha@sourceware.org Subject: Re: [PATCH v2] elf: Remove ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA Message-ID: <20220601073423.ddyb5wuwlo6tpisk@google.com> References: <20220601045033.809671-1-maskray@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=-20.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, 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, 01 Jun 2022 07:34:31 -0000 On 2022-06-01, Szabolcs Nagy wrote: >The 05/31/2022 21:50, 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. >> >> It's extremely unlikely anyone relies on the >> ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA behavior, so let's remove it. >> >> -- >> Changes from v1: >> * Reword commit message as suggested by Szabolcs Nagy > >Please document the interposition change or fix it. Does this paragraph count as an explanation? "Without ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, b.so accesses the copy relocated data like a.so." Or, what other documentation on the interposition behavior do you expect? >That is important as it affects binaries without copy relocation.