Message ID | 20200729080850.26078-1-szabolcs.nagy@arm.com |
---|---|
State | Committed |
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 778D13857C5F; Wed, 29 Jul 2020 08:09:16 +0000 (GMT) X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140055.outbound.protection.outlook.com [40.107.14.55]) by sourceware.org (Postfix) with ESMTPS id 45FEC3858D35 for <libc-alpha@sourceware.org>; Wed, 29 Jul 2020 08:09:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 45FEC3858D35 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=r7dxSC+0Z3PcKGjo12k468Rt9VryXrmz2nSJZNgDFvE=; b=5TKwF33wpuYw0DGbGoZWnZaC9a2d6bVQI0B6/E/L5zaOvNKTALX03/UV0Ydvx3DhSeSo5Cw5V6+puLfE2wowsu0tDNVZ1BXF8uKYkenjP2pGqA9t/BNgi8PRh8kL1wBu9BeYN7JF+uOBEVILE+Qty0NPYKMkms57B6t4zJ2GZps= Received: from DB6PR0501CA0033.eurprd05.prod.outlook.com (2603:10a6:4:67::19) by AM0PR08MB3442.eurprd08.prod.outlook.com (2603:10a6:208:d7::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.24; Wed, 29 Jul 2020 08:09:11 +0000 Received: from DB5EUR03FT022.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:67:cafe::13) by DB6PR0501CA0033.outlook.office365.com (2603:10a6:4:67::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.17 via Frontend Transport; Wed, 29 Jul 2020 08:09: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=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 DB5EUR03FT022.mail.protection.outlook.com (10.152.20.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.10 via Frontend Transport; Wed, 29 Jul 2020 08:09:11 +0000 Received: ("Tessian outbound 73b502bf693a:v62"); Wed, 29 Jul 2020 08:09:11 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: e829a74540fa3dd1 X-CR-MTA-TID: 64aa7808 Received: from 87e13dd1879c.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 136DDA21-B8D9-4B8E-B195-B3B988DCCDDC.1; Wed, 29 Jul 2020 08:09:03 +0000 Received: from EUR01-DB5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 87e13dd1879c.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 29 Jul 2020 08:09:03 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VSWbcbakFWStNsjbUo6uz3wtKPHihinet4vG/BFfb2ZH+COyaNOdEsvC4v9nYCVg94mK4+RjnShyjd3hCR54WO1WckwjCTm9lcVQ7Y7p4mjqweEPzdD6rTEFoG+JuOZik/nxv4DgUW1KPQe2kmBTgxcDmCpH22xtk/sQICGeeoo3QzgBYQeKf1qsnKqYy1MoPRJzWlzy63B6EVh4wo7d8qVOJ+Sj+bBXQajuMEb8/O3kUjSXBsIDd/s7DojuME5Qh6cO0PPxI1vwX8YO4icFKb44X8MB1Udac9XRwl2hS+5NjwcoQhorPA0htpW/J6RUkA74avl1HkTDRRCSPFwj4A== 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=r7dxSC+0Z3PcKGjo12k468Rt9VryXrmz2nSJZNgDFvE=; b=RSnnXhGEWptIoRGSoWskLlUYfwtWnIvQactFrw3NoSqJUCC0SsmP7CRZHrlaBfV5YyzJvaFHLFBTHxsn7U3Dfh8a/10dcca6kf83Ys5vpvrVRQG0fyg7PM0D9PHKr+u6hsBlmnVKZuws7qypZe1Ftav1SyCXlsm8TzDR05cH7E5etvEIKiKqYWAK2Vxh9xIo8JhmW3WcUE9/kJyOn8jcVbtlrWZNhFv/uMAYCqlVO9XhIJRjm1X7tsW+boIQD+qIgYarITDDNJTXqkDvcUymfqGUREltfS8Aka0EPgxnHLvp3l8cD/2WPAE0Edn0JBUByHjLRz7d79gHSVG9zVeSrQ== 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=r7dxSC+0Z3PcKGjo12k468Rt9VryXrmz2nSJZNgDFvE=; b=5TKwF33wpuYw0DGbGoZWnZaC9a2d6bVQI0B6/E/L5zaOvNKTALX03/UV0Ydvx3DhSeSo5Cw5V6+puLfE2wowsu0tDNVZ1BXF8uKYkenjP2pGqA9t/BNgi8PRh8kL1wBu9BeYN7JF+uOBEVILE+Qty0NPYKMkms57B6t4zJ2GZps= Authentication-Results-Original: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=arm.com; Received: from AM6PR08MB3047.eurprd08.prod.outlook.com (2603:10a6:209:4c::23) by AM6PR08MB3654.eurprd08.prod.outlook.com (2603:10a6:20b:4d::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.20; Wed, 29 Jul 2020 08:09:02 +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.3216.033; Wed, 29 Jul 2020 08:09:02 +0000 From: Szabolcs Nagy <szabolcs.nagy@arm.com> To: Florian Weimer <fweimer@redhat.com>, jeremy.linton@arm.com, Jakub Jelinek <jakub@redhat.com>, Jeff Law <law@redhat.com>, Carlos O'Donell <carlos@redhat.com> Subject: [PATCH] aarch64: update NEWS about branch protection Date: Wed, 29 Jul 2020 09:08:50 +0100 Message-Id: <20200729080850.26078-1-szabolcs.nagy@arm.com> X-Mailer: git-send-email 2.17.1 Content-Type: text/plain X-ClientProxiedBy: DM5PR1401CA0018.namprd14.prod.outlook.com (2603:10b6:4:4a::28) 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.52) by DM5PR1401CA0018.namprd14.prod.outlook.com (2603:10b6:4:4a::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16 via Frontend Transport; Wed, 29 Jul 2020 08:08:59 +0000 X-Mailer: git-send-email 2.17.1 X-Originating-IP: [217.140.106.52] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 6d01e085-10b3-4f98-aa66-08d83396ad02 X-MS-TrafficTypeDiagnostic: AM6PR08MB3654:|AM0PR08MB3442: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: <AM0PR08MB34428F9FC72D70CA41939A2DED700@AM0PR08MB3442.eurprd08.prod.outlook.com> x-checkrecipientrouted: true NoDisclaimer: true X-MS-Oob-TLC-OOBClassifiers: OLM:8273;OLM:8273; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: udWeyLzi/FdV1W4tgo+LPpl3pMPwbXTa/W9kHhKkngK4UvI3njmzuqy+imaBqIm4b2n+mBvZ6cnyCGLXgffnE8TNO4pj+GHMshlp2mFU9gO3aR3evxWofk4RiLeawuRmY8s0f4yOj4ABxaGG9N3+YD/nBnb+o2ezXf5Nydi2VvhFTPVxVtVowQU1eLGNKC/2mHpCujT88MMJtjbA0W/XDCXxmc095zbpnYy8YR1i1K/ycHlla84EoJJ4RVdvQ5MRjnodETuIt9mIPamxrEmyb+2iR0HS+8OW0kMbBbG7YcBZEX3tGMJ01lRHYtlYzEDVQXgxupHCg+fFy504YZJkfxoRCcaHXF47/Sge/XxK05i79vHELJZbkQUTAaVWS42e 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)(346002)(136003)(39850400004)(366004)(396003)(376002)(44832011)(26005)(6486002)(66946007)(956004)(1076003)(66556008)(8936002)(15650500001)(52116002)(6506007)(2616005)(186003)(16526019)(66476007)(6512007)(5660300002)(110136005)(69590400007)(83380400001)(86362001)(6666004)(316002)(478600001)(4326008)(36756003)(2906002)(8676002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: a18qIVWIoukkk5wvTqWbOTRW3pnyJgNLUwvLK1TaCtYbq296rLY5u6t6S8htV/Grtdv9j+sA9IZyoer4WZUjWTVsyyhY0a89QSELcsdCGpQ6UDJXvjG0bfojEHq7bEjJITSGJ7OBeR2IWjPqnyJQU71B1kFt/PnxQb1jkNzds9b/aVYrMJtoXzvozUf8uC0Y5me6WJMUu/dJAvPwYh1v+3uEGlgDj2cl/1GwGThR0sbIhri6iOTsOvwCaJqX0sTTonwtmhAdo/fKDaYfV5o78QwIdTJqqpI56mcLBftSDesQ29Akg3E8ZRPKoCluw6tTfMk0YIm08yhfyfh2UjQhSsML1iK0r21v+o8Yd+35xVkEVEdKUod3dp5E82IG0IANbVggVGcyrKmm8dNt6M4iYc1/VlEqfHn986CaMajPbavllfDQ/2tYCukd38Acs8qstxR3AvY/Ci+OxD4Emsfve3v1tGIhO58vrpCBCWPqhkmc+GwaZYU39Wg9aTehCAH7 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3654 Original-Authentication-Results: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT022.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 3f157049-cc12-461e-284d-08d83396a708 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 4zQlxO5lgmWSknb49LUZj3i8cf4QBBF4/I6gjMM7PmGRxteyzK0aCAm9KL/oG+7OOtM6Rgxj5luYRNo4/JHPvyezbClKMtxlWtXoFzyP20SZ3mUGFH938HYTKDvzeDeEGFZNIhcn87YVxY37TkiwDmmbJ9QswpHjpABicAuQ5Wv+8gKYcz/xcPmtSosdweZ29Rc2ixsrGcsBsxBpF6aJqUPhuegHUJq8IA0aFQF6N5ev2tF1R4W2IZxf8Y+GGnqu7SeVgMDP0uPLPPrg+9vRQn30VZrWy7CNNfb1pzflT2EWrY3NwI9RDdQztRRdUtnJpgjWmCSPUrbLICewMHdrAc9RYFK7a/3HKs8aGk8/3n32oZ3mLiT3gPV5qtENQ8W39jGK1MQBwaGtkRvc0fugRxn7y5taA/2QCS9rFNiHKe+D0S9TSWgaTUl9BY7BLlCL 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)(376002)(396003)(136003)(39860400002)(46966005)(81166007)(5660300002)(6666004)(86362001)(1076003)(26005)(2906002)(36756003)(70586007)(356005)(70206006)(82310400002)(956004)(336012)(316002)(16526019)(8936002)(44832011)(478600001)(110136005)(69590400007)(15650500001)(6506007)(6512007)(83380400001)(47076004)(4326008)(2616005)(8676002)(82740400003)(186003)(6486002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jul 2020 08:09:11.3609 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6d01e085-10b3-4f98-aa66-08d83396ad02 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: DB5EUR03FT022.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3442 X-Spam-Status: No, score=-15.4 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> Cc: libc-alpha@sourceware.org Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces@sourceware.org> |
Series |
aarch64: update NEWS about branch protection
|
|
Commit Message
Szabolcs Nagy
July 29, 2020, 8:08 a.m. UTC
After some discussions it seems the original news was not clear and that it is valid to manually pass the branch protection flags iff GCC target libs are built with them too. The main difference between manually passing the flags and using the configure option is that the latter also makes branch protection the default in GCC which may not be desirable in some cases. --- NEWS | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
Comments
* Szabolcs Nagy: > diff --git a/NEWS b/NEWS > index 1ef4a0a7a4..0e6ad5edc4 100644 > --- a/NEWS > +++ b/NEWS > @@ -70,7 +70,9 @@ Major new features: > > * 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 > + --enable-standard-branch-protection (or if -mbranch-protection=standard > + flag is passed when building both GCC target libraries and glibc, > + in either case a custom GCC is needed). 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, Please clarify if you need to pass the flags in CFLAGS or CC for glibc. Thanks. Florian
The 07/29/2020 10:11, Florian Weimer wrote: > * Szabolcs Nagy: > > > diff --git a/NEWS b/NEWS > > index 1ef4a0a7a4..0e6ad5edc4 100644 > > --- a/NEWS > > +++ b/NEWS > > @@ -70,7 +70,9 @@ Major new features: > > > > * 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 > > + --enable-standard-branch-protection (or if -mbranch-protection=standard > > + flag is passed when building both GCC target libraries and glibc, > > + in either case a custom GCC is needed). 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, > > Please clarify if you need to pass the flags in CFLAGS or CC for glibc. > Thanks. cflags is enough, but it is hard to tell what the glibc build system does with the various cflags. if i simply override CFLAGS i get # error "glibc cannot be compiled without optimization"
* Szabolcs Nagy: > The 07/29/2020 10:11, Florian Weimer wrote: >> * Szabolcs Nagy: >> >> > diff --git a/NEWS b/NEWS >> > index 1ef4a0a7a4..0e6ad5edc4 100644 >> > --- a/NEWS >> > +++ b/NEWS >> > @@ -70,7 +70,9 @@ Major new features: >> > >> > * 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 >> > + --enable-standard-branch-protection (or if -mbranch-protection=standard >> > + flag is passed when building both GCC target libraries and glibc, >> > + in either case a custom GCC is needed). 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, >> >> Please clarify if you need to pass the flags in CFLAGS or CC for glibc. >> Thanks. > > cflags is enough, but it is hard to tell what > the glibc build system does with the various > cflags. > > if i simply override CFLAGS i get > # error "glibc cannot be compiled without optimization" Okay, I trust you that CFLAGS is enough. Are there any ELF notes I should watch out for? My RM delegation has already expired, so I cannot approve your patch. Thanks, Florian
The 07/29/2020 11:01, Florian Weimer wrote: > * Szabolcs Nagy: > > > The 07/29/2020 10:11, Florian Weimer wrote: > >> * Szabolcs Nagy: > >> > >> > diff --git a/NEWS b/NEWS > >> > index 1ef4a0a7a4..0e6ad5edc4 100644 > >> > --- a/NEWS > >> > +++ b/NEWS > >> > @@ -70,7 +70,9 @@ Major new features: > >> > > >> > * 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 > >> > + --enable-standard-branch-protection (or if -mbranch-protection=standard > >> > + flag is passed when building both GCC target libraries and glibc, > >> > + in either case a custom GCC is needed). 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, > >> > >> Please clarify if you need to pass the flags in CFLAGS or CC for glibc. > >> Thanks. > > > > cflags is enough, but it is hard to tell what > > the glibc build system does with the various > > cflags. > > > > if i simply override CFLAGS i get > > # error "glibc cannot be compiled without optimization" > > Okay, I trust you that CFLAGS is enough. > > Are there any ELF notes I should watch out for? readelf should show GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0 Properties: AArch64 feature: BTI (PAC may be missing in some libgcc asm, that's fixed up in gcc-trunk, but it's harmless.) e.g. this should not print any file in the install dir: find . -type f |while read i do # skip non-elf files aarch64-none-linux-gnu-readelf -h $i >/dev/null 2>&1 || continue # print if missing BTI note aarch64-none-linux-gnu-readelf -nW $i |grep -q BTI || echo $i done > > My RM delegation has already expired, so I cannot approve your patch. ok.
* Szabolcs Nagy: >> Are there any ELF notes I should watch out for? > > readelf should show > > GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0 Properties: AArch64 feature: BTI > > (PAC may be missing in some libgcc asm, that's > fixed up in gcc-trunk, but it's harmless.) Thanks. It looks like with the flags in CFLAGS, the notes are indeed there in some cases, because RPM debugedit chokes on them: explicitly decompress any DWARF compressed ELF sections in /builddir/build/BUILDROOT/glibc-2.31.9000-23.fc33.aarch64/usr/bin/gencat extracting debug info from /builddir/build/BUILDROOT/glibc-2.31.9000-23.fc33.aarch64/usr/bin/gencat Failed to update file: invalid section entry size I'll try to figure out what is going on there. It's a bit suspicious that this is the first dynamically linked binary, so maybe the notes are missing from the shared objects and statically linked binaries still. Thanks, Florian
The 07/29/2020 12:04, Florian Weimer wrote: > * Szabolcs Nagy: > > >> Are there any ELF notes I should watch out for? > > > > readelf should show > > > > GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0 Properties: AArch64 feature: BTI > > > > (PAC may be missing in some libgcc asm, that's > > fixed up in gcc-trunk, but it's harmless.) > > Thanks. It looks like with the flags in CFLAGS, the notes are indeed > there in some cases, because RPM debugedit chokes on them: > > explicitly decompress any DWARF compressed ELF sections in /builddir/build/BUILDROOT/glibc-2.31.9000-23.fc33.aarch64/usr/bin/gencat > extracting debug info from /builddir/build/BUILDROOT/glibc-2.31.9000-23.fc33.aarch64/usr/bin/gencat > Failed to update file: invalid section entry size if it tries to parse the dwarf debug info then it may choke on the new dwarf op code that is used for PAC: DW_CFA_GNU_window_save > > I'll try to figure out what is going on there. It's a bit suspicious > that this is the first dynamically linked binary, so maybe the notes are > missing from the shared objects and statically linked binaries still. > > Thanks, > Florian > --
* Szabolcs Nagy: >> Okay, I trust you that CFLAGS is enough. >> >> Are there any ELF notes I should watch out for? > > readelf should show > > GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0 Properties: AArch64 feature: BTI > > (PAC may be missing in some libgcc asm, that's > fixed up in gcc-trunk, but it's harmless.) It looks like we're hitting a binutils bug: <https://sourceware.org/bugzilla/show_bug.cgi?id=26312> Thanks, Florian
The 07/29/2020 10:17, Szabolcs Nagy wrote: > The 07/29/2020 11:01, Florian Weimer wrote: > > * Szabolcs Nagy: > > > The 07/29/2020 10:11, Florian Weimer wrote: > > >> * Szabolcs Nagy: > > >> > diff --git a/NEWS b/NEWS > > >> > index 1ef4a0a7a4..0e6ad5edc4 100644 > > >> > --- a/NEWS > > >> > +++ b/NEWS > > >> > @@ -70,7 +70,9 @@ Major new features: > > >> > > > >> > * 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 > > >> > + --enable-standard-branch-protection (or if -mbranch-protection=standard > > >> > + flag is passed when building both GCC target libraries and glibc, > > >> > + in either case a custom GCC is needed). 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, > > >> > > >> Please clarify if you need to pass the flags in CFLAGS or CC for glibc. > > >> Thanks. > > > > > > cflags is enough, but it is hard to tell what > > > the glibc build system does with the various > > > cflags. > > > > > > if i simply override CFLAGS i get > > > # error "glibc cannot be compiled without optimization" > > > > Okay, I trust you that CFLAGS is enough. ... > > My RM delegation has already expired, so I cannot approve your patch. > > ok. ping.
The 07/31/2020 07:58, Szabolcs Nagy wrote: > The 07/29/2020 10:17, Szabolcs Nagy wrote: > > The 07/29/2020 11:01, Florian Weimer wrote: > > > * Szabolcs Nagy: > > > > The 07/29/2020 10:11, Florian Weimer wrote: > > > >> * Szabolcs Nagy: > > > >> > diff --git a/NEWS b/NEWS > > > >> > index 1ef4a0a7a4..0e6ad5edc4 100644 > > > >> > --- a/NEWS > > > >> > +++ b/NEWS > > > >> > @@ -70,7 +70,9 @@ Major new features: > > > >> > > > > >> > * 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 > > > >> > + --enable-standard-branch-protection (or if -mbranch-protection=standard > > > >> > + flag is passed when building both GCC target libraries and glibc, > > > >> > + in either case a custom GCC is needed). 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, Carlos, i think this NEWS update would be a useful clarification, is there some concern about it? > > > >> > > > >> Please clarify if you need to pass the flags in CFLAGS or CC for glibc. > > > >> Thanks. > > > > > > > > cflags is enough, but it is hard to tell what > > > > the glibc build system does with the various > > > > cflags. > > > > > > > > if i simply override CFLAGS i get > > > > # error "glibc cannot be compiled without optimization" > > > > > > Okay, I trust you that CFLAGS is enough. > ... > > > My RM delegation has already expired, so I cannot approve your patch. > > > > ok. > > ping. > --
On 7/29/20 4:08 AM, Szabolcs Nagy wrote: > After some discussions it seems the original news was not clear > and that it is valid to manually pass the branch protection flags > iff GCC target libs are built with them too. The main difference > between manually passing the flags and using the configure > option is that the latter also makes branch protection the > default in GCC which may not be desirable in some cases. > --- > NEWS | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/NEWS b/NEWS > index 1ef4a0a7a4..0e6ad5edc4 100644 > --- a/NEWS > +++ b/NEWS > @@ -70,7 +70,9 @@ Major new features: > > * 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 > + --enable-standard-branch-protection (or if -mbranch-protection=standard > + flag is passed when building both GCC target libraries and glibc, > + in either case a custom GCC is needed). 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, > OK for glibc 2.32. My apologies for the delay. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
diff --git a/NEWS b/NEWS index 1ef4a0a7a4..0e6ad5edc4 100644 --- a/NEWS +++ b/NEWS @@ -70,7 +70,9 @@ Major new features: * 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 + --enable-standard-branch-protection (or if -mbranch-protection=standard + flag is passed when building both GCC target libraries and glibc, + in either case a custom GCC is needed). 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,