5, 17 eller 30 procent? Stor usikkerhed om performance-tab efter Meltdown-patch

Det er endnu uvist hvad sikkerhedsopdateringen til Meltdown vil betyde for performance, hos blandt andet de store cloudleverandører Amazon, Google og Microsoft.

Sårbarheden Meltdown, der vedører Intel-processorer og muliggør nedbrydning mellem brugerens programmer og styresystemet er ved at blive lukket i diverse styresystemer. Sent onsdag blev detaljer om sårbarheden og en anden CPU-sårbarhed kaldet Spectre offentliggjort .

Ifølge The Register er der risiko for et performance-tab på mellem fem og op til 30 procent, når systemer med Intel-processorer bliver patched for Meltdown.

Den første bølge af patches er allerede rullet ud for Windows 10, MacOS, Linux og Android. Ifølge Businessinsider vil computerprocessorer baseret på Intels 2½-årig gamle Skylake arkitektur og nyere ikke blive mærkbart påvirket, mens ældre processorer risikerer større påvirkning i performance.

Læs også: Meltdown og Spectre: Enorme sikkerhedshuller fundet i CPU'er

Årsagen til den faldende perfomance skal findes i metoden speculative execution, som er den mest udbredte måde for styresystemer at interagere med programmer på. Speculative execution har været en kernemetode i Intels processor-arkitektur siden 1995.

Speculative execution giver programmer adgang til data fra styresystemet, før de faktisk skal anvendes, for på den måde at øge hastigheden. Når der lukkes for adgangen til speculative execution, risikerer performance at falde. Men præcist hvor meget er endnu uvist.

Intel: ingen betydning for almindelige brugere

Microsoft skriver i et blogindlæg om performance efter patching af virksomhedens cloud-miljø Azure:

»Vi har arbejdet med at optimere CPU'en og disk I/O-path, og vi ser ikke mærkbar performancenedgang efter opdateringen er gennemført. Et mindre del af vores kunder kan opleve en nedgang i netværksperformance. Det kan adresseres ved at slå Azure Accelerated Networking(Windows og Linux) til, hvilket er en gratis tjeneste for alle Azure-kunder. Vi overvåger løbende vores performance.«

Hos Intel afviser man, at sikkerhedsopdateringer får betydning for almindelige brugere.

»Enhver performance-påvirkning er afhængig af arbejdsmængden og burde, for den almindelige computerbruger, ikke være signifikant, og vil blive afbødet over tid,« skriver Intel i en pressemeddelelse.

Amazon skriver i en blog, at virksomheden er opmærksom på sikkerhedshullerne, og er i gang med at patche, men selskabet nævner ikke umiddelbart noget om påvirkning af performance i virksomhedens servermiljø på grund af opdateringerne.

I/O påvirker

Sikkerhedsopdateringen til Linux-baserede systemer var blandt de første patches og her viser estimater, at performance falder op mod 17 procent, mens andre applikationstests ikke viser et fald. Fælles for forskellige Linux-test er, at det er antallet af systemkald der påvirker performancetabet.

»Der har været mange overskrifter i dag på forskellige websites, der påstår at Intel CPU-bug giver 30 procent lavere performance, og det lyder som om det er en universel kendsgerning eller tæt på at være det. Jeg har endnu ikke set slutbrugere bliver dramatisk påvirket«, skriver Linux-mediet Phonorix.com

Softwareudvikler og Version2-blogger Poul-Henning Kamp oplyser via mail, at performancetabet kan være direkte proportionalt med antallet af systemkald, og at det derfor er I/O-tunge brugere, der risikerer at blive ramt - og altså ikke CPU-tunge brugere.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (12)
Jens Jönsson

Ifølge The Register er der risiko for et performance-tab på mellem fem og op til 30 procent, når systemer med Intel-processorer bliver patched for Meltdown.

[konspirationsteori begynd]

Man kunne foranlediges til at tro at Intel har gjort det med vilje. Viser det sig at det sløver systemerne så meget, kan man godt forestille sig at nogle vil investere i nyt.....
Det vil komme Intel tilgode, med mindre de selvfølgelig køber AMD....

Så er vi henne i den tilsvarende sag, som med gamle Apple iPhones....

[konspirationsteori slut]

Martin Kristiansen

Ydelsesomkostningen er afhængig af hvor mange kald man har ind i kernen. For de fleste desktop programmer vil prisen nok ligge nede i støjen, men for en du eller en find er 50% blevet nævnt. 17-23% performance-tab for Postgresql er også blevet nævnt.

Hvem samlingen regningen op for shared kernel løsninger som Docker/Jails? Cloud provideren eller kunden (Eller Intel) ?

Søren Ferling

"Det vil komme Intel tilgode, med mindre de selvfølgelig køber AMD...."

Nu er teknikken fra 1995 - men dette kommer nok lidt ubekvemt for Intel, når nu AMD for første gang i et årti har lanceret CPU'er, der er reelle konkurrenter til Intels.

Sune Marcher

Speculative execution giver programmer adgang til data fra styresystemet, før de faktisk skal anvendes, for på den måde at øge hastigheden. Når der lukkes for adgangen til speculative execution, risikerer performance at falde. Men præcist hvor meget er endnu uvist.

