Het issue draait om de manier waarop CPU's page tables van virtueel geheugen aanspreken. Door een ontwerpfout kan vanuit applicaties de inhoud van geheugen met de hoogste rechten worden uitgelezen. De techniek die daarvoor wordt gebruikt is een soort parallellisatiemethode die speculative execution wordt genoemd.
Hoe de aanval werkt
Dat is onderdeel van een dynamische uitvoermethode (OOE) waar de CPU een geïnformeerde gokpoging doet van waar in het geheugen de volgende opdracht wordt uitgevoerd. Het idee daarvan is dat de verwerking van een proces wordt versneld zonder dat er aanvullende CPU-tikken verloren gaan. Het is dus eigenlijk een techniek om de Von Neumann-bottleneck beter te pareren.
Intel belooft nu patches voor hardware van de afgelopen vijf jaar uit te brengen, maar het probleem kan dateren van de tijd dat er werd overgestapt op 64-bit in 2006 met de Penryn/Merom-chips. Intel hoorde voor het eerst van het issue in juni 2017 van onderzoekers bij Google. Die deden er verder het zwijgen toe totdat Intel en OS-leveranciers een oplossing hadden. Inmiddels zijn de bevindingen gepubliceerd (PDF).
De oplossing
Er zijn in totaal drie varianten van hetzelfde basisprobleem en ze kunnen alle drie worden opgelost, maar een patch kan alleen toegepast worden op het besturingssysteem. De fouten zitten ingebakken in het silicium: je kunt ze niet upgraden en geen BIOS-update repareert de architectuurfout. Alleen een OS-fix kan soelaas bieden.
De Linux-kernel heeft een oplossing en de fixes rollen uit naar diverse distro's, terwijl Microsoft het deze week uitrolde voor Windows 10-machines en aanstaande dinsdag naar de rest van de nog ondersteunde Windows-systemen. Maar dat is dus een stoplap. De echte oplossing ligt in het herontwerpen van de CPU's.
Vertraging chiproadmap
Hoe lang dat duurt, is een punt van discussie. Volgens Jim McGregor van Tirias Research zorgt een herontwerp van een vertraging van zes tot negen maanden op de roadmap van Intel. Nathan Brookwood van Insight64 rekent zelfs op twee tot vier jaar. Intel werd in juni 2017 geïnformeerd, maar het is niet duidelijk of er wijzigingen zijn aangebracht in de planning destijds voor 2018.
Normaal gesproken delen de kernel en applicaties adressen in het geheugen om prestaties te verbeteren als een app OS-calls maakt. Ze moeten schakelen tussen page tables als een app de kernel aanspreekt en data ophaalt. Kerneldata zou onzichtbaar moeten zijn, maar door deze techniek kan de software kernelinformatie achterhalen.
Oplossing zorgt voor vertraging
De oplossing is het aanbrengen van een strikte scheiding in de geheugenruimte die door de kernel wordt aangesproken en de adressen waar applicaties gebruik van kunnen maken. Het gevolg daarvan is een hogere overhead voor elke OS-call van software. De kerneldata moet steeds worden ingeladen, terwijl app-data uitlaadt en andersom voor elke call.
Hierna: Wat merk je hiervan en hoe zit het met AMD?
En dat is vooral een probleem als er een interrupt is, zoals een I/O-actie als een lees/schrijf-actie. Niet voor niets merkte Phoronix bij zijn tests weinig vertraging op bij normale pc-workloads, maar wel bij I/O-zware toepassingen als PostgreSQL en Redis. In plaats van de kerneldata en appdata in-memory te houden, moeten CPU's de twee steeds in- en uitladen. Dat heeft een duidelijke impact op de snelheid.
Pc's weinig last; servers kraken
Dat heeft ook invloed op elk scenario waarbij applicaties en het besturingssysteem met elkaar communiceren. Stel je eens een situatie voor waarbij een server tientallen VM's heeft draaien, elk met een eigen OS-instance, de hardware aansprekend door de hypervisor? Virtualisatie gaat het hardst geraakt worden door dit issue.
Hoe hard? The Register schat het op een gebied tussen de 5 en 30 procent, afhankelijk van de specifieke taak. Open source-site Phoronix schat het lager in op basis van benchmarktests met gepatchte systemen, maar voor het gebruik van databases komt dat nog steeds uit op 7 tot 20 procent. Voor zaken als pc-games is de impact verwaarloosbaar.
Ook zijn er klachten van gebruikers die vertragingen hebben opgemerkt bij cloudservers van Amazon. Dat speelt al enkele weken, met fixes die steeds op de achtergrond werden toegepast, maar nu met de bekendmaking van het CPU-gat is er een oorzaak aan te wijzen.
Intel: kalmte bewaren
Intel maant tot kalmte omdat er geen exploits in het wild zijn aangetroffen en het niet mogelijk is om code te injecteren, alleen om geheugen uit te lezen. Maar dat is meer dan voldoende om dit een ernstig probleem te maken. De grootste dreiging is voor datacenters waar meerdere gebruikers VM's op dezelfde hardware draaien en de ene een kijkje kan nemen bij de inhoud van de andere.
Dat is op z'n zachtst gezegd onacceptabel voor elke klant. Maar een vertraging van 20 tot 30 procent is evenmin acceptabel. Het is daarmee duidelijk dat Intels jaar helemaal vergalt is, en we zitten nog maar in de eerste week van 2018.
Hoe zit het met AMD?
Volgens Intel wordt AMD evengoed getroffen, maar iedereen heeft het over Intel. Dat komt doordat AMD zijn 64 bit-architectuur anders heeft ingericht. AMD voert namelijk geen speculative execution uit, het basisprobleem van Meltdown. De chips zijn wel enigszins kwetsbaar voor soortgelijke aanvallen, maar lang niet in dezelfde mate als die van Intel.
Intel voert namelijk een vrij agressieve vorm van branch prediction uit, waarbij de CPU dus geïnformeerde gokpogingen doet om kerneladressen te raden. AMD doet dat niet als er een risico is op geheugenuitvoer buiten de randvoorwaarden, zoals het uitlezen van kernelgeheugen. Dit is een issue dat de komende weken tot maanden blijft doorspelen en we hebben hier dus zeker nog niet het laatste over gehoord.
-
-
Er zijn nog geen reacties.Reageer
Preview