Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 37 reacties

HyperThreading aankondiging De onafhankelijk werkende BSD-programmeur Colin Percival waarschuwde afgelopen vrijdag dat het gebruik van HyperThreading-technologie op servers met meerdere gebruikers een beveiligingsrisico kon vormen. Er zou namelijk een methode bestaan om deze techniek - die al lange tijd standaard in een groot deel van de desktop- en serverchips van Intel zit - te misbruiken voor het achterhalen van encryptiesleutels van anderen. Nu de complete technische details met betrekking tot deze ontdekking bekend zijn gemaakt is het tijd om te bekijken wat er precies aan de hand is. Van te voren kunnen we al melden dat het allemaal niet zo spectaculair is als het in eerste instantie werd gebracht: Het is niet nodig voor Intel om al zijn HyperThreading Xeons terug te roepen, en waarschijnlijk zullen alleen de écht paranoïde systeembeheerders het de moeite waard vinden om er een oplossing voor te zoeken. Toch is het een interessante en vooral slimme truc, dus vandaar dat we er graag nog even aandacht aan willen besteden.

* Geheime kanalen

Om een beter idee te krijgen van wat er mogelijk kan gebeuren is het handig om eerst het concept van een 'secret channel' uit te leggen. Dit is een manier voor twee threads om met elkaar te communiceren zonder dat het operating systeem dat kan voorkomen of zelfs maar in de gaten heeft. Beide processen moeten hier bewust aan meewerken, maar een hacker kan op deze manier dus wel alle restricties omzeilen die het operating systeem heeft om gebruikers van elkaar gescheiden te houden. De eerste methode die we zullen bekijken gaat er wel vanuit dat er een bestand is waar beide processen van kunnen lezen, maar verderop zullen we zien dat zelfs dat niet nodig is.

De communicatie werkt op de volgende manier: Het 'verzendende' proces leest een paar delen van het bestand uit. Door het lezen van deze gegevens komen ze automatisch in het geheugen te staan. Het 'ontvangende' proces leest vervolgens het complete bestand uit. Het (virtuele) geheugen van een computer werkt altijd met brokken data van vaste grootte, de zogenaamde pagina's. Door te meten hoe lang het duurt voor iedere pagina van het bestand is opgehaald kan herkend worden welke delen ervan al een keer eerder zijn gelezen. Als een bepaald deel al in het RAM staat zal het immers veel eerder toegankelijk zijn dan wanneer het nog van de harde schijf gehaald moet worden. Door een simpele afspraak te maken (pagina lezen: 1, pagina niet lezen: 0) kunnen op deze manier gegevens in binaire vorm worden overgestuurd.

Wie nu denkt dat dit een gigantisch onhandige methode is met meer nadelen dat wat anders heeft helemaal gelijk. Toch is er een variant die wel degelijk (redelijk) goed werkt. Deze is gebaseerd op het cache van de processor en doet eigenlijk precies het tegenovergestelde van de eerste methode: In plaats van dingen te lezen zodat voor de ander merkbaar is dat ze sneller zijn, duwt deze juist data uit het cache om het voor de ander trager te maken. Het voordeel daarvan ten opzichte van de andere methode is dat de twee threads op deze manier geen toegang hoeven hebben tot een of ander gedeeld bestand, maar behalve het draaien op dezelfde processor geen enkele andere connectie nodig hebben.

Cacheing
Van traag en groot naar klein en snel: harde schijf, systeemgeheugen, L2-cache, L1-cache.

Het equivalent van een geheugenpagina in termen van processorcache is een lijn. Hoewel het operating systeem zelf kan bepalen hoe groot pagina's zijn, liggen cachelijnen vastgelegd in de hardware. Het L1-cache van de Pentium 4-architectuur is bijvoorbeeld opgebouwd uit 128 lijnen van 64 bytes groot. Voor iedere bit die de 'verzender' wil versturen moet het een stuk geheugen reserveren ter grootte van één cachelijn. Om een 32-bits woord te versturen is dus een array van 2048 bytes nodig. De ontvanger reserveert ondertussen een array dat precies even groot is als de capaciteit van het cache (voor het L1 van de Pentium 4 is dat 8KB) en leest dat direct helemaal in. Op dat moment staan er dus alleen nog maar gegevens van de ontvanger in het cache.

Vervolgens is de verzender aan de beurt om bepaalde delen van zijn 2KB-array lezen. Omdat het L1-cache al helemaal volstaat zal iedere keer dat de verzender iets leest een stuk data van de ontvanger weggegooid moeten worden. Als de ontvanger vervolgens weer aan de beurt is kan deze zijn eigen 8KB-array weer een keer nalopen, en meten of (en zo ja ook welke) lijnen door de verzender terug naar het L2-cache zijn geschopt. Er kunnen natuurlijk altijd andere threads tussendoor komen die roet in het eten gooien, maar gegeven dat er gunstige omstandigheden zijn en er een goed foutcorrectie-algoritme in het protocol zit kan op een 2,8GHz Pentium 4 toch een kanaal van 400KB/s worden gerealiseerd.

Ook het L2-cache kan gebruikt worden om een geheim kanaal aan te leggen, maar dat is om verschillende redenen al een stuk lastiger. Ten eerste bevat het L2-cache in tegenstelling tot het L1-cache een mix van instructies en data, waardoor de reden waarom een lijn uit het cache is geschopt minder zeker is. Ook is de extra latency bij ontbrekende gegevens minder consequent, omdat dankzij de TLB (translation lookaside buffer) de helft van de lijnen sneller in het geheugen kan worden gevonden dan de andere helft. Ook kan het hardwarematige prefetch-mechanisme roet in het eten gooien als er in een (te) voorspelbaar patroon uit het cache wordt gelezen. Toch is het mogelijk om deze problemen te omzeilen en een kanaal met een bandbreedte van ongeveer 100KB/s aan te leggen.


Lees meer over



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True