From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail05.groups.io (mail05.groups.io [45.79.224.7]) by spool.mail.gandi.net (Postfix) with ESMTPS id 758A9941C09 for ; Fri, 18 Apr 2025 21:33:56 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=6TFWhz6di4aJq1uQIWhrMkoLZkU9836coPLPaL18N10=; c=relaxed/simple; d=groups.io; h=From:To:CC:Subject:Thread-Topic:Thread-Index:Date:Message-ID:References:In-Reply-To:Accept-Language:msip_labels:MIME-Version:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Resent-Date:Resent-From:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type; s=20240830; t=1745012036; v=1; x=1745271234; b=p+fGMy4FagFN7HE8tpJLnW7CsJSUaWY6pVH/muEChqX5KsLpmK2QkF5Jy/PGCxAK1N1mNQfe Cp23s8jfYhXgnZ7yI/nr6jSsIx1f5YK7VsXNOCKQzkEzvxL/YFZ71MUHgphSx7jHJVd+YNq8KAP wDE3gmk5EOUfIF4veOricHqwY2b1vuGkRuqqA9zylVjUYQCNQ6zhalhnnTJC3gqXBe4DecafLhp dNtvyZotJ0h/EOsOH0ib02UJC0lXP/+0YkBOs37+0o2aM8XAM/B+OA/lABw5iTrNRdawWIDFFTJ niEqtXQ+8uvUNHNgqbDa9UDXv5gpcL8tgW98qb/Jgtx+Q== X-Received: by 127.0.0.2 with SMTP id YnyaYY7687511xTqRlu6lHVN; Fri, 18 Apr 2025 14:33:54 -0700 X-Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.18]) by mx.groups.io with SMTP id smtpd.web10.6148.1745012033835284045 for ; Fri, 18 Apr 2025 14:33:54 -0700 X-CSE-ConnectionGUID: dGGfpSWQSPmhzKCUvB1T5g== X-CSE-MsgGUID: 2eP1dY8aSrWy590z9Ybi7w== X-IronPort-AV: E=McAfee;i="6700,10204,11407"; a="46774476" X-IronPort-AV: E=Sophos;i="6.15,222,1739865600"; d="scan'208,217";a="46774476" X-Received: from orviesa009.jf.intel.com ([10.64.159.149]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Apr 2025 14:33:54 -0700 X-CSE-ConnectionGUID: TFKfGXD6QN2WcZoHfpF7LQ== X-CSE-MsgGUID: uGcn5uUdSEudqk6zXBijWg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.15,222,1739865600"; d="scan'208,217";a="130960519" X-Received: from orsmsx902.amr.corp.intel.com ([10.22.229.24]) by orviesa009.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Apr 2025 14:33:53 -0700 X-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.1544.14; Fri, 18 Apr 2025 14:33:52 -0700 X-Received: from orsedg603.ED.cps.intel.com (10.7.248.4) 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.1544.14 via Frontend Transport; Fri, 18 Apr 2025 14:33:52 -0700 X-Received: from NAM04-BN8-obe.outbound.protection.outlook.com (104.47.74.43) 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.44; Fri, 18 Apr 2025 14:33:52 -0700 X-Received: from CO1PR11MB4929.namprd11.prod.outlook.com (2603:10b6:303:6d::19) by SA1PR11MB8277.namprd11.prod.outlook.com (2603:10b6:806:25a::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8632.32; Fri, 18 Apr 2025 21:33:47 +0000 X-Received: from CO1PR11MB4929.namprd11.prod.outlook.com ([fe80::a886:6510:729d:f9d0]) by CO1PR11MB4929.namprd11.prod.outlook.com ([fe80::a886:6510:729d:f9d0%7]) with mapi id 15.20.8655.022; Fri, 18 Apr 2025 21:33:46 +0000 From: "Michael D Kinney via groups.io" To: Kun Qin , "Ni, Ray" CC: "devel@edk2.groups.io" , "Ni, Ray" , "Kinney, Michael D" Subject: Re: [edk2-devel] A bug in the SmmCommunication V3 logic Thread-Topic: A bug in the SmmCommunication V3 logic Thread-Index: AQHbsCxo5nQBH4RMRk+1qEepe02xqLOpBL4QgACO8lCAAComQIAAMy/A Date: Fri, 18 Apr 2025 21:33:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=7199950a-a9af-4e88-86e5-b41f15734340;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2025-04-18T07:21:47Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Tag=10, 3, 0, 1; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: CO1PR11MB4929:EE_|SA1PR11MB8277:EE_ x-ms-office365-filtering-correlation-id: 01eca5fe-6033-47dd-7a52-08dd7ec0b39a x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam-message-info: =?us-ascii?Q?74LnXq3TLTtwkojoBAUriBwiQ11NssOpgYmra7Ev7by2FcMY8okTJnsHmV5U?= =?us-ascii?Q?bi41RnwWH0jkUgSRO8eZ+a5CRjvbYLCZ2/GaFO+mtlOHYvgmggWpT8I3+xYc?= =?us-ascii?Q?XB4noogVifutqhh+Ej7Tg6BDZR5lDvI3AF7/CrLTIKG3B4lRVFNz8iZmflA4?= =?us-ascii?Q?R7YnBs+f9Nl9Ajh/CPcuKfMhxQP6OwwM9lT6XQtYcxSzi9QnSkeB3bTcLH59?= =?us-ascii?Q?AoyZJKMK3f2HOv+Ff+CnhViUiFMaH6DrMMxkchAULpQzkUIpg/D5TvW6DiQA?= =?us-ascii?Q?M422ermlyTCGO4iMYPg7DwW5DS39hswT8JbKOR0lRhLRwHpl4940ji1H2Tbm?= =?us-ascii?Q?TkLJrMf93PcVN61+Uz/0lGtH5kXY7NHnR3x7C/WiAxxGhVDyiHPpilvRplCB?= =?us-ascii?Q?AD2cao2Fl66ky4aMUg0FlCqmygYZWKbqMj9tXL7zCZltd6Q0ZsTnVZfW0ybB?= =?us-ascii?Q?09cjRhhn9s4S7+1/r8rusrPMHP7rcNLs7cjOep6Zbne7oPK8Jm20uGZ8BkTl?= =?us-ascii?Q?uYxNCgA8WuawxdevYektrSugCe5Ht2WpgMNiruUUShDdOGgL4UHyfkL0hLph?= =?us-ascii?Q?GEOjjQcyRo5gUN1zZ5A1Q0CgrxYO4s0A8T/yBvZjTM8RNdC65V498c0uYPHs?= =?us-ascii?Q?EBy0klQELQ5CWpd/Q+JRuvEZeneRFxl5jHH8A4+BIkT2Udz1rMWdiKGX7jsx?= =?us-ascii?Q?Um6wtg+jJQl0NpmFjWH4RsZElLHSeXA5zdtQp0w24CTjTqqBvLUsyhoqxtCu?= =?us-ascii?Q?A/RUEw/r4MLNpjDcZokDfMSkKb1lpSSC67JVwXKKO6jRwefYU6ZBmVsLfBwn?= =?us-ascii?Q?gDUC5rHmNDAGH2ZbbWX4dbfVCaQ7QOK2FVAunRiVD6Jq1SxpR0RxUvtRT0hJ?= =?us-ascii?Q?YGvRLWJ8USPcAQ0X9k8bxNcaGFiYlWmqqyVcwPAdFATKjYy4uyB5DoQsjvFz?= =?us-ascii?Q?wU+FPa6n73aGgILBac1/31HSKCC1ujL0+E/9tlf0TAjy4pp3sEIyzBUV2pUT?= =?us-ascii?Q?ulyydAf/JySiPSuGwm0n7zQFDV8yDdhPBZBMtHNTtKnnsfHCH7NujYcnqEs1?= =?us-ascii?Q?r2zq1PHvGYWIVnFJqR13eIcdN1ZbdklGGXUFzcoIR/vHAZ4W+3CRD8fRJmER?= =?us-ascii?Q?AMOOBy8gBFhh+NEfxb2hF7s7D/pdhTFBMqJbymz5ftRip0HTN2h/PCd9s7/9?= =?us-ascii?Q?/vvMovt7PXuGF64MYeiRO0BzLmYdDsWokxOv4d+PLa995uWUe+B/p6X413j4?= =?us-ascii?Q?HDkgPom4GLoZCN2ogL073a0P8uDncFt/yqprXHhXRmIFOm5YL9U5bXbwsQrm?= =?us-ascii?Q?ZKRjupFbAL6MHsasFU6dh0zXCB4sMIfF9KTC3y+l7+ydKSiKrwAet6iRRtLe?= =?us-ascii?Q?46MgHuFYd4ASCcuFobvDCr1upC89iaCm4TtYtLJl1GhIbtz2cgTnJyr/tr4T?= =?us-ascii?Q?0HU5VKgrwS3+N1e4LODjlNfFdkXF8jRWJF6zUdBnQzdr4OxIARu6cPh4mgfb?= =?us-ascii?Q?WlfSOWc/dSwW0jM=3D?= x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?Ym46weEwWQ7XCOIUJCNAq2pjGYdntunhEt4hWZPfiyMTW6f0u5MBTZeH9NEA?= =?us-ascii?Q?fNvGZWwems20zSPEHeX7w8IRS0o13IBMn0v/x4Ju7UvrqoLs54Z651tZdKnt?= =?us-ascii?Q?D4YvVgeksZd3gC46FDs/Ymfi5vvBNjm76mcxqUGBqvq04xtsFx/LFJSW8Eza?= =?us-ascii?Q?pvwv1mBbeePa2v1Us6LYUHGq9yYkxuDTW10Rdc/H36Q4nOyLqY7fKCdMbGOh?= =?us-ascii?Q?uE4fF2q1td7VP3Bj99ugrKZQ6pKGs6i+x46kYrNxxGg17OMVf7R2oDDA7JnO?= =?us-ascii?Q?6F2lHgRZP6MybDt/2MrbXkQGn0wGduHbJ1NcoyQR3FAYvpAYsMAmTdl2xXia?= =?us-ascii?Q?abXoJ8iup6xj70nPxpbkiA9HpU7TjgPSfIOdqC7Gh+c4eGlXyZ3MbIkCMaNL?= =?us-ascii?Q?U2JbqiN+p1FnY2+rPIMiQOIHjSoGBZ29c64J0x4V2dhOaOfFtQQpY8zkgJQr?= =?us-ascii?Q?uyItG8/xpa2e+jxZCimQaPQl1xrWcN1Ezo8mLJdmlhWfJnQf8zH918rpSzbH?= =?us-ascii?Q?6HreyJTVzdrBAnUPd8WWi6TVxFj/u3R90hJHQrSuIGxgHJBOeZnvf3JT1twe?= =?us-ascii?Q?vMTqEjsbmJItEocFeK9WYPwpzFoxneHQ96xAF/4I3o19i8ZhstpPzM072FJj?= =?us-ascii?Q?hUowaI792ApNxBFT/8Y9DlWP2JpA+3b4mPNLWJ44WBssjVqJEEIrewUAFgtq?= =?us-ascii?Q?tCoUyOxkF2zsAjXjQ39dHtRsVUrkic6QmKYOtUAkx91lvTyHSXLNVjwmQ1ZL?= =?us-ascii?Q?hPwDgf0V/17bpB5sTqges1pa0vgX+aLBm2D1ECNRdeaBKz8JwLwFQ67VEN86?= =?us-ascii?Q?Gx7qswjJLwMlgNfB6PIe8V31Ujq8z2I/yvdBg7M3XHD0Y2DbvwiLz+XOd7bW?= =?us-ascii?Q?6kV12hdv9V3VY71hWxse8sTEACWNSUzNjTiz4vacL3ZVXM0PvYu6KmwFx/k8?= =?us-ascii?Q?EFpkdLof8OfowDoDC5ltXEkbbzX2CPehFXVcS4Sz89VZ0SQvgQOR1d4WYcXr?= =?us-ascii?Q?YqoD7EM/aYXDgN60qKJeOUNrkg4iF1LBpkDDXH3Cl7YU4MjzvY7reTbwzdEX?= =?us-ascii?Q?J+iOEdlwY9fHjQK4YZ/WPnwSFGNsSU2dHMzgVgu2picbGVWWr0Kjcu0Sm3lF?= =?us-ascii?Q?cKwezz5jxrtvP8vIf5zWdybIH7GtuW/iL/jYnHtPLYWNYOpAOfZlWJQ4jpZ1?= =?us-ascii?Q?Bhnmn65cWwJgVcD2Q0LxMOg1hJafd7IANjnlqZZJfF0Z4Y7gf8XjX1LT48OZ?= =?us-ascii?Q?LPD8QwchSfhShLsB0m2SpZLM98ti9oH2clyYIt8k2Vja0jLbSJy3BatNUmoO?= =?us-ascii?Q?/leZYE4zLJ4qYYE0gWszwslHHmYLAsk7JRMi+lXo6qOm4A9Va+2ph8ArJePG?= =?us-ascii?Q?kBHIJj8wThyvHzdDc40G8oPFI7FXCB7a8hZeZn9j6fKNXkd01+gjj5/HQuLq?= =?us-ascii?Q?S5ldFOEy2U/mCZLaX7hxDvemxD7WqhnMdaGY4WFuOg0GhIRp4cRbAtH2A1PW?= =?us-ascii?Q?wi2a08YvEPpErRlLiqqi4oUCkQjBqTDZyRdakcO0guVdShgx5anI+weTgHXb?= =?us-ascii?Q?HRXb8LnvaRUPIkBk09zP/2HrhCiToVaAj8+gQvjByXzDGBOXpByXtWdRjaXB?= =?us-ascii?Q?Yg=3D=3D?= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4929.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 01eca5fe-6033-47dd-7a52-08dd7ec0b39a X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2025 21:33:46.8254 (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: FFe5EPwMtZVAnQOSsatX9k0a6g7uxgTHTsOvpGKDFz7kl164ndyqF0f56tq/3ap90Vod9E2hEZnAe/tXiQFgjohaeV7FvyAA5DH5q/AX0cs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR11MB8277 X-OriginatorOrg: intel.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Resent-Date: Fri, 18 Apr 2025 14:33:54 -0700 Resent-From: michael.d.kinney@intel.com Reply-To: devel@edk2.groups.io,michael.d.kinney@intel.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: XGhAMUe8v2OyJID2xTUWHcbtx7686176AA= Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_CO1PR11MB4929B86D67A7A22197971C2ED2BF2CO1PR11MB4929namp_" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20240830 header.b=p+fGMy4F; dmarc=pass (policy=none) header.from=groups.io; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 45.79.224.7 as permitted sender) smtp.mailfrom=bounce@groups.io --_000_CO1PR11MB4929B86D67A7A22197971C2ED2BF2CO1PR11MB4929namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kun, I have a proposed solution that puts SmmCommunicationCommunicate() back to = its original form, so there are no changes in behavior for SmmCommunication= Communicate() or SmmCommunicationMmCommunicate2(). I then pull the V3 only logic into MmCommunicationMmCommunicate3(). It has some code duplication, but makes it easier to understand and uses th= e virtual and physical pointers in the right places for the V3 implementati= on. What were you thinking? Mike From: Kun Qin Sent: Friday, April 18, 2025 11:26 AM To: Kinney, Michael D ; Ni, Ray Cc: devel@edk2.groups.io; Ni, Ray Subject: RE: A bug in the SmmCommunication V3 logic Hi Mike, Thanks for the explanation. That makes sense. I confirmed the issue on PiSm= mIpl side. A patch should be available some time today after I test both tr= aditional MM and Standalone MM paths. Regards, Kun From: Kinney, Michael D > Sent: Friday, April 18, 2025 8:59 AM To: Kun Qin >; Ni, Ray = > Cc: devel@edk2.groups.io; Ni, Ray >; Kinney, Michael D > Subject: [EXTERNAL] RE: A bug in the SmmCommunication V3 logic Hi Kun, I think the reason it may have always worked is for the case where SmmCommu= nicationCommunicate() at runtime after SetVirtualAddressMap() and CommSize = is not NULL. In that case, CommunicateHeader that points to CommBuffer is = never dereferenced and a call to mSmmControl2->Trigger() is made. If CommSize is NULL, then MessageLength field of CommunicateHeader would be= dereferenced as a physical address at OS runtime after SetVirtualAddressMa= p() and a page fault would occur. My guess is that CommSize is never NULL,= and that is why we have been lucky. With the addition of the check for the V3 GUID, the HeaderGuid field of Com= municateHeader is always dereferenced. So if CommunicateHeader is a physic= al address at OS Runtime after SetVirtualAddressMap(), then a page fault wi= ll always occur. No more luck. Mike From: Kun Qin > Sent: Friday, April 18, 2025 12:30 AM To: Ni, Ray > Cc: Kinney, Michael D >; devel@edk2.groups.io; Ni, Ray > Subject: RE: A bug in the SmmCommunication V3 logic Hi Ray, I will verify the code first thing tomorrow morning. But I just looked at t= he code flow before the change, it seems that SmmCommunicationMmCommunicate= 2 is also using physical address, and the common routine will deference the= pointer to read message length as well. I just checked variable runtime dr= iver did not convert the input physical pointer. Would that cause the same = issue? Did I miss something or we have lucked out all along? Regards, Kun From: Ni, Ray > Sent: Thursday, April 17, 2025 11:45 PM To: Kun Qin > Cc: Kinney, Michael D >; devel@edk2.groups.io; Ni, Ray > Subject: [EXTERNAL] A bug in the SmmCommunication V3 logic Hi Qin, I think there is a bug in the SmmCommunication protocol implementation. All 3 communication protocol calls go to the same communicate() function th= at tests the HeaderGuid against the V3 GUID. But when the call is from runtime, reading the HeaderGuid using the physica= l address of communication buffer would cause page fault. The virtual addre= ss should be used. The bug was not there without your patch because the communicate routines h= appened not to read any bytes from the communication buffer but simply pass= the address to SMM. SMM expects the physical address because the virtual-t= o-physical mapping in SMM is identical. The bug exists in both the SmmIpl.c in MdeModulePkg and the MmCommunication= Dxe.c in StandaloneMmPkg. The bug would cause OS boot failure if there is any communication protocol = invocation after ExitBootService. I guess the bug might not be there in your first version of patch, but was = introduced when I asked you to consolidate the logic together. Can you kindly reproduce it locally and send out a fix after confirming? Thanks, Ray -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#121267): https://edk2.groups.io/g/devel/message/121267 Mute This Topic: https://groups.io/mt/112327494/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- --_000_CO1PR11MB4929B86D67A7A22197971C2ED2BF2CO1PR11MB4929namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kun,<= /span>

 

I have a proposed s= olution that puts SmmCommunicationCommunicate() back to its original form, = so there are no changes in behavior for SmmCommunicationCommunicate() or Sm= mCommunicationMmCommunicate2().

 

I then pull the V3 = only logic into MmCommunicationMmCommunicate3().

 

It has some code du= plication, but makes it easier to understand and uses the virtual and physi= cal pointers in the right places for the V3 implementation.

 

What were you think= ing?

 

Mike

 

 

From: Kun Qin <Kun.Qin@microsoft.= com>
Sent: Friday, April 18, 2025 11:26 AM
To: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray &l= t;ray.ni@intel.com>
Cc: devel@edk2.groups.io; Ni, Ray <ray.ni@intel.com>
Subject: RE: A bug in the SmmCommunication V3 logic

 

Hi Mike,

 

Thanks for the explanation. That makes sense. I con= firmed the issue on PiSmmIpl side. A patch should be available some time to= day after I test both traditional MM and Standalone MM paths.

 

Regards,

Kun

 

From: Kinney, Michael D <michael.d.kinney@intel.com>
Sent: Friday, April 18, 2025 8:59 AM
To: Kun Qin <Kun.Qin@mic= rosoft.com>; Ni, Ray <ray.ni@= intel.com>
Cc: devel@edk2.groups.io= ; Ni, Ray <ray.ni@intel.com>;= Kinney, Michael D <michae= l.d.kinney@intel.com>
Subject: [EXTERNAL] RE: A bug in the SmmCommunication V3 logic<= /o:p>

 

Hi Kun,<= /span>

 

I think the reason = it may have always worked is for the case where SmmCommunicationCommunicate= () at runtime after SetVirtualAddressMap() and CommSize is not NULL.  = In that case, CommunicateHeader that points to CommBuffer is never dereferenced and a call to mSmmControl2->Trigger= () is made.

 

If CommSize is NULL= , then MessageLength field of CommunicateHeader would be dereferenced as a = physical address at OS runtime after SetVirtualAddressMap() and a page faul= t would occur.  My guess is that CommSize is never NULL, and that is why we have been lucky.

 

With the addition o= f the check for the V3 GUID, the HeaderGuid field of CommunicateHeader is a= lways dereferenced.  So if CommunicateHeader is a physical address at = OS Runtime after SetVirtualAddressMap(), then a page fault will always occur.  No more luck.=

 

Mike

 

From: Kun Qin <Kun.Qin@microsoft.com>
Sent: Friday, April 18, 2025 12:30 AM
To: Ni, Ray <ray.ni@intel.com= >
Cc: Kinney, Michael D <michael.d.kinney@intel.com>; devel@edk2.groups.io; Ni, Ray &= lt;ray.ni@intel.com>
Subject: RE: A bug in the SmmCommunication V3 logic

 

Hi Ray,

 

I will verify the code first thing tomorrow morning= . But I just looked at the code flow before the change, it seems that SmmCo= mmunicationMmCommunicate2 is also using physical address, and the common routine will deference the pointer to read message= length as well. I just checked variable runtime driver did not convert the= input physical pointer. Would that cause the same issue? Did I miss someth= ing or we have lucked out all along?

 

Regards,

Kun

 

From: Ni, Ray <ray.ni@intel.com>
Sent: Thursday, April 17, 2025 11:45 PM
To: Kun Qin <Kun.Qin@mic= rosoft.com>
Cc: Kinney, Michael D <michael.d.kinney@intel.com>; devel@edk2.groups.io; Ni, Ray &= lt;ray.ni@intel.com>
Subject: [EXTERNAL] A bug in the SmmCommunication V3 logic

 

Hi Qin,=

I think= there is a bug in the SmmCommunication protocol implementation.=

&n= bsp;

All 3 c= ommunication protocol calls go to the same communicate() function that test= s the HeaderGuid against the V3 GUID.

But whe= n the call is from runtime, reading the HeaderGuid using the physical addre= ss of communication buffer would cause page fault. The virtual address shou= ld be used.

The bug= was not there without your patch because the communicate routines happened= not to read any bytes from the communication buffer but simply pass the ad= dress to SMM. SMM expects the physical address because the virtual-to-physical mapping in SMM is identical.<= /o:p>

&n= bsp;

The bug= exists in both the SmmIpl.c in MdeModulePkg and the MmCommunicationDxe.c i= n StandaloneMmPkg.

The bug= would cause OS boot failure if there is any communication protocol invocat= ion after ExitBootService.

&n= bsp;

I guess= the bug might not be there in your first version of patch, but was introdu= ced when I asked you to consolidate the logic together.

&n= bsp;

Can you= kindly reproduce it locally and send out a fix after confirming?

&n= bsp;

Thanks,=

Ray

_._,_._,_
Groups.io Links:

=20 You receive all messages sent to this group. =20 =20

View/Reply Online (#121267) | =20 | Mute= This Topic | New Topic
Your Subscriptio= n | Contact Group Owner | Unsubscribe [rebecca@openfw.io]

_._,_._,_
--_000_CO1PR11MB4929B86D67A7A22197971C2ED2BF2CO1PR11MB4929namp_--