Message ID | 20220121172951.285848-1-adhemerval.zanella@linaro.org |
---|---|
Headers |
Return-Path: <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 170FC385781E for <patchwork@sourceware.org>; Fri, 21 Jan 2022 17:30:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 170FC385781E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1642786218; bh=j6lfFef2AV3kJh3vFSKYYB7RDt7YficAsgvmAXqGjuo=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=jVKJedscE7Lglr6lQk4m6lXNWiadLJYDup+JVryirfb38A8lbE1pyKAiiLUewVXR6 ePvdOHEG1Z49d7/lxgbyuupYSlHdknTdNsjKUbMh5ULOg2ujppJBlNYZLlPkIoSOU+ Oq2LtsZZRw2/pTZSRZFxr5f2WwUWPZPup2WF8VEk= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) by sourceware.org (Postfix) with ESMTPS id 0AC543858C60 for <libc-alpha@sourceware.org>; Fri, 21 Jan 2022 17:29:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0AC543858C60 Received: by mail-oi1-x234.google.com with SMTP id m9so50148oia.12 for <libc-alpha@sourceware.org>; Fri, 21 Jan 2022 09:29:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=j6lfFef2AV3kJh3vFSKYYB7RDt7YficAsgvmAXqGjuo=; b=lGZUj35zcc6UJJxPIZ893DK35gMjHc4YpdvzDv312lxIa2ItE9YZ94Dr3QYbcCOfnC Y7Afjl8tdD5Tvx3OKf5r99UG5/jIbDrXi46awWnLxR3h55qtIQZDj+iFWRzSzObrAF+i REy4eoQNTI5ny28lpZ4SAL+TUpm9SQfIQbOyR9DmvcYoPxyAw+MQIUk1C0sCJ+eotQtZ 9CFBOh+G4PcbsAiXNZNyzFCyKdlJyrXJKohOf83BeC6V78k8Eu27wBdscav3WOgYjEHm pW5B7lwGXCceM3XJx5qoi3ErZXjyrHyJ9m8oViDuzFoBPoNAUhtkmC4nFfp1WREsEksx 4cCQ== X-Gm-Message-State: AOAM531JsHpxIFCA4zx9zeFpKFF9cDs15s0bme130PSEkJlLgDRuW3u+ oCfDjI0RbmrCBU/itzUEf5mEmPdrEgzpnQ== X-Google-Smtp-Source: ABdhPJyRrPtr3blV8HwpQRubDHWp+zESV+/khrer76wFMx1dKcwgGaDkKTp6dtpC7B81M4coMxMgvA== X-Received: by 2002:aca:f241:: with SMTP id q62mr1434295oih.64.1642786195197; Fri, 21 Jan 2022 09:29:55 -0800 (PST) Received: from birita.. ([2804:431:c7cb:27f8:f8b7:bc61:9607:9ecb]) by smtp.gmail.com with ESMTPSA id i21sm1294706oto.27.2022.01.21.09.29.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Jan 2022 09:29:54 -0800 (PST) To: libc-alpha@sourceware.org Subject: [PATCH 0/3] Remove prelink support Date: Fri, 21 Jan 2022 14:29:48 -0300 Message-Id: <20220121172951.285848-1-adhemerval.zanella@linaro.org> X-Mailer: git-send-email 2.32.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP 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 <libc-alpha.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> From: Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org> Reply-To: Adhemerval Zanella <adhemerval.zanella@linaro.org> Cc: Richard Purdie <richard.purdie@linuxfoundation.org> Errors-To: libc-alpha-bounces+patchwork=sourceware.org@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> |
Series | Remove prelink support | |
Message
Adhemerval Zanella
Jan. 21, 2022, 5:29 p.m. UTC
As discussed recently on maillist [1], prelink is deprecated in practice: * There is no active development neither maintainace. * It misses supports for some architectures, even for architecture wildly deployed such as aarch64 [2]. * It does not work with recent security hardening such as PIE. * Nor it will work on future ABI additions such as DT_RELR. * Even when PIE is not enabled its coverity if flacky, with some binaries showing corrupted state [3]. * Recent glibc changes to support different tools (such as lld) showed inherent issue with current prelink support. The first patch removes both prelink support by the loader and the LD_TRACE_PRELINKING. The remove of mtrace TRACE_PRELINKING usage is on its own patch because it changes LD_TRACE_LOADED_OBJECTS semantic to support dumping the executable loading address and fixes mtrace for non PIE similar to BZ#22716. Finally the third part removed LD_USE_LOAD_BIAS, which is used solely for try support prelink with PIE. [1] https://sourceware.org/pipermail/libc-alpha/2022-January/135520.html [2] https://sourceware.org/pipermail/libc-alpha/2022-January/135522.html [3] https://embed.endfa.net/yocto-cross-prelink-1/ Adhemerval Zanella (3): elf: Remove prelink support malloc: Remove LD_TRACE_PRELINKING usage from mtrace elf: Remove LD_USE_LOAD_BIAS NEWS | 6 + elf/Makefile | 16 -- elf/dl-conflict.c | 77 ------- elf/dl-deps.c | 66 ------ elf/dl-error-skeleton.c | 4 +- elf/dl-load.c | 3 +- elf/dl-lookup.c | 161 -------------- elf/dl-main.h | 3 + elf/dl-map-segments.h | 3 +- elf/dl-support.c | 1 - elf/do-rel.h | 3 - elf/rtld.c | 283 ++++++------------------- elf/tst-prelink-cmp.c | 49 ----- elf/tst-prelink.c | 29 --- malloc/mtrace.pl | 55 ++--- sysdeps/alpha/dl-machine.h | 15 -- sysdeps/arm/dl-machine.h | 4 - sysdeps/generic/ldsodefs.h | 16 -- sysdeps/generic/unsecvars.h | 1 - sysdeps/i386/dl-machine.h | 16 +- sysdeps/or1k/dl-machine.h | 4 - sysdeps/powerpc/powerpc32/dl-machine.h | 31 +-- sysdeps/powerpc/powerpc64/dl-machine.h | 37 ---- sysdeps/s390/s390-32/dl-machine.h | 22 +- sysdeps/s390/s390-64/dl-machine.h | 22 +- sysdeps/sh/dl-machine.h | 2 +- sysdeps/sparc/sparc32/dl-machine.h | 52 +---- sysdeps/sparc/sparc64/dl-machine.h | 72 +------ sysdeps/x86_64/dl-machine.h | 48 ++--- 29 files changed, 167 insertions(+), 934 deletions(-) delete mode 100644 elf/dl-conflict.c delete mode 100644 elf/tst-prelink-cmp.c delete mode 100644 elf/tst-prelink.c
Comments
On 21/01/2022 14:29, Adhemerval Zanella wrote: > As discussed recently on maillist [1], prelink is deprecated in > practice: > > * There is no active development neither maintainace. > * It misses supports for some architectures, even for architecture > wildly deployed such as aarch64 [2]. > * It does not work with recent security hardening such as PIE. > * Nor it will work on future ABI additions such as DT_RELR. > * Even when PIE is not enabled its coverity if flacky, with some > binaries showing corrupted state [3]. > * Recent glibc changes to support different tools (such as lld) > showed inherent issue with current prelink support. > > The first patch removes both prelink support by the loader and the > LD_TRACE_PRELINKING. > > The remove of mtrace TRACE_PRELINKING usage is on its own patch > because it changes LD_TRACE_LOADED_OBJECTS semantic to support > dumping the executable loading address and fixes mtrace for non > PIE similar to BZ#22716. > > Finally the third part removed LD_USE_LOAD_BIAS, which is used > solely for try support prelink with PIE. > > [1] https://sourceware.org/pipermail/libc-alpha/2022-January/135520.html > [2] https://sourceware.org/pipermail/libc-alpha/2022-January/135522.html > [3] https://embed.endfa.net/yocto-cross-prelink-1/ Based on Weekly Call discussion, I will postpone it to 2.36 and sent a note that 2.35 is latest release that will support prelink.
On 1/21/22 12:29, Adhemerval Zanella via Libc-alpha wrote: > As discussed recently on maillist [1], prelink is deprecated in > practice: This goes in the right direction. I think we should review this for glibc 2.36. Leaving glibc 2.35 as the last release with prelink support. I've reviewed your NEWS entry for the removal note. > * There is no active development neither maintainace. > * It misses supports for some architectures, even for architecture > wildly deployed such as aarch64 [2]. > * It does not work with recent security hardening such as PIE. > * Nor it will work on future ABI additions such as DT_RELR. > * Even when PIE is not enabled its coverity if flacky, with some > binaries showing corrupted state [3]. > * Recent glibc changes to support different tools (such as lld) > showed inherent issue with current prelink support. > > The first patch removes both prelink support by the loader and the > LD_TRACE_PRELINKING. > > The remove of mtrace TRACE_PRELINKING usage is on its own patch > because it changes LD_TRACE_LOADED_OBJECTS semantic to support > dumping the executable loading address and fixes mtrace for non > PIE similar to BZ#22716. > > Finally the third part removed LD_USE_LOAD_BIAS, which is used > solely for try support prelink with PIE. > > [1] https://sourceware.org/pipermail/libc-alpha/2022-January/135520.html > [2] https://sourceware.org/pipermail/libc-alpha/2022-January/135522.html > [3] https://embed.endfa.net/yocto-cross-prelink-1/ > > Adhemerval Zanella (3): > elf: Remove prelink support > malloc: Remove LD_TRACE_PRELINKING usage from mtrace > elf: Remove LD_USE_LOAD_BIAS > > NEWS | 6 + > elf/Makefile | 16 -- > elf/dl-conflict.c | 77 ------- > elf/dl-deps.c | 66 ------ > elf/dl-error-skeleton.c | 4 +- > elf/dl-load.c | 3 +- > elf/dl-lookup.c | 161 -------------- > elf/dl-main.h | 3 + > elf/dl-map-segments.h | 3 +- > elf/dl-support.c | 1 - > elf/do-rel.h | 3 - > elf/rtld.c | 283 ++++++------------------- > elf/tst-prelink-cmp.c | 49 ----- > elf/tst-prelink.c | 29 --- > malloc/mtrace.pl | 55 ++--- > sysdeps/alpha/dl-machine.h | 15 -- > sysdeps/arm/dl-machine.h | 4 - > sysdeps/generic/ldsodefs.h | 16 -- > sysdeps/generic/unsecvars.h | 1 - > sysdeps/i386/dl-machine.h | 16 +- > sysdeps/or1k/dl-machine.h | 4 - > sysdeps/powerpc/powerpc32/dl-machine.h | 31 +-- > sysdeps/powerpc/powerpc64/dl-machine.h | 37 ---- > sysdeps/s390/s390-32/dl-machine.h | 22 +- > sysdeps/s390/s390-64/dl-machine.h | 22 +- > sysdeps/sh/dl-machine.h | 2 +- > sysdeps/sparc/sparc32/dl-machine.h | 52 +---- > sysdeps/sparc/sparc64/dl-machine.h | 72 +------ > sysdeps/x86_64/dl-machine.h | 48 ++--- > 29 files changed, 167 insertions(+), 934 deletions(-) > delete mode 100644 elf/dl-conflict.c > delete mode 100644 elf/tst-prelink-cmp.c > delete mode 100644 elf/tst-prelink.c >
On Wed, 2022-01-26 at 23:59 -0500, Carlos O'Donell wrote: > On 1/21/22 12:29, Adhemerval Zanella via Libc-alpha wrote: > > As discussed recently on maillist [1], prelink is deprecated in > > practice: > > This goes in the right direction. > > I think we should review this for glibc 2.36. > > Leaving glibc 2.35 as the last release with prelink support. Can I confirm that by the above, you mean that prelink is almost certain to be removed after 2.35 is released? Yocto Project has an LTS due soon and this does influence what we do there a little which is why I'm asking specifically. I'm saddened but resigned to it, the sad reality is there aren't enough people to maintain everything and the utility of prelink is now questionable. Cheers, Richard
On 03/02/2022 12:29, Richard Purdie wrote: > On Wed, 2022-01-26 at 23:59 -0500, Carlos O'Donell wrote: >> On 1/21/22 12:29, Adhemerval Zanella via Libc-alpha wrote: >>> As discussed recently on maillist [1], prelink is deprecated in >>> practice: >> >> This goes in the right direction. >> >> I think we should review this for glibc 2.36. >> >> Leaving glibc 2.35 as the last release with prelink support. > > Can I confirm that by the above, you mean that prelink is almost certain to be > removed after 2.35 is released? > > Yocto Project has an LTS due soon and this does influence what we do there a > little which is why I'm asking specifically. > > I'm saddened but resigned to it, the sad reality is there aren't enough people > to maintain everything and the utility of prelink is now questionable. Yes, it it still my plan to remove prelink on 2.36 as indicated in 2.35 NEWS.