Message ID | 20200430174518.GG29015@arm.com |
---|---|
State | Superseded |
Headers |
Return-Path: <libc-alpha-bounces@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6149B396E469; Thu, 30 Apr 2020 17:45:30 +0000 (GMT) X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60057.outbound.protection.outlook.com [40.107.6.57]) by sourceware.org (Postfix) with ESMTPS id 73F61395383D for <libc-alpha@sourceware.org>; Thu, 30 Apr 2020 17:45:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 73F61395383D 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=z9yDjLUV0ccJy38YWyTPfkyd5P3SiySjRuPYF17V4pA=; b=nZaOCOgnW2sHAJ5oAJ8RZwpUqMGZxWItqT7yvevL0HjxriCsdX7PRZ/zLcJEIHziWXas6ky6z5nirO/xPqweLnWzhUVQdUlEEUZoObHU36vcHSz21llcJj6NMQTuUIm3Q6RiszRmwYANbxBvi6OWgfH04PsCM9bDviIBElRAadU= Received: from DB6P191CA0008.EURP191.PROD.OUTLOOK.COM (2603:10a6:6:28::18) by DBBPR08MB4410.eurprd08.prod.outlook.com (2603:10a6:10:d2::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.20; Thu, 30 Apr 2020 17:45:26 +0000 Received: from DB5EUR03FT022.eop-EUR03.prod.protection.outlook.com (2603:10a6:6:28:cafe::e8) by DB6P191CA0008.outlook.office365.com (2603:10a6:6:28::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.20 via Frontend Transport; Thu, 30 Apr 2020 17:45:26 +0000 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.2958.20 via Frontend Transport; Thu, 30 Apr 2020 17:45:26 +0000 Received: ("Tessian outbound 5abcb386707e:v54"); Thu, 30 Apr 2020 17:45:26 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 49fc8645b29be8d5 X-CR-MTA-TID: 64aa7808 Received: from 5f7acb7c47b4.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 97D9AC50-5073-41CC-8305-91080D105A3A.1; Thu, 30 Apr 2020 17:45:20 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 5f7acb7c47b4.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 30 Apr 2020 17:45:20 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lVDu0TZO1W1jHHxzglclR4qVVAjhcuvnOrLpfvdPNQUwd9aj5U8AYHQlIcXf7L36cSd3WCGVsxKzpx+nfeL/41vFHM3vV/NRquM+Nz8dijfrhPtxbfelLijXgS5riXuemK+L3UOqiU3wHKbQBnzP2gG6Nj9xejPHYtG5USbU3MFusyNcv5vDd88WA2OQEHWuczIye9n2UH70lENeiK0Qwwy5tKEXh06nFTvnB7bT5RTN/ma41a5Sm361fYxPVBItVQZJKw0Yi3e0lm4SZFQM16koAZTtyrqxIl1p1JrKHYIm4HtTWfnP1HYMc2IFjYBQRrkf61rWJfAFNW4jDBYGoA== 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=z9yDjLUV0ccJy38YWyTPfkyd5P3SiySjRuPYF17V4pA=; b=lo+ppe2NF4OkfZQ0gmcgJFcECusEmTqsXQAtVjGgfVdV+8X3qMruzRU3sQLJ8I0HLab4o4/jOaXZx9Sp6JWK7THV6N65mdalIyjP+fGPoPeokyD6/oWvEYJSunvp0v0wLkhdzPypap+sgkHKSBcNtJN3k+QWh1bXIAhB9NkUTtBShp2zrrDA58LN31a5CAES/Acn+GtfqgS5xfJ7hlXi2HPc9hJBdF60qTdBMhZI7hJPwXuKK7HmDhxl0FCt83LDSRWVs2xq0iF2oHCxcx84+6gGvFKWClCDqLGeW3dvZE4GyI/l5xt/HDfGRW6H2ng10kDOthjU3XuXVCgljShlbA== 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=z9yDjLUV0ccJy38YWyTPfkyd5P3SiySjRuPYF17V4pA=; b=nZaOCOgnW2sHAJ5oAJ8RZwpUqMGZxWItqT7yvevL0HjxriCsdX7PRZ/zLcJEIHziWXas6ky6z5nirO/xPqweLnWzhUVQdUlEEUZoObHU36vcHSz21llcJj6NMQTuUIm3Q6RiszRmwYANbxBvi6OWgfH04PsCM9bDviIBElRAadU= 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 AM6PR08MB3224.eurprd08.prod.outlook.com (2603:10a6:209:47::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.19; Thu, 30 Apr 2020 17:45:20 +0000 Received: from AM6PR08MB3047.eurprd08.prod.outlook.com ([fe80::49fd:6ded:4da7:8862]) by AM6PR08MB3047.eurprd08.prod.outlook.com ([fe80::49fd:6ded:4da7:8862%7]) with mapi id 15.20.2958.020; Thu, 30 Apr 2020 17:45:20 +0000 Date: Thu, 30 Apr 2020 18:45:18 +0100 From: Szabolcs Nagy <szabolcs.nagy@arm.com> To: libc-alpha@sourceware.org Subject: [PATCH 11/12] aarch64: redefine RETURN_ADDRESS to strip PAC Message-ID: <20200430174518.GG29015@arm.com> References: <20200430173458.GV29015@arm.com> In-Reply-To: <20200430173458.GV29015@arm.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-ClientProxiedBy: LO2P265CA0255.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:8a::27) To AM6PR08MB3047.eurprd08.prod.outlook.com (2603:10a6:209:4c::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from arm.com (217.140.106.55) by LO2P265CA0255.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:8a::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.20 via Frontend Transport; Thu, 30 Apr 2020 17:45:19 +0000 X-Originating-IP: [217.140.106.55] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: e962704d-c2d5-42df-e800-08d7ed2e4410 X-MS-TrafficTypeDiagnostic: AM6PR08MB3224:|AM6PR08MB3224:|DBBPR08MB4410: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: <DBBPR08MB4410D9E11183B38C96F22A23EDAA0@DBBPR08MB4410.eurprd08.prod.outlook.com> x-checkrecipientrouted: true NoDisclaimer: true X-MS-Oob-TLC-OOBClassifiers: OLM:8882;OLM:8882; X-Forefront-PRVS: 0389EDA07F X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: bjQuq4ViE23H5svGlXRCc1tq3ir5ae7Z0U5fMI3Gv080w9paynetaaiy1lo394CMBN/M53Ryjv/NqXiMTG2X3QB1NZVsUbRFLPz+T2bFGAOwvth3oFgRbK+K7hvoIJ/g4PpgyItSaP+sibf9PkTRYfcVEx55fV8+PV9BU+U7zUuQ9V9qiIkvzouIflOD2nij98wXJeXmp8qZUpe+qJcONesWmzYGNn52OR0ZagrKhXt8FeytskdCvT5aFRZo3wzkfwfC92wbBZFkiKrEwuXAPdW43RYdSN8yUEdCoiL1T7RMkAasY7uKFbmGvp6jZSStOdiy6UzzjMtWpIXpbX7rEuYmtAckeLZb0RmsUp8iJiTsYp2VRKIFuIX0BTQyWMPP 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)(376002)(366004)(396003)(136003)(39860400002)(1076003)(86362001)(33656002)(36756003)(66946007)(235185007)(66476007)(8886007)(55016002)(66556008)(66616009)(564344004)(478600001)(16526019)(26005)(186003)(52116002)(6916009)(44832011)(7696005)(33964004)(2906002)(4326008)(8676002)(8936002)(44144004)(956004)(2616005)(316002)(2700100001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: O7k6YKzBWiwIEP0Ti9wgh9mBhjZi1859iOH5s0lrbSGPovehjzR0xBeR879SAw7qCF8afmm4is+tlvwdwnaH0u1OJ9BOOqagBFbCttKL6HVLrfgk9hTUaEEWDbTjkeSTjRgQJ9tl4NVDoRucTJssXmEbcEzvcs8qPdX8DUdxbZc50VRQk4sGjTSsA3JWspMPQI/9i0Z1WBhQdKUzXs3BkraMAvHS9Hl/RYM/izEbxkAvUkPA7UNtiNHGaJtpyIlTdKWhbUTaZ+BWB6AGIzNxauIgN5QqO3D8/1I4HLSWIpEw9DaateN2wwzZb74opCHTvK0L01hqbdGTttndnaLQHpnb6xT5KTQRm5Pv410i3fkLtW6N9rfC58aDqyjbl6w/r/48AvlwueM41+eq0i4ecaZlWRt0Oe8Eke2Hs55+62jtNiMHOeWjYLD5+tFD6pUJ+eH+xTT3fb/3U3DSnQKNr6TvApj8hBTgUPvGS8+clb/Z4mgWbMuLPTW5obeZ4Zs6eEDCMGGOwHTZ6AA3QbvteaEWg8Xgu//TLkGUVVWXSwXA0E6kzU5MWoU/AtP0bxNuXLIiF0ArrldMqi7ETpuQXzkMflpb94Dn0FLqZ020X13f3qNuwpz5XrzwkIV36Qorv6wZ8NXWAhXKD+Z+TB87lV8OZnVgfd/1KrvPkUo0XyEI0Rx7zTfgTJMqrJ1sG0pvCTlk2uvJC345dNOq5ZhOqdz+7ltXClDxLVUy8yXWk2y+vNMqwyi6m4yqEOIQ3s5CozSBlRSwa6l6iLVW0NpR3N0a77koJE3csXPLZep2zGU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3224 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: DB5EUR03FT022.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)(39860400002)(346002)(376002)(136003)(396003)(46966005)(316002)(8886007)(86362001)(564344004)(2616005)(2906002)(36756003)(33656002)(956004)(82310400002)(8676002)(81166007)(478600001)(70586007)(66616009)(70206006)(16526019)(7696005)(55016002)(26005)(47076004)(336012)(8936002)(186003)(33964004)(44144004)(356005)(1076003)(6916009)(44832011)(235185007)(4326008)(82740400003)(2700100001); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: a19b4921-e676-484d-c810-08d7ed2e403c X-Forefront-PRVS: 0389EDA07F X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: eTIPUTaZaIE3qykpvMgo9OkwpwplkBpVWDs2l/YZ/OerrSM9rWJY3VmSWAhfhikRh/5PseGCL+OFswSK7UOJhvzYWmoyWc+r+kJ3F2Cu8ps4VNV4l8EZQtImcq/Nzvc3kHj25FL/n5xxzDZSb7wQ8V32C6gMHerUM1MQNWrmPJoKEOHUWD12GDmaFaDF8n1GtClLt/7oHwVlooJsUI2kzDl8yP3GdHIQ6EGlO8E2ImknGFosv8+Y7wuromXv2K6h8pGDeVTN45sN5Hkfl/ELicFfpYMLQI7+QrGMNqSlGE6aUzJLuA6dOsQKTrSoyaucPK5V7wzq0nP0vAtLRu4hkiaiUNLr4heDnCHomj7VQdkunK/veWcYbVRkfzDwsLChMaYGsGWm/AWngoFUigMKaEjiLJ25/00u+h3pYSLR8IY= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Apr 2020 17:45:26.2381 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e962704d-c2d5-42df-e800-08d7ed2e4410 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-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB4410 X-Spam-Status: No, score=-29.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, 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 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="0011-aarch64-redefine-RETURN_ADDRESS-to-strip-PAC.patch" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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> Cc: Sudakshina Das <Sudi.Das@arm.com> Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces@sourceware.org> |
Series |
aarch64: branch protection support
|
|
Commit Message
Szabolcs Nagy
April 30, 2020, 5:45 p.m. UTC
Comments
On 30/04/2020 14:45, Szabolcs Nagy wrote: > RETURN_ADDRESS is used at several places in glibc to mean a valid > code address of the call site, but with pac-ret that includes a > pointer authentication code, so the definition is adjusted. > > XPAC is added unconditionally for now, but it's only needed if > glibc is compiled with -mbranch-protection=pac-ret. Inline asm > is used instead of __builtin_aarch64_xpaclri since that's an > undocumented builtin and not available in all supported gccs. > --- > sysdeps/aarch64/sysdep.h | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/sysdeps/aarch64/sysdep.h b/sysdeps/aarch64/sysdep.h > index 63a04a70cd..87f19b9bef 100644 > --- a/sysdeps/aarch64/sysdep.h > +++ b/sysdeps/aarch64/sysdep.h > @@ -35,6 +35,16 @@ > > #define PTR_SIZE (1<<PTR_LOG_SIZE) > > +/* Strip pointer authentication code from pointer p. */ > +#define XPAC(p) ({ \ > + register void *__ra asm ("x30") = (p); \ > + asm ("hint 7 // xpaclri" : "+r"(__ra)); \ > + __ra;}) > + > +/* This is needed when glibc is built with -mbranch-protection=pac-ret. */ > +#undef RETURN_ADDRESS > +#define RETURN_ADDRESS(n) XPAC(__builtin_return_address(n)) > + Maybe use a inline function instead? #ifndef __ASSEMBLER__ # include <sys/cdefs.h> /* Strip pointer authentication code from pointer p. */ static __always_inline void * return_address (unsigned int n) { register void *ra asm ("x30") = __builtin_return_address (n); asm ("hint 7 // xpaclri" : "+r" (ra)); return ra; } /* This is needed when glibc is built with -mbranch-protection=pac-ret. */ # undef RETURN_ADDRESS # define RETURN_ADDRESS(n) return_address (n) #endif > #ifdef __ASSEMBLER__ > > /* Syntactic details of assembler. */
The 05/08/2020 14:44, Adhemerval Zanella via Libc-alpha wrote: > On 30/04/2020 14:45, Szabolcs Nagy wrote: > > +++ b/sysdeps/aarch64/sysdep.h > > @@ -35,6 +35,16 @@ > > > > #define PTR_SIZE (1<<PTR_LOG_SIZE) > > > > +/* Strip pointer authentication code from pointer p. */ > > +#define XPAC(p) ({ \ > > + register void *__ra asm ("x30") = (p); \ > > + asm ("hint 7 // xpaclri" : "+r"(__ra)); \ > > + __ra;}) > > + > > +/* This is needed when glibc is built with -mbranch-protection=pac-ret. */ > > +#undef RETURN_ADDRESS > > +#define RETURN_ADDRESS(n) XPAC(__builtin_return_address(n)) > > + > > Maybe use a inline function instead? macro seems more reliable to me than always_inline when poking at __builtin_return_address and x30, but i'm not against always_inline if that's considered better. i'd prefer separate xpac (since it can be used not just with __builtin_return_address e.g. for stored code address in jmpbuf, which currently uses ptrmangling) > #ifndef __ASSEMBLER__ > # include <sys/cdefs.h> what is cdefs.h for? > /* Strip pointer authentication code from pointer p. */ > static __always_inline void * > return_address (unsigned int n) > { > register void *ra asm ("x30") = __builtin_return_address (n); > asm ("hint 7 // xpaclri" : "+r" (ra)); > return ra; > } > > /* This is needed when glibc is built with -mbranch-protection=pac-ret. */ > # undef RETURN_ADDRESS > # define RETURN_ADDRESS(n) return_address (n) > #endif
On 11/05/2020 09:38, Szabolcs Nagy wrote: > The 05/08/2020 14:44, Adhemerval Zanella via Libc-alpha wrote: >> On 30/04/2020 14:45, Szabolcs Nagy wrote: >>> +++ b/sysdeps/aarch64/sysdep.h >>> @@ -35,6 +35,16 @@ >>> >>> #define PTR_SIZE (1<<PTR_LOG_SIZE) >>> >>> +/* Strip pointer authentication code from pointer p. */ >>> +#define XPAC(p) ({ \ >>> + register void *__ra asm ("x30") = (p); \ >>> + asm ("hint 7 // xpaclri" : "+r"(__ra)); \ >>> + __ra;}) >>> + >>> +/* This is needed when glibc is built with -mbranch-protection=pac-ret. */ >>> +#undef RETURN_ADDRESS >>> +#define RETURN_ADDRESS(n) XPAC(__builtin_return_address(n)) >>> + >> >> Maybe use a inline function instead? > > macro seems more reliable to me than always_inline > when poking at __builtin_return_address and x30, > but i'm not against always_inline if that's > considered better. I would prefer a static inline unless a macro is really required (either due some compiler limitation or bug). > > i'd prefer separate xpac (since it can be used > not just with __builtin_return_address e.g. for > stored code address in jmpbuf, which currently > uses ptrmangling) Ack. > >> #ifndef __ASSEMBLER__ >> # include <sys/cdefs.h> > > what is cdefs.h for? The __always_inline macro. > >> /* Strip pointer authentication code from pointer p. */ >> static __always_inline void * >> return_address (unsigned int n) >> { >> register void *ra asm ("x30") = __builtin_return_address (n); >> asm ("hint 7 // xpaclri" : "+r" (ra)); >> return ra; >> } >> >> /* This is needed when glibc is built with -mbranch-protection=pac-ret. */ >> # undef RETURN_ADDRESS >> # define RETURN_ADDRESS(n) return_address (n) >> #endif
* Adhemerval Zanella via Libc-alpha: > On 11/05/2020 09:38, Szabolcs Nagy wrote: >> The 05/08/2020 14:44, Adhemerval Zanella via Libc-alpha wrote: >>> On 30/04/2020 14:45, Szabolcs Nagy wrote: >>>> +++ b/sysdeps/aarch64/sysdep.h >>>> @@ -35,6 +35,16 @@ >>>> >>>> #define PTR_SIZE (1<<PTR_LOG_SIZE) >>>> >>>> +/* Strip pointer authentication code from pointer p. */ >>>> +#define XPAC(p) ({ \ >>>> + register void *__ra asm ("x30") = (p); \ >>>> + asm ("hint 7 // xpaclri" : "+r"(__ra)); \ >>>> + __ra;}) >>>> + >>>> +/* This is needed when glibc is built with -mbranch-protection=pac-ret. */ >>>> +#undef RETURN_ADDRESS >>>> +#define RETURN_ADDRESS(n) XPAC(__builtin_return_address(n)) >>>> + >>> >>> Maybe use a inline function instead? >> >> macro seems more reliable to me than always_inline >> when poking at __builtin_return_address and x30, >> but i'm not against always_inline if that's >> considered better. > > I would prefer a static inline unless a macro is really required > (either due some compiler limitation or bug). I think __builtin_return_address is ill-defined: Does the frame count that vanishes due to inlining? So it's probably a case similar to alloca, where a macro has to be used.
* Szabolcs Nagy: > +/* This is needed when glibc is built with -mbranch-protection=pac-ret. */ > +#undef RETURN_ADDRESS > +#define RETURN_ADDRESS(n) XPAC(__builtin_return_address(n)) This looks suspicious. Is __builtin_return_address ever useful without the decoding? If not, why doesn't GCC emit the PAC removal itself?
On 11/05/2020 16:21, Florian Weimer wrote: > * Adhemerval Zanella via Libc-alpha: > >> On 11/05/2020 09:38, Szabolcs Nagy wrote: >>> The 05/08/2020 14:44, Adhemerval Zanella via Libc-alpha wrote: >>>> On 30/04/2020 14:45, Szabolcs Nagy wrote: >>>>> +++ b/sysdeps/aarch64/sysdep.h >>>>> @@ -35,6 +35,16 @@ >>>>> >>>>> #define PTR_SIZE (1<<PTR_LOG_SIZE) >>>>> >>>>> +/* Strip pointer authentication code from pointer p. */ >>>>> +#define XPAC(p) ({ \ >>>>> + register void *__ra asm ("x30") = (p); \ >>>>> + asm ("hint 7 // xpaclri" : "+r"(__ra)); \ >>>>> + __ra;}) >>>>> + >>>>> +/* This is needed when glibc is built with -mbranch-protection=pac-ret. */ >>>>> +#undef RETURN_ADDRESS >>>>> +#define RETURN_ADDRESS(n) XPAC(__builtin_return_address(n)) >>>>> + >>>> >>>> Maybe use a inline function instead? >>> >>> macro seems more reliable to me than always_inline >>> when poking at __builtin_return_address and x30, >>> but i'm not against always_inline if that's >>> considered better. >> >> I would prefer a static inline unless a macro is really required >> (either due some compiler limitation or bug). > > I think __builtin_return_address is ill-defined: Does the frame count > that vanishes due to inlining? > > So it's probably a case similar to alloca, where a macro has to be > used. This is at least what documentation states [1]: "When inlining the expected behavior is that the function returns the address of the function that is returned to. To work around this behavior use the noinline function attribute." [1] https://gcc.gnu.org/onlinedocs/gcc/Return-Address.html
* Adhemerval Zanella: > On 11/05/2020 16:21, Florian Weimer wrote: >> * Adhemerval Zanella via Libc-alpha: >> >>> On 11/05/2020 09:38, Szabolcs Nagy wrote: >>>> The 05/08/2020 14:44, Adhemerval Zanella via Libc-alpha wrote: >>>>> On 30/04/2020 14:45, Szabolcs Nagy wrote: >>>>>> +++ b/sysdeps/aarch64/sysdep.h >>>>>> @@ -35,6 +35,16 @@ >>>>>> >>>>>> #define PTR_SIZE (1<<PTR_LOG_SIZE) >>>>>> >>>>>> +/* Strip pointer authentication code from pointer p. */ >>>>>> +#define XPAC(p) ({ \ >>>>>> + register void *__ra asm ("x30") = (p); \ >>>>>> + asm ("hint 7 // xpaclri" : "+r"(__ra)); \ >>>>>> + __ra;}) >>>>>> + >>>>>> +/* This is needed when glibc is built with -mbranch-protection=pac-ret. */ >>>>>> +#undef RETURN_ADDRESS >>>>>> +#define RETURN_ADDRESS(n) XPAC(__builtin_return_address(n)) >>>>>> + >>>>> >>>>> Maybe use a inline function instead? >>>> >>>> macro seems more reliable to me than always_inline >>>> when poking at __builtin_return_address and x30, >>>> but i'm not against always_inline if that's >>>> considered better. >>> >>> I would prefer a static inline unless a macro is really required >>> (either due some compiler limitation or bug). >> >> I think __builtin_return_address is ill-defined: Does the frame count >> that vanishes due to inlining? >> >> So it's probably a case similar to alloca, where a macro has to be >> used. > > This is at least what documentation states [1]: > > "When inlining the expected behavior is that the function returns the address > of the function that is returned to. To work around this behavior use the > noinline function attribute." > > [1] https://gcc.gnu.org/onlinedocs/gcc/Return-Address.html Hmm, okay. It's still weird not to count those frames, but at least it's documented.
On 11/05/2020 16:22, Florian Weimer wrote: > * Szabolcs Nagy: > >> +/* This is needed when glibc is built with -mbranch-protection=pac-ret. */ >> +#undef RETURN_ADDRESS >> +#define RETURN_ADDRESS(n) XPAC(__builtin_return_address(n)) > > This looks suspicious. Is __builtin_return_address ever useful > without the decoding? If not, why doesn't GCC emit the PAC removal > itself? > Kernel seems to be working on same assumptions [1], and I would say the builtin works with the assumption it should return the return address as is in current frame state. Maybe extend gcc should extern __builtin_extract_return_addr to remove the PAC bits? [1] https://patchwork.kernel.org/patch/11195099/
The 05/11/2020 21:22, Florian Weimer wrote: > * Szabolcs Nagy: > > > +/* This is needed when glibc is built with -mbranch-protection=pac-ret. */ > > +#undef RETURN_ADDRESS > > +#define RETURN_ADDRESS(n) XPAC(__builtin_return_address(n)) > > This looks suspicious. Is __builtin_return_address ever useful > without the decoding? If not, why doesn't GCC emit the PAC removal > itself? the only user that needs it is libgcc because it has dwarf info about the stack pointer and pac state so it can authenticate the return address, but normally that's not available (and code that cares about this would need pac-specific changes). i consider this a major bug in the current pac-ret implementation that makes it unusable in existing software (it's unreasonable to recommend XPAC for __builtin_return_address users, they will have to disable pac-ret, but there is no easy way to test for pac-ret or to disable it without disabling other things), but not everybody agrees with me on this. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94891
From 2223e5ed1d78634ef59f0a7efbd3a9885a8da53f Mon Sep 17 00:00:00 2001 From: Szabolcs Nagy <szabolcs.nagy@arm.com> Date: Wed, 15 Apr 2020 17:40:45 +0100 Subject: [PATCH 11/12] aarch64: redefine RETURN_ADDRESS to strip PAC RETURN_ADDRESS is used at several places in glibc to mean a valid code address of the call site, but with pac-ret that includes a pointer authentication code, so the definition is adjusted. XPAC is added unconditionally for now, but it's only needed if glibc is compiled with -mbranch-protection=pac-ret. Inline asm is used instead of __builtin_aarch64_xpaclri since that's an undocumented builtin and not available in all supported gccs. --- sysdeps/aarch64/sysdep.h | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/sysdeps/aarch64/sysdep.h b/sysdeps/aarch64/sysdep.h index 63a04a70cd..87f19b9bef 100644 --- a/sysdeps/aarch64/sysdep.h +++ b/sysdeps/aarch64/sysdep.h @@ -35,6 +35,16 @@ #define PTR_SIZE (1<<PTR_LOG_SIZE) +/* Strip pointer authentication code from pointer p. */ +#define XPAC(p) ({ \ + register void *__ra asm ("x30") = (p); \ + asm ("hint 7 // xpaclri" : "+r"(__ra)); \ + __ra;}) + +/* This is needed when glibc is built with -mbranch-protection=pac-ret. */ +#undef RETURN_ADDRESS +#define RETURN_ADDRESS(n) XPAC(__builtin_return_address(n)) + #ifdef __ASSEMBLER__ /* Syntactic details of assembler. */ -- 2.17.1