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 889F8941975 for ; Fri, 18 Apr 2025 15:59:16 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=Q7S0doGI68wr7Illqy4MVpxHQ6S1TvpC1tzS7MS3DK0=; 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=1744991956; v=1; x=1745251154; b=eXlIFaD7ONceX+dfpUKNT3O1nxjmyohl6cG6A7Ly/woHnIl95ZeLKGV6f1DjYB1yQy7cjivS 5uuPFWNJ8i654teCHwcUsHLR82WlcVDXE4G7EaiITXolLRemqInhvfBmgjLeRCMNfzQKooGuuZn 4lSwEdiaNj9KmOvYaz161byUF5QG55hCuKZkPywYwPTrf5VhKKn6F9a/gX0vuTnpEYjk9cvMHaj V54MXVNbM1z2knlwcAav1I2ab1LVHvcZ6CeqlCuroCjCstLWHPKCBeGHNIWlmOE9tmGEijnPiFT bWw4PTsgDTN0IEtXK2Vld6xtn4njjjfbCgQ+s57bVTO/g== X-Received: by 127.0.0.2 with SMTP id ClgEYY7687511x4SW7G5xJiT; Fri, 18 Apr 2025 08:59:14 -0700 X-Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.19]) by mx.groups.io with SMTP id smtpd.web11.15161.1744991954194305905 for ; Fri, 18 Apr 2025 08:59:14 -0700 X-CSE-ConnectionGUID: JY8UtEmOQc+fi3dWZ2ENBg== X-CSE-MsgGUID: QvXk4ujjR1uRN6MQ13XR7Q== X-IronPort-AV: E=McAfee;i="6700,10204,11407"; a="46508355" X-IronPort-AV: E=Sophos;i="6.15,222,1739865600"; d="scan'208,217";a="46508355" X-Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa111.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Apr 2025 08:59:14 -0700 X-CSE-ConnectionGUID: rtAhWX3xSiCVgvbk6T5fvg== X-CSE-MsgGUID: jizzuCf+QSiLYAZkKIw1VQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.15,222,1739865600"; d="scan'208,217";a="136103689" X-Received: from orsmsx903.amr.corp.intel.com ([10.22.229.25]) by orviesa004.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Apr 2025 08:59:13 -0700 X-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.1544.14; Fri, 18 Apr 2025 08:59:13 -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 08:59:13 -0700 X-Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.176) 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 08:59:11 -0700 X-Received: from CO1PR11MB4929.namprd11.prod.outlook.com (2603:10b6:303:6d::19) by IA3PR11MB9254.namprd11.prod.outlook.com (2603:10b6:208:573::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8655.26; Fri, 18 Apr 2025 15:58:54 +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 15:58:54 +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+1qEepe02xqLOpBL4QgACO8lA= Date: Fri, 18 Apr 2025 15:58:54 +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_|IA3PR11MB9254:EE_ x-ms-office365-filtering-correlation-id: 0cd5d31c-b726-44a0-df3e-08dd7e91ebc9 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam-message-info: =?us-ascii?Q?W7HzJK8nTDOAqXUpAMj9RHSZoRuKY8nH/lseLygPjWpWEh0kvtd/s4teDn6N?= =?us-ascii?Q?tHCWRjZGrFh2XCvcq6hUpQ6gbnzqxFERMYgUzjKSNwYpbxT5y0W7ZRib5AYK?= =?us-ascii?Q?86PaeEBTsVV4DuzKkOr2YJY9rHWp1hfuyskg8eAfMaUbCrxlxD++5zMAA2Rv?= =?us-ascii?Q?VydOukTIdpuCSmvWtJ/VuzQ1RziPfQXaxui3jarcsCXjWkWBvtT6EohNDcmm?= =?us-ascii?Q?ggwY3tRGVeFEOW5F0DkYxIMp4cD7jboUwHsh2snW9591cLv3ebNDs4TqWG1h?= =?us-ascii?Q?BTla00UBeHKF/XiCiW+8a6xKALftaUBf0FJ1uRuhE2aOMrXpjgaoSq+2shXT?= =?us-ascii?Q?H2cT2jvbXRpAy9isskjvOEOAM9bUHPPM8JwxZn3Qvbzq4i9tUlRMCy70TEdo?= =?us-ascii?Q?NoCThzrCKB5L+w7WqKJsbnnuqu53QM50nIsKbuhQ2i/vtCNYJzuKuF/gi1Xf?= =?us-ascii?Q?iLGC/xTyiic9Blz4HVMeL6EMDk8fOAkRgZA9dK4tEYH3SrS2ZqP5AnIdcUF9?= =?us-ascii?Q?p+9u0aZhvnaZwxFSrjjwxaopp+iuw7phL/Cm2KFmoomSq4u56TDwcmEdrmjk?= =?us-ascii?Q?fv8BpzzfaHUmcOdKQFSw5pdsqnTTRQ+oj5zBnl6BBQlh33eoq0LsZfehAw5o?= =?us-ascii?Q?sqRvM04d8r3tcvmfKdEu0Qxfw18Zc0rtLnK/hM9RCfrgLiIy5QN4WCcfPsU4?= =?us-ascii?Q?ESpKWvJYzB9fvPyApj3tr0wLV5ct1DruVuVHjmDpCP4cdbpuQcJIco7ZqoLS?= =?us-ascii?Q?FoDhnOEEk4OVAVh+DgaYPkpkM5/ph6FmjwF0yPQPj18Grvc3bvJoe9dOES2c?= =?us-ascii?Q?E+CNdzXpJvWKeITFM5qRqzvfgfbkYBVKeEBU6P01WjoNSWURY3M1lnsDHvZH?= =?us-ascii?Q?z0woEfvwsVMAZ2xFT5P2xpU2f8/PRMwJ3RYttOiJFhC2Ua6Nvhji33/4QFET?= =?us-ascii?Q?KRWIscv3QZv/3CuD9/tBwGu4IH6kJs5NXlJh4Xs5d50Y1+Fr6umtmMB3P28T?= =?us-ascii?Q?F+gxkLRcXZ9JNTdf/uTQC7z1ATeODYt2viq+pf9ga4x598XvixVMOjUUk/4b?= =?us-ascii?Q?Os7/ZWQtnPrYGmXcKCGXI2GVCZxT31ryIMwa2yokryqX0c5dWOFRfSshPL5/?= =?us-ascii?Q?xrtZ7dPlHqCmnmJLvGBOYs1LAXSc4IXHBnyFKnrdvTdNdK5LGXltmKs8GRGn?= =?us-ascii?Q?QBLKJRbscddjkLcc/PMQ/bR0w+gu60O0hB1MZ1NItEE8sLNFIYMi0jZHCt3D?= =?us-ascii?Q?shm0+95KY/IQOUxrIBaycZky/SFxTJf/LIKuyz/GUkTYTyHpd9XabxhRuLDF?= =?us-ascii?Q?j6XsGOjjbv2A5ZmeeCh5+DyMoQedcu9D3OhnKvp1tGnpUI++vrkJ25b+x3lz?= =?us-ascii?Q?Ivh1kV402l13STQ+HRJ92O3bcy7VHdZ4dEObBji+Elax2bt4OaHkQB6wRAB7?= =?us-ascii?Q?j6H3pHJ1cU0L6dwm+V8qZw7heU1MAsXPImbACt9R6etJZWh7tQoqTUUo2AV8?= =?us-ascii?Q?RwOvh6HHdWP5BI0=3D?= x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?LzRq4BukvytoypSTwN4ArdpTtU1FruN2hS0JQMSLELEvuWUczwos0rkCedCN?= =?us-ascii?Q?Fc3jnT3JxCZc/MJOiic8faxt+x+nPQrYgJOFB2R5nTj2yRshZFVbKBzt54j0?= =?us-ascii?Q?jPLkQDr0O7Q2Rh3ABefmIM2iYyeCI+knr/7OHKHrg9RfBNC4K/DVdPVV4Crb?= =?us-ascii?Q?JnuV+QEUk/cXPa0Qly+iRrqOYU7txzdzrIYNX57I+opYTJCuFvmOMTsVcUYr?= =?us-ascii?Q?AFqvXsh0npvhcmVPODk2EEtvGD13rzmgU7xb8y2/CJgRkDUzRPXnTwNkAAFT?= =?us-ascii?Q?S5c78FOwCoHsJz8vLEQyVvqf7Ve44c/eZJbzVI0RqWN8H9p0aKZdo9b2Uazf?= =?us-ascii?Q?2QAzEEY+njI5BpV45kedN3IXr3wEOHjjNKeFEdsJCaUFWcgn9VvV3Z3Mmfrs?= =?us-ascii?Q?rBTgrMTZT88vZeSozePR/wwsyTGzXkHqM81MsbcrTTTfIkO7MZ6M5rAaSrq8?= =?us-ascii?Q?AyXyaEn1upCq6M9MNGv48egzpCgor2yFWv2YFClfBNzzk+EHBEaHP+3lJgGP?= =?us-ascii?Q?0q2zYnKOPVjiJPc6tAoYSp1+/8uOxnVJUHR9oZinsVgugruuo8cIToXYxND1?= =?us-ascii?Q?x/ffTKCtyzf1JXurkQ+0rS6oyPKdNnQk3s4uKquN3r0eMo7QdKoFJVDMbp9Y?= =?us-ascii?Q?V2FezMIcRhI68p/OUcmu7r9Jglk5UwJ68btqBY9lrVDHDPWF1P0ye4pR3lf/?= =?us-ascii?Q?Ujjdy9WdvQ6OSyDg1kF2l+2ID/Wer0GISvdB+6XfEDGABPPWEO73XEMLhuOD?= =?us-ascii?Q?EtL8MVodHAM8Q91FW/nXbDNduDgS2xmRCJm0DtOzM7lL9f997YTC1CgbZeoF?= =?us-ascii?Q?5fKi21K1AU3brtFvqfuuS2jE5uty1Mnf/c6+LXfgCBxNuQFCCbKnI0zC6vP2?= =?us-ascii?Q?Bn0RrxNSZIsUk5tm1H1In8FxKga8xCqMocziDRUUNtC/SGMVACJdz7qbNN63?= =?us-ascii?Q?FYHlXai8HbNHTzQtcuIKSRXJBizC/buDp1xksUytREjZMxjgDAqczWf1nJGF?= =?us-ascii?Q?b6fREfVlJ7V7lXl7KeSN6gW1uJNvaUmn2Eko46XDGgCxxAraS7oQlY/4i3Be?= =?us-ascii?Q?VOeqi2euebTsRoTpnG7+o7QvTz/vWBCe0JXFZslkJURkWkjdFO/cFHKGyhb8?= =?us-ascii?Q?Y2X0SkXWJJR/TKmSH9Aahnt7NCvL/GN9LAvJhxTwUOyPNgNZZarsTGdhAqGj?= =?us-ascii?Q?/STvp7uFudibCjyHCcC4XBIn6bnj0ShLoaYse/QFM12aGKf2CNoFn4OjaJSz?= =?us-ascii?Q?jPGDua3JjDNzxhEvwr+w7zZ9nOtf6M08jFAvAcZMngbVnEWVhb3ZahcoXkT1?= =?us-ascii?Q?0jto5SzJkmBQX2S1psLsBsfZC7i+jwxpu2aRawmZ//dmx+qoOkkJa+DDHvJn?= =?us-ascii?Q?B7Bj4wMg4D0sbwiPk7z+6+JcdXZ84eMiV6TKpwKWiv0zypPPn4uKaPOlUI7l?= =?us-ascii?Q?nHOBgmfwwsA1g+WT7Z+DP7+5192Gx3NtHIsT2NmAq32KyG3mHPqzDZr6O84O?= =?us-ascii?Q?Kdr8ew3qOetRneQRcnYPpJEJWeOS2famyvw0AeChaHCxubo6sU/ZCfjYDiJP?= =?us-ascii?Q?ce5Eo3b8elaL8EFxsLRWGXuUP4pnmM4O/Cq6waGGhfAM+WvTKr5ykxEFT9Ud?= =?us-ascii?Q?/w=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: 0cd5d31c-b726-44a0-df3e-08dd7e91ebc9 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2025 15:58:54.7220 (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: 7R1af4kvUXRyDIg3ywtnbgODumoz8FyYtBhNaprGXemR4d2wefH/HhKWmx1f1YpeNzEwzPW0cG8MurtWbIsKpD0Pf8N2PXC58XNzaJXRwoE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA3PR11MB9254 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 08:59:14 -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: 1oBtgBEZlqKkQQLWk58BKXCCx7686176AA= Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_CO1PR11MB4929C98561CA5FA5A6E2F193D2BF2CO1PR11MB4929namp_" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20240830 header.b=eXlIFaD7; 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_CO1PR11MB4929C98561CA5FA5A6E2F193D2BF2CO1PR11MB4929namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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; N= i, 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 (#121265): https://edk2.groups.io/g/devel/message/121265 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_CO1PR11MB4929C98561CA5FA5A6E2F193D2BF2CO1PR11MB4929namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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 <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 (#121265) | =20 | Mute= This Topic | New Topic
Your Subscriptio= n | Contact Group Owner | Unsubscribe [rebecca@openfw.io]

_._,_._,_
--_000_CO1PR11MB4929C98561CA5FA5A6E2F193D2BF2CO1PR11MB4929namp_--