From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by mx.groups.io with SMTP id smtpd.web10.3986.1681519791885178184 for ; Fri, 14 Apr 2023 17:49:52 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="unable to parse pub key" header.i=@intel.com header.s=intel header.b=GVtSWemi; spf=pass (domain: intel.com, ip: 192.55.52.120, 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=1681519791; x=1713055791; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8iUwbaRYiUTUiIhjY4S5x4CtDmPXn1VybWh298H7lSA=; b=GVtSWemiqxRaF/CJMxy7Ogz6BzdCdPfkVXCDY5kmn3JCVtKJvG460z6s sS2onbFuvs3uxBaxaLVQCEowAcPRtkcvzNa/2ApF3n7OnILbR2NHvVW4r uylKKdfIOtIr4do7pu1EHXX77MrhTO3hwVbkquBDvPoUFtnGNJPSPORte cYrAc8wUTCm63d6HBonTGldZM/GjWmINfCjVFugoUwBc3ax1DWIyETIUc /8quvPZnRkh+6kXmTg7VKkI+fyEKkGV/laJvXZxNLYO/z5naXYsLtHpyi 0qUUcSEgQXK2iep4t0MJibkpaaHdg1swOIJcWQljLYqivWPcb1DJWOxHG g==; X-IronPort-AV: E=McAfee;i="6600,9927,10680"; a="343356155" X-IronPort-AV: E=Sophos;i="5.99,198,1677571200"; d="scan'208,217";a="343356155" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Apr 2023 17:49:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10680"; a="759295683" X-IronPort-AV: E=Sophos;i="5.99,198,1677571200"; d="scan'208,217";a="759295683" Received: from orsmsx602.amr.corp.intel.com ([10.22.229.15]) by fmsmga004.fm.intel.com with ESMTP; 14 Apr 2023 17:49:50 -0700 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX602.amr.corp.intel.com (10.22.229.15) 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 17:49:50 -0700 Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) 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 via Frontend Transport; Fri, 14 Apr 2023 17:49:50 -0700 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.103) by edgegateway.intel.com (134.134.137.102) 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 17:49:50 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ywp9FF4AQSWyZXRPWzdFNeucYTptGRbAL8mxLKbXkudXZj51JGFkIgkN6ZVgBzfJ7YTuGBsI92NC06spUeN9NAqJfznUP4vWrSAPtfs1ali26BbFlEMynX8ipXYIiYZMOYZZcud0l6UFxN4LyJ1KpuLUdYWfULR6vch5RP+QW1d0ukcApVCbbFa7gf8Ph11iGyagoVSu83Mzj/hf/4n46JFovLN/Y5SLeEHAJxmzlVyE1YZYwiSQHyRkERXdI2/T9E9dqit9oJgEbONajGeyt44NxCG0bk5CGzNx0FVSVagnw8ix7qNyZZBjQTB/KQcF/xSl0fM1KkriQEbt1eg6oA== 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=p0Ou1lIh+xuMEPVxWnDHcOwjGCqW5Ln5EaWoih6YXLk=; b=SfCRX4r0Fy81ntfouDIjcnJeRZXaZ8SzHy6K/HVcL8IhTLDZosXVXEz7vVxzOQ9n9dbWsZBniBqY3OSSzuJ8MSyL9yFPA6S1ozb0zH5VtvbiUnkO7Rar9qxmnZxma2IJkOfxoAXdiLpnc8+lUeOVloSLCbD3+sjXdd52YarK1JAIyk6ESLeDujo2AhGVJxpZCNGV1oBPhFhDagGa52xyNXiYURpnVoxZXlsOkunWbDFfK8veVxpOMWJrEgUk5HZjzhK6FAPcvWIVbxc9FtxbY/zvVLsJ6rOYFtVmyBezdWppy6MNAHnBGAhjmc5v0rkimge+FFN8r0BCnfalnpC/RQ== 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 CY8PR11MB7337.namprd11.prod.outlook.com (2603:10b6:930:9d::22) 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 00:49:41 +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 00:49:41 +0000 From: "Ni, Ray" 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 Thread-Topic: [edk2-devel] Strange behavior between GCC 11 and GCC 12 Thread-Index: AQHZbw7yIYQebiLAmki+rXPudQEMCK8rVRiAgAADB4CAADGXcg== Date: Sat, 15 Apr 2023 00:49:41 +0000 Message-ID: References: <7f0f5f8e-09c7-4ae4-ffca-1a7c322949a8@amd.com> <9057b932-b10b-c2cd-af8c-ea0db5120bfc@amd.com> In-Reply-To: <9057b932-b10b-c2cd-af8c-ea0db5120bfc@amd.com> 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_|CY8PR11MB7337:EE_ x-ms-office365-filtering-correlation-id: 30fcce91-e05f-4d34-1310-08db3d4b4c4d x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yCtfAMGbxzeyCypBgIa15I86E+tZLGHR+im2yUZJrjiEkn/ISUYjTyXre3GRE/0BGJVvXU3i31aHGv498fSEOgRK3fVSPWidpavTrjaBcecln1khH3ySza7/bpcTqCCWYJYIHUUnaFL+CSnmelRpipO0e4AZyDTGPsVlQUzS3BO0jC1sFmVGAt0qNST/aDhALrgYHTxhQD+0g2Kp1OyUpydDJgHfxlZdDLcYKQ4siuEWyviCbNoVhOv3pei9mnTrUOhZwL6jbCm+Ezeii48N9dVAJZ5ADBMXIaxDKBhO8arJd9ls3Ss4e1JX+L3/Dlzo1rV9S0m+tEVmb27bcDr5eslOfcgV7YXLgPCOUyDB1tYT2HmQiapJa4e0FrN89HYFINUYLdEXUCbmMuyeNm2/t+5/V7S3WMnPokq8GDK8mMnAtyBVmG5HNvAqYEnCvxFFMcboVz27MglxF3EOLYR+SvD0zXaohgZgRuWdT2YrF6Iikh+TWQb3IQryA36h+r+wVEog15+8ax2w7tFdDKn1/Vn6DllVkChDX56L3yLqrPYCGLlOC388ps/C92PFU1aDf4cQZ+wh4aXaMwdSghoY+vhosRBhjjgVf8jHtsEMdYOGHtc+05F3EqYgTTvkAKNFtG+MM/mMsHs4uQ7NYLffIA== 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)(366004)(136003)(396003)(39860400002)(346002)(376002)(451199021)(41300700001)(4326008)(66446008)(66476007)(64756008)(66556008)(76116006)(66946007)(91956017)(186003)(66899021)(5660300002)(2906002)(38070700005)(83380400001)(52536014)(33656002)(166002)(8936002)(55016003)(8676002)(86362001)(71200400001)(82960400001)(54906003)(478600001)(966005)(7696005)(19627235002)(122000001)(53546011)(6506007)(9686003)(26005)(316002)(38100700002)(110136005);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?0inIC+/XOTvBKIu6I7DijWLNP27sIgyMtHD9ECOWto4JCPBrmUi6I8MmjHT4?= =?us-ascii?Q?gMzkhwHfgbZB1fL0MPu4xS3/tS/0jXzfcWrGU2OQUNaJw9Q51UeQQ/ezmI0l?= =?us-ascii?Q?7cgMOMqS6vYNjJmDCzLCQGeDlvCmpE/c4oV6Xv1LeL/+SJVyEkVAcfhb895B?= =?us-ascii?Q?ybPRrUXTr3HY9pxww6P7RTegBHuD9yevEYHLheWcaSI3W1E+F7zrAs14EykW?= =?us-ascii?Q?HKWAAJHoc2gHpRdSR1kbjm2ItpTbGyJAAvvQKyxbq1uV8RENVjk4gWHEEb4f?= =?us-ascii?Q?nhvnfaL63Hyt7R9KOg4zLifrcTLIbVG5rVg+XFDf/YqLg0VCyaZ0nUhbIz4c?= =?us-ascii?Q?79v7hAai/RFr6BaDkogcsPTmk7rimhRrl+yuUGUdrDXVHg1x3M/dceJHFrSr?= =?us-ascii?Q?nMQPh3bJhOwFxBFqOdXb7tqIsghEc3oIZKE2soPqHQfphpadUYY9+JcXEH+z?= =?us-ascii?Q?MQCSVDQmv79rt2W5qC2VX7t64ivTtz6owBUH8zPTSraBqRgyAz+QsbQHBqSG?= =?us-ascii?Q?nT6M/dUVTNAzavYGXFHGg2DN5EGQejL0b8wc8w97Q5M2C/05VEhU0fPAjbe0?= =?us-ascii?Q?pj7VyDdeEOlBFJGZel/tDjs1bowsYKZq6aYYEDhilqhIVOWcHxoIQ3KWh2Fz?= =?us-ascii?Q?RzhzbIljCV5VBXhz9wphpVDz9ubzPjvNDzXHztA+q4OWTlVfDL7Jhv5y1qJy?= =?us-ascii?Q?Pc55rEIiXfzUQcTwWdY2wpI9M+OFcXL7mYvEy6w48GAfKTMyR7cJ+FC1lUiC?= =?us-ascii?Q?LOerFUybg8gEU9mhr70N2GwN2PSLEQJesP0sIXiofwIO7PctC+UBmGUCIMB5?= =?us-ascii?Q?hpZR3Jrxk8+Ps8ICGTC19LVCfgQGkNxSghgXs0ZqNeMmbUHvDdOGp4pWERuT?= =?us-ascii?Q?TDZyZ/kgoxIKT0qF+sHGkfLTzMnKNA0KB9G2Rb3+imdedTMObmqHqZILBcGw?= =?us-ascii?Q?1PPbLFLnjx37EqZ/459exnMiZva2+7pujILboVGVZltJDxUS9bn0/EUl+QkO?= =?us-ascii?Q?r36HY2p0qOucUlJED6orM73JS509oMBOwygcan4FeHU00JFtR92uy+DqDuMk?= =?us-ascii?Q?hQIYYaZPSY0LX+nFCQtpu9cTr0wnXPMHptGEB3kFri5mH+u/DyRVOwC40PXr?= =?us-ascii?Q?CRBwqCFVNT8TFhqThWfISStz8u8wmX1/FJtz36GRi6jusURdFXJPmSyOmdz1?= =?us-ascii?Q?RKWK6M83Ii8vHTytKSybz+XnLakbulxuFmzTpcTGTCNKgJ0q0pYhScNpkHEK?= =?us-ascii?Q?NV2SHQz2k44AlKOxFO+jzax1e2va9P8+pgoDGlDEf/KtXUylrwol0MAzqto2?= =?us-ascii?Q?iBjnUM4QITBh4D1vPKWq2ryHYkR/oGG20ljQw+J0s7RV3ovTsjojbZ1PUZEW?= =?us-ascii?Q?ofErd1TJIomWYj7uRSKOMrC+nWRoSodBNvB0QwSi9amu6w/P7770CtcZ6OfZ?= =?us-ascii?Q?rql65hSKLj4RK+KI6E1qWdp3NAEAlOW6KjZZABzpeuHsMdacFNH8kV/dBMK/?= =?us-ascii?Q?/bH/B2Lk2eGkdEI/0hyjke3jO+PlDfh+wi6qn2N6FBIgW8GMxAQcFIMOe420?= =?us-ascii?Q?2BtwBzSjgpvPVi+8+YXmQ/zr8OuVYEY5T7qnsLWv8EhPjtomD+ws2DAHljiF?= =?us-ascii?Q?pQ=3D=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: 30fcce91-e05f-4d34-1310-08db3d4b4c4d X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2023 00:49:41.5006 (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: yqIaKndMC4qhY3vADla7aUEb5bmpSojbpfH58ltd7WuFFf3QIj5uFqtEz39aIgtirUR2kwB3jJY4wC+HN2SoEg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR11MB7337 Return-Path: ray.ni@intel.com X-OriginatorOrg: intel.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_MN6PR11MB82447101FD9DDC4E821098128C9E9MN6PR11MB8244namp_" --_000_MN6PR11MB82447101FD9DDC4E821098128C9E9MN6PR11MB8244namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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, Th= omas via groups.io 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 wrot= e: >> >> 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_MN6PR11MB82447101FD9DDC4E821098128C9E9MN6PR11MB8244namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Why does OVMF choose to migrate the content from NEM to ME= M itself?
PEI core can do the migration well.

thanks,
ray
From: devel@edk2.groups.io = <devel@edk2.groups.io> on behalf of Lendacky, Thomas via groups.io &l= t;thomas.lendacky=3Damd.com@groups.io>
Sent: Saturday, April 15, 2023 5:50:25 AM
To: Ard Biesheuvel <ardb@kernel.org>
Cc: devel@edk2.groups.io <devel@edk2.groups.io>; Gerd Hoffmann= <kraxel@redhat.com>
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 <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_MN6PR11MB82447101FD9DDC4E821098128C9E9MN6PR11MB8244namp_--