public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
* Should we make DT_HASH dynamic section for glibc?
@ 2022-08-08 17:31 Adhemerval Zanella Netto
  2022-08-08 20:40 ` Carlos O'Donell
  0 siblings, 1 reply; 11+ messages in thread
From: Adhemerval Zanella Netto @ 2022-08-08 17:31 UTC (permalink / raw)
  To: libc-alpha

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.

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.

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.

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.

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.

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.

[1] https://sourceware.org/git/?p=glibc.git;a=commit;h=e47de5cb2d4dbecb58f569ed241e8e95c568f03c
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=29456
[3] http://www.sco.com/developers/gabi/latest/ch5.dynamic.html

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Should we make DT_HASH dynamic section for glibc?
  2022-08-08 17:31 Should we make DT_HASH dynamic section for glibc? Adhemerval Zanella Netto
@ 2022-08-08 20:40 ` Carlos O'Donell
  2022-08-08 20:56   ` Carlos O'Donell
                     ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Carlos O'Donell @ 2022-08-08 20:40 UTC (permalink / raw)
  To: Adhemerval Zanella Netto, libc-alpha

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.

Right.

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

Correct.

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

Correct.

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

The Nobara Project includes "changes" to make EAC-enabled Steam games work:
https://nobaraproject.org/

I have reviewed the changes that Nobara is carrying and I would not apply them upstream.

The include such changes as reverting the clone3 addition because it impacts seccomp-based
isolation.

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

We should ask the gABI to mark DT_HASH as optional.

This doesn't resolve the user issue though...
 
> 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.

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.

> [1] https://sourceware.org/git/?p=glibc.git;a=commit;h=e47de5cb2d4dbecb58f569ed241e8e95c568f03c
> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=29456
> [3] http://www.sco.com/developers/gabi/latest/ch5.dynamic.html

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.

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

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.

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

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.

In summary:

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

- One specific use case of "Easy Anti-Cheat" software is impacted by
  this implementation detail change which impacts ELF consumers that
  require DT_HASH.

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

-- 
Cheers,
Carlos.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Should we make DT_HASH dynamic section for glibc?
  2022-08-08 20:40 ` Carlos O'Donell
@ 2022-08-08 20:56   ` Carlos O'Donell
  2022-08-08 22:59   ` Fangrui Song
  2022-08-09  9:21   ` Florian Weimer
  2 siblings, 0 replies; 11+ messages in thread
From: Carlos O'Donell @ 2022-08-08 20:56 UTC (permalink / raw)
  To: Adhemerval Zanella Netto, libc-alpha

On 8/8/22 16:40, Carlos O'Donell wrote:
> We should ask the gABI to mark DT_HASH as optional.

I've started that discussion.

https://groups.google.com/g/generic-abi/c/th5919osPAQ

-- 
Cheers,
Carlos.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Should we make DT_HASH dynamic section for glibc?
  2022-08-08 20:40 ` Carlos O'Donell
  2022-08-08 20:56   ` Carlos O'Donell
@ 2022-08-08 22:59   ` Fangrui Song
  2022-08-08 23:36     ` Sam James
  2022-08-09  9:21   ` Florian Weimer
  2 siblings, 1 reply; 11+ messages in thread
From: Fangrui Song @ 2022-08-08 22:59 UTC (permalink / raw)
  To: Carlos O'Donell; +Cc: Adhemerval Zanella Netto, libc-alpha

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.
>
>Right.
>
>> 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.
>
>Correct.
>
>> 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.
>
>Correct.
>
>> 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.
>
>The Nobara Project includes "changes" to make EAC-enabled Steam games work:
>https://nobaraproject.org/
>
>I have reviewed the changes that Nobara is carrying and I would not apply them upstream.
>
>The include such changes as reverting the clone3 addition because it impacts seccomp-based
>isolation.
>
>> 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.
>
>We should ask the gABI to mark DT_HASH as optional.
>
>This doesn't resolve the user issue though...
>
>> 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.
>
>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.
>
>> [1] https://sourceware.org/git/?p=glibc.git;a=commit;h=e47de5cb2d4dbecb58f569ed241e8e95c568f03c
>> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=29456
>> [3] http://www.sco.com/developers/gabi/latest/ch5.dynamic.html
>
>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.
>
>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).
>
>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.
>
>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).
>
>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.
>
>In summary:
>
>- 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.
>
>- One specific use case of "Easy Anti-Cheat" software is impacted by
>  this implementation detail change which impacts ELF consumers that
>  require DT_HASH.
>
>- 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.

Thanks for analyzing the issue!  On
https://github.com/ValveSoftware/Proton/issues/6051
nobody says this is related to DT_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-1208698263

