Spectre/Meltdown Patch Causing COM Method to Return E
I work on a project that uses COM heavily and the new Spectre/Meltdown patch has without a doubt messed with the communication within the program.
How Do I Know? I re-imaged a Windows Machine (May of 2017) where this patch didn't exist. I installed my program and everything works as expected. Then I downloaded all the required updates. The program no longer works. I then uninstalled the Meltdown/Spectre patch only (2018-01 Cumulative Update for Windows 10 Version 1507 for x64-based Systems (KB4056893)) and the program returns to normal behavior.
I hooked up the debugger to my program and traced it down to this section of code.
INvRtrControl4Itf * poRouterControl = GetNvRtrControl4();
if(poRouterControl)
{
//the following line of code always returns E_ACCESSDENIED
HRESULT hr = poRouterControl->GetXPTExtendedInfoForOutputs(lNumPorts, poOutputPorts, poXPTAndLPRInfo, peStatus);
if(FAILED(hr))
{
ConnectToRouterControl();
poRouterControl->Release();
return hr;
}
poRouterControl->Release();
}
Windows Debugger on an Un-Patched System :
poRouterControl->GetXPTExtendedInfoForOutputs returns S_OK
Windows Debugger on a Patched System :
poRouterControl->GetXPTExtendedInfoForOutputs returns E_ACCESSDENIED
I have a COM server A trying to communicate with a COM server B, both have the same permissions (SYSTEM). On the PATCHED system, when A invokes a method from the COM interface INvDevControl2Itf, the method is invoked by server B without errors. When that same server A tries to invoke a method from a different interface, INvRtrControl4Itf, on process B, E_ACCESSDENIED is returned and I never get across the COM interface. On an UN-PATCHED system, everything works as expected.
Has anyone encountered this problem yet with COM and the new Spectre/Meltdown patch? I will continue to look for the cause but the same exact code runs perfectly fine without the patch installed. However customers will want to update their systems eventually so I can't recommend and don't want to tell them to never install the patch.
With the help of the Windows Support Page on the Patch Itself, I was able to resolve the issue of the COM service failing to call the method GetXPTExtendedInfoForOutputs by changing some code in my COM service's CoInitializeSecurity() method call
hRes = CoInitializeSecurity(NULL, -1, NULL, NULL,
RPC_C_AUTHN_LEVEL_NONE,
RPC_C_IMP_LEVEL_IMPERSONATE,
NULL,
EOAC_NONE,
NULL);
to
hRes = CoInitializeSecurity(NULL, -1, NULL, NULL,
RPC_C_AUTHN_LEVEL_CALL, //<----------- changed
RPC_C_IMP_LEVEL_IMPERSONATE,
NULL,
EOAC_NONE,
NULL);
Although it solves the issue, it's somewhat troubling to know that some of the interfaces work perfectly fine with the original code where as others like INvRtrControl4Itf fail. Furthermore I didn't need to change the CoInitializeSecurity method initialization in the other COM service I am communicating with, only the caller COM service. The other COM service can still be intialized with RPC_C_AUTHN_LEVEL_NONE and my program works as before.
However, I did change all the CoInitializeSecurity method calls to use RPC_C_AUTHN_LEVEL_CALL, this should mitigate the possibility of future E_ACCESSDENIED hresults. Unfortunately now that every call to the RPC server will require authentication, I am going to assume my program's performance may take a small hit. I doubt it will be anything of concern.
Perhaps this is why some people are noticing a performance hit when updating their systems with the Spectre/Meltdown patch... Just a thought.
链接地址: http://www.djcxy.com/p/41056.html