From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) by sourceware.org (Postfix) with ESMTPS id 4BA473858D28 for ; Tue, 14 Dec 2021 21:07:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4BA473858D28 Received: by mail-qk1-x732.google.com with SMTP id t6so18110397qkg.1 for ; Tue, 14 Dec 2021 13:07:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=EaXIpodoGpSc+D6wNU3VtcdapMVeuk+1lHQcOv4LRBQ=; b=j0tpSGh8VnDbkIxvPvrFJl4l9RvVziE+mJJKmQLe80vIkjlJDC4U70PP8f+ctgUcrl rZgpQuBuGp9L/hGOKaYrd/TE7dd8byU340niOh05UFRe/IqaWb0T+xUnECIYliETmhXF rJ2twIKVtTb37HUBuu6F5vV20kg2IYM0EOe1rpXBwpX5jLaO4+n1Fk8HhuhRxF1cIYYl ClCR9AMoa5vOPNWXWVV3IeJddh0sqbnOnRcrcYejkSFpPEHz41bevVr0oe3gp6FAPn0x T8r+MR7Kd4Xp+sNFYauWSo+Z1Y66moW70TPaYm8r3O8PpCbLiMPTvJZSnvujbeq+qqv0 ESvg== X-Gm-Message-State: AOAM5309A/Cstgpw27IID4ucffZA4SpiY8qgT6K0jj2QzOMSQDxKBzyv 9CHpGlKEapn0h1F3O3NMs8A7VQPWwPVyJw== X-Google-Smtp-Source: ABdhPJxqPXKocCsk+w7Bwrmb+GrIwTTut4q4lNOszS6cbH2yEidbQT8aOTKxg4ghOiNhAaz3U/bOBA== X-Received: by 2002:a05:620a:706:: with SMTP id 6mr6443174qkc.374.1639516041480; Tue, 14 Dec 2021 13:07:21 -0800 (PST) Received: from ?IPV6:2804:431:c7ca:103f:1000:c46d:a2d6:9bed? ([2804:431:c7ca:103f:1000:c46d:a2d6:9bed]) by smtp.gmail.com with ESMTPSA id g12sm850325qtk.69.2021.12.14.13.07.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Dec 2021 13:07:21 -0800 (PST) Message-ID: <1ff795dc-d001-ca49-d787-accc6740956b@linaro.org> Date: Tue, 14 Dec 2021 18:07:19 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: [PATCH] elf: Add elf checks for main executable Content-Language: en-US To: Fangrui Song Cc: Florian Weimer , GNU C Library References: <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> <20211214001742.lbleuljd2dgmfinx@google.com> <87sfuvsgll.fsf@oldenburg.str.redhat.com> <20211214192411.qfwmv576757n4ciz@google.com> From: Adhemerval Zanella In-Reply-To: <20211214192411.qfwmv576757n4ciz@google.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_INFOUSMEBIZ, NICE_REPLY_A, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2021 21:07:24 -0000 On 14/12/2021 16:24, Fangrui Song wrote: > On 2021-12-14, Adhemerval Zanella wrote: >> >> >> On 14/12/2021 06:03, Florian Weimer wrote: >>> * Fāng-ruì Sòng: >>> >>>> 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. >>> >>> But if you don't backport, you can teach your toolchain to start >>> producing binaries that fail to load on older glibc.  You will have to >>> keep creating binaries that lack proper markup. >>> >>> My concern is that we go through all this trouble to implement a version >>> proper handshake, and yet Google binaries will still crash on older >>> glibc. >> >> Is ChromeOS glibc really binary compatible with glibc from other general >> Linux distributions? Different from google/grte branches, ChromeOS seems >> to work by patching upstream glibc and my impression is they not really care >> nor aim to be (Fāng-ruì remarks also strength this idea). > > Not binary compatible, like two very different Linux distributions (e.g. > a musl one vs a glibc one; a pure llvm-project toolchain based one vs a > traditional GNU toolchain based one). These are essentially two different ABIs due complete different libc, afaik musl support on gcc is doing with a different triplet to make it explicit. > >> In any case, ChromeOS's DT_RELR use does show that it is de facto a different >> ABI, it is only unfortunate that its ELF ABI does not give us any standard >> marking to advertise so (and we will need to resort on some hacking such as >> scanning for some symbol or versioning to to do). >> >> I am not sure if we should really care to handle such situations, it would >> be nice if we can coordinate with ChromeOS to get it align its ABI with >> mainstream and sort DT_RELR but I think *now* it is not a requisite and I >> think we should move DT_RELR support independently. > > Like every glibc Linux distribution carrying some glibc patches which > may decrease binary compatibility with other glibc Linux distributions, > ChromeOS carries some patches like RELR, Disable-float128, and > add-clang-style-FORTIFY patches. (I've heard about complaints about the > latter two patches, they are Clang oriented and will likely benefit > glibc-build-with-clang gets more love: > https://maskray.me/blog/2021-10-10-when-can-glibc-be-built-with-clang) My understanding it is something distributions *really* avoids to do. The only explicit deviation from upstream regarding ABI I am aware is SH [1], where Debian carries a patch to enable some FPU mode switch (I am not sure why it is not upstream). For instance, even for powerpc64le IBM and Red Hat pushed hard to avoid diverge from upstream regarding starting ABI version (which resulted in some heated discussion to which based ABI to use). In any case, both RELR and float128 disable reinforce my point that ChromeOS is a complete distinct ABI that I don't see much point in trying to handle/sanitize it. I think we should handle the same way we do for objects builds against a different libc (for instance trying to load a shared library built against musl). > > If you'd like to discuss with them to minimize ABI differences, they > will be happy to have a better communication with the upstream (and, the > software repository and code review website are all open). > Different Linux distributions have different priorities and focus. Yes, but I as far I as know they do not deviate from glibc upsteam ABI and as long you build against a older libc, retro-compatibility is maintained. That's not the case for ChromeOS. > > For RELR, my suggestion is: > > * add the DT_RELR patch without lockout to glibc 2.35 > * if some distributions are really fond of "time travel compatibility", >   develop the lockout mechanism (in 2.36 or 2.37) > * add GNU ld support > * After a long time, add a know to GCC to pass the glibc oriented option to ld > * I'll likely not add a lackout mechanism to ld.lld --pack-dyn-relocs. > * After many years, make GCC default to the RELR linker option. I agree with your points, but I still thin using a different EI_ABIVERSION for RELR should improve user experience for a opt-in feature. I am aware this does not help current way where kernel neither glibc checks is for the main executable, but we can backport this fix and it might support for general distribution once/if RELR is supported by GNU tools. [1] https://sourceware.org/glibc/wiki/Release/2.30#SH