From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2073.outbound.protection.outlook.com [40.107.21.73]) by sourceware.org (Postfix) with ESMTPS id 98AB23858D1E for ; Thu, 18 Aug 2022 16:28:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 98AB23858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=Rc9JAn/I//AbxM/m27kKnqTCd7JMnUX0mNF1JRGmf5+WvaC+xv5IUW7L0ahhFEFjX0bw/8rIiHlyBgU5nHaz6EMH6+ng7mCDHWAjJ1Hb8ssqR/td1Xl6flTniKa3OUBtkfKRfvi6GAsO3ypEVknd+vlT9FUf6DrPHWq1jOqX4DNLyaSIgtSW2Dr4BeDMPfOhCmsjJXW3dVxqD8xxbglj+VeNahdXt+DVivEyYQUAs2HBG7hVNYGRRSoYg9vkIxa8NSM4auGEp99emE8SUXb/cITbA6cmjOKSU9rSqqEDb9nIJY+W0QsambCn31oteqSF6HojLNuydjDxL/UcC+PBzQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=YDL5/cC4JS8FxioYNP5J+jADXfgzv0iFueY61Oj5fXQ=; b=K9xtrl++1XL+BaWEUiZDLRbFXg1trurd9qgCdj9qx1HvCnmtrR5rnU6X9MSOm1na2ifnnC2GkCioB2ZboOI04jFt2iqC9JSHlHwD8iEapJFdAf7a3i13zXOYNs+S+E/Co+DIMsS7yxIBsOUQNDPdrFkIHUjkCs5aaG57x7JutGEHQOcL/fdjOdVB+erhiWcfWZpWlsHhT9y11VUP8xiFpLkiuxd31wnFAA7VSU16m26jC++NG/7XLMsSFkgGN/n/VvYF46XezoM2dr6KN/ZMLSRQj5Lz5754rvNGY0tWnQBPiS5xdxz33NLIKBHeK+mFgXpkr6O4eu2tkYi0n872WQ== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=sourceware.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1, 1, smtp.mailfrom=arm.com] dmarc=[1, 1, header.from=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=YDL5/cC4JS8FxioYNP5J+jADXfgzv0iFueY61Oj5fXQ=; b=nhJj3BuZZScs/8CCdT1pje08MeOCc7x3Jg6zqSynwEpNVlDzmgnmLkgz5oUwJi8dUKojPLC1lMZqGBJ3WWuZEbwIgFDiGEk1S0Fa98uhMfjTkq67PCmi/J0Ub2BVcN1t5QAgrUUZ5L13JaSVJVsof+1dIqj7im8mKPsxVs7eyM4= Received: from AM7PR02CA0026.eurprd02.prod.outlook.com (2603:10a6:20b:100::36) by VE1PR08MB5648.eurprd08.prod.outlook.com (2603:10a6:800:1af::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5546.16; Thu, 18 Aug 2022 16:28:54 +0000 Received: from AM7EUR03FT031.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:100:cafe::d) by AM7PR02CA0026.outlook.office365.com (2603:10a6:20b:100::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5525.19 via Frontend Transport; Thu, 18 Aug 2022 16:28:54 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;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; pr=C Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM7EUR03FT031.mail.protection.outlook.com (100.127.140.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5546.15 via Frontend Transport; Thu, 18 Aug 2022 16:28:54 +0000 Received: ("Tessian outbound 2af316122c7a:v123"); Thu, 18 Aug 2022 16:28:54 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: a2bc378466c9ba3e X-CR-MTA-TID: 64aa7808 Received: from 095f83fe6f94.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 45C78AB1-0FE2-4BF7-8848-3D9D1A7A102E.1; Thu, 18 Aug 2022 16:28:47 +0000 Received: from EUR01-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 095f83fe6f94.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 18 Aug 2022 16:28:47 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=C63jU8y4D3ILfkI/1178K+E5VbeC78vTj9cVq8VR7ncVTDQJre8bkyFr9gZmP/GbdJEOnVukvUGEu/aoiGOB4+/X0dj5zOveoXtzkV2MnVM/pFMbBCKA8P7XlPeV8V0EzcqKHxhXvliJOT/MjsEah1xQdAXj5VCDe179q90SKr/i2F1nXPiDvxGBf1SarHBDSkFKbvgborCTgQNuyLy2CGagOKrhtyRsnM4SakS96ReFXaMBKDBsYhhk3TIpMSnHaLR73bAVUQv2kBReEUSVBvj//ujx5xfsZdkKmVRbdDA57dZl6V491lA2JPQ14s0X5LuBJw6EhuiR1ZfdAW9hDg== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=YDL5/cC4JS8FxioYNP5J+jADXfgzv0iFueY61Oj5fXQ=; b=d5KHRS9qhG++V9kFBCqbZG2a8uU3VeOFJBbxZdQ5mOp6FUNQnfDC9DmrW3HVWYVRNENi6V7XJTIEFNYpKiPWCD1fZtpDftM1YRUz+K5X9OxrPPjXTVlWIEimsh143j2iopMHSNkw5ItcEplYM0c4n0Xks0s6z0+J8+Rx9F7f8o0/qHUG12urGXIxjhF9bUV59AWHlJCwzWv4MWDJgQ2WH0zD3ysSBaOJTVXrwCxR/ker7sTmL0SOpy95bTXMz8v/ZMSKfNSXGIJn22tBxrHhVnbHFvlD7Ov5OhFTbLaa9FUhe7eDCDQlWtOdibTZK0w7sCcz7VKOsY9Xl4kVj7x93g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 40.67.248.234) smtp.rcpttodomain=sourceware.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=none (message not signed); 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=YDL5/cC4JS8FxioYNP5J+jADXfgzv0iFueY61Oj5fXQ=; b=nhJj3BuZZScs/8CCdT1pje08MeOCc7x3Jg6zqSynwEpNVlDzmgnmLkgz5oUwJi8dUKojPLC1lMZqGBJ3WWuZEbwIgFDiGEk1S0Fa98uhMfjTkq67PCmi/J0Ub2BVcN1t5QAgrUUZ5L13JaSVJVsof+1dIqj7im8mKPsxVs7eyM4= Received: from DB6PR07CA0061.eurprd07.prod.outlook.com (2603:10a6:6:2a::23) by DBBPR08MB6172.eurprd08.prod.outlook.com (2603:10a6:10:1f4::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5504.16; Thu, 18 Aug 2022 16:28:44 +0000 Received: from DBAEUR03FT018.eop-EUR03.prod.protection.outlook.com (2603:10a6:6:2a:cafe::6b) by DB6PR07CA0061.outlook.office365.com (2603:10a6:6:2a::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5566.4 via Frontend Transport; Thu, 18 Aug 2022 16:28:44 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 40.67.248.234) smtp.mailfrom=arm.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 40.67.248.234 as permitted sender) receiver=protection.outlook.com; client-ip=40.67.248.234; helo=nebula.arm.com; pr=C Received: from nebula.arm.com (40.67.248.234) by DBAEUR03FT018.mail.protection.outlook.com (100.127.142.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.5546.15 via Frontend Transport; Thu, 18 Aug 2022 16:28:44 +0000 Received: from AZ-NEU-EX04.Arm.com (10.251.24.32) by AZ-NEU-EX03.Arm.com (10.251.24.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.9; Thu, 18 Aug 2022 16:28:43 +0000 Received: from e125768 (10.2.78.50) by mail.arm.com (10.251.24.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.9 via Frontend Transport; Thu, 18 Aug 2022 16:28:43 +0000 From: "Victor L. Do Nascimento" To: Richard Earnshaw CC: , Subject: Re: [PATCH v2 1/8] newlib: libc: define M-profile PACBTI-enablement macros In-Reply-To: (Victor L. Do Nascimento's message of "Tue, 16 Aug 2022 17:11:12 +0100") References: <20220803153524.20631-1-victor.donascimento@arm.com> <20220803153524.20631-2-victor.donascimento@arm.com> <72ab6827-13eb-a2ed-668c-d6b53a83e9ca@foss.arm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) Date: Thu, 18 Aug 2022 17:28:43 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 1 X-MS-Office365-Filtering-Correlation-Id: b6e240f3-2d41-48be-b824-08da8136be2a X-MS-TrafficTypeDiagnostic: DBBPR08MB6172:EE_|AM7EUR03FT031:EE_|VE1PR08MB5648:EE_ x-checkrecipientrouted: true NoDisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: Jq1Ps1yTcUWda09b/+fdWxs6vBA/ZKm9GAhRLecEVVq2uCA64pKvX4Ntiifz7/+iyoKeOpjNzUxTlOwiYuzHFX0tZwh7bzkEWY23UM1jR2RfEUTEVfwF+tcU4GmkYj9O8BZZd0vr1lluTRim5gg+mDGbta/eR7aaPg3SsznM5Dwho7gdQhJ771Nl0OFLCb5EpR+2IqxMRUB697w+lqb5c5wYiSG6XWkSz5JK926BQZE04pqEg9dvRPEfj+/0/pgiT4PduFOlxCp0bt6OU54IoL5+LCuGB3gGeEiJdbhGCsUl8eRSNVYOf6d7Wm+5syqhWuOheMvovJd6I+k/Rty+ePe0bLops7rsAdTNIjdOIufUOLiDMXSGS9EswowhPnZKGdK75Ck80deu6J2E3vR6KkeY/nLYFT8afiNg/ijBPUt2oWb+2zjlbd0jk2CESsTTKv+sv1uDj+nWjQp2m37KbaN8gsajFvtSCpbGhkVQP+0M0WzSSlWcgV4KYj7xyGJh/c2KAfE6S6dq6CxFK7vaYeth9L3j1sE7hIqaYcekiS7nPij8d950SR47K9AKSv6vZkFbnqgSFe/iSiBIIuhO0pA5JyMZZ9HgJXboY5jFnahXRKrDTSQkoR/29J4RfKInYEtcJhadvm7Ybvzu0gvQmD7GwnUgu38IQe/bssjSNAn3Aq7O/y4MfUJH8S5S8PQvEwQHiDvL147mg7VVn4AeSpo6/qiJ4leBAMK7rANtb5BbZXN0FmTMbHZPuEAbP4PwBVC2ZMXwxmXzHPWTSMLet8e1uDF+SZ/6sV4t9vKEcNErDDmgmShWO1FbZSKufhj5 X-Forefront-Antispam-Report-Untrusted: CIP:40.67.248.234; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:nebula.arm.com; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(13230016)(4636009)(136003)(376002)(39860400002)(396003)(346002)(46966006)(40470700004)(36840700001)(5660300002)(36860700001)(70586007)(8676002)(316002)(4326008)(54906003)(40480700001)(82310400005)(70206006)(8936002)(2906002)(82740400003)(40460700003)(6862004)(81166007)(30864003)(356005)(36756003)(186003)(41300700001)(53546011)(26005)(86362001)(336012)(426003)(83380400001)(47076005)(2616005)(478600001)(36900700001); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB6172 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM7EUR03FT031.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: ffadd833-651b-4f18-3b83-08da8136b803 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: KUdLWdCK7AP58V36vCwJQOStXVF1Nhvc1swhjNK+sc4eFklpfwbhRPB+3vHLes7XtLQN567VLcyQrLGLHlJpo2rr9brFSu17QlL/5we4BIUXpqfbfLM/tDr4eJm2aS9Kd/SE205XLgesdmCh5xLBVzsnf39QE/3hs0IjxZXvHKaPuUNV5CFKjThFThDUzn6iUfy1bVw6bBOk7iCmAI0TivoBT/sY+3w7nPSClM8+amE3yOiXtqsSHmPtEiDx/bqp3ZSsC9dCjOj+rtVXHU7qsrYPtPyN4+knaBftw257797YdTUrhO2dyNQ3jQy5KMWz77WJHjBUImQWljjcdiQvxz9cBLC80kzdw+CPKBj1nZBOMUhu2LNSd98e6717/Lhbm90+GJXEuEgeA2tuobARZBi26WfXtY16Lv3tJsTH5zLoNgCZR+FLlOBK5ZyvAHtWgwmr3Jp71+JmI8hwo+ai9lrLiRHdKh5YCPOCRLpMwXsmJYLYfdPYWpgSM5skysGfeTg+DfNMLk6ZsBzUdlZ1qE9tpOaeijPucqfoGguU4RYpICpsgsgA7eGcciLt1wtQlqax2kMtTSyF8UGnHNubW0+LozgZfQ/ydwY+XxWO7KrWTE/6JMyQUZuJVdF8FJ5cGqHm8klmvPmXUD3CIIdvVXAt+I+qg9uh52dccDtPti/8CBQ0/QcD6aEvoevQecKdm1LiR0jy5cGgeYLHzym3WHTKNCUiU3qJ++LfB+tH2B0WK/6xl0EJ5IQePFl6Mv/EmSHa0etqttRc93faOXS53w== 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:(13230016)(4636009)(396003)(376002)(346002)(136003)(39860400002)(46966006)(36840700001)(40470700004)(426003)(2616005)(6862004)(47076005)(8936002)(186003)(53546011)(5660300002)(54906003)(336012)(40460700003)(4326008)(30864003)(40480700001)(8676002)(70206006)(70586007)(316002)(86362001)(36860700001)(26005)(81166007)(83380400001)(2906002)(82310400005)(478600001)(41300700001)(36756003)(82740400003); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2022 16:28:54.4409 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b6e240f3-2d41-48be-b824-08da8136be2a 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: AM7EUR03FT031.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB5648 X-Spam-Status: No, score=-13.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, FORGED_SPF_HELO, GIT_PATCH_0, KAM_DMARC_NONE, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2022 16:29:00 -0000 "Victor L. Do Nascimento" writes: > Richard Earnshaw writes: > >> On 03/08/2022 16:35, Victor Do Nascimento wrote: >>> Create an assembly header file that conditionally defines fuction >>> prologues/epilogues depending on the compile-time mbranch-protection >>> argument values. >>> * newlib/libc/machine/arm/pacbti.h: New. >>> --- >>> newlib/libc/machine/arm/pacbti.h | 64 ++++++++++++++++++++++++++++++++ >>> 1 file changed, 64 insertions(+) >>> create mode 100644 newlib/libc/machine/arm/pacbti.h >>> diff --git a/newlib/libc/machine/arm/pacbti.h >>> b/newlib/libc/machine/arm/pacbti.h >>> new file mode 100644 >>> index 000000000..4c31d00bc >>> --- /dev/null >>> +++ b/newlib/libc/machine/arm/pacbti.h >>> @@ -0,0 +1,64 @@ >>> +/* >>> + * Copyright (c) 2022 Arm Ltd >>> + * All rights reserved. >>> + * >>> + * Redistribution and use in source and binary forms, with or without >>> + * modification, are permitted provided that the following conditions >>> + * are met: >>> + * 1. Redistributions of source code must retain the above copyright >>> + * notice, this list of conditions and the following disclaimer. >>> + * 2. Redistributions in binary form must reproduce the above copyright >>> + * notice, this list of conditions and the following disclaimer in the >>> + * documentation and/or other materials provided with the distribution. >>> + * 3. The name of the company may not be used to endorse or promote >>> + * products derived from this software without specific prior written >>> + * permission. >>> + * >>> + * THIS SOFTWARE IS PROVIDED BY ARM LTD ``AS IS'' AND ANY EXPRESS OR IMPLIED >>> + * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF >>> + * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. >>> + * IN NO EVENT SHALL ARM LTD BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, >>> + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED >>> + * TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR >>> + * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF >>> + * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING >>> + * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS >>> + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. >>> + */ >>> + >>> +/* Checki whether leaf function PAC signing has been requested >>> + in the -mbranch-protect compile-time option. */ >>> +#define LEAF_PROTECT_BIT 2 >>> +#define __HAVE_PAC_LEAF \ >>> + __ARM_FEATURE_PAC_DEFAULT & (1 << LEAF_PROTECT_BIT) >> >> Either this header needs to avoid polluting the user namespace, or it >> doesn't. If it does, then LEAF_PROTECT_BIT fails to do that. If it >> doesn't then __HAVE_PAC_LEAF should really be HAVE_PAC_LEAF (to avoid >> polluting the reserved namespace. I suspect this header is private to >> newlib (won't be exported to users), so should not be prefixing names >> with __. >> >>> + >>> +/* Macro to handle function entry depending on branch-protection >>> + schemes. */ >>> + .macro pacbti_prologue >>> +#if __HAVE_PAC_LEAF >>> +#if __ARM_FEATURE_BTI_DEFAULT >>> + pacbti ip, lr, sp >>> +#else >>> + pac ip, lr, sp >>> +#endif /* __ARM_FEATURE_BTI_DEFAULT */ >>> + .cfi_register 143, 12 >>> + str ip, [sp, #-4]! >> >> This causes the stack to lose 8-byte alignment. Whilst for leaf >> functions that's probably not a problem, the macro should have an >> option where the user can ask for alignment to be preserved. But >> there should also be an option to not save IP on the stack at all (for >> when the user does not modify IP in the function body). > > Work is ongoing on implementing the macro with all necessary features. > > A better macro implementation for the prologue is given as follows (but > still lacks any alignment preservation logic): > > /* Emit .cfi_offset directives for a consecutive sequence of registers. > PAC_CFI_ADJ will be 4 bytes if IP reg is pushed. */ > .macro cfisavelist first, last, index=1 > .cfi_offset \last, -4*(\index) - PAC_CFI_ADJ > .if \last-\first > cfisavelist \first, \last-1, \index+1 > .endif > .endm > > /* Create a prologue entry sequence handling PAC/BTI, if required and emitting > CFI directives for generated PAC code and any pushed registers. */ > > #define NREG ((\last-\first)+1) > > .macro prologue first=-1, last=-1, savepac=PAC_LEAF_PUSH_IP > #if HAVE_PAC_LEAF > #if __ARM_FEATURE_BTI_DEFAULT > pacbti ip, lr, sp > #else > pac ip, lr, sp > #endif /* __ARM_FEATURE_BTI_DEFAULT */ > .cfi_register 143, 12 > #else > #if __ARM_FEATURE_BTI_DEFAULT > bti > #endif /* __ARM_FEATURE_BTI_DEFAULT */ > #endif /* HAVE_PAC_LEAF */ > .if \first != -1 > .if \last != -1 > .if \savepac > push {r\first-r\last, ip} > .cfi_adjust_cfa_offset NREG*4 + PAC_CFI_ADJ > .cfi_offset 143, -PAC_CFI_ADJ > cfisavelist \first, \last > .else > push {r\first-r\last} > .cfi_adjust_cfa_offset NREG*4 > cfisavelist \first, \last > .endif > .else > .if \savepac > push {r\first, ip} > .cfi_adjust_cfa_offset 4 + PAC_CFI_ADJ > .cfi_offset 143, -PAC_CFI_ADJ > cfisavelist \first, \first > .else // !\savepac > push {r\first} > cfisavelist \first, \first > .endif > .endif > .else // \first == -1 > .if \savepac > push {ip} > .cfi_adjust_cfa_offset PAC_CFI_ADJ > .cfi_offset 143, -PAC_CFI_ADJ > .endif > .endif > .endm > > The question remains of how I can ammend the register list in the push > directive when we wish to push an extra dummy register to the stack for > alignment purposes. > > A hypothetical solution (albeit a broken one, as we can't redefine macro > arguments in the body of the macro) for when pushing an even no. of > registers + the pac code is: > > .if \first != -1 > .if \last != -1 > .if \savepac > > + .if \align_requested && ( ( (NREG+1) % 2 ) != 0 && (\first != 0) ) > + \first = \first - 1 > + .endif > > push {r\first-r\last, ip} > .cfi_adjust_cfa_offset NREG*4 + PAC_CFI_ADJ > > + .if \align_requested && ( ((NREG+1) % 2 ) != 0 && (\first != 0) ) > + /* Having pushed the dummy, restore original register range. */ > + \first = \first + 1 > + .endif > > .cfi_offset 143, -PAC_CFI_ADJ > cfisavelist \first, \last > > .else > ... > > The logic above seems correct to me, but I need to figure out a way of > adjusting the value of \first in the least invasive way. > > If we emit the push instruction via a separate macro, we could then pass > the \first argument as \first-1 (e.g. pushmacro \first=\first-1, > last=last, savepac=1). Even so, creating a macro just to emit the push > instruction seems overkill. We may end up having way too many macros. > > Do you have any insights on how I may be able to fix the above code to > allow for alignment preservation elegantly within the limitations of > what assembler macros can do? > > Cheers, > V. > I've also been thinking about simplifying the align logic, such that if we request alignment preservation, it always pushes a dummy register along w/ the pac code. This way, we don't preserve alignment, but rather alignment "parity. If in the absence of pushing the pac-code a simple push operation would result in a misaligned stack pointer, I believe that adding the pac code to the register list should also result in the preservation of misalignment. I think that if in a hypothetical situation code gets written such that the original prologue results in a misaligned stack, it's correct to assume that the developer is aware of this and will manually compensate for it later on in the code if alignment is needed. The risk I see is that having too much hidden logic in our prologue macro might result in unforseen bugs for coders with insufficient familiarity with it. The alignment preservation feature should behave as follows: "With this turned on, no perceptable difference is observed in program behaviour irrespective of the presence/absence of the pac code on the stack." >>> + .save {ra_auth_code} >>> + .cfi_def_cfa_offset 4 >>> + .cfi_offset 143, -4 >>> +#elif __ARM_FEATURE_BTI_DEFAULT >>> + bti >>> +#endif /* __HAVE_PAC_LEAF */ >>> + .endm >>> + >>> +/* Macro to handle different branch exchange cases depending on >>> + branch-protection schemes. */ >>> + .macro pacbti_epilogue >>> +#if __HAVE_PAC_LEAF >>> + ldr ip, [sp], #4 >>> + .cfi_restore 143 >>> + .cfi_def_cfa_offset 0 >>> + aut ip, lr, sp >>> +#endif /* __HAVE_PAC_LEAF */ >>> + bx lr >>> + .endm >> >> I think these macros are really misnamed, firstly, they're only for >> leaf functions and secondly, they (particularly the epilogue) does >> something even if PAC is not needed. So I think they should be >> renamed as 'leaf_prologue' and 'leaf_epilogue' respectively. >> >> In consequence, I think this file should really be merged into the >> existing arm_asm.h, then we don't need yet another header file. >> >> Finally, the header needs to define a (C) macro that defines how much >> to adjust the CFI offset by for various scenarios: >> - When PAC is not used >> - When PAC is used with no alignment >> - When PAC is used and asked for 8-byte alignment to be preserved. This creates anoter level of complexity. As you mention that users should have the option of whether or not to push the pac code onto the stack when it won't be overwritten over the course of a leaf fuction, the logic for this C macro will take this into account. This leads us to create something as follows: #if HAVE_PAC_LEAF /* Pac code requested for leaf functions. */ # if PAC_LEAF_PUSH_IP /* Always push pac code to the stack. */ # if ALIGN_PRESERVE # define PAC_CFI_ADJ 8 # else # define PAC_CFI_ADJ 4 # endif # else # define PAC_CFI_ADJ 0 # endif /* PAC_LEAF_PUSH_IP*/ #else # define PAC_CFI_ADJ 0 #endif /* HAVE_PAC_LEAF */ Thus, if PAC_LEAF_PUSH_IP is not requested, PAC_CFI_ADJ is set to 0. This creates a problem for functions where pushing the pac code onto the stack is mandatory, as is the case for functions where the register storing it will be reused in the body of the function. In That case, we need a second macro which is independent of the value of PAC_LEAF_PUSH_IP. This leads to our second macro to be used for such functions: #if HAVE_PAC_LEAF # if ALIGN_PRESERVE # define PAC_CFI_ADJ_DEFAULT 8 # else # define PAC_CFI_ADJ_DEFAULT 4 # endif #endif and developers would have to choose correctly whether to write something like .cfi_offset , -(+PAC_CFI_ADJ) or .cfi_offset , -(+PAC_CFI_ADJ_DEFAULT) Does this sound remotely acceptable? We could use an assembler macro rather than C macro and calculate the offset based on some passed argument, but either way we find ourselves catering for a growing number of use cases and with it the complexity of any solution grows. I just thought I'd ask what your thoughts were on these matters. V. >> >> R.