En de oplossing?
‘Maar Intel, check de privileges van een instructie dan voor de speculatieve uitvoering, in plaats van daarna’, roep je nu naar je scherm. Dat lijkt de oplossing, maar daar schuilt net het probleem. De micro-architectuur is er op gebouwd om de check achteraf uit te voeren. Alle transistors en de interconnects die ze tot logische schakelingen maken, zijn in de designfase door de Intel-ingenieurs zo ontworpen om pas achteraf te checken. Het is mogelijk om de firmware aan te passen en het veiligheidsprobleem (deels) op te lossen, maar dat brengt een enorme impact op de prestaties met zich mee.
In het geval van de eerste variant van Spectre, versie 1.0, rolde Intel firmwarepatches uit waarbij de processor wisselde tussen een user mode en een kernel mode. Voor de uitvoering gebeurt na de patch een check op iedere instructie, waarna de processor naar de juiste modus schakelt. Dat verhelpt het probleem, maar vertraagt de cpu in de praktijk tot tien procent. De werkelijke vertraging hangt af van het type processor en het type workload. Vooral Haswell-chips en ouder krijgen het zwaar te verduren. In traditionele consumentenprogramma’s gebeurt het rekenwerk vooral in de user space, en is de impact klein. In serverland moet er veel meer tussen user space en kernel space gewisseld worden, waardoor de patch de prestaties flink naar omlaag haalt.
Het is mogelijk om het veiligheidsprobleem (deels) op te lossen, maar dat brengt een enorme impact op de prestaties met zich mee.
In het geval van de Chrome-patch voor Spectre wordt het probleem opnieuw verholpen, deze keer niet op niveau van de cpu-firmware maar op niveau van de software zelf. Opnieuw verdwijnt hierdoor een stuk van de efficiëntiewinst die speculatieve uitvoering met zich meebrengt, en die een cpu net z’n snelheid geeft. Het gevolg: Chrome heeft plots tot dertien keer meer systeemgeheugen nodig.
Zoals gezegd zijn ook AMD-chips en cpu’s op ARM-architectuur kwetsbaar. Toch ondervinden zij minder problemen. Op Intel na bouwde iedereen wel ruimte in om speculatieve instructies vooraf op de rooster te leggen. Een firmwarepatch heeft daardoor een veel kleinere tot onvoelbare impact op de prestaties.
Duistere toekomst
De kat is uit de zak. Spectre is intussen uitgegroeid tot een verzamelnaam voor lekken die speculatieve uitvoering misbruiken. Nu duidelijk is dat cpu’s kwetsbaar zijn via die vector, zoeken hackers en beveiligingsonderzoekers naarstig naar nieuwe manieren om speculatieve instructies te misbruiken. Daar zijn Spectre 1.1 en 1.2 voorbeelden van. Er is geen reden om te denken dat er geen versies 1.3 en 1.4 zullen komen, die andere manieren vinden om ongeoorloofde zaken speculatief realiteit te maken.
Intel zal dus kop van jut blijven, niet alleen met de huidige processor, maar ook met de volgende generaties. Een micro-architectuur ontwerp je immers niet op een weekje tijd. De cpu’s die Intel op de planning heeft staan, hebben de Spectre-kwetsbaarheid ingebakken. Intel heeft niet de optie om van de grond af te beginnen en een cpu zonder Spectre te ontwerpen. Dat kost tijd. Pas binnen enkele generaties zullen Intel-chips volledig Spectre-vrij zijn.
Tot het zover is, blijft Spectre een enorm venijnig lek, dat deels in de firmware kan worden verholpen, maar deels ook door alle softwarebouwers gemitigeerd moet worden. Helaas telkens met een prijs op het vlak van prestaties. Lees: de kwetsbaarheid blijft zeker en vast nog erg lang bestaan. hoor je binnen enkele maanden over een nieuwe gevaarlijke variant, dan weet je nu tenminste waarom die Spectre je blijft achtervolgen.
Eén lichtpuntje: in professionele omgevingen kunnen geavanceerde beveiligingsoplossingen soelaas bieden. Dat doen ze niet door het lek te patchen, maar door code na te kijken op kenmerken van een Spectre-aanval, bijvoorbeeld in een sandboxomgeving. De processor blijft wel kwetsbaar, maar malware wordt zo gestopt voor de aanval kan beginnen.
4 minuten geleden
