Message ID | cover.1610986541.git.szabolcs.nagy@arm.com |
---|---|
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 725113846075; Mon, 18 Jan 2021 16:23:10 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 725113846075 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1610986990; bh=AT0XLUcYbFPl9HB6F9Aj/wToeaHzq585sm2FI1hbh30=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=sU4s24CCmfJhuDbtqZBpWPqNmf8GDG/Ut2rEckuEZoA/71EIEoeZyvtR+zCEgogN8 A0X9B7TPFigO3hunfMehrD8KWNrWdn0REKXV1MKIZ4ygOf0UyY9AYYkqcWDvJJO2B7 h5SwzKUASfdQ6G5p/i3I66nXWFH2F4M08y/bzjec= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from EUR04-VI1-obe.outbound.protection.outlook.com (unknown [52.100.19.97]) by sourceware.org (Postfix) with ESMTPS id 5F6AE3858025 for <libc-alpha@sourceware.org>; Mon, 18 Jan 2021 16:23:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5F6AE3858025 Received: from DU2PR04CA0086.eurprd04.prod.outlook.com (2603:10a6:10:232::31) by DBBPR08MB5883.eurprd08.prod.outlook.com (2603:10a6:10:206::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.10; Mon, 18 Jan 2021 16:23:02 +0000 Received: from DB5EUR03FT051.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:232:cafe::c9) by DU2PR04CA0086.outlook.office365.com (2603:10a6:10:232::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.12 via Frontend Transport; Mon, 18 Jan 2021 16:23:02 +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.3763.12 via Frontend Transport; Mon, 18 Jan 2021 16:23:02 +0000 Received: ("Tessian outbound 28c96a6c9d2e:v71"); Mon, 18 Jan 2021 16:23:02 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: c0fad371a58a1738 X-CR-MTA-TID: 64aa7808 Received: from fa12bbb0ab8c.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id D6EE920B-C608-408A-9005-031F8DA12ECA.1; Mon, 18 Jan 2021 16:22:51 +0000 Received: from EUR04-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id fa12bbb0ab8c.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 18 Jan 2021 16:22:51 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aRz+4PTnt6WQtwJvIWI7beyHqgQY8uhe7yprBRYgFucqP/PsyfyDspfuVhaTXn9cTth+TmTeV9ZnZQWO/mbgm2EUqsKf+j2+QQAfg9NPcky3JJdNZnnnQqn6/XeqUiOoWKVtAxC7GhpKVgdmdAVTQRsTI7bJ8p/n4n0RojyEF/uEqYRhegIPHOepzb9rCRJkIKb5CN/KbwfiXp2dGvPUvJuQYUkpC1dW4VNbJhSuEV98P/A3syhNa7IpJK81sXjraUKqj8Notcb2k/ihVni0y4WufKL1iIaqopIVy6NbiJaQ7IdnyQBwOLMFdyRahYPwJdg8xDOmREkKmrmiwlJJuw== 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=AT0XLUcYbFPl9HB6F9Aj/wToeaHzq585sm2FI1hbh30=; b=MnqHLm36IlbB1/QjHQh0L3sHiTvlfB8rspWML6o97ivWXtqZoUBZjrAej6lIxgZmJJfeCrManGK7hrEsqWtiNvaoEtWr2QXRhcDA7df+eFCCfdB5jc3tA3mZDAx2AGIPoZYWFMLmcgsbR5YybpYmyRJOwsfTEN83Ao0Qj8ufogRkUq7rUu0sQWpnD6jgDnkIGQ9XI7oqDVn861xlYUvXBZOd/zb8F0MhMjRHOxXl8IVG1037hiTJ4S61PuiNxdjfCh5r/y7DQY36EwbUuQHCB0r+rBccezH7gNCms65/fsg7XCPJzGX16vQn3WWTxvpqwDtuvlLD4BdQDrsm89VT2g== 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 PA4PR08MB6238.eurprd08.prod.outlook.com (2603:10a6:102:e8::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.11; Mon, 18 Jan 2021 16:22:50 +0000 Received: from PA4PR08MB6320.eurprd08.prod.outlook.com ([fe80::700f:ddbe:a347:ee4f]) by PA4PR08MB6320.eurprd08.prod.outlook.com ([fe80::700f:ddbe:a347:ee4f%7]) with mapi id 15.20.3763.014; Mon, 18 Jan 2021 16:22:50 +0000 To: libc-alpha@sourceware.org Subject: [PATCH v4 00/10] fix ifunc with static pie [BZ #27072] Date: Mon, 18 Jan 2021 16:22:43 +0000 Message-Id: <cover.1610986541.git.szabolcs.nagy@arm.com> X-Mailer: git-send-email 2.17.1 Content-Type: text/plain X-Originating-IP: [217.140.106.54] X-ClientProxiedBy: LO2P123CA0104.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:139::19) 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.54) by LO2P123CA0104.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:139::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.10 via Frontend Transport; Mon, 18 Jan 2021 16:22:49 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 622b2911-8035-419f-60af-08d8bbcd53f7 X-MS-TrafficTypeDiagnostic: PA4PR08MB6238:|DBBPR08MB5883: X-Microsoft-Antispam-PRVS: <DBBPR08MB5883C4BA0D1413D4937F5C4FEDA40@DBBPR08MB5883.eurprd08.prod.outlook.com> x-checkrecipientrouted: true NoDisclaimer: true X-MS-Oob-TLC-OOBClassifiers: OLM:9508;OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: bQVIxb1kh2xO/GH/TfckHnaKUs9hWVP/3BB8akDVKY/JMGgARXgcLHhY4qi4EVp6TZIoJ7tF5MkPT3UX98DYN1LDGc7bxRvznGMTthwMVF5S1DnG7Z/ht+kcGZSTaJab4wLHhn/1ei1BD3BjQbftorF4SHwa/e4gEOQW9nwDU3t42T6iNwdE8prJjGrsacBKCJV4PihvBK5U8/X2wwf+VaIvWyY5gF09KA2vrGRtxE1NHbuU3HUhNdTN51knqcm9Kjb082462h3SKGNbmNciuvRNdebUiOW2IiCe7SPhm9w+s1kfLz4DTjuLYoDnIFzTO0tBUyvyjhRQnwu5KCtz/e3qcIfuYEm64KB1n0PSOjCEp2/f4ypU90lQ57LX52YxEMrt3W9aVV/239rGBdWa7JOtc6QG4uqPUiFHkFoLXJXppgnEDXpS4wTDmsqH2mMuKIegjd0hu3B17R4zn+0VH7G2KQwIlON9LfHLk0LBvhc8EY/qGnFlup4nEhacEVpJLps+vKgSRWX71MZlE/X+S3xPCHZLKb9DQ1xS3o3wMGILCK+y+0TkqvToUTo1HvAYdUaF14Beip/G2o77wnyAqg== 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)(366004)(39850400004)(376002)(396003)(136003)(346002)(83380400001)(6486002)(8676002)(69590400011)(478600001)(6666004)(52116002)(6916009)(316002)(8936002)(66476007)(66556008)(66946007)(5660300002)(86362001)(16526019)(26005)(6512007)(2906002)(186003)(6506007)(956004)(2616005)(36756003)(44832011); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: Hn0TLWlZRtGD+rMfUsTUamARaYyHc78tASZ80wHj2oF8i5Ynos+7hIo+ApYDyZh3hnmRl0TIC8fah5bizZDV8qroH507xDO1746mirP08LcSUYfhZIWO8tthIjKclS7FaqpeIR+tKoDh0+CcCMOxSRVkc71qe3x+tyhf+FQpklIc17ne7T5cbr2PhQ1T/dl6spf3ff8TLqZcJzrfIZ6cBq9CbeuU0O5Cd29oRdTfYTQdCYiGRPDwFzcVGS0qM8DlrRr9F+kIHW86TaozkO6cXcN7l7UlW9ATqb/QoA+e/99/Vop4HhWnS5q11VQoQwe9ba2U02ECm0/ieLwhtoSVZg5stnOIXAj5rPjlD+ootm5DgymfswRTZSayo3PaksTzI3zwubXX1e3XLbX08JEx+2db3DvE6jK56oiOgWxWV5XesGK53mluKp51niroT1RjbVcU8UxkRZv0y4IPQpjtJuuIf39DXJsRoaNepz9S3Z7H4yWeLECIuYqUf2/1JfWLYttIJgOUM2PqBFOIKDRD6nO5TWBVRV/qDS2gSvfOi6iKfvnQLQwPI7Ys/D/n7H+N+ktQqMAzfMKUtkl0Gyw/tCpZrH/hWHbVShvVA99bYiPw2Lk3O4xXoriv6/YUMpWHPkguX3shaF1MvkLuBK0CLLPLFJmdHr83O1lxDcGH84G2RwrQ/tFn6kZ7hsWyU2duAVeOUBmdAGdfU21XvsE1dOU8Dvfixn1Iet16wmsCLSMT/C4NqNzNdHocEQP+s2uwIcNpT5RCsGS4g5fyjC6rEE4HN8+n56gM0xnB78Zo5MY2JA4CTiuIQTEVewpujjX3wMjfUxuLaN4uBgclD8zEQlsBQupZQ7IptYW8P9FVTdWGL+uHpAryFhxtNlyUMQBSqbGlpBOvAkUOUmq/N9GNvHuST6bItv8s4g/xlbON48bdFjbqpdo1GoTdKGRPjY5uDA/kAXQuAfAWWalkrHOBUlFRUfyyBEBPjS3n4YsBap9OX7MZwHxkebJfwgSSKXrA X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR08MB6238 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: 020365d7-dc42-47c9-c0b9-08d8bbcd4c58 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: CP00T+rRhQBWBxAVMBRvPNzGdnLR0Pii1W6dJDCVpsslCiXU3EZbxS+uHo3nU8BxqUVhi7gSMXmKs4yAcqTXrQsjsJ38e8AESV5w12wFBrsXTzTaBt7xbR/DaSdPvINMdCqVn7+Wr+s+C1OBcbJjHw+BGEY0qJVQEJgltFC/y11o0R4Yjj33PuSsrfc6nmAPhLUnn+CeTy+ITR9PwlOfEmtSppPwcHSGEowcx5og7b4YRriw3YTJq2YSca7XDtwfTojr209aFhDZK9wYZEz5LM2ht6MWuziq/FViRU1/ezNy1bf3wrHnqiTJy28f92iLhcFj0ZZJQEsHUFTPmiWGwGEvT+w6GHwIGZlNudBmgsIqwpL4MF4iXxVV32SH/0p7XfNfaxvUHQp9X4F6O3JpAHBrn8BNaH5KwbEZtme9/ESiqpb7FhBRdiENJJjdyjnXRZa8UJ6hoSlS+9V8g+5/l3uxXm3FaVyf6TLTSX0OlBTujGdhkFqSXmJ4LsvDMkl/oMB8tpU2aOTx0aHNc+f2Uq+6zAY8hN9ApxYB+11Y8P4TkkRXM0+3hBC0aQWJixZql5/NP7xFtdPtY2mY4a35SFPk+FXcw6BxUIuj1CKCOY/2DHTO+v5PiyoYj1faPWLs 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)(39850400004)(346002)(136003)(396003)(376002)(46966006)(6512007)(6666004)(36756003)(82310400003)(34010700045)(956004)(83380400001)(2616005)(356005)(336012)(8676002)(2906002)(70206006)(86362001)(316002)(47076005)(82740400003)(26005)(69590400011)(6486002)(6916009)(81166007)(44832011)(70586007)(6506007)(8936002)(16526019)(186003)(5660300002)(478600001); DIR:OUT; SFP:1501; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jan 2021 16:23:02.4266 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 622b2911-8035-419f-60af-08d8bbcd53f7 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: DBBPR08MB5883 X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, MSGID_FROM_MTA_HEADER, RCVD_IN_DNSWL_NONE, 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]
|
|
Message
Szabolcs Nagy
Jan. 18, 2021, 4:22 p.m. UTC
v4: - added patches from H.J.Lu: - x86: fix libmvec tests - x86: fix syscalls in libc_enable_secure - x86: avoid relative reloc for _dl_sysinfo - x86: add ifunc test - i386 cannot mark all symbols hidden, so use fine grain marking in files that participate in early code before static pie self relocation. - the patch that makes all libc symbols hidden is still included: it is now only an optimization for non-i386 targets. v3: - refactor tunables: move internals out of dl-tunables.h - use generated max string length in the tunables list instead of magic values. v2: - check PI_STATIC_AND_HIDDEN for --enable-static-pie - change string buffer sizes in the tunables - fix env_alias == NULL logic in __tunables_init - move __ehdr_start processing after self relocation force pushed into nsz/bug27072 branch. Issues that are not addressed: - tunables try to allocate memory even with non-suid exe. allocation is only needed for rewriting the GLIBC_TUNABLES env var. (i think a case can be made that if anything there is TUNABLE_SECLEVEL_SXID_ERASE then this env var would be simply dropped, that would simplify this significantly). - __sbrk only needs the hidden visibility magic because of tunables, ideally we would not do allocations before self relocation. - tunable list data structure is not optimized for compactness. - all symbols are forced hidden in libc.a, but i think lib*.a should do the same. (other than lib*_nonshared.a) - i386 introduced a fair bit of complications: may be avoiding relative relocs is too much to ask for and relocations should be done in two steps after all: relative first, then irelative when tunable etc are set up. H.J. Lu (4): libmvec: Add extra-test-objs to test-extras elf: Avoid RELATIVE relocation for _dl_sysinfo Use <startup.h> in __libc_init_secure x86: Check ifunc resolver with CPU_FEATURE_USABLE [BZ #27072] Szabolcs Nagy (6): configure: Require PI_STATIC_AND_HIDDEN for static pie elf: Make the tunable struct definition internal only elf: Avoid RELATIVE relocs in __tunables_init Use hidden visibility for early static PIE code csu: Move static pie self relocation later [BZ #27072] Make libc symbols hidden in static PIE configure | 14 +++ configure.ac | 5 + csu/libc-start.c | 48 +++++--- elf/dl-reloc-static-pie.c | 2 + elf/dl-support.c | 18 ++- elf/dl-tunable-types.h | 42 +++++-- elf/dl-tunables.c | 6 +- elf/dl-tunables.h | 35 ++---- elf/enbl-secure.c | 10 +- include/libc-symbols.h | 9 +- misc/sbrk.c | 4 + scripts/gen-tunables.awk | 16 ++- sysdeps/generic/startup.h | 26 ++++ sysdeps/unix/sysv/linux/aarch64/libc-start.c | 5 + sysdeps/unix/sysv/linux/i386/startup.h | 29 ++++- sysdeps/x86/Makefile | 14 +++ sysdeps/x86/libc-start.c | 5 + sysdeps/x86/tst-ifunc-isa-1-static.c | 1 + sysdeps/x86/tst-ifunc-isa-1.c | 115 ++++++++++++++++++ sysdeps/x86/tst-ifunc-isa-2-static.c | 1 + sysdeps/x86/tst-ifunc-isa-2.c | 119 +++++++++++++++++++ sysdeps/x86_64/fpu/Makefile | 8 ++ 22 files changed, 465 insertions(+), 67 deletions(-) create mode 100644 sysdeps/x86/tst-ifunc-isa-1-static.c create mode 100644 sysdeps/x86/tst-ifunc-isa-1.c create mode 100644 sysdeps/x86/tst-ifunc-isa-2-static.c create mode 100644 sysdeps/x86/tst-ifunc-isa-2.c
Comments
As a side note I tried your branch with a build for all support Linux ABIs and it as least improves by issuing an error on architectures where previously indicated support static-pie but it is broken in practice (powerpc for instance [1]) So currently static-pie are support for all architectures, however it fails to build for: alpha-linux-gnu arc-linux-gnuhf hppa-linux-gnu ia64-linux-gnu m68k-linux-gnu microblaze-linux-gnu riscv32-linux-gnu-rv32imafdc-ilp32d riscv64-linux-gnu-rv64imafdc-lp64d s390-linux-gnu sparc64-linux-gnu sparcv9-linux-gnu By requiring PI_STATIC_AND_HIDDEN hppa, m68, microblaze, mips, nios2, and powerpc fail at configure. Some architecture still fails at build: alpha-linux-gnu arc-linux-gnuhf riscv32-linux-gnu-rv32imafdc-ilp32d riscv64-linux-gnu-rv64imafdc-lp64d s390-linux-gnu sparc64-linux-gnu sparcv9-linux-gnu I haven't checked if mips is currently broken for static-pie (since as for powerpc, it does not define PI_STATIC_AND_HIDDEN); but I would expect so. It would be good if we could avoid building the broken configuration and warn it on configure, but I don't think this should be a blocker. The NEWS for 2.27 states this features is only supported for x86 and aarch64, so I wonder if would be better to just enable it for the supported architectures instead of relying on PI_STATIC_AND_HIDDEN. I will finish review the patchset tomorrow. [1] https://bugs.gentoo.org/719444 On 18/01/2021 13:22, Szabolcs Nagy via Libc-alpha wrote: > v4: > - added patches from H.J.Lu: > - x86: fix libmvec tests > - x86: fix syscalls in libc_enable_secure > - x86: avoid relative reloc for _dl_sysinfo > - x86: add ifunc test > - i386 cannot mark all symbols hidden, so use fine grain > marking in files that participate in early code before > static pie self relocation. > - the patch that makes all libc symbols hidden is still > included: it is now only an optimization for non-i386 > targets. > > v3: > - refactor tunables: move internals out of dl-tunables.h > - use generated max string length in the tunables list > instead of magic values. > > v2: > - check PI_STATIC_AND_HIDDEN for --enable-static-pie > - change string buffer sizes in the tunables > - fix env_alias == NULL logic in __tunables_init > - move __ehdr_start processing after self relocation > > > force pushed into nsz/bug27072 branch. > > Issues that are not addressed: > - tunables try to allocate memory even with non-suid exe. > allocation is only needed for rewriting the GLIBC_TUNABLES > env var. (i think a case can be made that if anything there > is TUNABLE_SECLEVEL_SXID_ERASE then this env var would be > simply dropped, that would simplify this significantly). > - __sbrk only needs the hidden visibility magic because of > tunables, ideally we would not do allocations before self > relocation. > - tunable list data structure is not optimized for compactness. > - all symbols are forced hidden in libc.a, but i think lib*.a > should do the same. (other than lib*_nonshared.a) > - i386 introduced a fair bit of complications: may be avoiding > relative relocs is too much to ask for and relocations should > be done in two steps after all: relative first, then irelative > when tunable etc are set up. > > H.J. Lu (4): > libmvec: Add extra-test-objs to test-extras > elf: Avoid RELATIVE relocation for _dl_sysinfo > Use <startup.h> in __libc_init_secure > x86: Check ifunc resolver with CPU_FEATURE_USABLE [BZ #27072] > > Szabolcs Nagy (6): > configure: Require PI_STATIC_AND_HIDDEN for static pie > elf: Make the tunable struct definition internal only > elf: Avoid RELATIVE relocs in __tunables_init > Use hidden visibility for early static PIE code > csu: Move static pie self relocation later [BZ #27072] > Make libc symbols hidden in static PIE > > configure | 14 +++ > configure.ac | 5 + > csu/libc-start.c | 48 +++++--- > elf/dl-reloc-static-pie.c | 2 + > elf/dl-support.c | 18 ++- > elf/dl-tunable-types.h | 42 +++++-- > elf/dl-tunables.c | 6 +- > elf/dl-tunables.h | 35 ++---- > elf/enbl-secure.c | 10 +- > include/libc-symbols.h | 9 +- > misc/sbrk.c | 4 + > scripts/gen-tunables.awk | 16 ++- > sysdeps/generic/startup.h | 26 ++++ > sysdeps/unix/sysv/linux/aarch64/libc-start.c | 5 + > sysdeps/unix/sysv/linux/i386/startup.h | 29 ++++- > sysdeps/x86/Makefile | 14 +++ > sysdeps/x86/libc-start.c | 5 + > sysdeps/x86/tst-ifunc-isa-1-static.c | 1 + > sysdeps/x86/tst-ifunc-isa-1.c | 115 ++++++++++++++++++ > sysdeps/x86/tst-ifunc-isa-2-static.c | 1 + > sysdeps/x86/tst-ifunc-isa-2.c | 119 +++++++++++++++++++ > sysdeps/x86_64/fpu/Makefile | 8 ++ > 22 files changed, 465 insertions(+), 67 deletions(-) > create mode 100644 sysdeps/x86/tst-ifunc-isa-1-static.c > create mode 100644 sysdeps/x86/tst-ifunc-isa-1.c > create mode 100644 sysdeps/x86/tst-ifunc-isa-2-static.c > create mode 100644 sysdeps/x86/tst-ifunc-isa-2.c >
The 01/18/2021 18:37, Adhemerval Zanella wrote: > As a side note I tried your branch with a build for all support Linux > ABIs and it as least improves by issuing an error on architectures > where previously indicated support static-pie but it is broken in practice > (powerpc for instance [1]) > > So currently static-pie are support for all architectures, however it > fails to build for: > > alpha-linux-gnu > arc-linux-gnuhf > hppa-linux-gnu > ia64-linux-gnu > m68k-linux-gnu > microblaze-linux-gnu > riscv32-linux-gnu-rv32imafdc-ilp32d > riscv64-linux-gnu-rv64imafdc-lp64d > s390-linux-gnu > sparc64-linux-gnu > sparcv9-linux-gnu > > By requiring PI_STATIC_AND_HIDDEN hppa, m68, microblaze, mips, nios2, > and powerpc fail at configure. Some architecture still fails at build: > > alpha-linux-gnu > arc-linux-gnuhf > riscv32-linux-gnu-rv32imafdc-ilp32d > riscv64-linux-gnu-rv64imafdc-lp64d > s390-linux-gnu > sparc64-linux-gnu > sparcv9-linux-gnu > > I haven't checked if mips is currently broken for static-pie (since > as for powerpc, it does not define PI_STATIC_AND_HIDDEN); but I would > expect so. > > It would be good if we could avoid building the broken configuration > and warn it on configure, but I don't think this should be a blocker. > The NEWS for 2.27 states this features is only supported for x86 > and aarch64, so I wonder if would be better to just enable it for > the supported architectures instead of relying on PI_STATIC_AND_HIDDEN. i randomly checked alpha, which fails while linking sln: elf/dl-reloc-static-pie.c:40: undefined reference to `_DYNAMIC' i think this should be possible to configure test in case others targets fail in a similar way. > > I will finish review the patchset tomorrow. > > [1] https://bugs.gentoo.org/719444 > > On 18/01/2021 13:22, Szabolcs Nagy via Libc-alpha wrote: > > v4: > > - added patches from H.J.Lu: > > - x86: fix libmvec tests > > - x86: fix syscalls in libc_enable_secure > > - x86: avoid relative reloc for _dl_sysinfo > > - x86: add ifunc test > > - i386 cannot mark all symbols hidden, so use fine grain > > marking in files that participate in early code before > > static pie self relocation. > > - the patch that makes all libc symbols hidden is still > > included: it is now only an optimization for non-i386 > > targets. > > > > v3: > > - refactor tunables: move internals out of dl-tunables.h > > - use generated max string length in the tunables list > > instead of magic values. > > > > v2: > > - check PI_STATIC_AND_HIDDEN for --enable-static-pie > > - change string buffer sizes in the tunables > > - fix env_alias == NULL logic in __tunables_init > > - move __ehdr_start processing after self relocation > > > > > > force pushed into nsz/bug27072 branch. > > > > Issues that are not addressed: > > - tunables try to allocate memory even with non-suid exe. > > allocation is only needed for rewriting the GLIBC_TUNABLES > > env var. (i think a case can be made that if anything there > > is TUNABLE_SECLEVEL_SXID_ERASE then this env var would be > > simply dropped, that would simplify this significantly). > > - __sbrk only needs the hidden visibility magic because of > > tunables, ideally we would not do allocations before self > > relocation. > > - tunable list data structure is not optimized for compactness. > > - all symbols are forced hidden in libc.a, but i think lib*.a > > should do the same. (other than lib*_nonshared.a) > > - i386 introduced a fair bit of complications: may be avoiding > > relative relocs is too much to ask for and relocations should > > be done in two steps after all: relative first, then irelative > > when tunable etc are set up. > > > > H.J. Lu (4): > > libmvec: Add extra-test-objs to test-extras > > elf: Avoid RELATIVE relocation for _dl_sysinfo > > Use <startup.h> in __libc_init_secure > > x86: Check ifunc resolver with CPU_FEATURE_USABLE [BZ #27072] > > > > Szabolcs Nagy (6): > > configure: Require PI_STATIC_AND_HIDDEN for static pie > > elf: Make the tunable struct definition internal only > > elf: Avoid RELATIVE relocs in __tunables_init > > Use hidden visibility for early static PIE code > > csu: Move static pie self relocation later [BZ #27072] > > Make libc symbols hidden in static PIE > > > > configure | 14 +++ > > configure.ac | 5 + > > csu/libc-start.c | 48 +++++--- > > elf/dl-reloc-static-pie.c | 2 + > > elf/dl-support.c | 18 ++- > > elf/dl-tunable-types.h | 42 +++++-- > > elf/dl-tunables.c | 6 +- > > elf/dl-tunables.h | 35 ++---- > > elf/enbl-secure.c | 10 +- > > include/libc-symbols.h | 9 +- > > misc/sbrk.c | 4 + > > scripts/gen-tunables.awk | 16 ++- > > sysdeps/generic/startup.h | 26 ++++ > > sysdeps/unix/sysv/linux/aarch64/libc-start.c | 5 + > > sysdeps/unix/sysv/linux/i386/startup.h | 29 ++++- > > sysdeps/x86/Makefile | 14 +++ > > sysdeps/x86/libc-start.c | 5 + > > sysdeps/x86/tst-ifunc-isa-1-static.c | 1 + > > sysdeps/x86/tst-ifunc-isa-1.c | 115 ++++++++++++++++++ > > sysdeps/x86/tst-ifunc-isa-2-static.c | 1 + > > sysdeps/x86/tst-ifunc-isa-2.c | 119 +++++++++++++++++++ > > sysdeps/x86_64/fpu/Makefile | 8 ++ > > 22 files changed, 465 insertions(+), 67 deletions(-) > > create mode 100644 sysdeps/x86/tst-ifunc-isa-1-static.c > > create mode 100644 sysdeps/x86/tst-ifunc-isa-1.c > > create mode 100644 sysdeps/x86/tst-ifunc-isa-2-static.c > > create mode 100644 sysdeps/x86/tst-ifunc-isa-2.c > >
On Tue, Jan 19, 2021 at 10:25 AM Szabolcs Nagy via Libc-alpha <libc-alpha@sourceware.org> wrote: > > The 01/18/2021 18:37, Adhemerval Zanella wrote: > > As a side note I tried your branch with a build for all support Linux > > ABIs and it as least improves by issuing an error on architectures > > where previously indicated support static-pie but it is broken in practice > > (powerpc for instance [1]) > > > > So currently static-pie are support for all architectures, however it > > fails to build for: > > > > alpha-linux-gnu > > arc-linux-gnuhf > > hppa-linux-gnu > > ia64-linux-gnu > > m68k-linux-gnu > > microblaze-linux-gnu > > riscv32-linux-gnu-rv32imafdc-ilp32d > > riscv64-linux-gnu-rv64imafdc-lp64d > > s390-linux-gnu > > sparc64-linux-gnu > > sparcv9-linux-gnu > > > > By requiring PI_STATIC_AND_HIDDEN hppa, m68, microblaze, mips, nios2, > > and powerpc fail at configure. Some architecture still fails at build: > > > > alpha-linux-gnu > > arc-linux-gnuhf > > riscv32-linux-gnu-rv32imafdc-ilp32d > > riscv64-linux-gnu-rv64imafdc-lp64d > > s390-linux-gnu > > sparc64-linux-gnu > > sparcv9-linux-gnu > > > > I haven't checked if mips is currently broken for static-pie (since > > as for powerpc, it does not define PI_STATIC_AND_HIDDEN); but I would > > expect so. > > > > It would be good if we could avoid building the broken configuration > > and warn it on configure, but I don't think this should be a blocker. > > The NEWS for 2.27 states this features is only supported for x86 > > and aarch64, so I wonder if would be better to just enable it for > > the supported architectures instead of relying on PI_STATIC_AND_HIDDEN. > > i randomly checked alpha, which fails while linking sln: > > elf/dl-reloc-static-pie.c:40: undefined reference to `_DYNAMIC' > > i think this should be possible to configure test in case others > targets fail in a similar way. > Linker must be fixed to support static PIE: https://sourceware.org/bugzilla/show_bug.cgi?id=22269 https://sourceware.org/bugzilla/show_bug.cgi?id=22263 https://sourceware.org/bugzilla/show_bug.cgi?id=21252
On 19/01/2021 16:41, H.J. Lu wrote: > On Tue, Jan 19, 2021 at 10:25 AM Szabolcs Nagy via Libc-alpha > <libc-alpha@sourceware.org> wrote: >> >> The 01/18/2021 18:37, Adhemerval Zanella wrote: >>> As a side note I tried your branch with a build for all support Linux >>> ABIs and it as least improves by issuing an error on architectures >>> where previously indicated support static-pie but it is broken in practice >>> (powerpc for instance [1]) >>> >>> So currently static-pie are support for all architectures, however it >>> fails to build for: >>> >>> alpha-linux-gnu >>> arc-linux-gnuhf >>> hppa-linux-gnu >>> ia64-linux-gnu >>> m68k-linux-gnu >>> microblaze-linux-gnu >>> riscv32-linux-gnu-rv32imafdc-ilp32d >>> riscv64-linux-gnu-rv64imafdc-lp64d >>> s390-linux-gnu >>> sparc64-linux-gnu >>> sparcv9-linux-gnu >>> >>> By requiring PI_STATIC_AND_HIDDEN hppa, m68, microblaze, mips, nios2, >>> and powerpc fail at configure. Some architecture still fails at build: >>> >>> alpha-linux-gnu >>> arc-linux-gnuhf >>> riscv32-linux-gnu-rv32imafdc-ilp32d >>> riscv64-linux-gnu-rv64imafdc-lp64d >>> s390-linux-gnu >>> sparc64-linux-gnu >>> sparcv9-linux-gnu >>> >>> I haven't checked if mips is currently broken for static-pie (since >>> as for powerpc, it does not define PI_STATIC_AND_HIDDEN); but I would >>> expect so. >>> >>> It would be good if we could avoid building the broken configuration >>> and warn it on configure, but I don't think this should be a blocker. >>> The NEWS for 2.27 states this features is only supported for x86 >>> and aarch64, so I wonder if would be better to just enable it for >>> the supported architectures instead of relying on PI_STATIC_AND_HIDDEN. >> >> i randomly checked alpha, which fails while linking sln: >> >> elf/dl-reloc-static-pie.c:40: undefined reference to `_DYNAMIC' >> >> i think this should be possible to configure test in case others >> targets fail in a similar way. >> > > Linker must be fixed to support static PIE: > > https://sourceware.org/bugzilla/show_bug.cgi?id=22269 > https://sourceware.org/bugzilla/show_bug.cgi?id=22263 > https://sourceware.org/bugzilla/show_bug.cgi?id=21252 My question is which is the correct way to check at configure time for this support? Currently this patchset added the PI_STATIC_AND_HIDDEN, which is set by each configure snipper within glibc.
On Tue, Jan 19, 2021 at 12:16 PM Adhemerval Zanella <adhemerval.zanella@linaro.org> wrote: > > > > On 19/01/2021 16:41, H.J. Lu wrote: > > On Tue, Jan 19, 2021 at 10:25 AM Szabolcs Nagy via Libc-alpha > > <libc-alpha@sourceware.org> wrote: > >> > >> The 01/18/2021 18:37, Adhemerval Zanella wrote: > >>> As a side note I tried your branch with a build for all support Linux > >>> ABIs and it as least improves by issuing an error on architectures > >>> where previously indicated support static-pie but it is broken in practice > >>> (powerpc for instance [1]) > >>> > >>> So currently static-pie are support for all architectures, however it > >>> fails to build for: > >>> > >>> alpha-linux-gnu > >>> arc-linux-gnuhf > >>> hppa-linux-gnu > >>> ia64-linux-gnu > >>> m68k-linux-gnu > >>> microblaze-linux-gnu > >>> riscv32-linux-gnu-rv32imafdc-ilp32d > >>> riscv64-linux-gnu-rv64imafdc-lp64d > >>> s390-linux-gnu > >>> sparc64-linux-gnu > >>> sparcv9-linux-gnu > >>> > >>> By requiring PI_STATIC_AND_HIDDEN hppa, m68, microblaze, mips, nios2, > >>> and powerpc fail at configure. Some architecture still fails at build: > >>> > >>> alpha-linux-gnu > >>> arc-linux-gnuhf > >>> riscv32-linux-gnu-rv32imafdc-ilp32d > >>> riscv64-linux-gnu-rv64imafdc-lp64d > >>> s390-linux-gnu > >>> sparc64-linux-gnu > >>> sparcv9-linux-gnu > >>> > >>> I haven't checked if mips is currently broken for static-pie (since > >>> as for powerpc, it does not define PI_STATIC_AND_HIDDEN); but I would > >>> expect so. > >>> > >>> It would be good if we could avoid building the broken configuration > >>> and warn it on configure, but I don't think this should be a blocker. > >>> The NEWS for 2.27 states this features is only supported for x86 > >>> and aarch64, so I wonder if would be better to just enable it for > >>> the supported architectures instead of relying on PI_STATIC_AND_HIDDEN. > >> > >> i randomly checked alpha, which fails while linking sln: > >> > >> elf/dl-reloc-static-pie.c:40: undefined reference to `_DYNAMIC' > >> > >> i think this should be possible to configure test in case others > >> targets fail in a similar way. > >> > > > > Linker must be fixed to support static PIE: > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=22269 > > https://sourceware.org/bugzilla/show_bug.cgi?id=22263 > > https://sourceware.org/bugzilla/show_bug.cgi?id=21252 > > My question is which is the correct way to check at configure time > for this support? Currently this patchset added the PI_STATIC_AND_HIDDEN, > which is set by each configure snipper within glibc. Add and define SUPPORT_STATIC_PIE for x86 and aarch64. Other targets can opt-in.
On 19/01/2021 18:38, H.J. Lu wrote: > On Tue, Jan 19, 2021 at 12:16 PM Adhemerval Zanella > <adhemerval.zanella@linaro.org> wrote: >> >> >> >> On 19/01/2021 16:41, H.J. Lu wrote: >>> On Tue, Jan 19, 2021 at 10:25 AM Szabolcs Nagy via Libc-alpha >>> <libc-alpha@sourceware.org> wrote: >>>> >>>> The 01/18/2021 18:37, Adhemerval Zanella wrote: >>>>> As a side note I tried your branch with a build for all support Linux >>>>> ABIs and it as least improves by issuing an error on architectures >>>>> where previously indicated support static-pie but it is broken in practice >>>>> (powerpc for instance [1]) >>>>> >>>>> So currently static-pie are support for all architectures, however it >>>>> fails to build for: >>>>> >>>>> alpha-linux-gnu >>>>> arc-linux-gnuhf >>>>> hppa-linux-gnu >>>>> ia64-linux-gnu >>>>> m68k-linux-gnu >>>>> microblaze-linux-gnu >>>>> riscv32-linux-gnu-rv32imafdc-ilp32d >>>>> riscv64-linux-gnu-rv64imafdc-lp64d >>>>> s390-linux-gnu >>>>> sparc64-linux-gnu >>>>> sparcv9-linux-gnu >>>>> >>>>> By requiring PI_STATIC_AND_HIDDEN hppa, m68, microblaze, mips, nios2, >>>>> and powerpc fail at configure. Some architecture still fails at build: >>>>> >>>>> alpha-linux-gnu >>>>> arc-linux-gnuhf >>>>> riscv32-linux-gnu-rv32imafdc-ilp32d >>>>> riscv64-linux-gnu-rv64imafdc-lp64d >>>>> s390-linux-gnu >>>>> sparc64-linux-gnu >>>>> sparcv9-linux-gnu >>>>> >>>>> I haven't checked if mips is currently broken for static-pie (since >>>>> as for powerpc, it does not define PI_STATIC_AND_HIDDEN); but I would >>>>> expect so. >>>>> >>>>> It would be good if we could avoid building the broken configuration >>>>> and warn it on configure, but I don't think this should be a blocker. >>>>> The NEWS for 2.27 states this features is only supported for x86 >>>>> and aarch64, so I wonder if would be better to just enable it for >>>>> the supported architectures instead of relying on PI_STATIC_AND_HIDDEN. >>>> >>>> i randomly checked alpha, which fails while linking sln: >>>> >>>> elf/dl-reloc-static-pie.c:40: undefined reference to `_DYNAMIC' >>>> >>>> i think this should be possible to configure test in case others >>>> targets fail in a similar way. >>>> >>> >>> Linker must be fixed to support static PIE: >>> >>> https://sourceware.org/bugzilla/show_bug.cgi?id=22269 >>> https://sourceware.org/bugzilla/show_bug.cgi?id=22263 >>> https://sourceware.org/bugzilla/show_bug.cgi?id=21252 >> >> My question is which is the correct way to check at configure time >> for this support? Currently this patchset added the PI_STATIC_AND_HIDDEN, >> which is set by each configure snipper within glibc. > > Add and define SUPPORT_STATIC_PIE for x86 and aarch64. Other > targets can opt-in. I was expecting a way without an extra flag, but I think for now it should be suffice.
The 01/20/2021 08:29, Adhemerval Zanella wrote: > On 19/01/2021 18:38, H.J. Lu wrote: > > On Tue, Jan 19, 2021 at 12:16 PM Adhemerval Zanella > > <adhemerval.zanella@linaro.org> wrote: > >> On 19/01/2021 16:41, H.J. Lu wrote: > >>> Linker must be fixed to support static PIE: > >>> > >>> https://sourceware.org/bugzilla/show_bug.cgi?id=22269 > >>> https://sourceware.org/bugzilla/show_bug.cgi?id=22263 > >>> https://sourceware.org/bugzilla/show_bug.cgi?id=21252 > >> > >> My question is which is the correct way to check at configure time > >> for this support? Currently this patchset added the PI_STATIC_AND_HIDDEN, > >> which is set by each configure snipper within glibc. > > > > Add and define SUPPORT_STATIC_PIE for x86 and aarch64. Other > > targets can opt-in. > > I was expecting a way without an extra flag, but I think for now it > should be suffice. i can add the flag but when a target adds support there will be no check if the used linker is new enough.
On Wed, Jan 20, 2021 at 4:38 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote: > > The 01/20/2021 08:29, Adhemerval Zanella wrote: > > On 19/01/2021 18:38, H.J. Lu wrote: > > > On Tue, Jan 19, 2021 at 12:16 PM Adhemerval Zanella > > > <adhemerval.zanella@linaro.org> wrote: > > >> On 19/01/2021 16:41, H.J. Lu wrote: > > >>> Linker must be fixed to support static PIE: > > >>> > > >>> https://sourceware.org/bugzilla/show_bug.cgi?id=22269 > > >>> https://sourceware.org/bugzilla/show_bug.cgi?id=22263 > > >>> https://sourceware.org/bugzilla/show_bug.cgi?id=21252 > > >> > > >> My question is which is the correct way to check at configure time > > >> for this support? Currently this patchset added the PI_STATIC_AND_HIDDEN, > > >> which is set by each configure snipper within glibc. > > > > > > Add and define SUPPORT_STATIC_PIE for x86 and aarch64. Other > > > targets can opt-in. > > > > I was expecting a way without an extra flag, but I think for now it > > should be suffice. > > i can add the flag but when a target adds support there > will be no check if the used linker is new enough. The minimum link should work for x86 and aarch64. But if linker fixes are needed for other targets, they should add the linker check.