From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by sourceware.org (Postfix) with ESMTPS id 995EB385841C for ; Tue, 14 Dec 2021 00:17:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 995EB385841C Received: by mail-pj1-x1029.google.com with SMTP id q22-20020a17090a431600b001b0e3a74cf7so134462pjg.1 for ; Mon, 13 Dec 2021 16:17:48 -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:content-transfer-encoding :in-reply-to; bh=G8O/dM/espyLRAO8qzdlIHStzExdCS+5yEgvDny3Gt4=; b=GA20JPh67/R3/AEurf+B92TTiitGvUSF0qeaMl57w3CiKhqhTu9an9xh18VPf98s++ 2CHFPyrLsl8RnZEOSZ+R1/v15TPngwVDuReRR8VOxZPaCCAqLtgakWYUhbuKDjhkItBv rpsL0D8UXKAwKaqK0rIeU/Z0YpjdWZQ8kOJqEuxsA+Z6LNYLr6D6rSF6A06x169NqPX9 F0r5XaUP/pGtAVIDenJYTXua+t7U8ez199AZkbRqGqj8Dclo7NLmO/Z7xTQKxSC0F/sH dgyryPsbouwiNEvWvo96+oZ2aJlQEtPdYA1tOzxr5Q+BkgL0Deo/Vp0DlMdLTc6T/uaL 8vbQ== X-Gm-Message-State: AOAM532Q6jsv8g1infk3eKKHJQIcapUm53m6mNkp7p44rFUSJqjaEWzB qufzWOqCi3rgvah/Ug0/KslbPKrDW0vRnQ== X-Google-Smtp-Source: ABdhPJwLMmgGRCoQ+4j6KTe7tqaCrNnPiq4GiXpcK0v1hzvEzah16VMgd5q2RE4a8Ab+umNrl/Wj/Q== X-Received: by 2002:a17:90a:e40f:: with SMTP id hv15mr1657859pjb.5.1639441067503; Mon, 13 Dec 2021 16:17:47 -0800 (PST) Received: from google.com ([2620:15c:2ce:200:57f1:1c61:8d1d:88f5]) by smtp.gmail.com with ESMTPSA id 130sm13274430pfu.13.2021.12.13.16.17.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Dec 2021 16:17:47 -0800 (PST) Date: Mon, 13 Dec 2021 16:17:42 -0800 From: =?utf-8?B?RsSBbmctcnXDrCBTw7JuZw==?= To: Florian Weimer Cc: Adhemerval Zanella , GNU C Library Subject: Re: [PATCH] elf: Add elf checks for main executable Message-ID: <20211214001742.lbleuljd2dgmfinx@google.com> References: <20211119150329.2200675-1-adhemerval.zanella@linaro.org> <87bl1tmtxz.fsf@oldenburg.str.redhat.com> <873a6969-8c06-5233-2b4c-48360e120f07@linaro.org> <877dchlbb8.fsf@oldenburg.str.redhat.com> <6386c389-086d-e123-d4d6-a97777f207ed@linaro.org> <87czm8quz3.fsf@oldenburg.str.redhat.com> <871r2nmmaf.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <871r2nmmaf.fsf@oldenburg.str.redhat.com> X-Spam-Status: No, score=-19.4 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: Tue, 14 Dec 2021 00:17:50 -0000 On 2021-12-08, Florian Weimer wrote: >* Fāng-ruì Sòng: > >> On Tue, Dec 7, 2021 at 12:35 PM Adhemerval Zanella via Libc-alpha >> wrote: >>> >>> >>> >>> On 07/12/2021 12:45, Florian Weimer wrote: >>> > * Adhemerval Zanella: >>> > >>> >> It does, but only for specific configurations. bintutils does have a >>> >> testcase for it, pr21375*, but not all configurations does bump because >>> >> they do not require ABS relocations (for instance, for n64 -mmicromips >>> >> --defsym hidn=1 does set the ABI version to 4). >>> > >>> > Should this tell us something at DT_RELR? That binutils doesn't help us >>> > to prevent crashes for other features? >>> >>> I think it tell us that binutils support for DT_RELR or any other potential >>> abi disruptive feature will need a better ABI enforce for all Linux or >>> affected ABI. It seems that binutils support are not really unified with >>> the multiples architectures and ABI. >>> >>> But I think it should be doable on linker side. >> >> For DT_RELR, you may see >> https://maskray.me/blog/2021-10-31-relative-relocations-and-relr#ei_abiversion >> Many Linux executables (STB_GNU_UNIQUE/STT_GNU_IFUNC are not used) use >> ELFOSABI_NONE and the linker does not and should not bump >> EI_ABIVERSION. I was out-of-town for ~10 days. So sorry that I did not reply in time. >That radare2 command is really confusing. It changes the ABI version to >16. It does not change OSABI to GNU. Thanks. I clarified my wording and added "For ELFOSABI_GNU (r2 -nwqc 'wx 03 @ 7'), changing EI_ABIVERSION to 4 or above will observe the failure with ld.so mapped objects but not with kernel mapped objects." >So I think we actually agree on the ld behavior, that the >OSABI/ABIVERSION is not really used by binutils today. Agree that OSABI/ABIVERSION is not enforced in the linker. >One question I meant to ask you: If the GNU toolchain uses any mechanism >for lockout of older glibc, would Google start building binaries using >that mechanism and patch their glibc forks that implement DT_RELR to be >able to load binaries with the lockout? For ChromeOS patched glibc, I can forward the question to ChromeOS toolchain folks. Actually the code review is open to the public and you can comment on https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/3320511 I think their viewpoint is similar to the Gentoo developer: https://sourceware.org/pipermail/libc-alpha/2021-November/133388.html If a group chooses a non-default feature, they need to understand the implications and they cannot blame the upstream if porting the binary to old systems would crash. If the question is: "if upstream glibc implements the diagnostic, will ChromeOS port the patch to their glibc". My reply is non-authoritative, but if this has not been a problem for more than 3 years now, I do know see large value backporting the feature to their older glibc release. If the question is to Google internal systems, such a diagnostic would have a low value as production systems try hard not to have the mismatching version problem (which is probably common on Linux desktops). I believe many corporate users will share similar viewpoint. They may control their production systems in such a way that running a new executable on an old glibc is either impossible, or can be detected with other means, so a built-in glibc diagnostic is not that useful. While I am replying with my corporate email address (because I subscribe to this list with it), I also need to speak up for other customers I support as my non-work-related community duty (Android, Fuchsia, FreeBSD, etc). For Android and Fuchsia, they have the feature for ~3 years now, while I think (running on an old system) is explicitly unsupported for them, having a ld.so diagnostic (well, they use their own libc implementations) at this point is definitely nearly useless. For *BSD, I have heard multiple people saying something in line with "this is a Linux problem. They'd not add new knobs to the toolchain".