From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id Fl4TJKFii2gP0gAAWB0awg (envelope-from ) for ; Thu, 31 Jul 2025 08:33:37 -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=QyK1XdwV; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 86FA21E102; Thu, 31 Jul 2025 08:33:37 -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 EFBC01E091 for ; Thu, 31 Jul 2025 08:33:33 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 93F61385840D for ; Thu, 31 Jul 2025 12:33:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 93F61385840D 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=QyK1XdwV Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.17]) by sourceware.org (Postfix) with ESMTPS id B854B3858D1E for ; Thu, 31 Jul 2025 12:32:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B854B3858D1E 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 B854B3858D1E Authentication-Results: server2.sourceware.org; arc=fail smtp.remote-ip=198.175.65.17 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1753965166; cv=fail; b=AGqQ7gTPU85+ikPg8SqudY/N5W8/Bj2SUugKUIe08D5GMfKJ9KxMs0c2f+/KYzyAXLi5JAMqBJiliuLgsr//S6avv2zFVOIKGmUUFX4JL/fDuStf3aa0RgEpIEKiwaoYdLVlnCrPFo7Vf7LOZNVAuyPWjF+Y4oY9yKJC8L/CxpY= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1753965166; c=relaxed/simple; bh=kvtriCHnmAvArAOTZYp8XO64p5JSknaAN1A/xp6kbkM=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=V/FK7Yps/3QlmG5lCYlhev1XjzQUppROy7TxymxKhUy5rUrUr6E4oaO6u/vm8137+v2Ixnwjaf61asJvsG7yY5BxEhQ7m0CW/97XWI6a75T9hlCb4cFGT9Zjl3leTyXWtBwzkJMa86XO2m8VORri83ibSus/cS5CEdWu434Toh4= ARC-Authentication-Results: i=2; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B854B3858D1E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1753965166; x=1785501166; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version:content-transfer-encoding; bh=kvtriCHnmAvArAOTZYp8XO64p5JSknaAN1A/xp6kbkM=; b=QyK1XdwV5nsipUTrfQEGmOjdZjKnQlfMxUrB1Z7e0DLbf8gxvH/Scrcp U4PkerJvVrQiTxZyQFcJphnbBjVVFZDw5eS8PpEOfiM7cSPfWAFDXUXaR LNOnaVtrM7qOIE8/Spez7sqM3g53uRo3t7tjFkemvM58DjEoxEwi5Afp5 UYAO26P74SJNkzbjukxxR27LvZG3O4OWRkCox64Aiim12Gds4/k8l4Snd B0Fun+HyNpHB6k8flYP5ZoZ/xRFmvnq9b/Nll8BoeNPjXXsf6HXPrjj/p RmhDW+dCB/3K+xSxhX1yPN5edOneUBSdFnhAtnTHoNA/OOo/L72THiJbP w==; X-CSE-ConnectionGUID: Xj1r7HynQnOvFiS6laGx6Q== X-CSE-MsgGUID: U3KhWPkPTVakrOqxR9j+hw== X-IronPort-AV: E=McAfee;i="6800,10657,11508"; a="56250287" X-IronPort-AV: E=Sophos;i="6.17,353,1747724400"; d="scan'208";a="56250287" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by orvoesa109.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Jul 2025 05:32:45 -0700 X-CSE-ConnectionGUID: AvFHkH9qTa+2IXFJlrA5qQ== X-CSE-MsgGUID: boPnewVySJ6CMnageQye+Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.17,353,1747724400"; d="scan'208";a="164049040" Received: from orsmsx902.amr.corp.intel.com ([10.22.229.24]) by fmviesa010.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Jul 2025 05:32:44 -0700 Received: from ORSMSX901.amr.corp.intel.com (10.22.229.23) by ORSMSX902.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1748.26; Thu, 31 Jul 2025 05:32:43 -0700 Received: from ORSEDG901.ED.cps.intel.com (10.7.248.11) 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; Thu, 31 Jul 2025 05:32:43 -0700 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (40.107.223.44) by edgegateway.intel.com (134.134.137.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1748.26; Thu, 31 Jul 2025 05:32:43 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=tc+kvqCg81xdurHUWahgiwT521gfQO3PG/IIcNdtvhRbYPl4Knhn75GnVadRoO9h4JSuU1OLBUlE/5zWwL0VxmMrlbU8QcSb6ogcOFXJhTNpI+ZYIK9ZumfqBOzOFBuPKqMPmgZKimxHOeICM19KTef6fJaDhsuT60J9gBJyZjJy9mzirofvtg18IWvOhkccIJf91GutpGamb+GLSw/FAv+TSdC90nbNqRXHwpZueQyoK75aZjltAJhGPnmDePH7OEL2r9ftTCTe5rndFM1ySHEJYxXNV87pPKNNVo3eTKDYQcSo99+OlCA5Jz8PdmbW9gDxXhO5nM/k99IgIPOOOQ== 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=OUTOlriSZjyz+qo9yDPoHN19ex6NzzIP7rp6OXS5s9Y=; b=JisJyoWZyBJ8ITUzC6osHrmbbJGzs0P3TcBc2yQC3Ln2qWeSJh8OVgrfC8AjPsnJKrmoCvngecZ6R1YeIUvrO4YzX2c8n2eyezithO4y4ZdOwF1NR16ZsZqWg4lYtP9tQN2yJD+UI8Olha0y0OEF1X4frtLviBhxQMCVMeZIUfEG+5QTEIXpw+qiJufG7uUIFnVOedChilyv5QriR/6s28E/X/2PlcQ+czT82FkyTMNeLV8qePrJOhb53hRK1L8mE8Zg21pXy5NdSSEvVRR4a03LCHhuf/ySFSBULDCyg4zWOvmXOeLq/exFHK21GlkRtjSDLm+ILBtBMjE8Gy1JMQ== 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 SN7PR11MB7638.namprd11.prod.outlook.com (2603:10b6:806:34b::22) by PH7PR11MB7661.namprd11.prod.outlook.com (2603:10b6:510:27b::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8989.11; Thu, 31 Jul 2025 12:32:13 +0000 Received: from SN7PR11MB7638.namprd11.prod.outlook.com ([fe80::25b8:16dc:755e:34d1]) by SN7PR11MB7638.namprd11.prod.outlook.com ([fe80::25b8:16dc:755e:34d1%5]) with mapi id 15.20.8964.023; Thu, 31 Jul 2025 12:32:13 +0000 From: "Schimpe, Christina" To: Andrew Burgess , "gdb-patches@sourceware.org" CC: "thiago.bauermann@linaro.org" , "luis.machado@arm.com" Subject: RE: [PATCH v5 10/12] gdb: Implement amd64 linux shadow stack support for inferior calls. Thread-Topic: [PATCH v5 10/12] gdb: Implement amd64 linux shadow stack support for inferior calls. Thread-Index: AQHb6AcubkybuDLxKkGcicQboV5SXrRKwmQAgABB0yA= Date: Thu, 31 Jul 2025 12:32:13 +0000 Message-ID: References: <20250628082810.332526-1-christina.schimpe@intel.com> <20250628082810.332526-11-christina.schimpe@intel.com> <87freddh63.fsf@redhat.com> In-Reply-To: <87freddh63.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: SN7PR11MB7638:EE_|PH7PR11MB7661:EE_ x-ms-office365-filtering-correlation-id: 6ed51dad-c265-4dac-fb26-08ddd02e46c3 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; ARA:13230040|1800799024|366016|376014|38070700018; x-microsoft-antispam-message-info: =?us-ascii?Q?8pUYDSy7y7YiW7G8n/a7DqREiegMZAEIqoWMKwZ47w6Y15848ZHVZ4H9gA9Z?= =?us-ascii?Q?DjrSyz1WhX9TfXdr3+zBRobypXbAZsT3yyvH5o890lVlNWil6daYak6Ksjm3?= =?us-ascii?Q?8paZPAUTsZw2fK58Xc3rO8s5qZ1+Oeo+/vN6Ad8XYYB8EWvLS74abVyh9NBS?= =?us-ascii?Q?4xWOHZkdTH0fAMqj0PB8H59yJpekHbwGdy1L5PzXs37CmjbeA6pgAHU/QDc/?= =?us-ascii?Q?H3Ip26vSVSArLZtMdfTcndnYFsE4eT/iZ6tJppQJZOYco5voM6V4QHCFyZz2?= =?us-ascii?Q?8WaiN6CY+JjB7bre6wsFp5SaJsF/RuH04MRChgudgdk2/XkmXYU12gj/61mc?= =?us-ascii?Q?Vj0NO6k8EeAnEpS28sXLASokRakGhGvKtSRJ770onKG4ZVZtnAAjwBBvctu4?= =?us-ascii?Q?r5gVAu6ZcdGojwheHfSbWjpsWCtKWNhzlz2oQKc3SW3MxFZ5s77XsNmxxnRz?= =?us-ascii?Q?SP/f7dCM00gcLBO1cXI9VDVPQj/d/7dff3+w5GeNq5DY1GtogihAEV+9NvhB?= =?us-ascii?Q?yFbbPrIJCNWvdzgAkvf9Ls60dBIrVjRWS2HKUbYvl8nepPWRCKLgvD8vqv3U?= =?us-ascii?Q?8Jd2tC0ObgLeYgfK9v4KXEl2Yc+Dov7MnUex5Q73H6/YaDZFocRSYOHqSROQ?= =?us-ascii?Q?WbWoZ81pTdoCPBA251ZmxxH6VKaHI5m6ZRy05jJWqvOKsRjhuXwdkO0gWj8I?= =?us-ascii?Q?taguVWOuBJVU2dr0Q4wwIvnvTIgED+4Z3i+a6bJwTGrEMczofZlg2tvKRnu1?= =?us-ascii?Q?fdT0OZfnhaVAzT6RcWva+H5Jd3SLjkPOYVLH1RtYO6MIKogjjVEvLLw/0HTQ?= =?us-ascii?Q?KQf0MdiG0pT/eoNzxLrlrFNuIajeUyE5Mu7BP5RR57Ewge4C9Rv4XZ5w6oXC?= =?us-ascii?Q?3KzwNBxB9OTSDKMgLMUniG6vHd9a0V0j6MyOHJ0pLgYpyVyWXJV7oBC2PjF0?= =?us-ascii?Q?y57/A2TfhJCJ2SMQikdmls7gXTVN8WALbkQWUEylEmgaG9/hNdX8XMAweQt7?= =?us-ascii?Q?gQj/OvjWyAXvWHJkPA8PjKyj6Qhr6WOf253CfSfnSpTTg7pXJK6MCQtyiPeR?= =?us-ascii?Q?iWumJt/j9W2k/RClJQB6+rcIlZCuANrX+upG4SeZsC5vEngmXXdVzQVWJWzT?= =?us-ascii?Q?cLu5w4LdZMV7mZ0doVPWzNEJSYOWjYLWusdznLHI1w+IkmFbq8NRIwcgdXAU?= =?us-ascii?Q?gwBC5q7rHllbPhULamppCL2UHEcXw9ABkEbNKgMc3wOeHKKCZYPAbKOG4+YR?= =?us-ascii?Q?WsZMoWdpc9x09K+RaCeHcC0cvPBrgkd/KKuFfmjE5HiddL6you6FyEE+HJ5W?= =?us-ascii?Q?HwzYuSN+U5/O0Ly+or8OqyM5ofpJHiW1TNH59BfdDh4/+wyZfGMw/SL3Suab?= =?us-ascii?Q?YPmDb8xKSIl0Xb942Z3UuHf/scocKuNmK06Eq/A5ncXU6xzJt2qdW7N/wAD6?= =?us-ascii?Q?9zt6uwDGnJrJWkUa80XebzapsCfmOYmQaM+UMSi82T9kFBLC6/sk0Wkt/Jxh?= =?us-ascii?Q?mbvU51eI+j5QerI=3D?= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN7PR11MB7638.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(1800799024)(366016)(376014)(38070700018); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?YXkpPG8yoXD4vN13Y2puT3BtKuBGYAfJaaJivowjVoYLvmI9ZGMZbSKw8ptu?= =?us-ascii?Q?9zO97L2uZN8VoyyhH/1FdU8xrnWD0YPqmbG4wrgweLaZCvpy2z/ZgYRTLVld?= =?us-ascii?Q?m3Z+NfMhPaLz9wLc3ZRTT0xpTBj9eZC50yofLOg5kOeuhOJWIfe/0bHDAXGg?= =?us-ascii?Q?rNjMITPTCj00l5DQX9WwUvNpaCkc7ZYFqJYvE8lJm+Xg76PENFTmlzXMQ7xG?= =?us-ascii?Q?MVMEmPH9B/VEoBHIT5DimfH1ucvFD/MG2HvGV3u4FHH5ncx5A5ay/nKD9Wqq?= =?us-ascii?Q?YJZpBUfNAk4hFronVIiSH4dvU6PQvZZkEHCz6D1DEDrhNeCMAJ7DAd4RO/2s?= =?us-ascii?Q?rwlsZohyXzmP5eQ202R+GRtKqiULZXd1WLyl9LEy+7B1W2dlzgBdIBBJwO0P?= =?us-ascii?Q?wDpAX2qJTEAqUVrm0Ust1t/J47zbrZnNv4rGpoIi5i8KPMVDd5tI0SlBItx9?= =?us-ascii?Q?xdMLOpJY0yskxFgEUR04zNEAlMu1hxE3gOklVNkucl9V4auUpu+pjKjgO1wB?= =?us-ascii?Q?ITNTH7BWvhYhfQG25JrccEHRtktVYhwXCwPY+mwe5NsLn5oEvrldqb0mNUqw?= =?us-ascii?Q?2NZb0rI55hf+Njwn5+j/Vn9b/Zh3pJKssjyz23OtnVN8eQJ8ifOLlbsVrHZ2?= =?us-ascii?Q?3o1k2xU/4H+n0sXh7nQVStX5EREesuyg/05Ah8pP1VFdcQpu6nA0lfMea20C?= =?us-ascii?Q?cuBlRHCc9qB4lpxCqBw0LcaSTx0Z4cW86KQJSK8AZoeWxazaFIchMv1vufBV?= =?us-ascii?Q?xaSkXy2i8g9UjG/DYgWkyrhhmn3xx6BFRBHsiXTcrB7SHO40PlgtpDyki1lt?= =?us-ascii?Q?vMXtUMsEr1lqZ1yjM7DVsIRTZQDdt3dSbkHtNBp2CdJ/qArXrvpcyy6a7HKj?= =?us-ascii?Q?/P/KSXYUY6HGwfPfNsJqj9IJlhokZuBweAsiViLaxA/QVfomgf2lllP517Bp?= =?us-ascii?Q?E8U8Y3hJbI2ZmhD/v4vrNUm6iPN9oIa0m+0ksFTvg6l0X7148n/R1aCtDo1K?= =?us-ascii?Q?UBQRiGY5vZIVCMeZHSDlsojG7j6JDiHd34LWIl51AiLXLu2wBssb+qVCbC8d?= =?us-ascii?Q?Qgfonz+6lSwfzUeFxuLJlsmE4TDCyw0ZmgDHorXs2RQfSWS8McJTz7UP9N27?= =?us-ascii?Q?ryVGa6O0Owha/Vy4R+WvCla4L3PktSnfB1CGZpRod18Uzu6n2jOT3UdEij+N?= =?us-ascii?Q?TpSZ4WNlHbitqjSXQe6Sn+zhb5c4/TveJPoY5Qn9h38hkHCffe+cS+OYY6hj?= =?us-ascii?Q?ERuTRFGXtecz3ARw6rHBhP+HagtdPtTbCIqeIk/egZijwlHw5uhVSnLuk7sX?= =?us-ascii?Q?oE2ywzuIiJfsOJ921nI+0qWLPAfxjnE25UhXIlg/zBGgCNSn8roEZ18XqZPU?= =?us-ascii?Q?AGmrRLXmWaiR9GUJgUIj1gTcbAlw2d/L0UaPiDd0YM3L39GYKM2lv+I1WXRz?= =?us-ascii?Q?G+bbca4xg4dQggDm491lCfldpYTkuFImUbEfSVmoNGVXhCZv5mlUlLSCaFKb?= =?us-ascii?Q?8JRcXdCmUC96YXj8atiVP7Vc4337jFGiCeHlvncRl2ipoPj8cA/gMiUhyVB7?= =?us-ascii?Q?kbh3PEsE+rNFAFpphbTWxhd/4eNSNsdWk/IxvDcqm1d49xe/HgOKyeqHv3AG?= =?us-ascii?Q?LA=3D=3D?= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN7PR11MB7638.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6ed51dad-c265-4dac-fb26-08ddd02e46c3 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2025 12:32:13.0401 (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: CK4vhLgwhwnm2zCKXTJKa/s5zo+5vrv/+sHBKyep575Up29fGGEWa5Sf7S6R6LVeDgAreMBOYC26Sv69UuaFp4StHvYLbkjVyJvyTSyBnzw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB7661 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. Please find my comments to your feedback below. > -----Original Message----- > From: Andrew Burgess > Sent: Wednesday, July 30, 2025 1:58 PM > To: Schimpe, Christina ; gdb- > patches@sourceware.org > Cc: thiago.bauermann@linaro.org; luis.machado@arm.com > Subject: Re: [PATCH v5 10/12] gdb: Implement amd64 linux shadow stack > support for inferior calls. > = > Christina Schimpe writes: > = > > This patch enables inferior calls to support Intel's Control-Flow > > Enforcement Technology (CET), which provides the shadow stack feature > > for the x86 architecture. > > Following the restriction of the linux kernel, enable inferior calls > > for amd64 only. > > > > Reviewed-by: Thiago Jung Bauermann > > Reviewed-By: Eli Zaretskii > > Reviewed-By: Luis Machado > > --- > > gdb/amd64-linux-tdep.c | 63 +++++++++++++++++++ > > gdb/doc/gdb.texinfo | 29 +++++++++ > > .../gdb.arch/amd64-shadow-stack-cmds.exp | 55 +++++++++++++++- > > 3 files changed, 146 insertions(+), 1 deletion(-) > > > > diff --git a/gdb/amd64-linux-tdep.c b/gdb/amd64-linux-tdep.c index > > f6ae5395870..899fe2df02c 100644 > > --- a/gdb/amd64-linux-tdep.c > > +++ b/gdb/amd64-linux-tdep.c > > @@ -1932,6 +1932,67 @@ > amd64_linux_shadow_stack_element_size_aligned (gdbarch *gdbarch) > > return (binfo->bits_per_word / binfo->bits_per_byte); } > > > > +/* Read the shadow stack pointer register and return its value, if > > + possible. */ > > + > > +static std::optional > > +amd64_linux_get_shadow_stack_pointer (gdbarch *gdbarch, regcache > > +*regcache) { > > + const i386_gdbarch_tdep *tdep =3D gdbarch_tdep > > +(gdbarch); > > + > > + if (tdep =3D=3D nullptr || tdep->ssp_regnum < 0) > > + return {}; > = > We don't check for 'tdep =3D=3D nullptr' anywhere else (for x86), so I do= n't think > this check is needed. If you _really_ want you could gdb_assert, but I'm > pretty sure you'll have crashed long before now if tdep =3D=3D nullptr. I agree and will remove. > > + > > + CORE_ADDR ssp; > > + if (regcache_raw_read_unsigned (regcache, tdep->ssp_regnum, &ssp) > > + !=3D REG_VALID) > > + return {}; > > + > > + /* Dependent on the target in case the shadow stack pointer is > > + unavailable, the ssp register can be invalid or 0x0 when shadow s= tack > > + is supported by HW and the linux kernel but not enabled for the > > + current thread. */ > = > Just so I understand, is the 0 coming from actual inferior state? Or is = the 0 > creeping in from somewhere in GDB when we should be creating an > unavailable value, but get it wrong? > = > Using 0 a magic address value is something I really dislike (having worke= d on > targets where 0 is a valid address), so they always make me uncomfortable. > If this is an actual h/w thing then there's nothing we could or should do > about it ... but if this is a GDB thing, then maybe we can fix that? We see this dependent on the linux kernel version. So the value 0x0 is set = by the kernel I think. With kernels older than 6.13 we shouldn't see this anymore, due to this pat= ch: https://github.com/torvalds/linux/commit/a9d9c33132d49329ada647e4514d210d15= e31d81 > = > > + if (ssp =3D=3D 0x0) > > + return {}; > > + > > + return ssp; > > +} > > + > > +/* If shadow stack is enabled, push the address NEW_ADDR to the > shadow > > + stack and increment the shadow stack pointer accordingly. */ > > + > > +static void > > +amd64_linux_shadow_stack_push (gdbarch *gdbarch, CORE_ADDR > new_addr, > > + regcache *regcache) > > +{ > > + std::optional ssp > > + =3D amd64_linux_get_shadow_stack_pointer (gdbarch, regcache); > > + if (!ssp.has_value ()) > > + return; > > + > > + /* The shadow stack grows downwards. To push addresses to the stack, > > + we need to decrement SSP. */ > > + const int element_size > > + =3D amd64_linux_shadow_stack_element_size_aligned (gdbarch); const > > + CORE_ADDR new_ssp =3D *ssp - element_size; > > + > > + /* Using /proc/PID/smaps we can only check if NEW_SSP points to > shadow > > + stack memory. If it doesn't, we assume the stack is full. */ > > + std::pair memrange; if > > + (!linux_address_in_shadow_stack_mem_range (new_ssp, &memrange)) > > + error (_("No space left on the shadow stack.")); > > + > > + /* On x86 there can be a shadow stack token at bit 63. For x32, > > + the > = > I don't understand this first sentence and how it relates to either the r= est of > the comment, or the following code. Yes, this is confusing I agree. I guess all what I wanted to say is that we= have to write the full 8 bytes due to the token even though the actual address of t= he shadow stack pointer is only 4 bytes for x32. Example shadow stack token for x32 in frame #1: bt shadow^M #0 0x00000000f7d22040 in __restore_rt from /libx32/libc.so.6^M #1 0x80000000f7ce6fd8^M #2 0x00000000f7d21f8b in raise from /libx32/libc.so.6 The output is taken from a patch for the "bt shadow" command, which is not part of this series. = How about: On x86 there can be a shadow stack token at bit 63. For x32, the address size is only 32 bit. Always write back the full 8 bytes to include the shadow stack token. > = > > + address size is only 32 bit. Thus, we must use ELEMENT_SIZE (and > > + not gdbarch_addr_bit) to determine the width of the address to be > > + written. */ > > + const bfd_endian byte_order =3D gdbarch_byte_order (gdbarch); > > + write_memory_unsigned_integer (new_ssp, element_size, byte_order, > > + (ULONGEST) new_addr); > > + > > + i386_gdbarch_tdep *tdep =3D gdbarch_tdep > > + (gdbarch); regcache_raw_write_unsigned (regcache, tdep->ssp_regnum, > > + new_ssp); > = > By this point we know that tdep->ssp_regnum must be a valid regnum. But > the checks for that are in a separate function, so maybe we should: > = > gdb_assert (tdep->ssp_regnum > -1); Good idea, will add. > = > > +} > > > > /* Implement shadow stack pointer unwinding. For each new shadow > stack > > pointer check if its address is still in the shadow stack memory ra= nge. > > @@ -2059,6 +2120,8 @@ amd64_linux_init_abi_common(struct > gdbarch_info > > info, struct gdbarch *gdbarch, > > > > set_gdbarch_remove_non_address_bits_watchpoint > > (gdbarch, amd64_linux_remove_non_address_bits_watchpoint); > > + > > + set_gdbarch_shadow_stack_push (gdbarch, > > + amd64_linux_shadow_stack_push); > > dwarf2_frame_set_init_reg (gdbarch, amd64_init_reg); } > > > > diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo index > > 0881ac4aee5..b5120b78426 100644 > > --- a/gdb/doc/gdb.texinfo > > +++ b/gdb/doc/gdb.texinfo > > @@ -27037,6 +27037,35 @@ registers > > > > @end itemize > > > > +@subsubsection Intel Control-Flow Enforcement Technology. > > +@cindex Intel Control-Flow Enforcement Technology. > > + > > +The @dfn{Intel Control-Flow Enforcement Technology} (@acronym{Intel > > +CET}) provides two capabilities to defend against ``Return-oriented > Programming'' > > +and ``call/jmp-oriented programming'' style control-flow attacks: > > + > > +@itemize @bullet > > +@item Shadow Stack: > > +A shadow stack is a second stack for a program. It holds the return > > +addresses pushed by the call instruction. The @code{RET} instruction > > +pops the return addresses from both call and shadow stack. If the > > +return addresses from the two stacks do not match, the processor > > +signals a control protection exception. > > +@item Indirect Branch Tracking (IBT): > > +When IBT is enabled, the CPU implements a state machine that tracks > > +indirect @code{JMP} and @code{CALL} instructions. The state machine > > +can be either IDLE or WAIT_FOR_ENDBRANCH. In > WAIT_FOR_ENDBRANCH > > +state the next instruction in the program stream must be an > > +@code{ENDBR} instruction, otherwise the processor signals a control > protection exception. > = > If I understand it, the IBT doesn't currently have an impact on GDB, righ= t? > The inferior function being called likely starts with an `endbr` instruct= ion, but > GDB will just leave the IBT mechanism in the IDLE state, and the endbr wi= ll > be interpreted as a nop. There is no linux kernel support for IBT in userspace, yet. > = > I also found this description a little too light on the details. Just ha= ving the > name was enough to go and find the real docs, but I think the text could = be > made cleared with two additional sentences: > = > @item Indirect Branch Tracking (IBT): > When IBT is enabled, the CPU implements a state machine that tracks > indirect > @code{JMP} and @code{CALL} instructions. The state machine can be > either IDLE > or WAIT_FOR_ENDBRANCH. When a @code{JMP} or @code{CALL} is > executed > the state machine chages to the WAIT_FOR_ENDBRANCH state. In > WAIT_FOR_ENDBRANCH state the next instruction in the program stream > must be an @code{ENDBR} instruction, otherwise the > processor signals a control protection exception. After executing a > @code{ENDBR} instruction the state machine returns to the IDLE state. > = > This change isn't a hard requirement, but I do think this makes the > description more useful. I agree, your suggestion improves the description, thank you. Will improve = the docs here. > > +@end itemize > > + > > +Impact on Call/Print: > > +Inferior calls in @value{GDBN} reset the current PC to the beginning > > +of the function that is called. No call instruction is executed, but > > +the @code{RET} instruction actually is. To avoid a control > > +protection exception due to the missing return address on the shadow > > +stack, @value{GDBN} pushes the new return address to the shadow stack > and updates the shadow stack pointer. > > + > > @node Alpha > > @subsection Alpha > > > > diff --git a/gdb/testsuite/gdb.arch/amd64-shadow-stack-cmds.exp > > b/gdb/testsuite/gdb.arch/amd64-shadow-stack-cmds.exp > > index 17f32ce3964..622612d2f7d 100644 > > --- a/gdb/testsuite/gdb.arch/amd64-shadow-stack-cmds.exp > > +++ b/gdb/testsuite/gdb.arch/amd64-shadow-stack-cmds.exp > > @@ -13,12 +13,29 @@ > > # You should have received a copy of the GNU General Public License > > # along with this program. If not, see . > > > > -# Test shadow stack enabling for frame level update and the return > command. > > +# Test shadow stack enabling for frame level update, the return and > > +the # call commands. > > +# As potential CET violations often only occur after resuming normal > > +# execution, test normal program continuation after each return or > > +call # commands. > > > > require allow_ssp_tests > > > > standard_testfile amd64-shadow-stack.c > > > > +proc restart_and_run_infcall_call2 {} { > = > There should be a comment before each proc please. True, will add. Thanks! 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