From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) by sourceware.org (Postfix) with ESMTPS id 8A39C3858422 for ; Thu, 18 Nov 2021 23:27:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8A39C3858422 Received: by mail-pj1-x102f.google.com with SMTP id h24so6450078pjq.2 for ; Thu, 18 Nov 2021 15:27:05 -0800 (PST) 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=Ud/2hTYAOPuF/0JxGWRt81rT1OecTAOgCJc/z17b3T0=; b=M9ALQLPO2eYF7RTVfRpuHs8SCm8dk+nBWMMloKSYrwyXqJ187ToADVLDG8zTfisD+z ABbUby+4P0XzvkC9mcmqV+6kSdkybov5gojiA0UAFr+BSI2DzEza4H+W5u62Qdnk9rSb Y2CkO6nBrbULvvrdqUbObuEoa4E7Ah3BeKHR4N5pUwehHxVJLe1jjgaa63RE5X8FMLcb 3ofcJdnDO7Y/pAglHbtTBGoYz3mXevi+TIZhG0yQlFv70Gn+oRd4ZlbWCDQq+BwnOF83 pr6KLtBrc8dI760IjNrY8nQ1ERjU/Ms87Fu+d7avZAMirVI/YE9Eami0x6ORmlMM5UJx MqIg== X-Gm-Message-State: AOAM532GsN/zyeYGB2uQwTbNIzMIKwCXjxavVmZVnwf8YqlnQrrfpbeH IIBwSplETSTtEyjiRsz2NSCo5XvQeNSGZw== X-Google-Smtp-Source: ABdhPJx7kDhZk+MoE7CHefSEwgzh4f7HaM6BvLcJIUlPJ7DzRv+3AYCbVjs2CorlqVe7R9z9woOD/A== X-Received: by 2002:a17:90b:1185:: with SMTP id gk5mr67402pjb.113.1637278024498; Thu, 18 Nov 2021 15:27:04 -0800 (PST) Received: from google.com ([2620:15c:2ce:200:a3b8:a5e6:26b:8a0c]) by smtp.gmail.com with ESMTPSA id f4sm695059pfj.61.2021.11.18.15.27.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Nov 2021 15:27:03 -0800 (PST) Date: Thu, 18 Nov 2021 15:27:00 -0800 From: Fangrui Song To: Florian Weimer Cc: Fangrui Song via Libc-alpha , "H.J. Lu" , Rich Felker , Felix Yan , Sylvestre Ledru , sam@gentoo.org, Leah Neukirchen Subject: Re: Can DT_RELR catch up glibc 2.35? Message-ID: <20211118232700.vktq3tchmmlwcrwu@google.com> References: <20211112074723.uvmlvihlutnib6ik@google.com> <0732a3cc-8dad-52fb-96e3-ef5da8eb3a8e@linaro.org> <20211118003025.6pq5jucukbgrw7zg@google.com> <87pmqxztis.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <87pmqxztis.fsf@oldenburg.str.redhat.com> X-Spam-Status: No, score=-19.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, FSL_HELO_FAKE, KAM_INFOUSMEBIZ, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=no 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: Thu, 18 Nov 2021 23:27:07 -0000 (For newly CCed Linux distro folks, sorry for hijacking you here. Scroll to the end for my request from you.) The first message of the thread is https://sourceware.org/pipermail/libc-alpha/2021-November/133009.html and https://maskray.me/blog/2021-10-31-relative-relocations-and-relr#time-travel-compatibility provides context. ) On 2021-11-18, Florian Weimer wrote: >* Fangrui Song via Libc-alpha: > >> A synthesized versioned undefined dynamic symbol can indeed catch "time >> travel compatibility", but the mechanism would be the first time ld adds an option variant >> for a particular libc implementation (glibc) locking out all other >> implementations: --pack-dyn-relocs=relr-glibc or -z relr-glibc. >> Sigh, it is really not pretty. > >There are already other features that do not work with other libcs, >e.g. --audit, --filter, --auxiliary. And --dynamic-linker tends to lock >out other libcs, too. And it's a bit hard to argue against this given >that --pack-dyn-relocs=relr works the same way against upstream glibc. --audit, --filter, and --auxiliary do not lock out other implementations. Solaris has DT_AUDIT, DT_FILTER, and DT_AUXILIARY. If a libc implementation desires, it can add the support. --pack-dyn-relocs=relr-glibc or -z relr-glibc would be the first time an option name mentions glibc. (See below, it could be "relr-gnu", but still something not many users using ELFOSABI_GNU want). >However, I happen to dislike the glibc-tied approach as well, and would >like to see an ELFOSABI bump, along with a kernel fix to make it stick >for main programs as well. Thanks for disliking the glibc-tied approach :) EI_ABIVERSION depends on EI_OSABI. We need to discuss ELFOSABI_NONE/ELFOSABI_GNU separately. For ELFOSABI_GNU (alias: ELFOSABI_LINUX), the option name does not have to mention "glibc" and can probably use "relr-gnu". However, It is still odd that a feature exists/works well and a "*-gnu" variant is added just because glibc uses a different development model. I think Android bionic / musl may feel the change unnecessary but may not complain loudly because they just doesn't inspect EI_ABIVERSION. Well, musl doesn't support DT_RELR, but Rich can provide more authoritative opinion on EI_ABIVERSION bump from musl's point of view. For ELFOSABI_NONE: many Linux executables don't use STB_GNU_UNIQUE/STT_GNU_IFUNC and therefore use ELFOSABI_NONE. I think Solaris folks have ruled out the possibility to bump EI_OSABIVERSION. This is not something they/FreeBSD/etc need. In addition, to make EI_ABIVERSION check work. A distro needs to backport the change to many old glibc versions. I am not sure many distros want to do this. >> We know many other libc implementations don't want to synthesize such a >> symbol. > >It's been used for other toolchain features before, that's where the >idea comes from. E.g. __stack_chk_guard, _mcount from GCC/Clang instrumentation as a compiler-libc protocol. But this would be the first time the linker synthesizes an undefined symbol. >> "If user is deploying a *opt-in* feature that requires proper dynamic >> loader support, I would expect they know the environment they are targeting." >> >> May I suggest that: if a glibc distro really worries that users deploy >> ld.lld --pack-dyn-relocs=relr on their new system and back port that to >> old systems, just remove DT_RELR support from your local glibc? Since >> ld.lld --pack-dyn-relocs=relr doesn't work on your system with glibc >> 2.35, people wouldn't complain about not working on older versions. > >In a sense, isn't that what's happening? Albeit on an upstream scale. From my point of view, I want glibc based Linux distro to benefit from DT_RELR earlier. Blocking this on an upstream scale is not appealing. CCed a bunch of Linux distro folks (Arch/Debian/Gentoo/Void). * ld.lld is not a default linker on most Linux distros. * ld.lld --pack-dyn-relocs=relr is an opt-in feature. * --pack-dyn-relocs=relr is difficult to misuse because GNU ld doesn't support it. * binutils may get relr support one day, but may take several releases. * Nobody will switch the GCC/Clang default any time soon. * Coping the new executable to an old glibc system is unsupported. By enabling DT_RELR in upstream glibc, the Linux distros will get the glibc feature with ZERO overhead in their downstream packaging. Then, a user opting in ld.lld --pack-dyn-relocs=relr will have smaller executables. When GNU ld finally gets the feature, the benefit will reach more users. So why not having the feature to make the future feature enablement smoother?