Meltdown, Spectre en Linux

De kernelontwikkelaars hebben weken onder hoge druk gewerkt aan maatregelen tegen Meltdown. Die waren dan ook op tijd beschikbaar en goed gedocumenteerd. Het immuniseren tegen Spectre duurde echter langer. Een reden daarvoor was dat er gekozen kan worden

Zorgen alle aangeboden besturingssysteemupdates die de afgelopen weken en komende weken nog aangeboden worden ervoor dat alles weer goed is? Ja, voor Linux-pc's die gebruikt worden voor kantoorwerk en internetten zal dat naar de huidige stand van kennis voldoende zijn. Als je veeleisender taken doet of een Linux-server exploiteert, moet je echter even opletten: ter bescherming tegen Meltdown en Spectre (zie pagina 100) is er een hele trits aan maatregelen, waar bovendien nog flink aan gewerkt wordt. Geen wonder dus dat op het moment van schrijven eigenlijk nog geen enkele distributie helemaal veilig was. Aan de andere kant krijg je bij Linux inzichten in de tegenmaatregelen waar de Windows-wereld alleen maar van kan dromen. Bovendien kunnen Linuxers afzonderlijke beveiligingstechnieken die de systemen langzamer maken makkelijk uitschakelen

Isoleren tegen Meltdown

Nieuwe Linux-kernels beschermen tegen Meltdown met Page Table Isolation (PTI, soms ook Kernel PTI of KPTI genoemd). Die zelf ontwikkelde methoden lijken op de tegenmaatregelen tegen Meltdown van Windows: in de adresruimte van een proces is niet meer het hele kernelgeheugen ingebed, maar alleen een heel klein deel daarvan dat onmisbaar is voor interactie tussen het programma en de kernel (zie pagina 104).

Door PTI stijgt de overhead echter duidelijk als programma's een kernelfunctie aanroepen. De kernel moet zijn geheugen dan eerst weer inbedden omdat dit door het verstoppertje spelen uit de cache gevlogen is. Bezitters van AMDprocessors hoeven echter niet bang te zijn voor snelheidsverlies: Linux-kernels activeren PTI bij Athlon en Ryzen en dergelijke helemaal niet omdat die niet zijn getroffen door Meltdown.

Hoe sterk het performanceverlies bij Intel-cpu's uitvalt, ligt eraan van welke generatie die zijn. Bij processors met een Haswell-binnenwerk, dat bijvoorbeeld in de sinds medio 2013 verkochte Core i4000-processors zit, is het verlies minder dan bij oudere. De reden: bij Haswell en zijn opvolgers kan Linux de overhead van PTI reduceren met behulp van ProcessContext Identifiers (PCID). Oudere processors hebben die techniek niet of alleen op zo'n manier dat dit bij gebruik geen voordelen biedt.

Hoe sterk PCID het verlies kan beperken, hangt af van de PCID-ondersteuning en PTI-implementatie van de kernel. Linux 4.14.11, 4.15-rc6 en nieuwer halen daar het meeste uit omdat die PCID uitgebreid ondersteunen en een daarop afgestemde PTI-implementatie hebben. Linux 3.16.53, 4.4.110 en 4.9.75 combineren daarentegen een oudere PTI met een rudimentaire PCID-ondersteuning. Varianten daarvan zitten geïntegreerd in de kernel van de meeste distributies, voor zover die sowieso al niet 4.14 gebruiken. Een uitzondering is de 4.13-kernel van Ubuntu 17.10, die de moderne oplossing van 4.14.11 gebruikt.

Beide PTI-implementaties stammen af van KAISER (Kernel Address Isolation to have Side-channels Efficiently Removed). Die patchverzameling is afgelopen herfst al uitgebracht door de onderzoekers van de Technische Universiteit in Graz, die de mede-ontdekkers waren van Meltdown. Maar de code van de nieuwe PTI heeft daar nog maar weinig overeenkomsten mee. Tot nu toe is PTI er alleen voor 64bit x86- en ARM-Linux. Ondersteuning voor 32-bit Linux ontbreekt op dit moment nog. De ontwikkelaars hebben daar tijdens het dichten van al die gaten nog geen tijd voor gehad.

De PTI bevattende Linux 4.14.11 was bij het bekend worden van Meltdown al beschikbaar. Red Hat en Suse stelden op dat moment ook kernels met PTI voor hun zakelijke distributies beschikbaar. Veel van de andere mainstream distributies volgden pas de daarop volgende dagen. Ubuntu nam zelfs een week de tijd en daarna was alsnog een patch nodig: de eerste updatekernel voor Ubuntu 16.04 startte op een groot aantal systemen niet op.

Spectre-lappendeken

De voor Red Hat Enterprise Linux (RHEL) en Suse Enterprise Linux (SLE) vrijgegeven updates bevatten ook meteen een aantal maatregelen tegen Spectre. Van daaruit kwamen ze ook snel bij derivaten als CentOS en OpenSuse Leap terecht. De meeste andere distributies inclusief Debian en Ubuntu kwamen echter niet zo snel op gang met hun tegenmaatregelen.

Ze stelden vaak wel snel de nieuwe versie van Firefox 57 beschikbaar, die het benutten van de eerste Spectre-variant via JavaScript bemoeilijkt. Sommige leverden ook nieuwe microcode als update, waarmee processors zich konden beschermen tegen Spectre – maar zonder tegenpool aan kernelkant werkt dat niet. En dat was het bij de meeste distributies wat betreft maatregelen tegen Spectre. Pas twee weken na het bekend worden van de twee lekken, begon men met het integreren van de belangrijkste Spectrebeveiligingstechnieken.

Voor het efficiënt afdichten van de eerste Spectre-variant is onder meer een Spectre 1-beveiligingsuitbreiding voor compilers nodig, waarmee de kernel en alle software die mogelijk gevoelig is voor Spectre opnieuw gecompileerd moet worden. De ontwikkelaars proberen tegelijkertijd delen van de code in de kernel te elimineren die vatbaar zijn voor de lekken. Daarvoor moeten ze de hele kernelcode doorzoeken naar kritische plekken en er in de toekomst op letten dat er geen nieuwe aanvalsmogelijkheden ingebouwd worden. Bovendien wer-