From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by mx.groups.io with SMTP id smtpd.web10.1861.1681535080768135145 for ; Fri, 14 Apr 2023 22:04:40 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="unable to parse pub key" header.i=@intel.com header.s=intel header.b=kPWEm/0/; spf=pass (domain: intel.com, ip: 134.134.136.126, mailfrom: ray.ni@intel.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1681535080; x=1713071080; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gxaSGiCpq0wSPaeXZMTJYILZpsqpyW3wjvBEozQBMHc=; b=kPWEm/0/m6S2pwU5pwCEUzrHv1YMSDjmyyjcxshIqL7BToQMArQrRIiM 5pfC23vxe4yxI5D40TFodbf+tEV8zsgol3fUbRujcxguNJ4ARYdRgckr1 kMYKRROwFpzY+qMHnFWQIzjGAPVAXpsoqjjJ5lDLZiZ+mFTqxBRyFUvTw sQjSmvU+ym6SMNDh8FWQKIgcu2RhUAvYFXRpv0DXpHIw4gEV3wqPperPX 8bvvVPUgSEwaJWbyCjtKKJybUQAb+gu1mOfg1837gU8PT4/3mP2an1+0Y khCS+PIFcrwrgVR2isfh6IVEDLA+rVmN4WnPMb0JzGq1Ks7s7HQ/wDlMs Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10680"; a="328772763" X-IronPort-AV: E=Sophos;i="5.99,199,1677571200"; d="scan'208,217";a="328772763" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Apr 2023 22:04:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10680"; a="722689030" X-IronPort-AV: E=Sophos;i="5.99,199,1677571200"; d="scan'208,217";a="722689030" Received: from orsmsx601.amr.corp.intel.com ([10.22.229.14]) by orsmga001.jf.intel.com with ESMTP; 14 Apr 2023 22:04:39 -0700 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Fri, 14 Apr 2023 22:04:39 -0700 Received: from orsmsx611.amr.corp.intel.com (10.22.229.24) by ORSMSX610.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Fri, 14 Apr 2023 22:04:39 -0700 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx611.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23 via Frontend Transport; Fri, 14 Apr 2023 22:04:39 -0700 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.102) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.23; Fri, 14 Apr 2023 22:04:39 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W5C3dKX15YJA2a5gz77dZt0Hqq3+Oq3t1T6q7pHhg0u1KYIWw0XACQBaZViCIu7a+lzC/ogZ/xCajCN0hyOiiw6hqhD7Q8e0w3reJ6ndcVGA3XBlfKJCTU9YjOflTpV80PeGiRzz702xBDpIQGXvhGWBHaGuRXp8vW6BLHM8MKLuf4nmGDkPAr5btwRIFxZFAlaHxsVcPOCveIDoWNwNMgqjrQmPfaIjW4LWzioApvgx6SRvqIf6a1ta80kmJSgwu14ARSZUCQCePIqUBiyYOE+zSuOOGFbDPgBWk4ekeHxVX7XHNBYa/JU9YCPL5NKgIUdqxyimUJGl0UKsgEmVSw== 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=aJSymK78v5B6ttkpQlNUm0Zm0fzcrjmd7oD0RWqSSik=; b=HWVcgnlKe12QjekP9k6ufoqgUT5T4m1vjYpTdNS1fH4G/rDAKXkaTJXojdjFpfS5MbRj/l5t6MZ72z3SNg0WbLUkGMF7Y61tKX3kmWjIEsHFJp2m2/9hBUl/yblju9NGvu/RP59GYkWqrJzLY61dYb+GOWt9xoLBWlLfIMt7lg7wos7lsVxNH00v+o5D5iDqf+eHxaQmtv+I/3hezg2unv+/DmR3AJxbAsxgY6pbNamHzn5rm5FgT9MMp/EIUDVHtadi+Ik2PEGsrWCYj5aDHIFu3UACFI25wklsIgaovEyTIs5UmJBfyX9m1LaGSZBICXALPXqtLakQ7rWKp5JfYw== 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 MN6PR11MB8244.namprd11.prod.outlook.com (2603:10b6:208:470::14) by PH0PR11MB5207.namprd11.prod.outlook.com (2603:10b6:510:32::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6298.30; Sat, 15 Apr 2023 05:04:37 +0000 Received: from MN6PR11MB8244.namprd11.prod.outlook.com ([fe80::892b:b8e6:bab7:635d]) by MN6PR11MB8244.namprd11.prod.outlook.com ([fe80::892b:b8e6:bab7:635d%5]) with mapi id 15.20.6298.030; Sat, 15 Apr 2023 05:04:36 +0000 From: "Ni, Ray" To: "devel@edk2.groups.io" , "Ni, Ray" , "thomas.lendacky@amd.com" , "Ard Biesheuvel" CC: Gerd Hoffmann Subject: Re: [edk2-devel] Strange behavior between GCC 11 and GCC 12 Thread-Topic: [edk2-devel] Strange behavior between GCC 11 and GCC 12 Thread-Index: AQHZbw7yIYQebiLAmki+rXPudQEMCK8rVRiAgAADB4CAADGXcoAAR2Mw Date: Sat, 15 Apr 2023 05:04:36 +0000 Message-ID: References: <7f0f5f8e-09c7-4ae4-ffca-1a7c322949a8@amd.com> <9057b932-b10b-c2cd-af8c-ea0db5120bfc@amd.com> <1755F557A60CA0E1.29871@groups.io> In-Reply-To: <1755F557A60CA0E1.29871@groups.io> Accept-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: MN6PR11MB8244:EE_|PH0PR11MB5207:EE_ x-ms-office365-filtering-correlation-id: 06c55e4a-7f28-4f7e-b818-08db3d6ee912 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jJBQ7xvgRjwNupdq/1ltwBF9vNY7ifCLk52qgHcI1BFou6RuGl6zq20Bp/H02mvmW7jzHmiOcDFNXbGsfDReIVGOZZwdvxOP65fWX2eFN16gii81uKRQvI1fgLikImxTwjIMNiTUmoGXYirQiLC/QYIu7kSdVP1mzB6XKqwaJ1bqQq2v21BLiSty9b5qsVhvNZ6VCKcdHIfMqNsXk1Qn0l6h6/eJxerJCZ2i9SKouFK8Gqp1blYaaPri4cZhKsVSU6Zv0y35YYL8MnxCAYud+tiEVM4pX//NbxNXk1A4ox8p7ZudArWPrcCHAjjUblqpdX3YvaWIBeeuu/gQcyweX+L4GfJa9QQniYMr9zJXtEFV9yiwGkmBV28pYS/2AWJoevwrAyRzZytwsNzUmnjW/q0mbTM5ZbhJnNXr9XJsrprry4wKLavqaW8xefBT74pQl97GkwvhVL0OvR9W/GazwMv1aMGGTmv962F2NkyIP1jANZ3A3pJ5ycoC7qIGEoza//Z0VYCGuWqhtZVcuSzx6CzeU/T3E+1DmDvY4TC5WhQt/JWsazTlYLL7lhHsHXbcwiJoH3mB7QAxcJT6eBqcYDGKEZyJyK1xXMMv7E4id3qoXjyMpzTh5Q8wf+5nyIiXh0DT3IqkNP+fmLRu9c/CqA== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN6PR11MB8244.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230028)(396003)(346002)(136003)(376002)(39860400002)(366004)(451199021)(5660300002)(71200400001)(7696005)(66556008)(66476007)(2906002)(66946007)(4326008)(66446008)(76116006)(64756008)(19627235002)(166002)(86362001)(38070700005)(76236004)(122000001)(41300700001)(33656002)(478600001)(38100700002)(52536014)(82960400001)(316002)(8936002)(8676002)(55016003)(9686003)(53546011)(110136005)(6506007)(26005)(66899021)(186003)(83380400001)(1406899024);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?eSrW8Rlm6LD2GpWTU5EXxlpAA9PJr0fvdFdS66nyTJ6WJ3UcgilSwQskcEjC?= =?us-ascii?Q?HmYmN1QGV9NXK9lVQtyFPIuTSQSaV8VuRS71s5NVDXOgxZa60Sqc75zjR7DV?= =?us-ascii?Q?wYkDQRb5QSVV23TgRARW61HdzxJ+rx8XrNbXjPdEH7c++NPrbBvwzUA8Nw/7?= =?us-ascii?Q?G1qCQaYGCyBkJ0RveZN2Bpy9u33fHIs+Fr9LphrctDv9ZUVi+gKeRJZKsPeh?= =?us-ascii?Q?4foDuQoGHSzcXBGdP69sSbCyvLKvztN6fnm/XMGYUjsOURbyeQ+SX5cTxTsi?= =?us-ascii?Q?u1LqCnO/+nwG7UTZxs3s/I11F/SHVV9Mbd6BA5g4O4eQ3L13lz5WQ8g4RSsJ?= =?us-ascii?Q?6bD19SnWOzK/1QnnRKOaOJwxODiGQX8SXESm/2Qb8qxpvPXHcAkeIgql39iP?= =?us-ascii?Q?aHn8DpQc7+MGFh7vyessu7qDyofkPpxg85c08H0dcTU+9HRTmUtb7+cbk9NX?= =?us-ascii?Q?8U1gtA1E2UacVF23xjNh5qQf5jXPhpAsZ4QgFqMCi+Oam6o5jpX0y6M3orMo?= =?us-ascii?Q?UljSygkzBa3djn60Km+C7VGtJDcCbl5psx/eWt+rRMnXFTLnyTinBf9QXy44?= =?us-ascii?Q?Ai0nuObqKMKHkvPOQjNfg12ZL+toLy6Atlq7EYJTjf4rbyQXrpPacE+Kfrws?= =?us-ascii?Q?tPJZIAIxdVkdZHjzasUv316q10q7WmkwC8RHO7lcf0agNNarDgP7NMUm5zZ+?= =?us-ascii?Q?RxmCleuyw/j82b8nqP0QxgKDbVw8EGre5IX3077RDC5xPL2luv0ksB96p2bN?= =?us-ascii?Q?DIFX6/gq+8+qkLvR7dmCqzj16v0I8Q7Ed/A+q/0dghTGh294h73VmKyKSGA/?= =?us-ascii?Q?gYmnOt6GfkGvo92KB5sQrYRaVlRIMWp7KATpm3606jii0hLyXT8BdIKdhJrz?= =?us-ascii?Q?3z+GdNBbfrQ1MajQ12F52U1Lamz5V2v2Cigpm+KBR8ICkGXu88bOZCI33rKr?= =?us-ascii?Q?5hZJY7Lki/j0uOUT1+FwPekAvqEmiZF6jkzQJNCpn02nWvjD/SYiO8yac3xg?= =?us-ascii?Q?4KVQz9z6QdnvLJ4ZeSewgeRs/5tTFJndqvZwgHIh1xsDcdPGUytCNTh8oZqL?= =?us-ascii?Q?sV/Rt/bQ/ddWgvjL9CwuusdcfSRHfmTpP0XfRyD/vjyfu55vsRmL7P9LOqdh?= =?us-ascii?Q?vHR8XTi5yqvYmawsnMvlXn86ppZGEu9FGV2OHUk1fawz8OiEymKCywQid/V/?= =?us-ascii?Q?VvcxXdCFG0OkqbfXT4r2zMjUZyaq9AcVnBeHTwvRc98kjBA6Kx8x4TEb9qb0?= =?us-ascii?Q?L/H5NnfPhrAOLe5mjm2oWTO8fYyUByqsSe4k+zwbHG5E3O+WoeKgPol8ESui?= =?us-ascii?Q?8vl+JtU1cimylxmf1F6mmRMSBYujkLiRvz93QF5AIJrSuHwfi45R1BLWnxx4?= =?us-ascii?Q?ySPgIOjR3VkllQ2HaQ66nOvuWPqVgRcMj8m7hfptRhpG+24sXYdbbMVS8U/5?= =?us-ascii?Q?1Sm9/ia9sopL4tVJjFYsWqoMZmpwGja9hz4SYtPGO+OQDitf8jVZpTO9tMOZ?= =?us-ascii?Q?Jbe4+mN2wJH1M5TWVylLYYCmKeG5691aR++p5QAvU1zl7SJJGrHQpbYzJ9R8?= =?us-ascii?Q?LjuYw94kROs/RH4GIjw=3D?= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN6PR11MB8244.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 06c55e4a-7f28-4f7e-b818-08db3d6ee912 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2023 05:04:36.9019 (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: Si3hURQt5C8n1rpCbqAQdlwz3Zo30gXW48YBVgAgbo2Z0nMOmXsXk4tBFqSfLC6N+9PpfFOQQrD7jPyaXybZJQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5207 Return-Path: ray.ni@intel.com X-OriginatorOrg: intel.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_MN6PR11MB82447B5EEF5A9EE6601EB9CE8C9E9MN6PR11MB8244namp_" --_000_MN6PR11MB82447B5EEF5A9EE6601EB9CE8C9E9MN6PR11MB8244namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I did a quick check on what TemporaryRamMigration does for OVMF. No magic there. I think you could try to remove the code in OvmfPkg/Sec/Sec= Main.c that does the TemporaryRamSupportPpi installation. If no such PPI, the migration will be done by PEI core. Thanks, Ray From: devel@edk2.groups.io On Behalf Of Ni, Ray Sent: Saturday, April 15, 2023 8:50 AM To: devel@edk2.groups.io; thomas.lendacky@amd.com; Ard Biesheuvel Cc: devel@edk2.groups.io; Gerd Hoffmann Subject: Re: [edk2-devel] Strange behavior between GCC 11 and GCC 12 Why does OVMF choose to migrate the content from NEM to MEM itself? PEI core can do the migration well. thanks, ray ________________________________ From: devel@edk2.groups.io > on behalf of Lendacky, Thomas via groups.i= o > Sent: Saturday, April 15, 2023 5:50:25 AM To: Ard Biesheuvel > Cc: devel@edk2.groups.io >; Gerd Hoffmann > Subject: Re: [edk2-devel] Strange behavior between GCC 11 and GCC 12 On 4/14/23 16:39, Ard Biesheuvel wrote: > On Fri, 14 Apr 2023 at 22:23, Tom Lendacky > wrote: >> >> I've been trying to debug a problem I'm seeing when I moved to the GCC 1= 2 >> compiler. Under SEV it results in the guest crashing. >> >> I narrowed the issue down to the call to TemporaryRamMigration() in >> PeiCheckAndSwitchStack() of MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.= c. >> >> I get this output on GCC11: >> Old Stack size 32768, New stack size 131072 >> Stack Hob: BaseAddress=3D0x3BF76000 Length=3D0x20000 >> Heap Offset =3D 0x3B786000 Stack Offset =3D 0x3B776000 >> *** DEBUG: PeiCheckAndSwitchStack:851 - SecCoreData=3D3BF95D20 >> TemporaryRamMigration(0x810000, 0x3BF8E000, 0x10000) >> *** DEBUG: PeiCheckAndSwitchStack:871 - SecCoreData=3D3BF95D20 >> >> and everything is good. >> >> However, I get this output on GCC12: >> Old Stack size 32768, New stack size 131072 >> Stack Hob: BaseAddress=3D0x3BF76000 Length=3D0x20000 >> Heap Offset =3D 0x3B786000 Stack Offset =3D 0x3B776000 >> *** DEBUG: PeiCheckAndSwitchStack:851 - SecCoreData=3D3BF95D20 >> TemporaryRamMigration(0x810000, 0x3BF8E000, 0x10000) >> *** DEBUG: PeiCheckAndSwitchStack:871 - SecCoreData=3D7770BD20 >> MMIO using encrypted memory: 7770BD48 >> !!!! X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID = - 00000000 !!!! >> >> and terminate because SecCoreData has been corrupted and points to an >> address in an MMIO range (this is an SEV-ES/SEV-SNP example). >> >> As near as I can tell from looking at the object code, on GCC12 it looks >> like the SecCoreData value is stored in the RBP register, which appears = to >> be getting corrupted when calling TemporaryRamMigration(). >> >> Does anyone have any thoughts on this? >> > > The stack switching logic in OvmfPkg/Sec/SecMain.c looks highly dubious t= o me. > > LongJump() can be used to do a long return, i.e., it allows to return > from several levels deep in the call stack to back up to where > SetJump() was called. However, using LongJump() to return to the > caller with a different stack is, quite frankly, insane, and I'm > surprised it didn't break a lot sooner. > > In this particular case, RBX gets updated along with RSP, presumably > because the code assumes it is being used as a frame pointer? Are you > building with -fomit-frame-pointer perhaps? Looks like our emails crossed paths... turns out I was on the wrong branch for my testing and didn't have ff36b2550f94 ("OvmfPkg/Sec: fix stack switch"). So you can disregard, but thanks for taking a look. Thanks, Tom --_000_MN6PR11MB82447B5EEF5A9EE6601EB9CE8C9E9MN6PR11MB8244namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I did a quick check on what TemporaryRamMigration do= es for OVMF.

No magic there. I think you could try to remove the = code in OvmfPkg/Sec/SecMain.c
that does the TemporaryRamSupportPpi installation.

If no such PPI, the migration will be done by PEI co= re.

 

Thanks,

Ray

 

From: devel@edk2.groups.io <devel@edk2.gro= ups.io> On Behalf Of Ni, Ray
Sent: Saturday, April 15, 2023 8:50 AM
To: devel@edk2.groups.io; thomas.lendacky@amd.com; Ard Biesheuvel &l= t;ardb@kernel.org>
Cc: devel@edk2.groups.io; Gerd Hoffmann <kraxel@redhat.com> Subject: Re: [edk2-devel] Strange behavior between GCC 11 and GCC 12=

 

Why does OVMF choose to migrate the content from NEM= to MEM itself?

PEI core can do the migration well.

 

thanks,

ray

On 4/14/23 16:39, Ard= Biesheuvel wrote:
> On Fri, 14 Apr 2023 at 22:23, Tom Lendacky <thomas.lendacky@amd.com> wrote:
>>
>> I've been trying to debug a problem I'm seeing when I moved to the= GCC 12
>> compiler. Under SEV it results in the guest crashing.
>>
>> I narrowed the issue down to the call to TemporaryRamMigration() i= n
>> PeiCheckAndSwitchStack() of MdeModulePkg/Core/Pei/Dispatcher/Dispa= tcher.c.
>>
>> I get this output on GCC11:
>>     Old Stack size 32768, New stack size 13107= 2
>>     Stack Hob: BaseAddress=3D0x3BF76000 Length= =3D0x20000
>>     Heap Offset =3D 0x3B786000 Stack Offset = =3D 0x3B776000
>>     *** DEBUG: PeiCheckAndSwitchStack:851 - Se= cCoreData=3D3BF95D20
>>     TemporaryRamMigration(0x810000, 0x3BF8E000= , 0x10000)
>>     *** DEBUG: PeiCheckAndSwitchStack:871 - Se= cCoreData=3D3BF95D20
>>
>> and everything is good.
>>
>> However, I get this output on GCC12:
>>     Old Stack size 32768, New stack size 13107= 2
>>     Stack Hob: BaseAddress=3D0x3BF76000 Length= =3D0x20000
>>     Heap Offset =3D 0x3B786000 Stack Offset = =3D 0x3B776000
>>     *** DEBUG: PeiCheckAndSwitchStack:851 - Se= cCoreData=3D3BF95D20
>>     TemporaryRamMigration(0x810000, 0x3BF8E000= , 0x10000)
>>     *** DEBUG: PeiCheckAndSwitchStack:871 - Se= cCoreData=3D7770BD20
>>     MMIO using encrypted memory: 7770BD48
>>     !!!! X64 Exception Type - 0D(#GP - General= Protection)  CPU Apic ID - 00000000 !!!!
>>
>> and terminate because SecCoreData has been corrupted and points to= an
>> address in an MMIO range (this is an SEV-ES/SEV-SNP example).
>>
>> As near as I can tell from looking at the object code, on GCC12 it= looks
>> like the SecCoreData value is stored in the RBP register, which ap= pears to
>> be getting corrupted when calling TemporaryRamMigration().
>>
>> Does anyone have any thoughts on this?
>>
>
> The stack switching logic in OvmfPkg/Sec/SecMain.c looks highly dubiou= s to me.
>
> LongJump() can be used to do a long return, i.e., it allows to return<= br> > from several levels deep in the call stack to back up to where
> SetJump() was called. However, using LongJump() to return to the
> caller with a different stack is, quite frankly, insane, and I'm
> surprised it didn't break a lot sooner.
>
> In this particular case, RBX gets updated along with RSP, presumably > because the code assumes it is being used as a frame pointer? Are you<= br> > building with -fomit-frame-pointer perhaps?

Looks like our emails crossed paths...  turns out I was on the wrong <= br> branch for my testing and didn't have ff36b2550f94 ("OvmfPkg/Sec: fix =
stack switch").

So you can disregard, but thanks for taking a look.

Thanks,
Tom




--_000_MN6PR11MB82447B5EEF5A9EE6601EB9CE8C9E9MN6PR11MB8244namp_--