Spectre en Meltdown maakten in 2018 maar al te duidelijk dat hardware en code veiliger moeten worden. We leggen uit welke beveiligingsfuncties er zijn en welke restrisico’s er nog overblijven.
Van crisis naar structurele bescherming
Het jaar 2018 begon turbulent voor de IT-sector: op 3 januari meldde Intel als eerste CPU-fabrikant beveiligingslekken waar de aanval Meltdown misbruik van maakte. In de dagen daarna volgden de gebeurtenissen elkaar in rap tempo op: naast Meltdown kwam ook Spectre om de hoek kijken en al snel werd duidelijk dat bijna alle toenmalige processors en systemen kwetsbaar waren.
Daarna heerste er wekenlang chaos omdat fabrikanten sommige patches weer terugtrokken, andere updates fouten bevatten en vooral omdat de omvang van de dreiging onduidelijk was.
Hier leggen we de belangrijkste beschermingsmaatregelen (mitigaties) uit tegen CPU-beveiligingslekken van het type Spectre en Meltdown. Dergelijke mitigaties zijn op verschillende niveaus ingebouwd: in de programmacode, in compilers, in besturingssystemen, in de systeemconfiguratie, in speciale firmware voor processors en ten slotte in de CPU-hardware.
Spectre en Meltdown waren een heilzame schok – niet alleen voor CPU-ontwikkelaars zoals AMD, Apple, ARM, IBM, Intel en Qualcomm, maar ook voor leveranciers van besturingssystemen, clouddienstverleners en programmeurs van systeemgerichte code.
Tegenwoordig gaan veel grote bedrijven in de branche professioneler om met beveiligingslekken. Besturingssystemen, browsers en cloudplatforms zijn beter beschermd tegen sidechannel-aanvallen. Zoals uitgelegd in een eerder artikel [1], richten aanvallen van het type Spectre en Meltdown zich op functies die de rekenkracht van processors aanzienlijk verhogen: out-of-order-uitvoering, speculatieve uitvoering, sprongvoorspelling, Simultaneous Multithreading (SMT) en diverse interne buffers, caches en registers.
Het omgekeerde maakt duidelijk dat beveiligingsmaatregelen tegen Spectre en Meltdown de CPU-prestaties flink kunnen verminderen. Sommige patches leidden tot prestatieverlies van meer dan 20 procent. Vaak kwamen er later echter verbeterde maatregelen met minder negatieve invloed op de prestaties.
Remmende factoren
Maar afhankelijk van waar de processors worden gebruikt en het geschatte aanvalsrisico daar, zijn er nog steeds beveiligingsmaatregelen die flink wat prestaties kosten. Zo wordt SMT in bijzonder veiligheidsgevoelige omgevingen uitgeschakeld en gebruiken sommige clouddienstverleners daarvoor processors zonder SMT.
De meeste ARM-serverprocessors en ook Intels efficiëntiekernen (E-Cores) hebben geen SMT. Omdat E-Cores relatief weinig siliciumoppervlak innemen, zet Intel ze in bij Xeon 6-versies met bijzonder veel CPU-kernen: de Xeon 6+ Clearwater Forest heeft tot wel 288 E-Cores.
Dat laat trouwens ook zien hoe groot de cloudsystemen zijn die tegenwoordig in gebruik zijn: watergekoelde serverkasten bieden plaats aan 80 afzonderlijke servers met samen 160 processorsockets. Met 288-core-processors kun je daarin in totaal 46.080 CPU-kernen inzetbaar maken met samen 320 TB RAM, dus 2 TB per CPU of 7 GB per core.
Tussen theorie en praktijk
Het artikel over de CPU-kwetsbaarheden Spectre en Meltdown [1] beschrijft de 35 belangrijkste kwetsbaarheden van het type Spectre en Meltdown die sinds 2018 gepubliceerd zijn. Die enorme hoeveelheid wekt de indruk dat alle processors in wezen onveilig zijn. Maar slechts een klein deel van de ontdekte kwetsbaarheden vormt een daadwerkelijk praktisch risico.
Meltdown was een extreem geval: makkelijk te misbruiken en meteen wereldwijd relevant. Ook Spectre dwong onmiddellijke aanpassingen af, zoals beveiligingsupdates voor browsers omdat daardoor op JavaScript gebaseerde sidechannels mogelijk werden.
Veel recentere Spectre-varianten vergen daarentegen dat een aanvaller al code op het doelsysteem kan uitvoeren, bijvoorbeeld in een virtuele machine, sandbox of als een proces zonder beheerdersrechten.
Aan die voorwaarde wordt in cloudomgevingen vaak voldaan. Het daadwerkelijk misbruiken blijft echter vaak moeilijk, omdat het bovendien geschikte codereeksen, nauwkeurige controle over micro-architecturale toestanden en – bij cross-VM-aanvallen – meestal een plaatsing op dezelfde fysieke server vereist.
Als een aanvaller daarnaast echter eenvoudigere aanvalsroutes tot zijn beschikking heeft, kiest hij waarschijnlijk de weg van de minste weerstand om gegevens te stelen. Daarom zal hij daarvoor waarschijnlijk maar zelden een ingewikkelde en specifieke sidechannel-aanval op de betreffende hardware uitvoeren, maar eerder op zoek gaan naar kwetsbaarheden in de software.
In dat geval zijn klassieke beschermingsmethoden tegen kwaadaardige software, zoals virusscanners, waarschijnlijk effectiever. Toch vormen CPU-kwetsbaarheden een relevant veiligheidsrisico, voor zover ze de isolatie tussen processen, virtuele machines en sandboxes doorbreken.
Sommige sidechannels maken namelijk daadwerkelijk toegang mogelijk tot verboden delen van het werkgeheugen – hoewel dat onder realistische omstandigheden vaak maar met een lage leessnelheid van een paar kilobyte per seconde gaat.
Om het enorme RAM-geheugen van moderne cloudservers volledig te doorzoeken, zou de aanval weken of maandenlang ongestoord moeten kunnen doorgaan.
Sidechannel-aanvallen zijn daarom vooral nuttig voor het stelen van afzonderlijke geheimen, zoals wachtwoorden. En hoewel er gespecialiseerde (software)bewakingssystemen bestaan die dergelijke aanvallen aan de hand van hun kenmerkende toegangspatronen kunnen herkennen, garanderen ze niet dat deze ook daadwerkelijk worden ontdekt.
Gevoelige zones
Vooral cloudservers en sandbox-omgevingen blijven kwetsbaar voor sidechannel-aanvallen. Cloudservers zijn specifiek ontworpen om containers en virtuele machines van verschillende klanten op dezelfde hardware te draaien. Een aanvaller kan daar dus makkelijk een plekje huren.
Sandboxen zijn op hun beurt al een aantrekkelijk doelwit voor aanvallen, juist omdat ze eigenlijk bedoeld zijn om malware in te dammen. Aanvallen zoals RIDL en ZombieLoad maakten het expliciet mogelijk om gevirtualiseerde omgevingen aan te vallen, waarbij een kwaadaardige virtuele machine informatie kan stelen uit een andere virtuele machine. LVI richtte zich daarentegen vooral op enclaves met Software Guard Extensions (SGX) en andere isolatiegrenzen [1].
Programmeurs reageerden daarop met aanpassingen aan systeemdichte code, zoals die van de kernel en de hypervisor: bij het wisselen tussen beveiligingsdomeinen zorgen extra ingevoegde commando’s ervoor dat de betreffende interne CPU-buffers (Cache-Flushes) worden leeggemaakt, en bij sommige aanvallen ook bepaalde caches. Zo blijven er geen bruikbare oude gegevens achter die een kwaadaardige thread zou kunnen buitmaken.
Het uitschakelen van SMT, bij Intel HyperThreading genoemd, maakt dergelijke aanvallen nog moeilijker. Bij SMT delen meerdere threads immers bepaalde functieblokken in de CPU.
Ook het besturingssysteem kan de veiligheid verhogen, bijvoorbeeld door restrictieve CPU-scheduling.
Speculatiebescherming
De speculatieve uitvoering van code (Speculative Execution) versnelt de uitvoering van programma’s doordat de processor vooruitlopend instructies uitvoert die eigenlijk nog niet aan de beurt zouden zijn.
De zogenaamde sprongvoorspelling (Branch Prediction) voorspelt daarbij welk uitvoeringspad het programma waarschijnlijk zal volgen. Daarbij kan het gebeuren dat speculatief uitgevoerde instructies gegevens laden van RAM-adressen waartoe het betreffende programma wel toegang heeft, maar die buiten de beoogde grenzen liggen.
Dat is in theorie geen probleem, omdat een zogeheten Bounds Check dit controleert. Het woord ‘bounds’ staat hier voor de grenzen van bijvoorbeeld een array. Maar omdat de CPU de volgende instructies al uitvoert voordat de uitkomst van de bounds-check vaststaat, kan de speculatie buiten die grens reiken en sporen van gevoelige gegevens in de cache achterlaten.
Die sporen kan malware op zijn beurt via een sidechannel analyseren. Daarom hebben CPU-ontwerpers extra functies in de hardware van nieuwere processors ingebouwd om de speculatie in te perken: Speculation Barriers en besturingsfuncties zoals Indirect Branch Restricted Speculation (IBRS).
Sommige CPU-series hebben dergelijke functies achteraf gekregen via zogeheten microcode-updates. De microcode is een soort CPU-firmware die interne besturingsprocessen aanpast om fouten te corrigeren of in beperkte mate nieuwe functies toe te voegen. Microcode is door middel van cryptografische handtekeningen beveiligd tegen manipulatie.
Die achteraf toegevoegde beveiligingsfuncties zorgen echter vaak voor grotere prestatieverliezen dan wanneer ze direct in de hardware van de CPU zouden zijn ingebouwd. En dat is precies wat de CPU-fabrikanten vervolgens ook deden in latere generaties van hun chips.
De ontwikkeling van een fundamenteel nieuwe processor met miljarden transistoren kan echter meer dan vijf jaar duren, en zelfs een generatiewisseling met kleinere verbeteringen al zo’n twee jaar.
Voor dringende patches worden nog steeds microcode-updates gebruikt. Dergelijke microcode-updates komen meestal op twee manieren op computers met actuele besturingssystemen terecht: zowel via de automatische updatefuncties van de besturingssystemen zoals Windows Update als via firmware-updates, oftewel: een nieuw (UEFI-)BIOS.
Omdat een groot deel van de wereldwijd gebruikte computers maar heel zelden of nooit firmware-updates krijgt, is de route via het besturingssysteem extra belangrijk.
Onder Linux en FreeBSD kun je microcode-updates ook handmatig installeren.
Compilerhardening
Nieuwe CPU-instructies alleen bieden echter geen bescherming tegen aanvallen van het type Spectre en Meltdown. De draaiende software moet ze namelijk ook gebruiken, vooral de hardwaregerelateerde en veiligheidskritische onderdelen van het besturingssysteem, zoals de kernel. Daarom moesten programmeurs van dergelijke software hun code aanpassen en als updates uitbrengen.
Ook sommige apps zijn extra kwetsbaar voor aanvallen, bijvoorbeeld apps die rechtstreeks communiceren met externe servers op internet en ook het uitvoeren van code toestaan – zoals browsers. Daarom moest ook hun broncode worden aangepast.
Voor sommige tegenmaatregelen waren nieuwe compilerversies nodig. AMD, Intel en ARM werkten daarom nauw samen met beveiligingsonderzoekers, kernelprogrammeurs en compilerontwikkelaars om de sidechannels te bestrijden. Daarnaast brachten ze handleidingen voor programmeurs uit met voorbeelden van codepatches.
In kernelcomponenten werden beveiligingsmechanismen ingebouwd om geheugengebieden van elkaar af te schermen (isolation) en de speculatieve uitvoering op veiligheidskritieke punten te beperken (speculation fencing).
Bij compilerbased hardening bouwt de compiler automatisch beveiligingspatronen in de code in. Voorbeelden daarvan zijn Speculative Load Hardening (SLH) tegen Spectre v1, dat speculatief geladen waarden maskeert of ‘ongeldig maakt’, en Retpolines (daarover straks meer) tegen Spectre v2.
Memory Barriers zijn instructies die een vaste volgorde voor loads en stores afdwingen. Hardwarebarrières voorkomen dat de processor geheugentoegangen over bepaalde punten heen herschikt. Compilerbarrières voorkomen dat de compiler dergelijke herschikkingen doorvoert. Ze zijn vooral belangrijk om correcte zichtbaarheids- en geheugenvolgorderegels te garanderen.
Speculation Fencing bouwt barrières in die speculatieve uitvoering op precies gedefinieerde punten stopt of beperkt, zodat gevoelige bewerkingen niet meer speculatief ‘vooruitlopen’ en gegevens via sidechannels prijsgeven. Daaronder vallen bijvoorbeeld LFENCE-instructies op x86 en vergelijkbare primitieven van andere architecturen.
Jump-ontkrachting
Een bijzonder aantrekkelijk doelwit voor Spectre zijn indirecte sprongen in de code, omdat het jumpadres daarbij niet vastligt. In plaats daarvan berekent het programma dat tijdens het uitvoeren dynamisch, afhankelijk van andere variabelen. Het voorspellen van dergelijke sprongdoelen is een achterdeur voor manipulatie.
Een codeconstructie genaamd Retpoline leidt indirecte sprongen zodanig om dat de CPU niet meer kan speculeren op doelen die door de aanvaller beïnvloed zijn. Daarnaast is de nauwkeurigheid van browsertimers beperkt om timing-gebaseerde aanvallen met kwaadaardige JavaScript op gemanipuleerde websites of in advertenties te bemoeilijken.
In de weken en maanden nadat Spectre en Meltdown bekend werden, regende het dan ook updates: BIOS-updates, microcode-updates, updates voor talloze besturingssystemen en browsers. Maar ook voor webservers, databases, opslagservers, firewalls, routers en ontelbare andere systemen.
Verschillen in de aanpak
Meltdown kon relatief doelgericht worden gepatcht, bijvoorbeeld via Kernel Page Table Isolation (KPTI). Maar Spectre bleek een systemisch en hardnekkig probleem te zijn. Tegenmaatregelen zijn omslachtig en pas nieuwe processorarchitecturen kunnen volledige bescherming bieden.
Retbleed en Zenbleed troffen grote groepen gebruikers en vereisten snelle patches. Ook Downfall en afzonderlijke scheduler-aanvallen op AMD-CPU’s leidden tot microcode-updates. Bij Downfall konden die prestatieverlies veroorzaken.
Veel andere recentere kwetsbaarheden werden door de betrokken CPU-fabrikanten als weinig relevant voor de praktijk beschouwd. AMD noemde Inception 2023 bijvoorbeeld slechts potentieel lokaal misbruikbaar, terwijl Intel Downfall als matig ernstig en eveneens lokaal misbruikbaar classificeerde.
Bij sommige varianten helpen bestaande tegenmaatregelen zoals IBRS of Retpolines. Sommige heel specifieke aanvallen zijn alleen onder laboratoriumomstandigheden uitvoerbaar, vereisen complexe opstellingen of leveren maar heel weinig bruikbare gegevens op, zoals op afstand aangestuurde SpectreLeaks met extreem lage bandbreedte, zoals bij NetSpectre.
In sommige gevallen, bijvoorbeeld bij GhostRace, zag het Linux-kernelproject aanvankelijk af van de voorgestelde generieke mitigatie vanwege zorgen over de prestaties.
Aanbieders van cloudservers en geïsoleerde enclaves nemen dergelijke publicaties daarentegen wel serieus en voeren tegenmaatregelen door.
Tegenmaatregelen in de hardware
Intel was al sinds medio 2017 op de hoogte van de kwetsbaarheden en leverde vanaf oktober 2018 CPU’s met hardwarematige tegenmaatregelen tegen Meltdown (variant 3) en delen van Spectre v2.
Modellen zoals de Coffee Lake Refresh (Core i9000) en later Ice Lake U/Y (Core i1000-generatie) zijn via de hardware beschermd tegen Meltdown. Hardware-aanpassingen en het leegmaken van de Level 1-caches zorgen ervoor dat Foreshadow geen gevaar meer vormt. Voor Spectre v2 heeft Intel beschermingsmechanismen ingevoerd, zoals het eerder genoemde IBRS, maar ook Single Thread Indirect Branch Predictors (STIBP) en later het uitgebreide eIBRS.
IBRS en STIBP werden aanvankelijk via microcode achteraf geïnstalleerd. eIBRS zit sinds de Cascade Lake-generatie van de Xeon-processors voor servers standaard in de hardware (XeonSP Gen2, 2019). Nieuwere series zoals Alder Lake (Core i12000), Arrow Lake (Core Ultra 200) en Lunar Lake (Core Ultra 200V) bieden extra bescherming tegen aanvallen. Sommige nieuwere modellen melden bijvoorbeeld BHI_NO en geven daarmee aan dat ze niet kwetsbaar zijn voor Branch History Injection.
Tegen Spectre v1 bestaat er daarentegen nog steeds geen algemene hardware-oplossing. Daar helpen softwarematige maatregelen zoals LFENCE, indexmaskering en Speculative Load Hardening.
AMD-processors hadden geen last van de oorspronkelijke Meltdown-variant omdat hun architectuur speculatieve toegang tot gegevens met hogere bevoegdheden verhinderde. Tegen Spectre v1 raadde AMD softwarematige maatregelen aan, tegen Spectre v2 bracht AMD bovendien microcode-updates uit en raadde onder andere Retpolines aan.
Zen 2 (Ryzen 3000) bracht verdere wijzigingen in de sprongvoorspelling, Zen 3 (Ryzen 5000) was vanaf het begin niet kwetsbaar voor Retbleed. Bepaalde functies, zoals Predictive Store Forwarding (PSF), kun je indien nodig uitschakelen.
Hoe sterk de beveiligingsmaatregelen de prestaties vanaf Zen 4 vertragen, hangt af van de workload en de geactiveerde beveiligingsmaatregelen. AMD reageert bovendien snel op nieuwe ontdekkingen: voor Inception (2023) en Transient Scheduler Attacks (TSA, 2025) kwamen er snel firmware- en deels besturingssysteemupdates. Bij TSA werkte AMD samen met onderzoekers van Microsoft.
Ook ARM reageerde in 2018 snel: voor kernen die al vroeg kwetsbaar waren, zoals de Cortex-A75, werden software- en firmware-mitigaties beschikbaar gesteld. Later volgden gespecialiseerde instructies en statussen – zoals CSDB, SSBB/PSSBB en PSTATE. SSBS. Sommige werden al vóór de herziene architectuurspecificatie Armv8.5 geïntroduceerd, bij Armv9 kwamen er nog meer beschermingsmechanismen bij.
Een algemene automatische scheiding van alle speculatieve statussen tussen beveiligingsdomeinen is echter niet gegarandeerd. Software kan bij contextwisselingen bepaalde toestanden negeren of barrières instellen. Toch hebben verschillende aanvallen van de afgelopen jaren laten zien dat ook ARM-CPU’s kwetsbaar kunnen zijn.
RAM-beveiliging
Om geheugenfouten en manipulatie van de controlflow te bemoeilijken, zijn verschillende technieken ontwikkeld. Hardware ondersteunt veel van die beveiligingsfuncties omdat puur softwarematige oplossingen het systeem meer kunnen vertragen.
Een voorloper van dergelijke methoden is het begin jaren 2000 geïntroduceerde No Execute (NX)-bit, dat geheugenpagina’s markeert waarvan de processor de inhoud niet als code mag uitvoeren. Dat werd destijds geprezen als een mijlpaal in de hardware-gebaseerde bescherming tegen aanvallen.
NX biedt echter geen volledige bescherming omdat aanvallers in de loop van de tijd hebben geleerd om de beveiligingsfunctie te omzeilen. Moderne processors hebben ingebouwde geheugencontrollers, dus sturen ze het werkgeheugen rechtstreeks aan. Sommige beveiligingsfuncties zijn in het geheugenpad ingebouwd, zoals RAM-versleuteling.
Serverprocessors met Confidential Computing-functies kunnen het privégeheugen van elke beveiligde virtuele machine met een eigen sleutel versleutelen. Zelfs een gehackte hypervisor kan het beveiligde RAM van zo’n virtuele machine dus niet in leesbare vorm lezen.
Bij Memory Tagging, bijvoorbeeld met de ARM Memory Tagging Extensions (MTE), voorziet de hardware geheugengebieden en bijbehorende pointers van tags. Zo kun je onder andere bufferoverflows en toegang tot al vrijgegeven geheugen herkennen.
Apple heeft MTE uitgebreid met de Enhanced Memory Tagging Extension en andere hardware- en softwaremaatregelen voor Memory Integrity Enforcement (MIE).
Pointer Authentication Code (PAC) is meer een bescherming tegen softwareaanvallen, met name via Return-Oriented Programming (ROP). PAC kan geselecteerde pointers voorzien van een cryptografische authenticatiecode, die wordt opgeslagen in de ongebruikte bovenste bits van een pointer. Een controle vóór gebruik stelt vast of de pointer gewijzigd is. PAC is gespecificeerd sinds Armv8.3-A.
Een functioneel verwante x86-beveiliging is de Controlflow Enforcement Technology (CET), die onder andere gebruikmaakt van Shadow Stacks en Indirect Branch Tracking.
Lessen uit Spectre en Meltdown
Sinds 2018 is bij CPU-fabrikanten ook de samenwerking tussen bedrijven, hun interne veiligheidscultuur en beveiligingsmechanismen op systeemniveau verbeterd. Dat zijn lessen die zijn geleerd bij de onthulling van Spectre en Meltdown. Destijds verliepen zaken nogal rommelig: er lekte voortijdig informatie uit, wat voor onzekerheid zorgde.
De onthulling van nieuwe kwetsbaarheden zoals ZombieLoad (2019) en Retbleed (2022) werd voorbereid in nauwe samenwerking tussen de teams van CPU-fabrikanten en fabrikanten van grote besturingssystemen – inclusief gecoördineerde publicaties met al voltooide kernelpatches.
Voor veel kwetsbaarheden konden fabrikanten en partners daardoor al tegenmaatregelen treffen voordat ze openbaar werden. Downfall werd in augustus 2022 al aan Intel gemeld – bijna een jaar voor de onthulling. Intel, AMD en ARM hebben hun Product Security Incident Response Teams (PSIRT) verder uitgebreid.
Ook andere bedrijven zetten steeds meer in op formele verificatiemethoden, gerichte red-teaming-processen en samenwerking met externe beveiligingsonderzoekers. Ontwikkelaars controleren nieuwe optimalisaties om te zien of ze speculatieve lekken veroorzaken. Nieuwe CPU-generaties krijgen hardwarematige beveiligingsmaatregelen tegen bekende soorten aanvallen.
Ook software en systeemarchitecturen zijn sinds 2018 veranderd. Browsers zoals Chrome gebruiken Site Isolation om JavaScript-pagina’s van elkaar te scheiden. Cloudproviders passen extra isolatiemaatregelen toe, schakelen SMT uit of verplaatsen veiligheidsgevoelige functies naar gespecialiseerde hardwaremodules zoals de Nitro-kaarten van AWS. De bevoorrechte besturingsfuncties daarvan zijn niet direct bereikbaar voor aanvalscode in een cloudinstantie.
Door hardware beschermde Trusted Execution Environments (TEE’s) isoleren code en gegevens. Hun status kan met cryptografische methoden aangetoond worden. Veel hardwarematige maatregelen draaien onzichtbaar op de achtergrond voor de applicatiesoftware, maar verhogen het beveiligingsniveau aanzienlijk.
Spectre en Meltdown leidden tot een golf van wetenschappelijke publicaties – met deels praktische, deels visionaire voorstellen zoals Secure Speculative Execution, Cache Partitioning en hardwarematige randomisatie. Sommige van die ideeën zijn al verwerkt in de huidige CPU-ontwerpen.
Intel publiceerde in 2022 een verfijnde terminologie en classificatie van tijdelijke uitvoeringsaanvallen. De sensationele namen van sommige beveiligingslekken, zoals ZombieLoad, Downfall en Hertzbleed, droegen wel bij aan de brede media-aandacht, maar leidden ook tot vermoeidheid binnen de IT-beveiligingsgemeenschap.
Fabrikanten doen tegenwoordig vaker hun best om risico’s objectief in te schatten in plaats van ze te dramatiseren. De communicatie rond Downfall is daar een goed voorbeeld van: talrijke processorgeneraties waren getroffen, maar de aanval vereiste lokale toegang tot de code. Intel stelde microcode-updates beschikbaar. De sector heeft zijn processen voor gecoördineerde openbaarmakingen en tegenmaatregelen dan ook geprofessionaliseerd.
Minder drama, meer inhoud
Acht jaar na Spectre en Meltdown blijkt dat de industrie veel juiste lessen geleerd heeft. Openbaarmakingsprocessen zijn volwassen geworden, beveiligingsfuncties zijn in chips ingebouwd, systeemgrenzen zijn versterkt.
Transient execution bij processors brengt nog steeds risico’s met zich mee, maar de aanpak ervan is tegenwoordig gestructureerder, preciezer en gericht op schadebeperking in plaats van paniek.
Hardware-sidechannels zijn een beheersbaar onderdeel geworden van het dagelijkse IT-leven.
David Knichel en Noud van Kruysbergen
Literatuur
[1] David Knichel en Noud van Kruysbergen, CPU-kwetsbaarheden Spectre en Meltdown: acht jaar lang onder vuur, c’t 10/2026, p.128
Praat mee