From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) by sourceware.org (Postfix) with ESMTPS id 0A4CD3858D38 for ; Sat, 1 Oct 2022 07:41:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0A4CD3858D38 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=google.com Received: by mail-pf1-x42b.google.com with SMTP id g130so5498693pfb.8 for ; Sat, 01 Oct 2022 00:41:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date; bh=sOs8quf4tvqd/3QCSCJcCV4OPfZczsOujAKweWyJUNg=; b=L3bYRBdoy0amKWtv48ETBZDRVnL44VCg1YvmcJQmhFNGQk11IWufyAp7H0LiZjdxkA OzRUMOg0Hshz+zfDRkwt7afl49XhfnSGrMNZJprbPtDIPkxqqrO3WDKmk5myCAXc88DK T2vu7uz9hIQ0VslV/i4G+8uBlW9VkGbkDLQdVishrtctwVscjtDlt5Oc/8biihTlhI26 O9GCC8I1ztmoWK1vuEk0Vezk8tY3vQNL/BdEI7f1fjtt2VjdQqqPs7nXcPup/XRrzeV6 R+bPi6j5A0b1sg2kyTs56ENecSK8CYKSmPjE89sq+KQqVMNTaAi0B75MVVfhU78Ln87z woJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date; bh=sOs8quf4tvqd/3QCSCJcCV4OPfZczsOujAKweWyJUNg=; b=yn0w+qm9l7no5/D3AMiBYDSyJKfrPVXe+Zf2PTbalZVTjfL0jrsE5WlViDPI5sgQfi SruYGuSoNghg5DEF+s24TkeNC/70fHODQBURDID99MvHqS32jBhQXTO92K3LG1m3XJ9h GzwHFTLDz5vlSxYUxlg1uPjQGj+JdNMTXldkHiH9nXDpaqN6ZdOB4jGF4+4Mlgiz5FmL XJWSM5HNaAun96/4JTOSWMAV9KoqX2PTBJCk9oxoLDjoCLgCbfjHY8+GrSzOtKG7TNmR dFRyIosbYL+0AFSU8bql1uGVVOS5zwIhXpbMwTMGpRAfYVIywc5A1ZNa2WViX7+HqmGV i/TQ== X-Gm-Message-State: ACrzQf0B9pjKmC+bK76RFou0ypyvuW+x6evC7Kz4A7eSDhmwkC4lV9Wv A2+LS73+qREdVBoCh5rARwuoJewViN8oWQ== X-Google-Smtp-Source: AMsMyM73w+jmI1eZQv1saMnMSO5qVsyPwSO3QXqNHpHqSe6jz+GITZMNbHn2dxJ6Yd1U6xlubHlOYQ== X-Received: by 2002:aa7:9d9a:0:b0:53e:8bc5:afb7 with SMTP id f26-20020aa79d9a000000b0053e8bc5afb7mr12616898pfq.54.1664610060890; Sat, 01 Oct 2022 00:41:00 -0700 (PDT) Received: from google.com ([2620:15c:2ce:200:3a85:8afb:786d:5a2a]) by smtp.gmail.com with ESMTPSA id z15-20020a1709027e8f00b0016f196209c9sm3150027pla.123.2022.10.01.00.40.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 01 Oct 2022 00:40:59 -0700 (PDT) Date: Sat, 1 Oct 2022 00:40:55 -0700 From: Fangrui Song To: Carlos O'Donell Cc: Florian Weimer , Carlos O'Donell via Libc-alpha Subject: Re: Should we make DT_HASH dynamic section for glibc? Message-ID: <20221001074055.cwwid4yxy6zdmzhn@google.com> References: <8c6fbd40-a0c6-d84f-4e5a-10e7109ffc08@linaro.org> <87bkstn566.fsf@oldenburg.str.redhat.com> <128f4264-d3da-9b04-e567-89b4e73fe299@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <128f4264-d3da-9b04-e567-89b4e73fe299@redhat.com> X-Spam-Status: No, score=-19.9 required=5.0 tests=BAYES_00,DKIMWL_WL_MED,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,ENV_AND_HDR_SPF_MATCH,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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? >> >> (“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...