From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id DRMwExGdg2jtFjwAWB0awg (envelope-from ) for ; Fri, 25 Jul 2025 11:04:49 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=HQ3iG9z8; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 374561E102; Fri, 25 Jul 2025 11:04:49 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-10.1 required=5.0 tests=ARC_SIGNED,ARC_VALID, BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED, RCVD_IN_VALIDITY_RPBL,RCVD_IN_VALIDITY_SAFE autolearn=ham autolearn_force=no version=4.0.1 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id B502E1E091 for ; Fri, 25 Jul 2025 11:04:46 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 321683861029 for ; Fri, 25 Jul 2025 15:04:46 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 321683861029 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=HQ3iG9z8 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) by sourceware.org (Postfix) with ESMTPS id 4C9F2385117E for ; Fri, 25 Jul 2025 15:04:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4C9F2385117E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=intel.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 4C9F2385117E Authentication-Results: server2.sourceware.org; arc=fail smtp.remote-ip=192.198.163.15 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1753455844; cv=fail; b=Jl3VCbj/Vf4NR7/jP3ab41q5hjpna/BKG2ykD/c9e+whxJddTPgCyVoudnXGBPuG4gn0+CUSTpwTG28fT3VqLC6Zv43tOyuTbr+3xVF2RiaglxVZtZq3CH0w2bzqIriCMPVy4oYirwO1BNEtO5kCYmTwh+95iTb8PEM4rb9tfSA= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1753455844; c=relaxed/simple; bh=9PAT7jGqjryCx4khiibwFpY89XF+186LZIT15sn7bFY=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=HRLSnv9OP+rUyfXDYu2xh/nstPHl/OssE52LNBFM3UUwNv8zVh9t/xASSIe9VDYbmqNRNU1pixYsaIC3bNFc2kuJMTDV+KKo/kYd+B8kapsUR+x86e+e2xRGJ3ctU2JbgOG0O+tQxcDPmNFrk2s+eV8UQlm/kAjt7BFCEB/JeWQ= ARC-Authentication-Results: i=2; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4C9F2385117E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1753455844; x=1784991844; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version:content-transfer-encoding; bh=9PAT7jGqjryCx4khiibwFpY89XF+186LZIT15sn7bFY=; b=HQ3iG9z8Xp6zm90D9uqwr6HOJcpMvINEAxrDV0xEE37rqr2FRU4OrJcQ 5wrB+H3w/ym6gs20b2xZsdoNBy1WarIH7gsfN+iCa44rg0TCzOKe8/eeS VyxfMhiUUbtm9Ekydy0tlQIMh8kjdsV/wTtttswmehNkFykXzfCe4dzL/ /1fuzN2+lLDUVOAV6iHOC7yfhLIEC2/EdmtOW97Wu6Zn5zmS7JQqHMF19 VhMg/IhAaLI4K25zntyLJnshZ6eKSl+OcgqVsb7ONNf8ToeywWfjhV5EB PRuWgfWz5fcvbxMTGMiVXC4OJvn055fQwv8TzbkCJSHqYv8rICAA4I/+7 Q==; X-CSE-ConnectionGUID: uURyybttRl24OTpKYmENSQ== X-CSE-MsgGUID: 7DrScvuPQ4aUgbVF+kSilQ== X-IronPort-AV: E=McAfee;i="6800,10657,11503"; a="55939592" X-IronPort-AV: E=Sophos;i="6.16,339,1744095600"; d="scan'208";a="55939592" Received: from orviesa003.jf.intel.com ([10.64.159.143]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jul 2025 08:04:00 -0700 X-CSE-ConnectionGUID: /GNfYKADRf+xvUPUkcxUJg== X-CSE-MsgGUID: tlEF1GihQWSUS5mLZUga3w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,339,1744095600"; d="scan'208";a="165138795" Received: from orsmsx903.amr.corp.intel.com ([10.22.229.25]) by orviesa003.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jul 2025 08:04:00 -0700 Received: from ORSMSX901.amr.corp.intel.com (10.22.229.23) by ORSMSX903.amr.corp.intel.com (10.22.229.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1748.26; Fri, 25 Jul 2025 08:03:59 -0700 Received: from ORSEDG903.ED.cps.intel.com (10.7.248.13) by ORSMSX901.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1748.26 via Frontend Transport; Fri, 25 Jul 2025 08:03:59 -0700 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (40.107.96.86) by edgegateway.intel.com (134.134.137.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1748.26; Fri, 25 Jul 2025 08:03:59 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=cDCXG5Yk0vARKr7osh8SLhu+X71N26iViOfWlopGL+MP0Oa1KNDWDOD0qHEjayIWtDzdpf2hC42/COkVm4VGzwBdyx5yD9o/AxW5UuKOnjDWOjecIID51TAS/s+besjfL+fHL5QrAOzt43ZgFVOtUkEzfAvBzVMijw7yDkMncvy2WexeS/VcFUO0UH5iTacCNoV+BceTty9Nw2BeDklj6WdDHRCMR9C59Fa59L1QVOPZAcJz5DtCTYpjgya4/nMpPWJU4RyoCdn9D62VtgiIuYY1RmB//LZWd4KvPitE+65sN3C/hoKcSYVYR42lIq6cXScK22fQxu0azSzxmF4U6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=VCU330q8pKrgJxQJXJqz61BPIVlPKFXW7FXI/sT9TSQ=; b=PjT8bVw6YLhqM2BCWrCxe4AfcOpWCnd6nAoZtnWzRB2IJZ9XEStWRkLIFN3fsr1nfGFOka6Fb1H9zlMa/rcQG5zOy72NO6KqGzQV43O6CnuKS1xMqGiZHkDBQsSPPu8DqvxqNizFqihWQF39H7+CEFGqduHNX8CJuUoBaEoSu83RnMmHYvBohKzt3uqUNXMuGcp7vbl1M8QJWYApPcvjocPA228m5xs0UdVCNOglNoRfT0ogMiG4+49UbFGnFTwVMoP8rKeFnQuk+XpDBX5R4sMYRvdgbvKdWL2hODpYJMDasD/jBAEfPYwixox9IK3rTaLxY/exc1DBi7kRt5+MdA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from PH0PR11MB7636.namprd11.prod.outlook.com (2603:10b6:510:26f::13) by SJ0PR11MB4880.namprd11.prod.outlook.com (2603:10b6:a03:2af::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8943.30; Fri, 25 Jul 2025 15:03:56 +0000 Received: from PH0PR11MB7636.namprd11.prod.outlook.com ([fe80::e7bd:a2c9:c01d:1823]) by PH0PR11MB7636.namprd11.prod.outlook.com ([fe80::e7bd:a2c9:c01d:1823%4]) with mapi id 15.20.8943.028; Fri, 25 Jul 2025 15:03:56 +0000 From: "Schimpe, Christina" To: Andrew Burgess , "gdb-patches@sourceware.org" CC: "thiago.bauermann@linaro.org" , "luis.machado@arm.com" Subject: RE: [PATCH v5 06/12] gdb, gdbserver: Add support of Intel shadow stack pointer register. Thread-Topic: [PATCH v5 06/12] gdb, gdbserver: Add support of Intel shadow stack pointer register. Thread-Index: AQHb6Acq3rWeR1UfBECDbgcmq9LBerRC9SqAgAAL4gA= Date: Fri, 25 Jul 2025 15:03:56 +0000 Message-ID: References: <20250628082810.332526-1-christina.schimpe@intel.com> <20250628082810.332526-7-christina.schimpe@intel.com> <87cy9oe8pc.fsf@redhat.com> In-Reply-To: <87cy9oe8pc.fsf@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PH0PR11MB7636:EE_|SJ0PR11MB4880:EE_ x-ms-office365-filtering-correlation-id: 03d32100-b75b-43bc-cc9e-08ddcb8c7a22 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; ARA:13230040|1800799024|366016|376014|38070700018|13003099007; x-microsoft-antispam-message-info: =?us-ascii?Q?CIDuEvCbyKQcxUv22GVfbdIGUwuYONor000cygUZ8a6/uum/y5DlVxqLi4Is?= =?us-ascii?Q?wwlvjj7ep+o1YIM6C8mSF4j28P1eMMPThSAuzI6ZTz5bA7XO0hgWHGA2qtxa?= =?us-ascii?Q?tyXsTxfUYUDwqeuq1CXhDzy+C8V5Y74mbxb0SvR6yyXh3Tm7sVAVcqGlF6sz?= =?us-ascii?Q?fyV303OWo4srCQT/N2x7R+T7NIofA8ZjlMzkhd/ldHnkp17Ebw+TBedcHPEJ?= =?us-ascii?Q?Z8cvGLgxYXwUT3D+vpxWT9Se7Al5iVI7mUft0xS3z/QGQsZhUttNFmyZ/Rb4?= =?us-ascii?Q?znt7fLp2HGP+Dz5CiFFL5FXfHw1z496BDGs2TbPOMhffX5LiqkLIeAQU/Ytq?= =?us-ascii?Q?Y4+n6P3nsfHo4hcA+gb467cWAoxrtRMhAKbR7KHW2Lge7PyYhB7xSFIh454u?= =?us-ascii?Q?29tvI4zqYg0jDDO9Bx6qIh7/Pb+6HCex/7ChoyPlC2xUpBFFa3d7PP/QyqRf?= =?us-ascii?Q?A1ZWQ3JhkxCR269e2FOcn1S/brcgjRaz2aNzeeWwDi07itPKbyDKy7UWW/1P?= =?us-ascii?Q?WBNZfjs14PsExS1xm+zbWkgEypw74UFYYBoe8Nvm9fuyS4AeP5Qfdb2cvGO2?= =?us-ascii?Q?w6UxfE4U+TpqaBvwuf2ooiQsqTv4qaXttTQYyR3QkM3RzcXf9KoQE9ktr6Jq?= =?us-ascii?Q?M4rHEafFiOOoDTNl+oeNJEXFRyFeG0/+W09ltHugfUlJ3W+9L13FMhQXQ9NO?= =?us-ascii?Q?Ki0aO/GepUSYtdwuayuoNDdhKKN2eCHxSFHYpi2NvGis1bHGzWdFzSrjStrK?= =?us-ascii?Q?Q0jwL9Du/ILZX0bPpUynGPokhlRQsWhbj2BNCOapfge2hKYO44U/5kVgchd9?= =?us-ascii?Q?513KDW8+i51JWXXJfe2KqZCjo45AjoNlkb6qZQNVgKls1ntaro2X/JAfGxFR?= =?us-ascii?Q?5y9f2wIBieR58R9wUbsDTAyX5dYriqc5IGo+I3XFRVvvhLupxq3dmu7ip5zY?= =?us-ascii?Q?MDj8qKKaGpQQ41qd+7lPqsOfFZsYfXGc50o0KaKMrD3KsbGGoW5Df6z7NT0x?= =?us-ascii?Q?n1DzIH/N9tAKHJt5mXc1JleWTZcadty/10ETsrI5f2lS3MBWmWR+kjlLx2I/?= =?us-ascii?Q?8i7JFlylNRZfQtCiIxr3LJxK7IV48O0rm6dzaNDkyliLOtp1j0iU9hH89gqb?= =?us-ascii?Q?mLrsv+q5cv1FRqzetZGO2u1fknfyMgPsx4JvXdxdBFCfaHly6rfiayhYkJQo?= =?us-ascii?Q?WkQyQiUYZ3lshanoMgU42sty7xygVWlLkx25+qWyfxv3vdhdNloPlxE8rqVW?= =?us-ascii?Q?2BVlWS1nN72HMYbAr8ifIkn3zJ++vef/ngT/RoAZ2zcvtqb3lMU3YqRXJfhp?= =?us-ascii?Q?PDJNWecmQbJmqC+CftQADYwk1e60htcxv6RSq9EmOE/ELxh3HAJ3e+EzDazM?= =?us-ascii?Q?DajFRnzNPch3QLySp4VLPFFx3DfkuyxXyDQP94VuiMlE8gOdJLAI/fVOBVaJ?= =?us-ascii?Q?ZXuRRTaTZjMyDGINGl6nqN152KdeIbyV?= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB7636.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(1800799024)(366016)(376014)(38070700018)(13003099007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?/9giRKZKlRT3ypWxZqrQAbwfyJlSxgzZwL3N9hRd1EO1OENY3LlLt4LslJ7f?= =?us-ascii?Q?0Skg4oSI9guOBmb8dZhe/k+aPMYRP5C1ZTyX9LbyabyWpXFo2Qa6OOaFGAoQ?= =?us-ascii?Q?XWn/rQFMYUZqSZgBNA3gsvdTE0n3FV09NBOG5vxaMNAtK3ZpY7JKJux5A5le?= =?us-ascii?Q?XuHilrypiJa7uO6J/TjnYF1QhX3uQJMakI9os1SuMeKSpcC+iENG7Sn4clPd?= =?us-ascii?Q?yQ2y4KrsRqJ1CsCBC4E2rT/tq305j0yksxjjyUkVMfzX7tH5thzgWAOY3zat?= =?us-ascii?Q?Ke3cLkRRLTR5/Y8SiGa0HmjARzvZJGuO0GdJFjyE+scmGWIpjn3QeyRF99p9?= =?us-ascii?Q?iwQjS9zTjrdgoHRp2E0m72ldorzjMv7jk0q5ptrDT4RAWWKDItBJOnHrYwlg?= =?us-ascii?Q?EiXh35ndMfrUX5Refl991tRn3KVwmrKX8tow2xFTjLJhvL++iuJznOASigSM?= =?us-ascii?Q?Hh1iRrjojr695o8p/2FYVnSDKdPH50xq4eTakyzvCJdg82vK8Gak2V2b3SSZ?= =?us-ascii?Q?6vXesqtXfPFczgsuquM8xBekCXBsuRJJ7mpyMTyYqp9wkpOOPtMTFLCi6n8s?= =?us-ascii?Q?HczXtE/hleUrYLS2wLlB3hmTIur4k53H54dNW0+aFJLoi0urgRl7ailAztZq?= =?us-ascii?Q?wrAlCuVR0Uz8Vm59mo4wHg5LPsvuSN0ptSnwXVqEj5+cZ0HDH77S6XKSrwDW?= =?us-ascii?Q?6gHFT/tK/EiG8+hGjaWLQjuW55GSpgDrxMASj6ezLRlnMc5++RTzuBJZ1FC8?= =?us-ascii?Q?AKB5cya8fThwGiT6FY9TdK3gvq7I2oked2l7BXzQjZnZaXegOqCsL7zAKbdw?= =?us-ascii?Q?XavMz9QGQFOO3enCgJ6sWzeqUtPxyQbJg+4VcwtMsoWCSuKt/x4PTVQJExJC?= =?us-ascii?Q?Maly4oZ+AClp2/P6uq7nmxTvt8c2YzG5gOz6IP2KytH04SWHA5oyU/aSB1Od?= =?us-ascii?Q?G8BAsbntw0TVx0MN7zW52MGmP6N6Q9dqt7BlGwRVs1H97gNwzQfWKAzyDOuw?= =?us-ascii?Q?/qSX2XkqL48D8wj2Dn+PHvr2AVKrEg8BG4kW3y4Drlyt6TaMgNuFJSgnN8SM?= =?us-ascii?Q?al2D1aYlkAqIr2D9kkJoBC4a++0loa3PykkJoxclXATB3BEIO3hLKV3tNrN7?= =?us-ascii?Q?1OVFKApewWJEZ80tOItj1NouiWAOHPGXJubEby8K6fMJcG9y0mAo6gU1g1lF?= =?us-ascii?Q?5nfHX+5YZfiHd3ytZ9JWWoVJvKqFBjll5edUDy/0iw9SWg2GBo+GLjstDq0u?= =?us-ascii?Q?c/EbzavJRwCr5lNNgvMqvkHnZcNXcEQP78dJjzyz7tzAGRktIHBsGxiS2acY?= =?us-ascii?Q?9wKmKwdozLzQW0ovVTYrImMTEUBgOzFZW8RRFlk4zcNfzDOjpIEIc1DHejMu?= =?us-ascii?Q?XhmhEjQJI6lvPImRVI0jMh27k8XvHh0DFuSrsv7Uf6NNYLhq6vPkdY8eKJWT?= =?us-ascii?Q?yRSACN2aTedZeLHxItjaEoxcLHBdJhtxBjwszRx5UyJksrRIiHUInI0XilhR?= =?us-ascii?Q?NfSmNmwS8TWwyyCsgBRVOsDYPzEaQh6TDM0Kf0+k/OCA3PwDmGzlo7UqFOfK?= =?us-ascii?Q?LSS9a/O0Ck4bp+siRBLOe0hoPeAJcAOH40pChP9fPqnoBY7fyJTV++v/44bR?= =?us-ascii?Q?Aw=3D=3D?= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB7636.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 03d32100-b75b-43bc-cc9e-08ddcb8c7a22 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2025 15:03:56.0902 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: YVm+Q+2IZUJIUebd406GUQlOVVhSmVC8ZstfBwz3xHp1UgKjt1kV5lqVJAH+7YJ4g5it0tJUOfOqnEd1sDnBi/Ij/PJITv/4tdOZ0okeu6E= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB4880 X-OriginatorOrg: intel.com Content-Transfer-Encoding: quoted-printable X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org Hi Andrew, Thanks a lot for the review! I have some questions for your feedback, please find my comments below. > -----Original Message----- > From: Andrew Burgess > Sent: Friday, July 25, 2025 2:50 PM > To: Schimpe, Christina ; gdb- > patches@sourceware.org > Cc: thiago.bauermann@linaro.org; luis.machado@arm.com > Subject: Re: [PATCH v5 06/12] gdb, gdbserver: Add support of Intel shadow > stack pointer register. > = > Christina Schimpe writes: > = > > This patch adds the user mode register PL3_SSP which is part of the > > Intel(R) Control-Flow Enforcement Technology (CET) feature for support > > of shadow stack. > > For now, only native and remote debugging support for shadow stack > > userspace on amd64 linux are covered by this patch including 64 bit > > and > > x32 support. 32 bit support is not covered due to missing Linux > > kernel support. > > > > This patch requires fixing the test gdb.base/inline-frame-cycle-unwind > > which is failing in case the shadow stack pointer is unavailable. > > Such a state is possible if shadow stack is disabled for the current > > thread but supported by HW. > > > > This test uses the Python unwinder inline-frame-cycle-unwind.py which > > fakes the cyclic stack cycle by reading the pending frame's registers > > and adding them to the unwinder: > > > > ~~~ > > for reg in pending_frame.architecture().registers("general"): > > val =3D pending_frame.read_register(reg) > > unwinder.add_saved_register(reg, val) > > return unwinder > > ~~~ > > > > However, in case the python unwinder is used we add a register > > (pl3_ssp) that is unavailable. This leads to a NOT_AVAILABLE_ERROR > > caught in gdb/frame-unwind.c:frame_unwind_try_unwinder and it is > > continued with standard unwinders. This destroys the faked cyclic > > behavior and the stack is further unwinded after frame 5. > > > > In the working scenario an error should be triggered: > > ~~~ > > bt > > 0 inline_func () at /tmp/gdb.base/inline-frame-cycle-unwind.c:49^M > > 1 normal_func () at /tmp/gdb.base/inline-frame-cycle-unwind.c:32^M > > 2 0x000055555555516e in inline_func () at > > /tmp/gdb.base/inline-frame-cycle-unwind.c:45^M > > 3 normal_func () at /tmp/gdb.base/inline-frame-cycle-unwind.c:32^M > > 4 0x000055555555516e in inline_func () at > > /tmp/gdb.base/inline-frame-cycle-unwind.c:45^M > > 5 normal_func () at /tmp/gdb.base/inline-frame-cycle-unwind.c:32^M > > Backtrace stopped: previous frame identical to this frame (corrupt > > stack?) > > (gdb) PASS: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 5: > > backtrace when the unwind is broken at frame 5 ~~~ > > > > To fix the Python unwinder, we simply skip the unavailable registers. > > > > Reviewed-by: Thiago Jung Bauermann > > Reviewed-By: Eli Zaretskii > > Reviewed-By: Luis Machado > > --- > > gdb/NEWS | 3 + > > gdb/amd64-linux-nat.c | 17 +++++ > > gdb/amd64-linux-tdep.c | 1 + > > gdb/amd64-tdep.c | 6 +- > > gdb/amd64-tdep.h | 1 + > > gdb/arch/amd64.c | 10 +++ > > gdb/arch/i386.c | 4 ++ > > gdb/arch/x86-linux-tdesc-features.c | 1 + > > gdb/doc/gdb.texinfo | 4 ++ > > gdb/features/Makefile | 2 + > > gdb/features/i386/32bit-ssp.c | 14 ++++ > > gdb/features/i386/32bit-ssp.xml | 11 +++ > > gdb/features/i386/64bit-ssp.c | 14 ++++ > > gdb/features/i386/64bit-ssp.xml | 11 +++ > > gdb/i386-tdep.c | 22 +++++- > > gdb/i386-tdep.h | 4 ++ > > gdb/nat/x86-linux-tdesc.c | 2 + > > gdb/nat/x86-linux.c | 57 +++++++++++++++ > > gdb/nat/x86-linux.h | 4 ++ > > gdb/testsuite/gdb.arch/amd64-shadow-stack.c | 22 ++++++ > > gdb/testsuite/gdb.arch/amd64-ssp.exp | 50 +++++++++++++ > > .../gdb.base/inline-frame-cycle-unwind.py | 4 ++ > > gdb/testsuite/lib/gdb.exp | 70 +++++++++++++++++++ > > gdb/x86-linux-nat.c | 49 +++++++++++-- > > gdb/x86-linux-nat.h | 11 +++ > > gdb/x86-tdep.c | 21 ++++++ > > gdb/x86-tdep.h | 9 +++ > > gdbserver/linux-x86-low.cc | 28 +++++++- > > gdbsupport/x86-xstate.h | 5 +- > > 29 files changed, 447 insertions(+), 10 deletions(-) create mode > > 100644 gdb/features/i386/32bit-ssp.c create mode 100644 > > gdb/features/i386/32bit-ssp.xml create mode 100644 > > gdb/features/i386/64bit-ssp.c create mode 100644 > > gdb/features/i386/64bit-ssp.xml create mode 100644 > > gdb/testsuite/gdb.arch/amd64-shadow-stack.c > > create mode 100644 gdb/testsuite/gdb.arch/amd64-ssp.exp > > > = > = > > diff --git a/gdb/amd64-linux-nat.c b/gdb/amd64-linux-nat.c index > > dbb9b3223cb..4df99ccca54 100644 > > --- a/gdb/amd64-linux-nat.c > > +++ b/gdb/amd64-linux-nat.c > > @@ -32,6 +32,7 @@ > > #include "amd64-tdep.h" > > #include "amd64-linux-tdep.h" > > #include "i386-linux-tdep.h" > > +#include "x86-tdep.h" > > #include "gdbsupport/x86-xstate.h" > > > > #include "x86-linux-nat.h" > > @@ -237,6 +238,14 @@ amd64_linux_nat_target::fetch_registers (struct > > regcache *regcache, int regnum) > > > > if (have_ptrace_getregset =3D=3D TRIBOOL_TRUE) > > { > > + if ((regnum =3D=3D -1 && tdep->ssp_regnum > 0) > > + || (regnum !=3D -1 && regnum =3D=3D tdep->ssp_regnum)) > = > It's really nit-picking, but I don't think the '>' here check is correct.= You're > checking that tdep->ssp_regnum has been assigned a value, right? And it's > default value is -1, so, shouldn't the check really be '>=3D 0' or '!=3D = -1' maybe? > > The same pattern is repeated below in ::store_registers. > = > Ahh, reading further on, I see that (not just you), but all the *_regnum = fields > in i386_gdbarch_tdep start set to 0 (which is a valid register number), b= ut are > set to -1 if the feature is not found. Maybe I'm missing something incre= dibly > clever about this ... but I suspect this code is just showing its age a l= ittle. I > still think the validity check should be against -1. Yes I agree, it seems to me that there is something inconsistent in GDB. The current default value is 0, we set all regnums to 0 initially in gdb/i3= 86-tdep.h And we set it to -1 to indicate the absence of that specific register. But on the other hand the enums (enum amd64_regnum/enum i386_regnum) defini= ng the register numbers start at 0. So that seems to be a separate issue one could consider to fix. Maybe the default should be simply -1, instead of 0 ? But for my specific patch here the best would be to compare against against= -1, I agree and will fix. > > + { > > + x86_linux_fetch_ssp (regcache, tid); > > + if (regnum !=3D -1) > > + return; > > + } > > + > > /* Pre-4.14 kernels have a bug (fixed by commit 0852b374173b > > "x86/fpu: Add FPU state copying quirk to handle XRSTOR failure on > > Intel Skylake CPUs") that sometimes causes the mxcsr location > > in @@ -302,6 +311,14 @@ amd64_linux_nat_target::store_registers (struct > regcache *regcache, int regnum) > > if (have_ptrace_getregset =3D=3D TRIBOOL_TRUE) > > { > > gdb::byte_vector xstateregs (tdep->xsave_layout.sizeof_xsave); > > + if ((regnum =3D=3D -1 && tdep->ssp_regnum > 0) > > + || (regnum !=3D -1 && regnum =3D=3D tdep->ssp_regnum)) > > + { > > + x86_linux_store_ssp (regcache, tid); > > + if (regnum !=3D -1) > > + return; > > + } > > + > > struct iovec iov; > > > > iov.iov_base =3D xstateregs.data (); > = > = > > diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo index > > 4ef640698bd..0881ac4aee5 100644 > > --- a/gdb/doc/gdb.texinfo > > +++ b/gdb/doc/gdb.texinfo > > @@ -49959,6 +49959,10 @@ The @samp{org.gnu.gdb.i386.pkeys} feature > is > > optional. It should describe a single register, @samp{pkru}. It is > > a 32-bit register valid for i386 and amd64. > > > > +The @samp{org.gnu.gdb.i386.pl3_ssp} feature is optional. It should > > +describe the user mode register @samp{pl3_ssp} which has 64 bits on > > +amd64. Following the restriction of the Linux kernel, only amd64 is > supported for now. > = > You mention a couple of times in this patch that the shadow stack is only > supported (for now) on amd64 (& x32), but you have added an i386 version > of the org.gnu.gdb.i386.pl3_ssp feature with a 32-bit pl3_ssp register. We need the 32-bit pl3_ssp register for x32, since for x32 the shadow stack= pointer has 32 bits only. > This feature is (as far as I can tell) instantiated for 32-bit targets, w= hich means > gdbserver will send out target descriptions containing this feature. > = > I think either (a) you should drop the i386 xml file and feature, or (b) = my > preferred choice, document the i386 version here. It's still fine to say= that > the 32-bit (i386) register is ignored by GDB for now though. I had a go = at > rewording the paragraph, but I'm not 100% sure its OK yet: > = > The @samp{org.gnu.gdb.i386.pl3_ssp} feature is optional. It should > describe the user mode register @samp{pl3_ssp} which has 64 bits on > amd64 and 32 bits on i386. Following the restriction of the Linux > kernel, only GDB for amd64 targets makes use of this feature for now. I missed to describe x32 here, actually. So I'd write it as follows: The @samp{org.gnu.gdb.i386.pl3_ssp} feature is optional. It should describe the user mode register @samp{pl3_ssp} which has 64 bits on amd64, 32 bits on amd64 with 32-bit pointer size (X32) and 32 bits on i386= . = Following the restriction of the Linux kernel, only GDB for amd64 targets m= akes use of this feature for now. What do you think? > = > > + > > @node LoongArch Features > > @subsection LoongArch Features > > @cindex target descriptions, LoongArch Features diff --git > > a/gdb/features/Makefile b/gdb/features/Makefile index > > 7a8c7999733..2afda1ccd00 100644 > > --- a/gdb/features/Makefile > > +++ b/gdb/features/Makefile > > @@ -225,6 +225,7 @@ FEATURE_XMLFILES =3D aarch64-core.xml \ > > i386/32bit-avx.xml \ > > i386/32bit-avx512.xml \ > > i386/32bit-segments.xml \ > > + i386/32bit-ssp.xml \ > > i386/64bit-avx512.xml \ > > i386/64bit-core.xml \ > > i386/64bit-segments.xml \ > > @@ -232,6 +233,7 @@ FEATURE_XMLFILES =3D aarch64-core.xml \ > > i386/64bit-linux.xml \ > > i386/64bit-sse.xml \ > > i386/pkeys.xml \ > > + i386/64bit-ssp.xml \ > > i386/x32-core.xml \ > > loongarch/base32.xml \ > > loongarch/base64.xml \ > > diff --git a/gdb/features/i386/32bit-ssp.c > > b/gdb/features/i386/32bit-ssp.c new file mode 100644 index > > 00000000000..991bae3c1e6 > > --- /dev/null > > +++ b/gdb/features/i386/32bit-ssp.c > > @@ -0,0 +1,14 @@ > > +/* THIS FILE IS GENERATED. -*- buffer-read-only: t -*- vi:set ro: > > + Original: 32bit-ssp.xml */ > > + > > +#include "gdbsupport/tdesc.h" > > + > > +static int > > +create_feature_i386_32bit_ssp (struct target_desc *result, long > > +regnum) { > > + struct tdesc_feature *feature; > > + > > + feature =3D tdesc_create_feature (result, > > +"org.gnu.gdb.i386.pl3_ssp"); > > + tdesc_create_reg (feature, "pl3_ssp", regnum++, 1, NULL, 32, > > +"data_ptr"); > > + return regnum; > > +} > > diff --git a/gdb/features/i386/32bit-ssp.xml > > b/gdb/features/i386/32bit-ssp.xml new file mode 100644 index > > 00000000000..d17e7004eec > > --- /dev/null > > +++ b/gdb/features/i386/32bit-ssp.xml > > @@ -0,0 +1,11 @@ > > + > > + > > + > > + > +name=3D"org.gnu.gdb.i386.pl3_ssp"> > > + > > diff --git a/gdb/features/i386/64bit-ssp.c > > b/gdb/features/i386/64bit-ssp.c new file mode 100644 index > > 00000000000..5468099ddf6 > > --- /dev/null > > +++ b/gdb/features/i386/64bit-ssp.c > > @@ -0,0 +1,14 @@ > > +/* THIS FILE IS GENERATED. -*- buffer-read-only: t -*- vi:set ro: > > + Original: 64bit-ssp.xml */ > > + > > +#include "gdbsupport/tdesc.h" > > + > > +static int > > +create_feature_i386_64bit_ssp (struct target_desc *result, long > > +regnum) { > > + struct tdesc_feature *feature; > > + > > + feature =3D tdesc_create_feature (result, > > +"org.gnu.gdb.i386.pl3_ssp"); > > + tdesc_create_reg (feature, "pl3_ssp", regnum++, 1, NULL, 64, > > +"data_ptr"); > > + return regnum; > > +} > > diff --git a/gdb/features/i386/64bit-ssp.xml > > b/gdb/features/i386/64bit-ssp.xml new file mode 100644 index > > 00000000000..a0688d018a5 > > --- /dev/null > > +++ b/gdb/features/i386/64bit-ssp.xml > > @@ -0,0 +1,11 @@ > > + > > + > > + > > + > +name=3D"org.gnu.gdb.i386.pl3_ssp"> > > + > > diff --git a/gdb/i386-tdep.c b/gdb/i386-tdep.c index > > 90ff0c5c706..8eb5b4fac86 100644 > > --- a/gdb/i386-tdep.c > > +++ b/gdb/i386-tdep.c > > @@ -8403,7 +8403,8 @@ i386_validate_tdesc_p (i386_gdbarch_tdep *tdep, > > const struct tdesc_feature *feature_core; > > > > const struct tdesc_feature *feature_sse, *feature_avx, *feature_avx5= 12, > > - *feature_pkeys, *feature_segments; > > + *feature_pkeys, *feature_segments, > > + *feature_pl3_ssp; > > int i, num_regs, valid_p; > > > > if (! tdesc_has_registers (tdesc)) > > @@ -8429,6 +8430,9 @@ i386_validate_tdesc_p (i386_gdbarch_tdep *tdep, > > /* Try PKEYS */ > > feature_pkeys =3D tdesc_find_feature (tdesc, > > "org.gnu.gdb.i386.pkeys"); > > > > + /* Try Shadow Stack. */ > > + feature_pl3_ssp =3D tdesc_find_feature (tdesc, > > + "org.gnu.gdb.i386.pl3_ssp"); > > + > > valid_p =3D 1; > > > > /* The XCR0 bits. */ > > @@ -8544,6 +8548,15 @@ i386_validate_tdesc_p (i386_gdbarch_tdep > *tdep, > > tdep->pkeys_register_names[i]); > > } > > > > + if (feature_pl3_ssp !=3D nullptr) > > + { > > + if (tdep->ssp_regnum < 0) > > + tdep->ssp_regnum =3D I386_PL3_SSP_REGNUM; > > + > > + valid_p &=3D tdesc_numbered_register (feature_pl3_ssp, tdesc_dat= a, > > + tdep->ssp_regnum, "pl3_ssp"); > > + } > > + > > return valid_p; > > } > > > > @@ -8835,6 +8848,9 @@ i386_gdbarch_init (struct gdbarch_info info, > struct gdbarch_list *arches) > > /* No segment base registers. */ > > tdep->fsbase_regnum =3D -1; > > > > + /* No shadow stack pointer register. */ tdep->ssp_regnum =3D -1; > > + > > tdesc_arch_data_up tdesc_data =3D tdesc_data_alloc (); > > > > set_gdbarch_relocate_instruction (gdbarch, > > i386_relocate_instruction); @@ -8955,13 +8971,15 @@ const struct > > target_desc * i386_target_description (uint64_t xstate_bv_mask, bool > > segments) { > > static target_desc *i386_tdescs \ > > - [2/*SSE*/][2/*AVX*/][2/*AVX512*/][2/*PKRU*/][2/*segments*/] =3D {}; > > + [2/*SSE*/][2/*AVX*/][2/*AVX512*/][2/*PKRU*/][2/*CET_U*/] \ > > + [2/*segments*/] =3D {}; > > target_desc **tdesc; > > > > tdesc =3D &i386_tdescs[(xstate_bv_mask & X86_XSTATE_SSE) ? 1 : 0] > > [(xstate_bv_mask & X86_XSTATE_AVX) ? 1 : 0] > > [(xstate_bv_mask & X86_XSTATE_AVX512) ? 1 : 0] > > [(xstate_bv_mask & X86_XSTATE_PKRU) ? 1 : 0] > > + [(xstate_bv_mask & X86_XSTATE_CET_U) ? 1 : 0] > > [segments ? 1 : 0]; > > > > if (*tdesc =3D=3D NULL) > > diff --git a/gdb/i386-tdep.h b/gdb/i386-tdep.h index > > 239bc8674e8..60d6f3eb732 100644 > > --- a/gdb/i386-tdep.h > > +++ b/gdb/i386-tdep.h > > @@ -191,6 +191,9 @@ struct i386_gdbarch_tdep : gdbarch_tdep_base > > /* PKEYS register names. */ > > const char * const *pkeys_register_names =3D nullptr; > > > > + /* Shadow stack pointer register. */ int ssp_regnum =3D 0; > = > I know all the other *_regnum fields start as 0, but I really don't under= stand > why. Surely starting as -1 would make more sense? This isn't a hard > requirement, but maybe you see some reason why these fields should start > at 0 that I'm missing? I agree. As stated before setting the regnums to -1 here by default would m= ake more sense to me. So I think I should set ssp_regnum here to -1. I'd do that, unless I see some issues with that when testing of course. The other registers set to 0 here could be fixed separately. Does that sound reasonable? > > + > > /* Register number for %fsbase. Set this to -1 to indicate the > > absence of segment base registers. */ > > int fsbase_regnum =3D 0; > > @@ -293,6 +296,7 @@ enum i386_regnum > > I386_ZMM0H_REGNUM, /* %zmm0h */ > > I386_ZMM7H_REGNUM =3D I386_ZMM0H_REGNUM + 7, > > I386_PKRU_REGNUM, > > + I386_PL3_SSP_REGNUM, > > I386_FSBASE_REGNUM, > > I386_GSBASE_REGNUM > > }; > = > = > > diff --git a/gdb/testsuite/gdb.arch/amd64-ssp.exp > > b/gdb/testsuite/gdb.arch/amd64-ssp.exp > > new file mode 100644 > > index 00000000000..6ddc875b9a3 > > --- /dev/null > > +++ b/gdb/testsuite/gdb.arch/amd64-ssp.exp > > @@ -0,0 +1,50 @@ > > +# Copyright 2018-2024 Free Software Foundation, Inc. > > + > > +# This program is free software; you can redistribute it and/or > > +modify # it under the terms of the GNU General Public License as > > +published by # the Free Software Foundation; either version 3 of the > > +License, or # (at your option) any later version. > > +# > > +# This program is distributed in the hope that it will be useful, # > > +but WITHOUT ANY WARRANTY; without even the implied warranty of # > > +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # > GNU > > +General Public License for more details. > > +# > > +# You should have received a copy of the GNU General Public License # > > +along with this program. If not, see . > > + > > +# Test accessing the shadow stack pointer register. > > + > > +require allow_ssp_tests > > + > > +standard_testfile amd64-shadow-stack.c > = > Test source files should be named to match the .exp file. But in this ca= se > 'amd64-shadow-stack' seems better than 'amd64-ssp', so I'd renamed the > .exp file to amd64-shadow-stack.exp, then this line can be just: > = > standard_testfile Yes, I agree and will fix. > > + > > +save_vars { ::env(GLIBC_TUNABLES) } { > > + > > + append_environment GLIBC_TUNABLES "glibc.cpu.hwcaps" "SHSTK" > > + > > + if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfil= e} \ > > + additional_flags=3D"-fcf-protection=3Dreturn"] } { > > + return -1 > > + } > > + > > + if {![runto_main]} { > > + return -1 > > + } > = > The 'return -1' can become just 'return'. The return value doesn't mean > anything. True will fix (also in following patches, that have the same for the test f= iles). > > + > > + # Read PL3_SSP register. > > + set ssp_main [get_hexadecimal_valueof "\$pl3_ssp" "read pl3_ssp > > + value"] > > + > > + # Write PL3_SSP register. > > + gdb_test "print /x \$pl3_ssp =3D 0x12345678" "=3D 0x12345678" "set= pl3_ssp > value" > > + gdb_test "print /x \$pl3_ssp" "=3D 0x12345678" "read pl3_ssp value= after > setting" > > + > > + # Restore original value. > > + gdb_test "print /x \$pl3_ssp =3D $ssp_main" "=3D $ssp_main" "resto= re > original pl3_ssp" > > + > > + # Potential CET violations often only occur after resuming normal > execution. > > + # Therefore, it is important to test normal program continuation a= fter > > + # configuring the shadow stack pointer. > > + gdb_continue_to_end > = > I assume that if we continue with the bogus value in place the inferior w= ould > either give an error or terminate. Is it worth trying this and checking = that the > inferior behaves as expected? If we don't reset the shadow stack pointer to it's original value we will s= ee a SEGV. = Dependent on the address of the wrong shadow stack pointer it's either a SE= GV with si code that points to a control flow protection fault or a different = si code. So if I stay in a valid address range for configuring pl3_ssp but don't res= tore the original value I'll see a control flow protection exception: [...] breakpoint 1, 0x0000555555555148 in main ()^M (gdb) print /x $pl3_ssp^M $1 =3D 0x7ffff7bfffe8^M (gdb) PASS: gdb.arch/amd64-ssp.exp: get hexadecimal valueof "$pl3_ssp" print /x $pl3_ssp =3D 0x7ffff7bfffe0^M $2 =3D 0x7ffff7bfffe0^M (gdb) PASS: gdb.arch/amd64-ssp.exp: set pl3_ssp value print /x $pl3_ssp^M $3 =3D 0x7ffff7bfffe0^M (gdb) PASS: gdb.arch/amd64-ssp.exp: read pl3_ssp value after setting continue^M Continuing.^M ^M Program received signal SIGSEGV, Segmentation fault.^M 0x0000555555555158 in main ()^M (gdb) FAIL: gdb.arch/amd64-ssp.exp: continue until exit Siginfo shows si_code =3D 10, which indicates a control protection fault. p $_siginfo^M $4 =3D {si_signo =3D 11, si_errno =3D 0, si_code =3D 10, [...] If I set the value of pl3_ssp as in the current test (0x12345678) I'll see = a different SEGV actually p $_siginfo $4 =3D {si_signo =3D 11, si_errno =3D 0, si_code =3D 1, [...] > = > What if, say, the $pl3_ssp value only ever made it as far as the register= cache, > and was never actually written back to the inferior? I don't think the a= bove > test would actually spot this bug, right? Hm, if I understand you correctly here and you mean the scenario as shown above the above test would spot this bug I think (as we saw a fail). Does my example above show what you described or do you mean a different sc= enario? Regards Christina Intel Deutschland GmbH Registered Address: Am Campeon 10, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Sean Fennelly, Jeffrey Schneiderman, Tiffany Doon Silva Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928