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

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(<em>kernel_address) << 12];  
 
Process 2:  
uint8_t</em> 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;  
    }  
}

men med noget smart timing-kode

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(<em>kernel_address) << 12)];
 
Process 2:
uint8_t</em> 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).

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?

Så er der ingen risiko.

Alle de patches jeg har hørt om kan disables på boottime.

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å.

Speculative execution betyder at en CPU eksekverer begge branches af if-sætninger ...

Meget velskrevet (hele dit indlæg)!

Mod in-memory databaser vinder på dette, de skal trods alt ikke bruge kald til storage!?

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.

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.

"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.

Jeg synes ikke, jeg er blevet klogere på, hvad det er OSet kan gøre for at forhindre at instruktioner ligger sådan i memory, at spekulativ udførsel forhindres. Det er vel compileren som beslutter programlayout på oversættelsestidspunktet? Eller er der tale om at vippe en bit i processoren som slår spekulativ udførsel fra?

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) ?

Man kunne foranlediges til at tro at Intel har gjort det med vilje.

"Never attribute to malice what can be explained by simple incompetence"

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]