Should we make DT_HASH dynamic section for glibc?

[Carlos O'Donell]

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.

-- 
Cheers,
Carlos.