Spectre/Meltdown Patch Causing COM Method to Return E_ACCESSDENIED

Question

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.

Answer 1

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.