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 SmmCommunicationMmCommunicate2 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 something 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@microsoft.com>
Cc: Kinney, Michael D <michael.d.kinney@intel.com>; devel@edk2.groups.io; Ni, Ray <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.
All 3 communication protocol calls go to the same communicate() function that tests the HeaderGuid against the V3 GUID.
But when the call is from runtime, reading the HeaderGuid using the physical address of communication buffer would cause page fault. The virtual address should 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 address to SMM. SMM expects the physical
address because the virtual-to-physical mapping in SMM is identical.
The bug exists in both the SmmIpl.c in MdeModulePkg and the MmCommunicationDxe.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