From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id D32AF3858D38 for ; Fri, 30 Sep 2022 12:57:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D32AF3858D38 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1664542623; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=PhiLwdSP0T7fdsBerOsUScrFLLoDdu/Acv3Q39OhiiI=; b=UGSIvmKNVIaIO4l/CnvBu9freKBslvXWMCkEjHH7/S+lOE0RrHoHi1hC/aU0yoP6WVFWsR 7ZoL5krjHYs6qbR7+04XXCuAOXOjHpG0JfgZ/agOjGnbjrDBJp2PlJaL7pCW+CNM3zX0Rv KsTOetzOPSwlQLo7VRF4Tx/FGExzVoA= Received: from mail-io1-f72.google.com (mail-io1-f72.google.com [209.85.166.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-453-n7iY_bNZOCC0ZY1Gzr9ZAw-1; Fri, 30 Sep 2022 08:57:02 -0400 X-MC-Unique: n7iY_bNZOCC0ZY1Gzr9ZAw-1 Received: by mail-io1-f72.google.com with SMTP id l84-20020a6b3e57000000b006a3fe90910cso2703610ioa.16 for ; Fri, 30 Sep 2022 05:57:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date; bh=PhiLwdSP0T7fdsBerOsUScrFLLoDdu/Acv3Q39OhiiI=; b=3e0S24g6SNrZJw2rK/c0jXu/6ag3YDatKX+qVjGfhnE4HV7/E5yNZD4OLcshHVQ9Hr t3OtQQSbkQRVebwaoPnw/pF5V9oZciOHOW9KxgUbEtv/c69Z0AOT/Q7PZ77NIIAdtvR0 iSBgzMXuKq0n7EzKw5/99lvYRBsFH0GwlucyRe8ooJJTIzBEQg7qYGYU6mqAPqlxuQOc nX4MLiVJJwdQ03mcUyhXtAzfMjuP1kM1+nufHdBE9iUyy+kjuUis6MrAlbZCHyRu1AgO ZpeyxIzFcSxC2JE92EDYD/MediuCS9irRoxc4vXysumWn/FgqLzQ8rDUm98aguBiSnTh D2/w== X-Gm-Message-State: ACrzQf1tCzZFv1/9yNqBbMM30FFkZtc/isheWMgwcC7UDcKFJNAFpn/G Yh+RCcdvkgaW5pz7jbkxe2NEGZWKrvE3AOYBA7jxw7ITQWGMnOqTd4K+7SLSTeyHJTo6INaDbMk M7wfBhspe1vyP9pMx63p2 X-Received: by 2002:a05:6638:d03:b0:35a:71b9:1e86 with SMTP id q3-20020a0566380d0300b0035a71b91e86mr4686958jaj.68.1664542621531; Fri, 30 Sep 2022 05:57:01 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5aK0NqMCcfr0xSJm/CpNWFSzjH02iJjabzv5BSR5tzFs4acGXx2IfSfkq1uAWw5rEvNCU5sw== X-Received: by 2002:a05:6638:d03:b0:35a:71b9:1e86 with SMTP id q3-20020a0566380d0300b0035a71b91e86mr4686947jaj.68.1664542621253; Fri, 30 Sep 2022 05:57:01 -0700 (PDT) Received: from [192.168.0.241] (192-0-145-146.cpe.teksavvy.com. [192.0.145.146]) by smtp.gmail.com with ESMTPSA id s20-20020a056638219400b0035a143b451esm905629jaj.128.2022.09.30.05.57.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Sep 2022 05:57:00 -0700 (PDT) Message-ID: <128f4264-d3da-9b04-e567-89b4e73fe299@redhat.com> Date: Fri, 30 Sep 2022 08:56:59 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: Should we make DT_HASH dynamic section for glibc? To: Florian Weimer , Carlos O'Donell via Libc-alpha Cc: Adhemerval Zanella Netto References: <8c6fbd40-a0c6-d84f-4e5a-10e7109ffc08@linaro.org> <87bkstn566.fsf@oldenburg.str.redhat.com> From: Carlos O'Donell Organization: Red Hat In-Reply-To: <87bkstn566.fsf@oldenburg.str.redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,TXREP 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 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. -- Cheers, Carlos.