Many distributions have dropped DT_HASH (e.g.
see https://github.com/llvm/llvm-project/blob/b405407/clang/lib/Driver/ToolChains/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.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Should we make DT_HASH dynamic section for glibc?
  2022-08-08 22:59   ` Fangrui Song
@ 2022-08-08 23:36     ` Sam James
  0 siblings, 0 replies; 11+ messages in thread
From: Sam James @ 2022-08-08 23:36 UTC (permalink / raw)
  To: Fangrui Song; +Cc: Carlos O'Donell, libc-alpha

[-- Attachment #1: Type: text/plain, Size: 6411 bytes --]



> On 8 Aug 2022, at 23:59, Fangrui Song via Libc-alpha <libc-alpha@sourceware.org> wrote:
> 
> 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.
>> 
>> Right.
>> 
>>> 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.
>> 
>> Correct.
>> 
>>> 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.
>> 
>> Correct.
>> 
>>> 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.
>> 
>> The Nobara Project includes "changes" to make EAC-enabled Steam games work:
>> https://nobaraproject.org/
>> 
>> I have reviewed the changes that Nobara is carrying and I would not apply them upstream.
>> 
>> The include such changes as reverting the clone3 addition because it impacts seccomp-based
>> isolation.
>> 
>>> 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.
>> 
>> We should ask the gABI to mark DT_HASH as optional.
>> 
>> This doesn't resolve the user issue though...
>> 
>>> 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.
>> 
>> 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.
>> 
>>> [1] https://sourceware.org/git/?p=glibc.git;a=commit;h=e47de5cb2d4dbecb58f569ed241e8e95c568f03c
>>> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=29456
>>> [3] http://www.sco.com/developers/gabi/latest/ch5.dynamic.html
>> 
>> 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.
>> 
>> 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).
>> 
>> 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.
>> 
>> 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).
>> 
>> 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.
>> 
>> In summary:
>> 
>> - 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.
>> 
>> - One specific use case of "Easy Anti-Cheat" software is impacted by
>> this implementation detail change which impacts ELF consumers that
>> require DT_HASH.
>> 
>> - 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.
> 
> Thanks for analyzing the issue!  On
> https://github.com/ValveSoftware/Proton/issues/6051
> nobody says this is related to DT_HASH :(
> 

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/8afecc68b8d689dbfdbff3b16ca50be66deb3cce

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

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/ToolChains/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

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Should we make DT_HASH dynamic section for glibc?
  2022-08-08 20:40 ` Carlos O'Donell
  2022-08-08 20:56   ` Carlos O'Donell
  2022-08-08 22:59   ` Fangrui Song
@ 2022-08-09  9:21   ` Florian Weimer
  2022-09-30 12:56     ` Carlos O'Donell
  2 siblings, 1 reply; 11+ messages in thread
From: Florian Weimer @ 2022-08-09  9:21 UTC (permalink / raw)
  To: Carlos O'Donell via Libc-alpha

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

THanks,
Florian


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Should we make DT_HASH dynamic section for glibc?
  2022-08-09  9:21   ` Florian Weimer
@ 2022-09-30 12:56     ` Carlos O'Donell
  2022-10-01  7:40       ` Fangrui Song
  0 siblings, 1 reply; 11+ messages in thread
From: Carlos O'Donell @ 2022-09-30 12:56 UTC (permalink / raw)
  To: Florian Weimer, Carlos O'Donell via Libc-alpha
  Cc: Adhemerval Zanella Netto

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.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Should we make DT_HASH dynamic section for glibc?
  2022-09-30 12:56     ` Carlos O'Donell
@ 2022-10-01  7:40       ` Fangrui Song
  2022-10-01  8:31         ` Sam James
  0 siblings, 1 reply; 11+ messages in thread
From: Fangrui Song @ 2022-10-01  7:40 UTC (permalink / raw)
  To: Carlos O'Donell; +Cc: Florian Weimer, Carlos O'Donell via Libc-alpha

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Should we make DT_HASH dynamic section for glibc?
  2022-10-01  7:40       ` Fangrui Song
@ 2022-10-01  8:31         ` Sam James
  2022-10-01  8:41           ` Andreas Schwab
  0 siblings, 1 reply; 11+ messages in thread
From: Sam James @ 2022-10-01  8:31 UTC (permalink / raw)
  To: Fangrui Song
  Cc: Carlos O'Donell, Florian Weimer, Carlos O'Donell via Libc-alpha

[-- Attachment #1: Type: text/plain, Size: 3083 bytes --]



> On 1 Oct 2022, at 08:40, Fangrui Song via Libc-alpha <libc-alpha@sourceware.org> wrote:
> 
> 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...

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

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Should we make DT_HASH dynamic section for glibc?
  2022-10-01  8:31         ` Sam James
@ 2022-10-01  8:41           ` Andreas Schwab
  2022-10-01 13:49             ` Florian Weimer
  0 siblings, 1 reply; 11+ messages in thread
From: Andreas Schwab @ 2022-10-01  8:41 UTC (permalink / raw)
  To: Sam James
  Cc: Fangrui Song, Florian Weimer, Carlos O'Donell via Libc-alpha

On Okt 01 2022, Sam James wrote:

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

It's much easier to configure binutils with
--enable-default-hash-style=both.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Should we make DT_HASH dynamic section for glibc?
  2022-10-01  8:41           ` Andreas Schwab
@ 2022-10-01 13:49             ` Florian Weimer
  0 siblings, 0 replies; 11+ messages in thread
From: Florian Weimer @ 2022-10-01 13:49 UTC (permalink / raw)
  To: Andreas Schwab
  Cc: Sam James, Florian Weimer, Carlos O'Donell via Libc-alpha

* Andreas Schwab:

> On Okt 01 2022, Sam James wrote:
>
>> 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.
>
> It's much easier to configure binutils with
> --enable-default-hash-style=both.

Changing the linker flags for the glibc build should work, too, I
think, but I haven't tested it.  These days, we just inherit what the
toolchain provides.

I any case, no patching of glibc should be needed.

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2022-10-01 13:49 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-08 17:31 Should we make DT_HASH dynamic section for glibc? Adhemerval Zanella Netto
2022-08-08 20:40 ` Carlos O'Donell
2022-08-08 20:56   ` Carlos O'Donell
2022-08-08 22:59   ` Fangrui Song
2022-08-08 23:36     ` Sam James
2022-08-09  9:21   ` Florian Weimer
2022-09-30 12:56     ` Carlos O'Donell
2022-10-01  7:40       ` Fangrui Song
2022-10-01  8:31         ` Sam James
2022-10-01  8:41           ` Andreas Schwab
2022-10-01 13:49             ` Florian Weimer

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).