From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) by sourceware.org (Postfix) with ESMTPS id B99293858D28 for ; Tue, 14 Dec 2021 21:30:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B99293858D28 Received: by mail-pj1-x1035.google.com with SMTP id mj19so560015pjb.3 for ; Tue, 14 Dec 2021 13:30:23 -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=Fe3wCf7gtCuKwFLz3uHW6E4Q/Nm4m7RIWWql9EmYrvE=; b=OFZfjSaePWwHe3K3lacivQnetdOQc0sE9ka4SqeKgY3KVzTDW85j+iRi9kHlbzuG1e SrM84YuAE7fPp6s9YDsQcOavpA9vmNniU3pAUB42I8Ae0F3MyNhCAgSuoSpr+i7x7f5G h1oRB4j0oZD6SSiZg17oxzZUzAz0jeMml8EwPf285uZp/2qGttoCGWTHPzSxIJi2iIRv tBmje3uSuFqumAjoZ5ZpWLaOjrBD0Hun6UKiRGInOI4s9DMuTdC9rpA3tyul189g67mb +3EgpBrbg1/nzGsbszMRKp1AzzWAiUXxfWTFAMO5/AEPmX8IhWJXICKiDB36FPID2avY zY1g== X-Gm-Message-State: AOAM530juxpFYKKxvYcTwVykK1vwjF0qRzkwM4Tk80WVhAxDO3niofmk 8KDOZbrxbnVpvu48aq83m94DJVFvnoT4AA== X-Google-Smtp-Source: ABdhPJy/4aLhs/ntmXSbbhtjFvhUJmAAbHuXlThkmKmCU0cLwJvQMmfDvupD3sNAKdMahUw2UT44Fw== X-Received: by 2002:a17:902:be07:b0:148:a2f7:9d73 with SMTP id r7-20020a170902be0700b00148a2f79d73mr1398366pls.146.1639517422550; Tue, 14 Dec 2021 13:30:22 -0800 (PST) Received: from google.com ([2620:15c:2ce:200:11df:985b:eae3:6445]) by smtp.gmail.com with ESMTPSA id on5sm525106pjb.23.2021.12.14.13.30.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Dec 2021 13:30:22 -0800 (PST) Date: Tue, 14 Dec 2021 13:30:17 -0800 From: Fangrui Song To: Adhemerval Zanella Cc: Florian Weimer , GNU C Library Subject: Re: [PATCH] elf: Add elf checks for main executable Message-ID: <20211214213017.26ykobarym4kr7il@google.com> References: <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> <1ff795dc-d001-ca49-d787-accc6740956b@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1ff795dc-d001-ca49-d787-accc6740956b@linaro.org> 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: Tue, 14 Dec 2021 21:30:25 -0000 On 2021-12-14, Adhemerval Zanella wrote: > > >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). Should we consider different target triples as different ABI? * Debian/Ubuntu use Debian-style multiarch target triples like x86_64-linux-gnu. * RedHat uses target triples like x86_64-redhat-linux (considered questionable by some folks: https://reviews.llvm.org/D110900) * Suse uses target triples like x86_64-suse-linux (considered questionable by some folks). Currently there is no rigid enforcement that one target triple doesn't run on another, but a mechanism could be developed if you want to prevent "running one distro's exe on another leads to crash". This practice can make some software unhappy as they currently release binary releases which may run a different distro, which even if brittle, sometimes/oftentimes work. >> >> 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 As my blog post says, ELFOSABI_NONE will unlikely change EI_ABIVERSION for RELR. Is the proposal "if ld.bfd --pack-dyn-relocs=relr-glibc is specified, and the output is otherwise ELFOSABI_NONE or ELFOSABI_GNU, use ELFOSABI_GNU and bump EI_ABIVERSION to 4"? This ELFOSABI_GNU is not elegant as RELR is not a GNU extension. OK, I have objection but not so strongly. Since ld.lld --pack-dyn-relocs=relr is there and won't change the behavior, ld.lld's relr-glibc will likely just be an alias without doing the EI_ABIVERSION dance.