Dette er en værre omgang vås.

For det første bliver der ikke lukket af for speculative execution - det ville give performancenedgang af helt andre dimensioner.

Speculative execution betyder at en CPU eksekverer begge branches af if-sætninger - dette gøres fordi CPU'er er nogle komplekse pipelinede bæster, og er i stand til at eksekvere statements før retnigen af en if er kendt. Når retningen af if'en er kendt, bliver state af den forkerte eksekvering discarded og den korrekte committed. (Forsimplet forklaring, men forhåbentligt simpel nok til at være forståelig).

Mens kode bliver spekulativt afviklet, bliver CPU'ens cacher anvendt, ganske som normalt. Problemet er at Intel-CPU'er loader cache før de checker for user vs kernelmode privilegier i paging tabellerne. Dette ville burde i sig selv ikke være et problem, da man ikke har mulighed for at tilgå indholdet af CPU-cachen... men med noget smart timing-kode kan man konstruere en side-channel der effektivt set giver mulighed for at gætte nok på cache-indhold til at man kan konstruere en byte ad gangen.

Det vil sige at kode der ikke logisk set bliver udført påvirker mikro-arkitekturen på en måde der kan aflæses af usermode kode.

Linux og macOS har (før KAISER patches) mapped hele det fysiske addresserum så det er tilgængeligt for hver process, dog med "kernel-mode access only" bit sat for hver page. Windows gør det anderledes, men alt hvad der er in-memory kan tilgås - det er mere besværligt og giver ikke adgang til arbitrær fysisk hukommelse, men ret beset er man interesseret i at fiske credentials, access tokens, private keys eller lignende, så det er godt nok.

Fixet mod at læse kernel mode memory er at undlade at mappe kernel mode memory i usermode - bortset fra det allermest krævede... basically interrupt handlers og nogle "trampoliner" der skifter til en kernel-mode pagetable og hopper videre til det relevante kode. På den måde bliver side-channel angrebet begrænset til at kunne læse den nuværende process' hukommelse samt nogle ikke specielt interessante kernel-områder, der forøvrigt kan være svære at finde frem til.

Det er relativt dyrt at skifte paging tabeller - normalt har man kun gjort det når OS'ets scheduler skifter fra en tråd i en process til en anden, hvilket er til at leve med når tråde får lov til at køre i flere millisekunder ad gangen. Men nu kommer det altså til at ske ved hvert enkel syscall... så kode der laver masser af små I/O kald bliver hårdt ramt, hvorimod talknusnings-opgaver ikke bør blive ramt mærkbart.

Kjeld Flarup Christensen

Hvis man har en "beskyttet" server som håndterer en del netværkstrafik eller database, så vil den jo blive ramt.

Hvad er egentligt risikoen ved ikke at patche, hvis man er sikker på at det kun er ens egen kode der kører på serveren?

Derved kunne der være en del performance at hente/bevare ved ikke at have denne patch på.

Lasse Lasse

men med noget smart timing-kode


Noget i stil med:

Process 1:  
uint8_t* process_shared_probe = ...;  
volatile uint8_t* kernel_address  = ...;  
while(uint64_t(*kernel_address) << 12 != 0) {  
}  
char dummy = process_shared[uint64_t(*kernel_address) << 12)];  
   
Process 2:  
uint8_t* process_shared_probe = ...;  
for(int8_t c = 0; c < 256; c++) {  
    start timer  
    _mm_clflush(process_shared[c << 12]);  
    afslut timer  
    if(tidsforbrug > whatever) {  
        stdout << "kernel memory byte: " << c;  
    }  
}

Nogle implementeringer af meltdown glemmer i øvrigt "volatile" sådan at compileren vil optimere while-løkken bort med /O3 selvom den gør det mere pålideligt (meltdown har en del støj/fejl).

Lasse Lasse

Nej ok, det var lidt hastight...

Process 1:    
uint8_t* process_shared = ...;    
volatile uint8_t* kernel_address  = ...;    
while(uint64_t(*kernel_address) << 12 != 0) {    
}    
char dummy = process_shared[uint64_t(*kernel_address) << 12];    
   
Process 2:    
uint8_t* process_shared = ...;    
for(int8_t c = 0; c < 256; c++) {    
    start timer    
    _mm_clflush(&process_shared[c << 12]);    
    afslut timer    
    if(tidsforbrug < whatever) {    
        stdout << "kernel memory byte: " << c;    
    }    
}
Log ind eller Opret konto for at kommentere
Pressemeddelelser

Welcome to the Cloud Integration Enablement Day (Bring your own laptop)

On this track, we will give you the chance to become a "Cloud First" data integration specialist.
15. nov 2017

Silicom i Søborg har fået stærk vind i sejlene…

Silicom Denmark arbejder med cutting-edge teknologier og er helt fremme hvad angår FPGA teknologien, som har eksisteret i over 20 år.
22. sep 2017

Conference: How AI and Machine Learning can accelerate your business growth

Can Artificial Intelligence (AI) and Machine Learning bring actual value to your business? Will it supercharge growth? How do other businesses leverage AI and Machine Learning?
13. sep 2017
Jobfinder Logo
Job fra Jobfinder