Bug in Intel-processors lekt data uit kernel, oplossing verlaagt prestaties aanzienlijk

135 reacties

Er is een nieuwe bug gevonden in zo'n beetje alle recente Intel-processors, die vermoedelijk elke gebruiker van een dergelijke chip gaat raken. Eerder publiceerden we een artikel hierover, maar in dit bericht zetten we gedetailleerder uiteen wat het probleem inhoudt. Het lijkt namelijk breder te zijn dan eerder gedacht.

Lees ook: Alles wat je moet weten over de processorbug

Hardwarematige bug

De bug zit op hardwareniveau in de scheiding tussen user space en kernel space, waardoor er vanuit user space soms de mogelijkheid bestaat om het aan de kernel toegewezen werkgeheugen uit te lezen. Details daarover zijn nog niet bekendgemaakt en zullen vermoedelijk pas volgen als er voor de meeste systemen een update klaarligt. The Register is echter op een spoor gekomen over waar het probleem mogelijk zit. AMD-processors zijn niet getroffen.

Speculeren zonder beveiliging

Het probleem lijkt te liggen in een techniek die Intel gebruikt om instructies zo snel mogelijk uit te laten voeren. De processor speculeert over welke instructies vermoedelijk zullen gaan komen en haalt die vast op, om ze zo snel mogelijk uit te kunnen voeren. Het probleem daarbij is echter, dat bij het uitvoeren van speculatieve instructies, beveiligingsmaatregelen overboord gegooid worden. Zo kan code die normaal niet toegankelijk is, bijvoorbeeld van de kernel, normaalgesproken niet uitgevoerd worden, maar als de processor speculeert dat het in de toekomst komt, voert hij de code wel uit omdat er geen beveiligingscheck is. Op deze manier zouden de idealiter ontoegankelijke kernel, toch deels toegankelijk worden vanuit user space.

Update via OS

Het kritieke punt aan de bug is, dat elke software theoretisch misbruik kan maken van de kwetsbaarheid, waardoor een simpele browser-plugin al kwaad kan. Hierbij is het bekend dat het een probleem op hardware niveau is, wat oplossen van het probleem moeilijk en veelomvattend maakt. Zo is het niet op te lossen met nieuwe microcode via een bios-update, omdat het tussen het besturingssysteem en de processor ligt. Het besturingssysteem zal anders om moeten gaat met calls aan het adres van de processor.

Gevolg is dat systemen na een update voor dit probleem vermoedelijk fors langzamer zullen worden. Er zal namelijk een techniek geïmplementeerd moeten worden die het werkgeheugen van de gebruiker en de kernel, volledig van elkaar gescheiden houdt. Op dit moment schakelt de processor tussen de kernel space en user space, maar is in beide tegelijk actief, zodat schakelen ertussen heel vlot gaat. Het probleem daarbij is dat de scheiding tussen die twee te omzeilen is. Een mogelijke oplossing is KPTI, ofwel Kernel Page Table Isolation. Hiermee wordt de kernel space compleet gescheiden van user space.

KPTI

Dit werkt simpelweg door de gehele kernel uit het werkgeheugen te halen als het niet nodig is. Als de processor in user space bezig is, zal de kernel fysiek niet in het geheugen staan en dus ook nergens terug te vinden zijn. Als er een taak komt die de kernel uit moet voeren, dan wordt er in een alsnog gescheiden virtueel deel, een schaduwkopie gemaakt van zowel de kernel- als de user space. Dit maakt het mogelijk de taak in kernel space uit te voeren, zonder dat beide delen bij elkaar kunnen. Als de taak klaar is, dat wordt de kernel weer uit het geheugen gezet en schakelt de cpu terug naar user space.

Fors lagere prestaties

Hoewel deze oplossing het probleem van lekkende gegevens uit de kernel verhelpt, brengt het andere problemen met zich mee, en die zijn simpeler dan je zou vermoeden. Het continue laden van de kernel in het geheugen en het weer verwijderen ervan, maakt dat schakelen tussen user space en kernel space veel meer tijd gaat kosten dan voorheen het geval was, wat een forse daling in de prestaties teweegbrengt. Er wordt gesproken van 5 tot meer dan 30% lagere prestaties, afhankelijk van het model processor. Daarbij maakt het ook uit wat voor applicatie er draait. Operaties die alleen in user space liggen, zullen vermoedelijk nog net zo snel zijn als voorheen.

Makers van OS'en aan zet

Daarnaast ligt er een verantwoordelijkheid bij makers van besturingssystemen als Microsoft, Apple en de mensen achter de Linux-kernel. Stuk voor stuk zullen ze aangepast moeten worden en KPTI gaan implementeren, met daarnaast vermoedelijk nog andere maatregelen. Voordat alle besturingssystemen een update hebben gehad kan er wat tijd verstrijken, waarna mensen nog over zullen moeten stappen naar de nieuwe versie - iets dat lang kan duren.

Het probleem werd bekend nadat de Linux-kernel aangepast werd om KASLR (Kernel Address Space Layout Randomization) te beschermen - een techniek die gevoelige gegevens random over het geheugen verspreidt om zo onvindbaar te zijn. Het graven in de kernel door middel van de huidige bug, zou het KASLR-mechanisme kunnen voorspellen om zo gemakkelijk gevoelige data uit het geheugen te kunnen halen als wachtwoorden en encryption keys. Het blijft dus zo dat die gegevens relatief onvindbaar zijn in het geheugen, maar de kans bestaat dat voorspeld kan worden waar ze staan, waardoor gevoelige gegevens kunnen lekken.

AMD niet vatbaar

AMD ondersteunt het speculeren over toekomstige instructies ook, maar voert wel een controle uit of het geheugen dat het wil benaderen wel benaderd mag worden. De chips van het bedrijf zijn daarom ook niet vatbaar voor deze bug. Hoewel ze niet vatbaar zijn, levert KPTI ook voor AMD-processors een lagere prestatie op als het overal geïmplementeerd wordt. Het is dus van belang dat de update alleen doorgevoerd wordt voor Intel-chips, zoals Tom Lendacky ook zegt in LKML. Hij publiceerde een stukje code om AMD-processors uit te sluiten van KPTI.

Bron: The Register

« Vorig bericht Volgend bericht »
0
*