From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from supercat.cmpct.info (supercat.cmpct.info [71.19.146.230]) by sourceware.org (Postfix) with ESMTPS id 239583858C55 for ; Sat, 1 Oct 2022 08:31:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 239583858C55 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=cmpct.info Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cmpct.info Received: from smtpclient.apple (unknown [82.8.138.118]) by supercat.cmpct.info (Postfix) with ESMTPSA id C83DC441A0; Sat, 1 Oct 2022 08:31:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpct.info; s=default; t=1664613093; bh=hqqMLDbRVHGKnvEhI0JxohhtsL88j0YxXQ2ztS5kTkc=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=qonOxU4JsC8lsW1ejDEy4aunnu4WflcCvX5apg15xwwl58UAWzWIUVU8aRP8an+RM Ai/2u8pTx7rVZIt2buU4VVihVu/xecH9Cae4tl0YL796c1J/7Be8NPZeyPx4laL9Ul MXdSJ/SZP/5KX0nR0Yv5A4zMbJ9+W9O3PjSHpGkw= Content-Type: multipart/signed; boundary="Apple-Mail=_85598CBB-F75F-41DC-83A2-245067780946"; 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: <20221001074055.cwwid4yxy6zdmzhn@google.com> Date: Sat, 1 Oct 2022 09:31:27 +0100 Cc: Carlos O'Donell , Florian Weimer , Carlos O'Donell via Libc-alpha Message-Id: References: <8c6fbd40-a0c6-d84f-4e5a-10e7109ffc08@linaro.org> <87bkstn566.fsf@oldenburg.str.redhat.com> <128f4264-d3da-9b04-e567-89b4e73fe299@redhat.com> <20221001074055.cwwid4yxy6zdmzhn@google.com> To: Fangrui Song X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_INFOUSMEBIZ,KAM_SHORT,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --Apple-Mail=_85598CBB-F75F-41DC-83A2-245067780946 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 1 Oct 2022, at 08:40, Fangrui Song via Libc-alpha = wrote: >=20 > On 2022-09-30, Carlos O'Donell via Libc-alpha wrote: >> On 8/9/22 05:21, Florian Weimer wrote: >>> * Carlos O'Donell via Libc-alpha: >>>=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 >>> I think there are several other glibc patches required to fix Rogue >>> Company? >>>=20 >>> (=E2=80=9Cglibc = with reverts >>> applied to allow Rogue Company to work with EasyAntiCheat=E2=80=9D) = makes the >>> following changes: >>>=20 >>> =C2=B7 Install shared objects under traditional versioned nmaes. >>> =C2=B7 Bring back various GLIBC_PRIVATE symbols. >>> =C2=B7 Disable clone3. >>>=20 >>> If EasyAntiCheat has been fixed for those, surely it can be fixed to = use >>> DT_GNU_HASH as well. >>=20 >> The fix is available in version 1.15.2 of the EOS SDK and in the new >> corresponding version of the anti-cheat module. This was released in = August. >>=20 >> Fixing this issue though requires several steps that need to be taken = by the >> developers of the game itself. >>=20 >> The issue therefore has direct impact on users of these binaries, and = we can >> help lessen that impact by adding back DT_HASH. Making this change = upstream >> has value for all the distributions that want to support these games. >>=20 >> I am evaluating this change in isolation and weighing the pros and = cons of >> just this change. As you note there are other changes impact other = games and >> this speaks to me of a disconnect with how Linux is developed versus = how these >> specific applications are being developed. That's something we can = work on >> together as a community by engaging developers directly to see how = their >> workflow maps to our update process. >>=20 >> Looking across the distributions some of them are carrying a revert = that adds >> back DT_HASH. Therefore I think it would help the distributions and = add >> back DT_HASH support for a longer period of time before final = removal. >>=20 >> I don't think this will solve all the problems, but I will work to = test out >> the revert on my Fedora system. >=20 > Just a weak opinion: if downstream Linux distributions have done the > work to carry a local revert, reverting DT_HASH removal in the glibc > release branch doesn't seem to help them... True, but it helps those who have been on the fence and didn't want to deviate from glibc upstream. It also shows that it's an acceptable move to make. Best, sam --Apple-Mail=_85598CBB-F75F-41DC-83A2-245067780946 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+RkAUCYzf6318UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MAAKCRBzhAn1IN+R kE41AQCtrFwjctqQIEGjIdgCf1wgQvIWAh+koLRuP19+Yv/TwgEAoqGy9W4ISxaz sAd0V14W+hxJCbniY/5LKKmkcP4a1QE= =Tk60 -----END PGP SIGNATURE----- --Apple-Mail=_85598CBB-F75F-41DC-83A2-245067780946--