Message ID | 90d6dfb05675c96e1f4cd35187d2fb783fc00204.1594209990.git.szabolcs.nagy@arm.com |
---|---|
State | Committed |
Commit | a2a83bf6d9f1d4d297c5378f0fda0d8f85bc75f2 |
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 27B7338618FF; Wed, 8 Jul 2020 12:15:01 +0000 (GMT) X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20081.outbound.protection.outlook.com [40.107.2.81]) by sourceware.org (Postfix) with ESMTPS id 930953861843 for <libc-alpha@sourceware.org>; Wed, 8 Jul 2020 12:14:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 930953861843 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=Szabolcs.Nagy@arm.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E4xInZUS3InrnwaukwkcAhAbeCfvGs4aGkN56jP3PsY=; b=QYCpEQi8Bd5oJTbQh3rm4gOLH1vY0mvSE2GKPI3tZnN8lqbGQUZ8EYofnFJBT7J1EeOUoK71yJi76SepvICqz2wWx9H8Ukv1+ILWyPgT3UmrSNhJ1rlok5usHuZVh76ZJHr3KgWAcJcLIl8PqOtRC+mJWBw7+0ngewMRcBtuQtE= Received: from AM5PR0202CA0004.eurprd02.prod.outlook.com (2603:10a6:203:69::14) by VI1PR08MB2943.eurprd08.prod.outlook.com (2603:10a6:802:23::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.20; Wed, 8 Jul 2020 12:14:55 +0000 Received: from VE1EUR03FT004.eop-EUR03.prod.protection.outlook.com (2603:10a6:203:69:cafe::98) by AM5PR0202CA0004.outlook.office365.com (2603:10a6:203:69::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.20 via Frontend Transport; Wed, 8 Jul 2020 12:14:55 +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=bestguesspass 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 VE1EUR03FT004.mail.protection.outlook.com (10.152.18.106) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.21 via Frontend Transport; Wed, 8 Jul 2020 12:14:55 +0000 Received: ("Tessian outbound b8ad5ab47c8c:v62"); Wed, 08 Jul 2020 12:14:54 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: d6f5dece7d1ab600 X-CR-MTA-TID: 64aa7808 Received: from 82b932ec01b4.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id E5913145-C8C0-4EF0-9BA5-3317A7010FB5.1; Wed, 08 Jul 2020 12:14:49 +0000 Received: from EUR04-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 82b932ec01b4.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 08 Jul 2020 12:14:49 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RTovpAuOjptw3qg6I1RrLlPLtbvyMAiDlRUYqsO248KiT7wvi8t7S+jL17kNsaUiIduHhiQZc7p4/cw177rkr+KZk9AC2d77lFFWNk7ognOa2+GE+UvBL0V7Q4WD72pk6/MwVCYUi/NvyYg6nFLwh0KMSlIIqlrpAuTOOlIHLE1VU4gNONkRBw2YUqnXWx/fDax//Bu5ZJzm7T+lUHQGEZ9KSrbaRNc/zineJw/Co4OUiFzVz7wP+huIeZldjI2A9NO/5QLuKMSmLtX5V3ZzlrB9OUI+AAuPYwM1bT8JRWqGPZtJdtkslLkMtmSkYKHhZCp2CJVUYGFONQFsdoa6WQ== 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=E4xInZUS3InrnwaukwkcAhAbeCfvGs4aGkN56jP3PsY=; b=M4sLn4Mm2ZN162pP2bOePnMSWSR1uAZ00QKMZMmK1xHaSrURymmNQ97fmnx54to36DlYyB/YfSAwwWZFpTNz3zF7bl9nBSOOzM+DPE9TF1Ik9HTHef2dce4gkZSx7QpuTwSZzZxlvfFSaWHQRL7f2SLf05ZrMBm1da/UfwOfAS4TSe8aSRsvOppZo1Zzw6p8fQWwP+StSRRr2CwreTew47d8dS7oNXUx8Kn1ojhiVuNu1oJu7+W6lp8WXIzOn4yjBjoCzNltIZLN6wX0+LBvhEs8pIL0BohQmLtbG1hWb3yW0BXEjdwEfRiBlzwi/kSDeAcJ/G3EQ2HwMmTUqU01Jw== 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E4xInZUS3InrnwaukwkcAhAbeCfvGs4aGkN56jP3PsY=; b=QYCpEQi8Bd5oJTbQh3rm4gOLH1vY0mvSE2GKPI3tZnN8lqbGQUZ8EYofnFJBT7J1EeOUoK71yJi76SepvICqz2wWx9H8Ukv1+ILWyPgT3UmrSNhJ1rlok5usHuZVh76ZJHr3KgWAcJcLIl8PqOtRC+mJWBw7+0ngewMRcBtuQtE= 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 AM6PR08MB3047.eurprd08.prod.outlook.com (2603:10a6:209:4c::23) by AM7PR08MB5527.eurprd08.prod.outlook.com (2603:10a6:20b:de::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.28; Wed, 8 Jul 2020 12:14:48 +0000 Received: from AM6PR08MB3047.eurprd08.prod.outlook.com ([fe80::2404:de9f:78c0:313c]) by AM6PR08MB3047.eurprd08.prod.outlook.com ([fe80::2404:de9f:78c0:313c%6]) with mapi id 15.20.3153.031; Wed, 8 Jul 2020 12:14:48 +0000 From: Szabolcs Nagy <szabolcs.nagy@arm.com> To: libc-alpha@sourceware.org Subject: [PATCH v7 14/14] aarch64: add NEWS entry about branch protection support Date: Wed, 8 Jul 2020 13:14:41 +0100 Message-Id: <90d6dfb05675c96e1f4cd35187d2fb783fc00204.1594209990.git.szabolcs.nagy@arm.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <cover.1594209990.git.szabolcs.nagy@arm.com> References: <cover.1594209990.git.szabolcs.nagy@arm.com> Content-Type: text/plain X-ClientProxiedBy: LO2P265CA0138.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9f::30) To AM6PR08MB3047.eurprd08.prod.outlook.com (2603:10a6:209:4c::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost.localdomain (217.140.106.53) by LO2P265CA0138.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9f::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.23 via Frontend Transport; Wed, 8 Jul 2020 12:14:47 +0000 X-Mailer: git-send-email 2.17.1 X-Originating-IP: [217.140.106.53] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: bb9366cd-bce6-490d-1a47-08d82338864c X-MS-TrafficTypeDiagnostic: AM7PR08MB5527:|VI1PR08MB2943: X-Microsoft-Antispam-PRVS: <VI1PR08MB29434AFD35CBDD0830CDF395ED670@VI1PR08MB2943.eurprd08.prod.outlook.com> x-checkrecipientrouted: true NoDisclaimer: true X-MS-Oob-TLC-OOBClassifiers: OLM:8882;OLM:8882; X-Forefront-PRVS: 04583CED1A X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: zlzLHXc0+xuHnJerVKzPhAlL4TFc1TFjti0ZU6X7H8QvA7Hw1g4w0g+feqGbG2/PvPuMgHHJB58XDPZvkrwSb4YEZvQPqD2k3AcQfU7voKRXPQK0jPGKBFKEtCU3B9O09zM6nZwMQL/hQZfhBahE3QCdJM4rcNnO0AD5C11+EKvvlu9PrE6xjcOTN21GgUiZy9giRhWlmol5Ad2ylULEe17TfWdQGsTrkJSfQHhQfJurrER3waDNmu3/wferUlLAQC1EnxTkJtUhov+RsHe+aut9r3ruEIHmjc8YPmAnzPJix1Zh0bMd2K2hXMgyYsPbHN0IB3uxIL7IlibormL+XV0JO0YVn/nr/tyVi98XhfBQ2/F+gFFe0JvdEBOIF6LLgjHX2wFzSMLK4eowJJkYj4YLz6bmlk7rW6onVcIUvLs= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB3047.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39860400002)(396003)(376002)(346002)(366004)(8676002)(478600001)(6506007)(2616005)(956004)(8936002)(44832011)(16526019)(2906002)(186003)(26005)(36756003)(66476007)(66556008)(6916009)(316002)(66946007)(6666004)(5660300002)(83380400001)(86362001)(69590400007)(6512007)(6486002)(52116002)(136400200001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: qJ0Oiyh2E0jafHLaqPkPVOqGgHmg/hwcDcxQUZHRs4H+8qI51+QyoqVI6J6c8gFMwjUvymK4sgc+Wh0MmmaYhnoFRQiPbpqn9btx3y8QMolTc/V27TBbOBSpAr0IRABF1tw9tEVQeSGz6isBPosKh5ulAaGYUDhXGoVdLxWumcDSLY29O6xAwDF7lFfViOE2wnhjD+KbPQIgQAhk+LC1JzQIEb7kX3VpsWIveYWmWueKLtEuyirwG7hHViFVcL6ylrzUJtxWH7a5Fx8+Rgwguikfj0lBVaEoq0zrb5YlqpBQWVMal95lC3KLXfMFKaBStIA2WAulJsd5CAV22bsfqOjDaFqWtwgZOKrnydCuVymyoijoy1FfTqaLsIAY4rm5Bukrzw1Z1LcceO2cwR6Ty/hagJViWEBQQVhCHpORVe06KvqyYR936t3HRBZY7aeRKdssQ+2Wj6Vso3q3RoNHX5Aozg9WBrATt6LEeHom6U4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR08MB5527 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: VE1EUR03FT004.eop-EUR03.prod.protection.outlook.com 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; SFTY:; SFS:(4636009)(346002)(136003)(376002)(396003)(39860400002)(46966005)(186003)(16526019)(6512007)(2906002)(6506007)(8936002)(26005)(83380400001)(44832011)(8676002)(478600001)(36906005)(2616005)(956004)(6916009)(82740400003)(356005)(82310400002)(6486002)(336012)(81166007)(316002)(47076004)(70206006)(36756003)(5660300002)(6666004)(86362001)(70586007)(69590400007)(136400200001); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 332f5e72-9d5a-439c-6b3e-08d823388205 X-Forefront-PRVS: 04583CED1A X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: hUeqXHDiKCLj1yA7wpSn/pcBdp5v0hzlRDYDMR2jLC+HPM9CCf2XSwFjYjrgNfg0G1dYFZTMMJ03nWvqcxBueB01zd5hNNUrK9vg2CHOIO7cOgczrn/gGQtbS12rbNJh4AGUNEvElRx/Y9AviuChM9w5tRTDoWcVsG6rKr6C0ELK7xKreq95iI0Z+BJNtidrQdAARYJhUsLr5r/S2q1CqynpV0F5bfknAqlRODhLV4xxnPhLcpb60j5Y5iJek7cIcGfeP+RflWGaigqT2wjs1Pi1sK6cVLWKKxkRCy9eo5sy/TxDKO0bHmz6k2yTdaJ06/8GuEZw7nTv8mgkCoJZND8LLoLEcSmMBhrHqSWw556C1QezpBhJWGQgkcnEb90Lm1Wmn7z4jqoK08LkSc3BFjKrVAq2YqfWAtCRkU6tD7OANSkOMkcW4nCaolbXOtm8BMzieROwavM6DGFpW+Oo2Q== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jul 2020 12:14:55.0070 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: bb9366cd-bce6-490d-1a47-08d82338864c 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: VE1EUR03FT004.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB2943 X-Spam-Status: No, score=-16.0 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: <http://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: <http://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces@sourceware.org> |
Series |
aarch64: branch protection support
|
|
Commit Message
Szabolcs Nagy
July 8, 2020, 12:14 p.m. UTC
This is a new security feature that relies on architecture extensions and needs glibc to be built with a gcc configured with branch protection. --- NEWS | 11 +++++++++++ 1 file changed, 11 insertions(+)
Comments
On 08/07/2020 09:14, Szabolcs Nagy wrote: > This is a new security feature that relies on architecture > extensions and needs glibc to be built with a gcc configured > with branch protection. LGTM, thanks. I think I have acked patches, is there still a missing one? Otherwise I think the patchset it ok to be pushed upstream. > --- > NEWS | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/NEWS b/NEWS > index d7282b4ad5..5083f5eacf 100644 > --- a/NEWS > +++ b/NEWS > @@ -67,6 +67,17 @@ Major new features: > They should be used instead of sys_errlist and sys_nerr, both are > thread and async-signal safe. These functions are GNU extensions. > > +* AArch64 now supports standard branch protection security hardening > + in glibc when it is built with a GCC that is configured with > + --enable-standard-branch-protection. This includes branch target > + identification (BTI) and pointer authentication for return addresses > + (PAC-RET). They require armv8.5-a and armv8.3-a architecture > + extensions respectively for the protection to be effective, > + otherwise the used instructions are nops. User code can use PAC-RET > + without libc support, but BTI requires a libc that is built with BTI > + support, otherwise runtime objects linked into user code will not be > + BTI compatible. > + > Deprecated and removed features, and other changes affecting compatibility: > > * The deprecated <sys/sysctl.h> header and the sysctl function have been > Ok.
The 07/08/2020 10:48, Adhemerval Zanella wrote: > On 08/07/2020 09:14, Szabolcs Nagy wrote: > > This is a new security feature that relies on architecture > > extensions and needs glibc to be built with a gcc configured > > with branch protection. > > LGTM, thanks. I think I have acked patches, is there still a missing one? > Otherwise I think the patchset it ok to be pushed upstream. thanks, pushed the series.
* Szabolcs Nagy: > +* AArch64 now supports standard branch protection security hardening > + in glibc when it is built with a GCC that is configured with > + --enable-standard-branch-protection. This includes branch target > + identification (BTI) and pointer authentication for return addresses > + (PAC-RET). They require armv8.5-a and armv8.3-a architecture > + extensions respectively for the protection to be effective, > + otherwise the used instructions are nops. User code can use PAC-RET > + without libc support, but BTI requires a libc that is built with BTI > + support, otherwise runtime objects linked into user code will not be > + BTI compatible. How can I test whether GCC has been built with --enable-standard-branch-protection? We have a Fedora change for this: <https://fedoraproject.org/wiki/Changes/Aarch64_PointerAuthentication> But no GCC update has been submitted for it, and we have not adjust our glibc build accordingly. It also doesn't look like libc_nonshared.a is built correctly for this. In particular, __libc_csu_init (which is linked statically into every program) does not have any BTI+PAC marker instructions, as far as I can see: 0000000000000000 <__libc_csu_init>: 0: stp x29, x30, [sp, #-64]! 4: mov x29, sp 8: stp x19, x20, [sp, #16] c: adrp x20, 0 <__init_array_end> c: R_AARCH64_ADR_PREL_PG_HI21 __init_array_end 10: add x20, x20, #0x0 10: R_AARCH64_ADD_ABS_LO12_NC __init_array_end 14: stp x21, x22, [sp, #32] 18: adrp x21, 0 <__init_array_start> 18: R_AARCH64_ADR_PREL_PG_HI21 __init_array_start 1c: add x21, x21, #0x0 1c: R_AARCH64_ADD_ABS_LO12_NC __init_array_start 20: sub x20, x20, x21 24: mov w22, w0 28: stp x23, x24, [sp, #48] 2c: mov x23, x1 30: mov x24, x2 34: asr x20, x20, #3 38: bl 0 <_init> 38: R_AARCH64_CALL26 _init 3c: cbz x20, 68 <__libc_csu_init+0x68> 40: mov x19, #0x0 // #0 44: nop 48: ldr x3, [x21, x19, lsl #3] 4c: mov x2, x24 50: add x19, x19, #0x1 54: mov x1, x23 58: mov w0, w22 5c: blr x3 60: cmp x20, x19 64: b.ne 48 <__libc_csu_init+0x48> // b.any 68: ldp x19, x20, [sp, #16] 6c: ldp x21, x22, [sp, #32] 70: ldp x23, x24, [sp, #48] 74: ldp x29, x30, [sp], #64 78: ret 7c: nop Is there an alternative to enabling this for glibc (and elsewhere) without a special build of GCC? Or will this still not work because without --enable-standard-branch-protection for GCC, libgcc.a is not ready? Thanks, Florian
The 07/24/2020 09:19, Florian Weimer wrote: > * Szabolcs Nagy: > > +* AArch64 now supports standard branch protection security hardening > > + in glibc when it is built with a GCC that is configured with > > + --enable-standard-branch-protection. This includes branch target > > + identification (BTI) and pointer authentication for return addresses > > + (PAC-RET). They require armv8.5-a and armv8.3-a architecture > > + extensions respectively for the protection to be effective, > > + otherwise the used instructions are nops. User code can use PAC-RET > > + without libc support, but BTI requires a libc that is built with BTI > > + support, otherwise runtime objects linked into user code will not be > > + BTI compatible. > > How can I test whether GCC has been built with > --enable-standard-branch-protection? unfortunately in gcc-10.1 and <= gcc-9.3 there was no easy check for this, that's why i have complicated configure tests for it in glibc: right now you need to link some program that uses gcc target objects and see if it has the property notes, in gcc-10.2 i added the acle macros https://developer.arm.com/documentation/101028/0011/Feature-test-macros?lang=en __ARM_FEATURE_DEFAULT_BTI __ARM_FEATURE_DEFAULT_PAC which are set when the code is compiled with -mbranch-protection=bti|pac-ret|standard so at least the code generation can be checked. > > We have a Fedora change for this: > > <https://fedoraproject.org/wiki/Changes/Aarch64_PointerAuthentication> > > But no GCC update has been submitted for it, and we have not adjust our > glibc build accordingly. > > It also doesn't look like libc_nonshared.a is built correctly for this. > In particular, __libc_csu_init (which is linked statically into every > program) does not have any BTI+PAC marker instructions, as far as I can > see: > > 0000000000000000 <__libc_csu_init>: > 0: stp x29, x30, [sp, #-64]! > 4: mov x29, sp > 8: stp x19, x20, [sp, #16] > c: adrp x20, 0 <__init_array_end> > c: R_AARCH64_ADR_PREL_PG_HI21 __init_array_end > 10: add x20, x20, #0x0 > 10: R_AARCH64_ADD_ABS_LO12_NC __init_array_end > 14: stp x21, x22, [sp, #32] > 18: adrp x21, 0 <__init_array_start> > 18: R_AARCH64_ADR_PREL_PG_HI21 __init_array_start > 1c: add x21, x21, #0x0 > 1c: R_AARCH64_ADD_ABS_LO12_NC __init_array_start > 20: sub x20, x20, x21 > 24: mov w22, w0 > 28: stp x23, x24, [sp, #48] > 2c: mov x23, x1 > 30: mov x24, x2 > 34: asr x20, x20, #3 > 38: bl 0 <_init> > 38: R_AARCH64_CALL26 _init > 3c: cbz x20, 68 <__libc_csu_init+0x68> > 40: mov x19, #0x0 // #0 > 44: nop > 48: ldr x3, [x21, x19, lsl #3] > 4c: mov x2, x24 > 50: add x19, x19, #0x1 > 54: mov x1, x23 > 58: mov w0, w22 > 5c: blr x3 > 60: cmp x20, x19 > 64: b.ne 48 <__libc_csu_init+0x48> // b.any > 68: ldp x19, x20, [sp, #16] > 6c: ldp x21, x22, [sp, #32] > 70: ldp x23, x24, [sp, #48] > 74: ldp x29, x30, [sp], #64 > 78: ret > 7c: nop gcc-10.1 with --enable-standard-branch-protection gives me 0000000000000000 <__libc_csu_init>: 0: d503233f paciasp 4: a9bc7bfd stp x29, x30, [sp, #-64]! 8: 910003fd mov x29, sp c: a90153f3 stp x19, x20, [sp, #16] 10: 90000014 adrp x20, 0 <__init_array_end> 10: R_AARCH64_ADR_PREL_PG_HI21 __init_array_end 14: 91000294 add x20, x20, #0x0 14: R_AARCH64_ADD_ABS_LO12_NC __init_array_end 18: a9025bf5 stp x21, x22, [sp, #32] 1c: 90000015 adrp x21, 0 <__init_array_start> 1c: R_AARCH64_ADR_PREL_PG_HI21 __init_array_start 20: 910002b5 add x21, x21, #0x0 20: R_AARCH64_ADD_ABS_LO12_NC __init_array_start 24: cb150294 sub x20, x20, x21 28: 2a0003f6 mov w22, w0 2c: a90363f7 stp x23, x24, [sp, #48] 30: aa0103f7 mov x23, x1 34: aa0203f8 mov x24, x2 38: 9343fe94 asr x20, x20, #3 3c: 94000000 bl 0 <_init> 3c: R_AARCH64_CALL26 _init 40: b4000154 cbz x20, 68 <__libc_csu_init+0x68> 44: d2800013 mov x19, #0x0 // #0 48: f8737aa3 ldr x3, [x21, x19, lsl #3] 4c: aa1803e2 mov x2, x24 50: 91000673 add x19, x19, #0x1 54: aa1703e1 mov x1, x23 58: 2a1603e0 mov w0, w22 5c: d63f0060 blr x3 60: eb13029f cmp x20, x19 64: 54ffff21 b.ne 48 <__libc_csu_init+0x48> // b.any 68: a94153f3 ldp x19, x20, [sp, #16] 6c: a9425bf5 ldp x21, x22, [sp, #32] 70: a94363f7 ldp x23, x24, [sp, #48] 74: a8c47bfd ldp x29, x30, [sp], #64 78: d50323bf autiasp 7c: d65f03c0 ret > > Is there an alternative to enabling this for glibc (and elsewhere) > without a special build of GCC? Or will this still not work because > without --enable-standard-branch-protection for GCC, libgcc.a is not > ready? i require --enable-standard-branch-protection exactly because gcc target libs and crt files are not branch protected by default, this can change later (always build target libs with branch protection), but i consider it risky given that the pac-ret instructions can be mishandled by custom unwinders who don't know the new dwarf op code for it or tools that don't understand the gnu property notes (note handling in binutils can be checked at gcc build time, but other things cannot be, so there will be some risk when using a gcc with branch-protection and it will take some time to find the issues given the lack of hardware)
* Szabolcs Nagy: > i require --enable-standard-branch-protection exactly > because gcc target libs and crt files are not branch > protected by default, this can change later (always > build target libs with branch protection), but i > consider it risky given that the pac-ret instructions > can be mishandled by custom unwinders who don't know > the new dwarf op code for it or tools that don't > understand the gnu property notes (note handling in > binutils can be checked at gcc build time, but other > things cannot be, so there will be some risk when using > a gcc with branch-protection and it will take some time > to find the issues given the lack of hardware) Okay, then the NEWS entry is appriate, and we did not follow the required steps for enabling this feature in Fedora 33. 8-( Thanks, Florian
diff --git a/NEWS b/NEWS index d7282b4ad5..5083f5eacf 100644 --- a/NEWS +++ b/NEWS @@ -67,6 +67,17 @@ Major new features: They should be used instead of sys_errlist and sys_nerr, both are thread and async-signal safe. These functions are GNU extensions. +* AArch64 now supports standard branch protection security hardening + in glibc when it is built with a GCC that is configured with + --enable-standard-branch-protection. This includes branch target + identification (BTI) and pointer authentication for return addresses + (PAC-RET). They require armv8.5-a and armv8.3-a architecture + extensions respectively for the protection to be effective, + otherwise the used instructions are nops. User code can use PAC-RET + without libc support, but BTI requires a libc that is built with BTI + support, otherwise runtime objects linked into user code will not be + BTI compatible. + Deprecated and removed features, and other changes affecting compatibility: * The deprecated <sys/sysctl.h> header and the sysctl function have been