Re: Should we make DT_HASH dynamic section for glibc?

[Fangrui Song <maskray@google.com>]

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:
>>
>>>> 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.
>>>
>>> The tool is EAC.
>>>
>>> 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.
>>>
>>> The game "Rogue Company" is known to use EAC and is likely broken by
>>> this change.
>>
>> I think there are several other glibc patches required to fix Rogue
>> Company?
>>
>> <https://github.com/GloriousEggroll/glibc-eac-rc> (“glibc with reverts
>> applied to allow Rogue Company to work with EasyAntiCheat”) makes the
>> following changes:
>>
>> · Install shared objects under traditional versioned nmaes.
>> · Bring back various GLIBC_PRIVATE symbols.
>> · Disable clone3.
>>
>> If EasyAntiCheat has been fixed for those, surely it can be fixed to use
>> DT_GNU_HASH as well.
>
>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.
>
>Fixing this issue though requires several steps that need to be taken by the
>developers of the game itself.
>
>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.
>
>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.
>
>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.
>
>I don't think this will solve all the problems, but I will work to test out
>the revert on my Fedora system.

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...