Message ID | 1bfa01e6e92073b30c02cb76a209656b9d97b675.1610016590.git.szabolcs.nagy@arm.com |
---|---|
State | Superseded |
Headers |
Return-Path: <libc-alpha-bounces@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1D0C4396EC6C; Thu, 7 Jan 2021 11:02:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1D0C4396EC6C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1610017336; bh=4O5/Z462ld6sHUvdnvdeWAas8EtVOmhZJf2PjNA+Cy0=; h=To:Subject:Date:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=U63NIofkAz2bWdm8sVDZcaew84Z2w1Q1/y7wAkxJ44ZPePKsgMRFWK0LWKA86w5cU lpKqrYiipFnjBXBtKY6aT01dpAlf4Kk8WpWOMbU3DzQVrKIcJH9ggaJ4RQn/MwF+Ox 478c04wf+vgG76fAj5WW4rDgNMmYGWZ7i/PZHCLY= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60058.outbound.protection.outlook.com [40.107.6.58]) by sourceware.org (Postfix) with ESMTPS id B84EC396EC4C for <libc-alpha@sourceware.org>; Thu, 7 Jan 2021 11:02:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B84EC396EC4C Received: from DB8PR03CA0021.eurprd03.prod.outlook.com (2603:10a6:10:be::34) by AM5PR0801MB2084.eurprd08.prod.outlook.com (2603:10a6:203:4f::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3721.20; Thu, 7 Jan 2021 11:02:11 +0000 Received: from DB5EUR03FT051.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:be:cafe::2) by DB8PR03CA0021.outlook.office365.com (2603:10a6:10:be::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6 via Frontend Transport; Thu, 7 Jan 2021 11:02:11 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; sourceware.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;sourceware.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT051.mail.protection.outlook.com (10.152.21.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6 via Frontend Transport; Thu, 7 Jan 2021 11:02:11 +0000 Received: ("Tessian outbound 39646a0fd094:v71"); Thu, 07 Jan 2021 11:02:11 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: dbb824716ae570f0 X-CR-MTA-TID: 64aa7808 Received: from 8cecfecdd3db.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id FD489339-DEDB-4694-A0C0-D8D0EC05440A.1; Thu, 07 Jan 2021 11:02:05 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 8cecfecdd3db.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 07 Jan 2021 11:02:05 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UHMuv8L0lNZqVv8tBtHFJLm8sqOYsPgM63dCXyCUsBbepDr0sY6c1ZW7nVmlarT/u1ouufkxxWF5D2iDBl0MB+GFOVSkLes3nmKfoT38hFLM3HwxYGXno87oo0Zq+5796k7adRYkl/n3suGmOzIhFqaXIFawYKBlK8XtCoflwL9A3SksQvHzSV62Bw+HF83w89aMdhh2p/Q3znprE+PvXTuw1kjxqzGpb0K0R8ntiilDgrEiRBIsWH7sqqf87dN4eyryY3v6I28+QCNjiwj1Y5E7S9l3QVcs4vFDgI5FAphZNfY/OSxtNRB16T+0nIjblLz79M/SCCfW8Ahg81zSvA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4O5/Z462ld6sHUvdnvdeWAas8EtVOmhZJf2PjNA+Cy0=; b=BH34dPTObOi4wuzDKbCfqZxdtbbKavZA/OwhP96yW+eSsZ5gkIAtbKyaM5FW/qzlUiKdZb1y7uGdSLxed09/sTgc+fr0s7g5L48FVbzFVKz605VcwD53fgVRzrvlZNsrPmRuF6NAdmvLjCNo+ArOz6C7E/I8AOCfYLTgGZq8kh65X0MDTAHeaUv8zKF9CVCSpxuKzwRj+GYYo4nLnyv1rdYzIq3N87cnB+P3DhSFCaY7lBG1q2HVJynLWcAhyhDsGbTvHdt4zYxfl+zzIQtT3ww1uvraQaRftDPR+RY/lP7S7gQ/MDISr8oxTr7Vtafzm6J4gJOMIYOFktr13Zc3+g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none Authentication-Results-Original: sourceware.org; dkim=none (message not signed) header.d=none;sourceware.org; dmarc=none action=none header.from=arm.com; Received: from PA4PR08MB6320.eurprd08.prod.outlook.com (2603:10a6:102:e5::9) by PA4PR08MB6271.eurprd08.prod.outlook.com (2603:10a6:102:eb::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3721.23; Thu, 7 Jan 2021 11:02:05 +0000 Received: from PA4PR08MB6320.eurprd08.prod.outlook.com ([fe80::700f:ddbe:a347:ee4f]) by PA4PR08MB6320.eurprd08.prod.outlook.com ([fe80::700f:ddbe:a347:ee4f%6]) with mapi id 15.20.3742.006; Thu, 7 Jan 2021 11:02:05 +0000 To: libc-alpha@sourceware.org Subject: [PATCH 3/3] csu: Move static pie self relocation later [BZ #27072] Date: Thu, 7 Jan 2021 11:01:54 +0000 Message-Id: <1bfa01e6e92073b30c02cb76a209656b9d97b675.1610016590.git.szabolcs.nagy@arm.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <cover.1610016590.git.szabolcs.nagy@arm.com> References: <cover.1610016590.git.szabolcs.nagy@arm.com> Content-Type: text/plain X-Originating-IP: [217.140.106.51] X-ClientProxiedBy: SA0PR11CA0098.namprd11.prod.outlook.com (2603:10b6:806:d1::13) To PA4PR08MB6320.eurprd08.prod.outlook.com (2603:10a6:102:e5::9) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost.localdomain (217.140.106.51) by SA0PR11CA0098.namprd11.prod.outlook.com (2603:10b6:806:d1::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6 via Frontend Transport; Thu, 7 Jan 2021 11:02:03 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 1f5d6487-4eff-4ed7-b6aa-08d8b2fbaebb X-MS-TrafficTypeDiagnostic: PA4PR08MB6271:|AM5PR0801MB2084: X-Microsoft-Antispam-PRVS: <AM5PR0801MB2084C56111636B0A63F3BD9CEDAF0@AM5PR0801MB2084.eurprd08.prod.outlook.com> x-checkrecipientrouted: true NoDisclaimer: true X-MS-Oob-TLC-OOBClassifiers: OLM:8882;OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: XWeiTG/TYAu9tiq5d/SZrusUfA1Fqln6Mk2Lxs6T5Qz3CuxMdGf5Uop4yqfA1vQ1fpADeHEZ1pymUbCLN0OSwiXmAWTto0xw/CDMZ4dsWnqvcLmdWEobSekWzIx3/YOqgWRVB0GhrcR9gOC1+3G9FTvSHT6gHplDd+PoHPiiQ8JQqVtc7xT/INyU3Hd8i9hm/m6uCLX9YQLrvPiDCy/gzeUOsf6/uJBcu8m9vNkKCZjjWDuQbDAI2NxCXzBjHDO2lg1WN4TVZnXt5E0YEvlXoKG6w8EXapgVnnL1UgDnB5EVBCLaRWJbFylg6PBgiYY5dpx2L6C3saNDGdI71oqihjjqELq+uJrTYMAP/lIEOu6MZARoGWiH2HMME6YhBHhKfVe0fU1M899jau3yI9bZv7/dHrB4PMzkAHmGsyc3GNU2s92AClJiXUa7lWeQOToPK5yG/kHep9q4w+L+hmFDrg== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PA4PR08MB6320.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(136003)(366004)(39860400002)(376002)(396003)(6666004)(2616005)(956004)(26005)(16526019)(66476007)(66946007)(66556008)(6506007)(186003)(8676002)(2906002)(52116002)(6916009)(8936002)(69590400011)(6486002)(478600001)(44832011)(83380400001)(5660300002)(36756003)(6512007)(316002)(86362001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: /RkVKRpMX6Z+EzVpe+7VhtasIzd/ot4rbGgfA2gxU4VtTtltuNLAKfxpFN7fDYBcsqbwW/8JM/4n1cWE0zDIxA6AGsINs6QVMl6eAPckae+C0x6s81diUi1+lUXsKsddHnid7ClCD1P6j4mV/Q6MPVP5drwCC6aBUECjvrPn5jSF8iIig5VJiJEkMliZaLQ+CEVCrlS51jnJ9YUEkAshd3X3M8Ytd++lA9aT0YBpXBxzEFmkh7+KVXzKuvrBvX7BBN3poZKLMOnknD6H7eCh9urKmAVpcZi3P0JHeWjJA/mYcJg3XZoWxHbzAMkcX0P2NbiSnaW5ua1+Rpn3047A36RSvoI9IlUUEapiuNxbPouDNZzKF/AGac/Hf7K008sYBfawBOGhjCWJLc5l8dz2pC8bK+VHdnHiTIvvIc/jOb8NESh6nd037mzoiR7Yu9QSPEHu0wxOLnMPGYdS5AwpHWlrDEZ7v2ADrn4WY68d/+Csnap18rmejSov+GageFMGneCeGh0SdSZHfK5HDPcIBUDbUmYHmMkFcfT4NvLSTnrHWZVlJtDaO4snlbhpj6XAix16P/QfAVbY0Sx1WIR2kn3G/wuM65ASkuIoBulu3c46EkUiibn8Q80J8wg6Xt/Z0AslyzF0NmpeAxRihjhvCJdLPnjJJhtxeJ3tQyLT69s6z07Pnw80xv9qNZi99OxsuqLKx0McXT5sAjQQKeER8R1oNyetd3pbspB0MswoTFdlgNYYNHpcOiliPfpt3zJCSfzBsLX4Hek79xprPLTXcwQIbrMwFVQdNEZifKnf8jATrkA9paM9qgqqiUs1ZgpQnj3w3CHcsZ+rAUfMP17YxQelxieusXO7bN9CJUiMAUGQPdXCrUr8iD4cF/QbePve3Cwlzt8fGKML0+/2ltzkzB8pU6HNfJRKXbiahCohf2MnnaKbC4EHl8weXzGw46nMfbcTpT3MPs5z+aWeVBcgyh0w9JBDkgQNs7lvs1cWyoCun+hXWx17kdxYFKjxLuuq X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR08MB6271 Original-Authentication-Results: sourceware.org; dkim=none (message not signed) header.d=none; sourceware.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT051.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 4b555cd0-f296-43d4-444b-08d8b2fbab1a X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: bcezjAxC234ZVKwZr8g1xqJ0jg9Oh7Ah2kwFJRoJDhRaA/33TfPhCShDhlByQetQEiHz5lfBG169XMmZ7U+XHLk0oNu6ehHSU7CMqauAFLKWvS/gpOq+8BPbBj/0W+RL4oLt4sd+ecngk97k3Hlvqj9S+YArEw3tnowJ0rNoJJJLL9Ljy2t09DwsCatRyTsoHkQcGlEms4qYcL9tjaIIuw+BqNB6dngkuswrHkAH8je0nLQhIXa1yyS4NgBxQF/eagiWFZkJCQ9Scv8KuLny2iohETFtF1LhPUU9DXONm9J3lWktXQxOpNfTVh/HDVaxW4pSB0bzCSYw5qLn5fpO91EhrhA+v5LVs5eKVGNxIiU+QyZQJA7Ql75qwNGq45lV3Py9zRN1q1/9za0QdSNslnAQ2LvWdmkL9jmv5Elpf/JIGioSEjJ9EIT9w920KZ96Yje1C5pOrKw4uvYqJGE5YJR2DALKzEw7RiDkz/XIOtKZ6+gsULMOR/cawLL0DeeLFptX3O7R1ANegtjBMdrv8g== X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(376002)(39860400002)(396003)(136003)(346002)(46966006)(69590400011)(6512007)(82740400003)(478600001)(6916009)(8676002)(36756003)(34020700004)(82310400003)(8936002)(2906002)(44832011)(70206006)(316002)(70586007)(26005)(83380400001)(5660300002)(186003)(6506007)(6486002)(2616005)(16526019)(956004)(336012)(6666004)(81166007)(356005)(86362001)(47076005); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jan 2021 11:02:11.0928 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1f5d6487-4eff-4ed7-b6aa-08d8b2fbaebb X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DB5EUR03FT051.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0801MB2084 X-Spam-Status: No, score=-14.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, GIT_PATCH_0, MSGID_FROM_MTA_HEADER, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> From: Szabolcs Nagy via Libc-alpha <libc-alpha@sourceware.org> Reply-To: Szabolcs Nagy <szabolcs.nagy@arm.com> Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces@sourceware.org> |
Series |
fix ifunc with static pie [BZ #27072]
|
|
Commit Message
Szabolcs Nagy
Jan. 7, 2021, 11:01 a.m. UTC
On targets where hidden symbol access does not need RELATIVE relocs, move the static pie self relocation after tunables and cpu features are set up. This allows processing IRELATIVE relocs with correct ifunc dispatch logic. Unfortunately it is hard to guarantee that there will be no dynamic relocations in the early start up code, so this is a bit fragile. Ideally the RELATIVE relocs would be processed as early as possible and IRELATIVE relocs after cpu features are setup, but in glibc it is hard to separate them into two steps. --- csu/libc-start.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
Comments
On Thu, Jan 7, 2021 at 3:04 AM Szabolcs Nagy via Libc-alpha <libc-alpha@sourceware.org> wrote: > > On targets where hidden symbol access does not need RELATIVE > relocs, move the static pie self relocation after tunables and > cpu features are set up. This allows processing IRELATIVE > relocs with correct ifunc dispatch logic. > > Unfortunately it is hard to guarantee that there will be no > dynamic relocations in the early start up code, so this is a > bit fragile. Ideally the RELATIVE relocs would be processed as > early as possible and IRELATIVE relocs after cpu features are > setup, but in glibc it is hard to separate them into two steps. x86 linker places IRELATIVE relocations the last: https://sourceware.org/bugzilla/show_bug.cgi?id=13302 Does your linker have this bug fixed?
On 1/7/21 7:36 AM, H.J. Lu via Libc-alpha wrote: > On Thu, Jan 7, 2021 at 3:04 AM Szabolcs Nagy via Libc-alpha > <libc-alpha@sourceware.org> wrote: >> >> On targets where hidden symbol access does not need RELATIVE >> relocs, move the static pie self relocation after tunables and >> cpu features are set up. This allows processing IRELATIVE >> relocs with correct ifunc dispatch logic. >> >> Unfortunately it is hard to guarantee that there will be no >> dynamic relocations in the early start up code, so this is a >> bit fragile. Ideally the RELATIVE relocs would be processed as >> early as possible and IRELATIVE relocs after cpu features are >> setup, but in glibc it is hard to separate them into two steps. > > x86 linker places IRELATIVE relocations the last: > > https://sourceware.org/bugzilla/show_bug.cgi?id=13302 > > Does your linker have this bug fixed? Agreed, this is something I asked about during the design of IFUNCs and I was told by Ulrich and others that IRELATIVE has to be placed in a group and after RELATIVE relocs. We need to document more of the guarantees and semantics here.
On Thu, Jan 7, 2021 at 4:46 AM Carlos O'Donell <carlos@redhat.com> wrote: > > On 1/7/21 7:36 AM, H.J. Lu via Libc-alpha wrote: > > On Thu, Jan 7, 2021 at 3:04 AM Szabolcs Nagy via Libc-alpha > > <libc-alpha@sourceware.org> wrote: > >> > >> On targets where hidden symbol access does not need RELATIVE > >> relocs, move the static pie self relocation after tunables and > >> cpu features are set up. This allows processing IRELATIVE > >> relocs with correct ifunc dispatch logic. > >> > >> Unfortunately it is hard to guarantee that there will be no > >> dynamic relocations in the early start up code, so this is a > >> bit fragile. Ideally the RELATIVE relocs would be processed as > >> early as possible and IRELATIVE relocs after cpu features are > >> setup, but in glibc it is hard to separate them into two steps. > > > > x86 linker places IRELATIVE relocations the last: > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=13302 > > > > Does your linker have this bug fixed? > > Agreed, this is something I asked about during the design of > IFUNCs and I was told by Ulrich and others that IRELATIVE has > to be placed in a group and after RELATIVE relocs. Not just before RELATIVE. IRELATIVE should be processed the last before all other relocations. See PR 13302 for other cases.
The 01/07/2021 04:51, H.J. Lu wrote: > On Thu, Jan 7, 2021 at 4:46 AM Carlos O'Donell <carlos@redhat.com> wrote: > > > > On 1/7/21 7:36 AM, H.J. Lu via Libc-alpha wrote: > > > On Thu, Jan 7, 2021 at 3:04 AM Szabolcs Nagy via Libc-alpha > > > <libc-alpha@sourceware.org> wrote: > > >> > > >> On targets where hidden symbol access does not need RELATIVE > > >> relocs, move the static pie self relocation after tunables and > > >> cpu features are set up. This allows processing IRELATIVE > > >> relocs with correct ifunc dispatch logic. > > >> > > >> Unfortunately it is hard to guarantee that there will be no > > >> dynamic relocations in the early start up code, so this is a > > >> bit fragile. Ideally the RELATIVE relocs would be processed as > > >> early as possible and IRELATIVE relocs after cpu features are > > >> setup, but in glibc it is hard to separate them into two steps. > > > > > > x86 linker places IRELATIVE relocations the last: > > > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=13302 > > > > > > Does your linker have this bug fixed? > > > > Agreed, this is something I asked about during the design of > > IFUNCs and I was told by Ulrich and others that IRELATIVE has > > to be placed in a group and after RELATIVE relocs. > > Not just before RELATIVE. IRELATIVE should be processed the > last before all other relocations. See PR 13302 for other cases. this is about static pie: sorting relocs does not help, the problem is not that ifunc resolvers have some relocs in them, but that the target specific relocation processing is one monolithic switch in a loop that handles all relocs in one go, there is no api to request only a subset of relocs to be processed (either by type or ordering in the list of relocs). in __libc_start_main we need to do do_relative_relocs(); setup_auxv_tunables_cpu_etc(); do_irelative_relocs(); which cannot be done without major changes in all targets and generic elf reloc handling code. so the second best is setup_auxv_tunables_cpu_etc(); // avoid relative relocs do_all_relocs(); on targets where this can be done (other targets do not support static pie).
The 01/07/2021 13:02, Szabolcs Nagy via Libc-alpha wrote: > this is about static pie: sorting relocs does not help, the > problem is not that ifunc resolvers have some relocs in them, > but that the target specific relocation processing is one > monolithic switch in a loop that handles all relocs in one go, > there is no api to request only a subset of relocs to be > processed (either by type or ordering in the list of relocs). > > in __libc_start_main we need to do > > do_relative_relocs(); > setup_auxv_tunables_cpu_etc(); > do_irelative_relocs(); i just realized we can do this because RELATIVE and IRELATIVE happen to be in different places (one where DT_REL{A} points to and another where DT_JUMPREL points to). i dont know how reliable this is across targets, but we only need this to work in static pie (which is only supported on a small number of targets as far as i know). so i can try to tease _dl_relocate_static_pie apart into 'normal' reloc and 'plt' reloc processing (normally this is done so that plt relocs can be lazy evaluated, but here we would do it so IRELATIVE is processed in a separate step). it still sounds like a big hack that relies on where IRELATIVE is placed with current linkers and that there are no other relocs we need to care about in static pie. i can create a patch to see if it works.
On 1/7/21 7:55 PM, Szabolcs Nagy via Libc-alpha wrote: > it still sounds like a big hack that relies on where > IRELATIVE is placed with current linkers and that there > are no other relocs we need to care about in static pie. > i can create a patch to see if it works. This is probably a safe assumption for pointer based architectures but not for those with capabilities. I have a feeling you might care about the latter ;) Siddhesh
The 01/07/2021 20:18, Siddhesh Poyarekar wrote: > On 1/7/21 7:55 PM, Szabolcs Nagy via Libc-alpha wrote: > > it still sounds like a big hack that relies on where > > IRELATIVE is placed with current linkers and that there > > are no other relocs we need to care about in static pie. > > i can create a patch to see if it works. > > This is probably a safe assumption for pointer based architectures but not > for those with capabilities. I have a feeling you might care about the > latter ;) well static pie is broken now, i care about that more. we don't know yet how capability relocs will work with static linking and ifuncs. but the main problem with this idea is that i have to copy a large part of the elf reloc code and hack it apart to do static pie relocation (and that code is not a nice piece of code in the first place).
On Thu, Jan 7, 2021 at 7:25 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote: > > The 01/07/2021 20:18, Siddhesh Poyarekar wrote: > > On 1/7/21 7:55 PM, Szabolcs Nagy via Libc-alpha wrote: > > > it still sounds like a big hack that relies on where > > > IRELATIVE is placed with current linkers and that there > > > are no other relocs we need to care about in static pie. > > > i can create a patch to see if it works. > > > > This is probably a safe assumption for pointer based architectures but not > > for those with capabilities. I have a feeling you might care about the > > latter ;) > > well static pie is broken now, i care about that more. > we don't know yet how capability relocs will work with > static linking and ifuncs. > > but the main problem with this idea is that i have > to copy a large part of the elf reloc code and hack > it apart to do static pie relocation (and that code > is not a nice piece of code in the first place). We should call _dl_relocate_static_pie as early as possible and delay others as much as we can.
On Thu, Jan 7, 2021 at 3:04 AM Szabolcs Nagy via Libc-alpha <libc-alpha@sourceware.org> wrote: > > On targets where hidden symbol access does not need RELATIVE > relocs, move the static pie self relocation after tunables and > cpu features are set up. This allows processing IRELATIVE > relocs with correct ifunc dispatch logic. > > Unfortunately it is hard to guarantee that there will be no > dynamic relocations in the early start up code, so this is a > bit fragile. Ideally the RELATIVE relocs would be processed as > early as possible and IRELATIVE relocs after cpu features are > setup, but in glibc it is hard to separate them into two steps. > --- > csu/libc-start.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/csu/libc-start.c b/csu/libc-start.c > index db859c3bed..b8d22bd59e 100644 > --- a/csu/libc-start.c > +++ b/csu/libc-start.c > @@ -142,7 +142,10 @@ LIBC_START_MAIN (int (*main) (int, char **, char ** MAIN_AUXVEC_DECL), > int result; > > #ifndef SHARED > +# ifndef PI_STATIC_AND_HIDDEN > + /* Do static pie self relocation as early as possible. */ > _dl_relocate_static_pie (); > +# endif It should be simply removed. PI_STATIC_AND_HIDDEN should be required for static PIE. > char **ev = &argv[argc + 1]; > > @@ -191,6 +194,13 @@ LIBC_START_MAIN (int (*main) (int, char **, char ** MAIN_AUXVEC_DECL), Does { /* Starting from binutils-2.23, the linker will define the magic symbol __ehdr_start to point to our own ELF header if it is visible in a segment that also includes the phdrs. So we can set up _dl_phdr and _dl_phnum even without any information from auxv. */ extern const ElfW(Ehdr) __ehdr_start __attribute__ ((weak, visibility ("hidden"))); if (&__ehdr_start != NULL) { assert (__ehdr_start.e_phentsize == sizeof *GL(dl_phdr)); GL(dl_phdr) = (const void *) &__ehdr_start + __ehdr_start.e_phoff; GL(dl_phnum) = __ehdr_start.e_phnum; } } here require RELATIVE relocation? > ARCH_INIT_CPU_FEATURES (); > > +# ifdef PI_STATIC_AND_HIDDEN > + /* Do static pie self relocation after cpu features are setup. > + Code before this point must avoid relocations, which in practice > + means no initialized global pointer or ifunc symbol access. */ > + _dl_relocate_static_pie (); > +# endif > + > /* Perform IREL{,A} relocations. */ > ARCH_SETUP_IREL (); > > -- > 2.17.1 >
The 01/07/2021 13:03, H.J. Lu wrote: > On Thu, Jan 7, 2021 at 3:04 AM Szabolcs Nagy via Libc-alpha > <libc-alpha@sourceware.org> wrote: > > #ifndef SHARED > > +# ifndef PI_STATIC_AND_HIDDEN > > + /* Do static pie self relocation as early as possible. */ > > _dl_relocate_static_pie (); > > +# endif > > It should be simply removed. PI_STATIC_AND_HIDDEN should be > required for static PIE. i guess that makes sense, i can add an assertion for that. > > char **ev = &argv[argc + 1]; > > > > @@ -191,6 +194,13 @@ LIBC_START_MAIN (int (*main) (int, char **, char ** MAIN_AUXVEC_DECL), > > Does > { > /* Starting from binutils-2.23, the linker will define the > magic symbol __ehdr_start to point to our own ELF header > if it is visible in a segment that also includes the phdrs. > So we can set up _dl_phdr and _dl_phnum even without any > information from auxv. */ > > extern const ElfW(Ehdr) __ehdr_start > __attribute__ ((weak, visibility ("hidden"))); > if (&__ehdr_start != NULL) > { > assert (__ehdr_start.e_phentsize == sizeof *GL(dl_phdr)); > GL(dl_phdr) = (const void *) &__ehdr_start + __ehdr_start.e_phoff; > GL(dl_phnum) = __ehdr_start.e_phnum; > } > } > > here require RELATIVE relocation? hm indeed __ehdr_start is accessed via GOT. (i thought pc relative access would work, but i guess that cannot work for an undefined weak symbol.) without relocation processing &__ehdr_start will always evaluate to 0, i.e. as if it was undefined. but i think GL(dl_phdr) is only used much later so it can be moved after self relocs. that would also make it clear that we don't use anything here from phdrs that might require relocations. i'll fix this.
diff --git a/csu/libc-start.c b/csu/libc-start.c index db859c3bed..b8d22bd59e 100644 --- a/csu/libc-start.c +++ b/csu/libc-start.c @@ -142,7 +142,10 @@ LIBC_START_MAIN (int (*main) (int, char **, char ** MAIN_AUXVEC_DECL), int result; #ifndef SHARED +# ifndef PI_STATIC_AND_HIDDEN + /* Do static pie self relocation as early as possible. */ _dl_relocate_static_pie (); +# endif char **ev = &argv[argc + 1]; @@ -191,6 +194,13 @@ LIBC_START_MAIN (int (*main) (int, char **, char ** MAIN_AUXVEC_DECL), ARCH_INIT_CPU_FEATURES (); +# ifdef PI_STATIC_AND_HIDDEN + /* Do static pie self relocation after cpu features are setup. + Code before this point must avoid relocations, which in practice + means no initialized global pointer or ifunc symbol access. */ + _dl_relocate_static_pie (); +# endif + /* Perform IREL{,A} relocations. */ ARCH_SETUP_IREL ();