From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by sourceware.org (Postfix) with ESMTPS id BDF383858C20 for ; Mon, 8 Aug 2022 22:59:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BDF383858C20 Received: by mail-pl1-x62b.google.com with SMTP id z19so9852487plb.1 for ; Mon, 08 Aug 2022 15:59:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc; bh=GgE3Z4P6sLcScgUdtF657zLw/YdV2I9vDI1S70mm1KM=; b=Y/nEAKVqccyMIrRV1MSuHrwWtrlh2gi2z3faq7FzOA5zvfcEaJTiGZw2F3rM1dqpY8 wiiLuNhhFQ7IW9ReLaQ0tGi8v5DtTaB53N59AXcNLN1scAScKInGjD4FX079xvt0u2A+ zYzfQEGO5d8OXBoLt9Sa4STe7HDWAkT/HC5xLXpfcokCuBdgTUD8VIRYtxoPK+FbPtL6 VbAzrcVylSxEWBjYMHPzl6HVEnOpQPIv7XwVkxisTENRSyd+idldOp4dAMAa4tJ0s7IH gK9Bx1luZ+xmJmkQbq8XCpCumIaeYYT5KN+miFWnkjkAS8FzF7jJoEVO/a+nFm9cGiw2 nx1g== X-Gm-Message-State: ACgBeo1fhE7KWsP0N+nbYscP/mwB5LuZuQLJwiWmLTOSeEx+LP8BpLWE QO/ZSfd09+ckKhmCcZkP50U7vw== X-Google-Smtp-Source: AA6agR5puBtDmW8QOH/fFCPYdmFIsX1ecCHla28ws3blenVTB9QVVotKRxb/6RR0nGjpxChuxz2rLQ== X-Received: by 2002:a17:903:2442:b0:16f:1319:d28c with SMTP id l2-20020a170903244200b0016f1319d28cmr21098282pls.95.1659999588507; Mon, 08 Aug 2022 15:59:48 -0700 (PDT) Received: from google.com ([2620:15c:2ce:200:bab6:334a:f9d5:62ba]) by smtp.gmail.com with ESMTPSA id d29-20020a631d5d000000b0041296bca2a8sm6765683pgm.12.2022.08.08.15.59.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Aug 2022 15:59:47 -0700 (PDT) Date: Mon, 8 Aug 2022 15:59:43 -0700 From: Fangrui Song To: Carlos O'Donell Cc: Adhemerval Zanella Netto , libc-alpha Subject: Re: Should we make DT_HASH dynamic section for glibc? Message-ID: <20220808225943.gdedpxqvhh2zzrz3@google.com> References: <8c6fbd40-a0c6-d84f-4e5a-10e7109ffc08@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, FSL_HELO_FAKE, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL 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 22:59:52 -0000 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.