From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) by sourceware.org (Postfix) with ESMTP id 4DAE33858C20 for ; Mon, 8 Aug 2022 23:36:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4DAE33858C20 Content-Type: multipart/signed; boundary="Apple-Mail=_259FB79F-9436-45B7-8A93-234BAA1EA33A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: Should we make DT_HASH dynamic section for glibc? From: Sam James In-Reply-To: <20220808225943.gdedpxqvhh2zzrz3@google.com> Date: Tue, 9 Aug 2022 00:36:41 +0100 Cc: Carlos O'Donell , libc-alpha Message-Id: References: <8c6fbd40-a0c6-d84f-4e5a-10e7109ffc08@linaro.org> <20220808225943.gdedpxqvhh2zzrz3@google.com> To: Fangrui Song X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, KAM_SHORT, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Mon, 08 Aug 2022 23:36:51 -0000 --Apple-Mail=_259FB79F-9436-45B7-8A93-234BAA1EA33A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 8 Aug 2022, at 23:59, Fangrui Song via Libc-alpha = wrote: >=20 > On 2022-08-08, Carlos O'Donell via Libc-alpha wrote: >> On 8/8/22 13:31, Adhemerval Zanella Netto via Libc-alpha wrote: >>> It seems that the recent change to remove the multiple hash schemes = on >>> 2.36 [1] broke some specific tools used on proton games [2]. So = instead >>> of explicit set the section type to use both sysv and gnu, we use = the >>> toolchain default which might exclude the sysv type. >>=20 >> Right. >>=20 >>> The last gABI states that DT_HASH is mandatory [3], but DT_GNU_HASH = works >>> a direct replacement meaning that it contains all information for = symbol >>> resolution that DT_HASH provides. >>=20 >> Correct. >>=20 >>> It was done as size optimization from perceived unused features = since >>> DT_GNU_HASH is being used as a default on most distros for a long = time, >>> meaning DT_HASH might not be set. For instance, on a Ubuntu 22.05 = system >>> (GLIBC 2.35) only the glibc provided binaries (pldd, gencat, etc.) = and some >>> external tools (nvidia command line) do provide DT_HASH. >>=20 >> Correct. >>=20 >>> So the question is whether we should enforce at least on glibc by = reverting >>> e47de5cb2d4dbec. It does sounds muddle to keep this solely on = glibc, where >>> rest of the system is not enforcing it, and only for compatibility = with an >>> obscure tools where there is no much information on why it requires = it. >>=20 >> The tool is EAC. >>=20 >> It is EPICs "Easy Anti-Cheat" (https://www.easy.ac/en-us/) and like = other non-standard >> consumers it has to know some specific ELF details. >>=20 >> The game "Rogue Company" is known to use EAC and is likely broken by = this change. >>=20 >> The Nobara Project includes "changes" to make EAC-enabled Steam games = work: >> https://nobaraproject.org/ >>=20 >> I have reviewed the changes that Nobara is carrying and I would not = apply them upstream. >>=20 >> The include such changes as reverting the clone3 addition because it = impacts seccomp-based >> isolation. >>=20 >>> Another option might to extend gABI to state that if DT_GNU_HASH is = presents, >>> it works as DT_HASH and it should not mark as mandated. >>=20 >> We should ask the gABI to mark DT_HASH as optional. >>=20 >> This doesn't resolve the user issue though... >>=20 >>> And if DT_HASH is require required, one possibility is to add a = binutils >>> option to emit an empty DT_HASH just for compatibility and get the = code size >>> improvement. >>=20 >> The chain array needs to be as big as the symbol table since the = presence >> of DT_HASH means it can be indexed into, therefore I don't think we = can >> have an empty DT_HASH. >>=20 >>> [1] = https://sourceware.org/git/?p=3Dglibc.git;a=3Dcommit;h=3De47de5cb2d4dbecb5= 8f569ed241e8e95c568f03c >>> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=3D29456 >>> [3] http://www.sco.com/developers/gabi/latest/ch5.dynamic.html >>=20 >> Using only DT_GNU_HASH is a choice we *always* wanted to allow the >> downstream distributions to make, it was part of the binutils changes = to >> allow just DT_GNU_HASH. >>=20 >> Software that is an ELF consumer on Linux has had 16 years to be = updated >> to handle the switch from DT_HASH to DT_GNU_HASH (OS-specific). >>=20 >> While I'm sympathetic to application developers and their backwards >> compatibility requirements, this specific case is about an ELF = consumers >> and such a consumer needs to track upstream Linux ELF developments. >>=20 >> We aren't breaking ABI when we remove the PLT, remove the old HASH, = or >> other Linux ELF changes (like the recent DT_RELR addition), but we do >> need to allow time for these changes to be absorbed by the ecosystem >> and ELF consumers (like debug information consumers). >>=20 >> At present I would not make any changes to glibc. I would close bug = 29456 >> as RESOLVED/WONTFIX. I'm open to hearing from the EPIC EAC developers >> if they have a case to make about DT_HASH. >>=20 >> In summary: >>=20 >> - DT_GNU_HASH was added in 2006, and for the last 16 years has been = the >> modern standard on Linux. The glibc change was made to allow the >> distributions to choose how backwards compatible they want to be with >> ELF consumers and the hash function and section. This is not ABI, = just >> like the PLT and RELRO are not ABI. >>=20 >> - One specific use case of "Easy Anti-Cheat" software is impacted by >> this implementation detail change which impacts ELF consumers that >> require DT_HASH. >>=20 >> - The choice to have DT_HASH is with the distributions. If this = breaks >> specific applications then those developers need to engage with the >> ecosystem or adapt their software. >=20 > Thanks for analyzing the issue! On > https://github.com/ValveSoftware/Proton/issues/6051 > nobody says this is related to DT_HASH :( >=20 For a long time in Gentoo, we forced DT_GNU_HASH only, but reverted it about a month ago [0] as we had a few reports of Gentoo-only bugs as a result. I spoke to Carlos today and regret not communicating with him before doing that, as this might have revealed the problem earlier, but lesson learned! [0] = https://github.com/gentoo/gentoo/commit/8afecc68b8d689dbfdbff3b16ca50be66d= eb3cce At https://github.com/anyc/steam-overlay/issues/309, we saw various reports of EAC needing DT_GNU_HASH. > If "Easy Anti-Cheat" requires DT_HASH, I think it is a unreasonable > request. I left a comment on > = https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-120869826= 3 >=20 FWIW, and I don't think this is a reason to keep it, I just want to = raise it, some free software has this issue too, like libstrangle: https://bugs.gentoo.org/863863 / = https://gitlab.com/torkel104/libstrangle/-/issues/59. But they just need to adapt to using DT_GNU_HASH. > Many distributions have dropped DT_HASH (e.g. > see = https://github.com/llvm/llvm-project/blob/b405407/clang/lib/Driver/ToolCha= ins/Linux.cpp#L241-L244 > for the encoded Clang knowledge), it is entirely fine for glibc to = drop > DT_HASH for its own shared objects, even if ELFOSABI_NONE is used. > Perhaps, as Roland suggested, clarifying the optional DT_HASH thing on = gnu-gabi@ may help. The only issues we were ever aware of were libstrangle and the EAC bug. So, all in all, having run this for several years, the fallout wasn't that great (limited in scope). Best, sam --Apple-Mail=_259FB79F-9436-45B7-8A93-234BAA1EA33A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCYvGeC18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MAAKCRBzhAn1IN+R kLVYAP9Mk81FXYCPmQMMe6I3GA8YqNTt7mwnksgxsPTixK2wEAEAh9iGVDiQG3Ff 1dkQumLTlk52i16GIc+GBbzUxAImSgQ= =OdDb -----END PGP SIGNATURE----- --Apple-Mail=_259FB79F-9436-45B7-8A93-234BAA1EA33A--