Intel lanserar Xeon W 3200-serien – Cascade Lake med 28 kärnor

En gemensam nämnare för alla de sårbarheter man hittat i CPUer från Spectre/Meltdown och framåt är att de på något sätt kan resultera i att information kan läcka mellan säkerhetsdomäner som är tänkt att vara isolerade från varandra.

En annan gemensam nämnare är att fixarna man stoppat in i operativsystemen bara ger en prestandapåverkan i fall där man växlar kontext, t.ex. går från applikationens adressrymd till kärnas adressrymd eller går mellan adressrymd i två applikationer.

Applikationer som spendera väldigt nära 100 % av CPU-tiden i samma kontext, vilket definitivt är fallet för Cinebench men är även sant för spel, påverkas därför i princip inte alls. Phoronix har tittat på detta en hel del, för spel gjorde man en artikel och konstaterade att prestandapåverkan där är irrelevant.

Har man däremot fall som växlar extremt frekvent mellan applikation och OS-kärna, som t.ex. vissa nätverks- och disk-tunga applikationer, kan man se en brutal påverkan. Vad som på något underligt sätt verkar falla bort här är att de riktigt I/O-tunga (räknat i I/O operationer per sekund) är ett specialfall där Intel råkar ha en ovanligt stor fördel över Zen (faktum är att detta är Intels paradgren, jobbet undersöker sätt att minska beroendet från Intel på serversidan men problemet är att våra servers gör ju nästan uteslutande just det Intel är överlägsen på, Rome kan förhoppningsvis lyfta sig här och de ARM-servers som är på väg ut har tagit I/O väldigt seriöst genom att FPGA-accelerera de vanligaste fallen).

Fall som detta är inte extremfall, kommunikation mellan virtuella maskiner (som använder snarlik teknik, här är Intels fördel ännu lite större) och containers (t.ex. Docker, där används exakt samma teknik som i detta fall) uppvisar liknande fördel.

En annan sak som rätt konsekvent verkar trilla bort i diskussionen kring dessa svagheter är: under vilka förutsättningar kan något överhuvudtaget utnyttja dem?

Linux har nu infört ett enkelt sätt att slå av all form av OS-stöd för dessa fixar. Detta då prestandaförlusten i vissa applikationer är helt oacceptabel + när man tittar på under vilka förutsättningar svagheterna kan utnyttjas inser man att det är rätt mycket ett icke-problem för många system.

Den som attackerar måste kunna köra valfri kod på din dator. Att köra saker i webbläsaren fungerar bara för Spectre variant 1 (är praktiskt möjligt så webbläsaren måste patchas) samt MDS när HT är påslaget (fast det är rätt mycket en teoretisk attack då man här även måste säkerställa att programmet som utför attacken och det som attackeras kör på samma CPU, i teorin möjligt från slumpen men kräver admin-rättigheter för att säkerställa, jobbas på en patch som säkerställer att olika program aldrig delar fysisk kärna -> helt löst).

Just kravet att en attack kräver att den som utför attacken redan kan köra valfri kod på datorn gör dessa svagheter rätt värdelösa i praktiken i de flesta fall. Det stora viktiga undantaget är molntjänster där flera kunder kör virtuella maskiner på HW som delas med andra man inte litar på.

Antar att du menar att Zen/Zen+ i genomsnitt ser en något större vinst från fallet när en CPU-tråd används per kärna jämfört med när båda trådarna används.

Med en sådan definition på "bättre" blir i så fall Intels Bonnell/Saltwell (ursprungliga in-order Atom som hade bedrövlig IPC) med råge den bästa SMT implementation som x86 någonsin skådat. Där såg man regelmässigt ~50 % boost från HT. När Silvermont sedan lanserades kapade man HT då övergången till en smal out-of-order design resulterade i att Silvermont hade högre IPC på en tråd jämfört med vad summan för Bonnell/Saltwell över två trådar.

Enda vettiga måttet på "bra" är: vem kommer närmast den teoretisk maximala IPC? Intels/AMDs problem är att man börjar komma rätt nära teoretisk maximal IPC för en ström av x86 instruktioner. Finns flera orsaker varför vi nu ser strömhopp av ARM64 (Aarch64) designer som passerar x86 i IPC, en är att en ström av Aarch64 instruktioner i princip alltid har högre teoretisk IPC jämfört med motsvarade för x86.