windows - Specter/Meltdown Patch forårsager COM metode til at returnere E\_ACCESSDENIED

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg arbejder på et projekt, der bruger COM stærkt, og det nye Specter/Meltdown-patch har uden tvivl messet med kommunikationen inden for programmet.


Hvordan ved jeg? Jeg re-afbildet en Windows-maskine (maj 2017), hvor denne patch ikke eksisterede. Jeg installerede mit program og alt fungerer som forventet. Derefter downloadede jeg alle de nødvendige opdateringer. Programmet virker ikke længere. Jeg afinstallerede derefter Meltdown/Kun Specter-patch (2018-01 Kumulativ opdatering til Windows 10 Version 1507 til x64-baserede systemer (KB4056893)), og programmet vender tilbage til normal adfærd.


Jeg tilsluttede debuggeren til mit program og spores det ned til dette afsnit af kode.


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 på et Un-Patched -system:


poRouterControl->GetXPTExtendedInfoForOutputs returns S\_OK


Windows Debugger på et Patched -system:


poRouterControl->GetXPTExtendedInfoForOutputs returns E\_ACCESSDENIED


Jeg har en COM-server En forsøger at kommunikere med en COM-server B, begge har de samme tilladelser (SYSTEM). På PATCHED-systemet, når A påberåber en metode fra COM-grænsefladen INvDevControl2Itf, påberåbes fremgangsmåden af ​​server B uden fejl. Når den samme server A forsøger at påberåbe sig en metode fra en anden grænseflade, returneres INvRtrControl4Itf, på proces B, E\_ACCESSDENIED, og ​​jeg kommer aldrig over COM-grænsefladen. På et UN-PATCHED-system fungerer alt som forventet.


Har nogen fundet dette problem endnu med COM og den nye Specter/Meltdown patch? Jeg vil fortsætte med at lede efter årsagen, men den samme nøjagtige kode kører helt fint uden at lappen er installeret. Men kunder vil gerne opdatere deres systemer til sidst, så jeg kan ikke anbefale og vil ikke fortælle dem, at de aldrig skal installere patchen.

Bedste reference


Ved hjælp af Windows Support-siden på selve patch'en kunne jeg løse problemet med COM-tjenesten, uden at kalde metoden GetXPTExtendedInfoForOutputs ved at ændre nogle kode i min COM-tjeneste s CoInitializeSecurity () metodeopkald [6]


hRes = CoInitializeSecurity(NULL, -1, NULL, NULL,
        RPC\_C\_AUTHN\_LEVEL\_NONE,
        RPC\_C\_IMP\_LEVEL\_IMPERSONATE,
        NULL,
        EOAC\_NONE,
        NULL);


til


hRes = CoInitializeSecurity(NULL, -1, NULL, NULL,
        RPC\_C\_AUTHN\_LEVEL\_CALL, //<----------- changed
        RPC\_C\_IMP\_LEVEL\_IMPERSONATE,
        NULL,
        EOAC\_NONE,
        NULL);


Selv om det løser problemet, er det noget foruroligende at vide, at nogle af grænsefladerne virker helt fine med den oprindelige kode, hvor andre som INvRtrControl4Itf fejler. Desuden behøvede jeg ikke at ændre CoInitializeSecurity-metoden initialisering i den anden COM service I kommunikerer med, kun den, der ringer op, COM. Den anden COM-tjeneste kan stadig blive initialiseret med RPC\_C\_AUTHN\_LEVEL\_NONE, og mit program fungerer som før.


Jeg ændrede dog alle CoInitializeSecurity-metodeopkaldene til at bruge RPC\_C\_AUTHN\_LEVEL\_CALL, hvilket skulle begrænse muligheden for fremtidige E\_ACCESSDENIED hresults. Desværre nu, at ethvert opkald til RPC-serveren vil kræve godkendelse, vil jeg antage, at mit programs ydeevne kan tage et lille hit. Jeg tvivler på, at det vil være noget af bekymring.


Måske er det derfor, at nogle mennesker bemærker et præstations hit, når de opdaterer deres systemer med Specter/Meltdown patch ... Bare en tanke.