Cirka 70 procent av alla sårbarheter i datorsystem beror på problem med minneshantering. En siffra som inte nämnvärt krympt, trots att det lagts mycket tid och arbete på att motverka dessa problem. 

Artikeln är tidigare publicerad i magasinet Elektroniktidningen. Prenumerera kostnadsfritt!

Kodningsregler, granskningar, verktyg för kodanalys, stresstestning med indata (fuzzing) är några sätt. Men ingen metod har löst det grundläggande problemet. 

I C och C++ är en pekare ett heltal som råkar innehålla en adress. Vad den pekar på – och hur resurser den pekar på allokeras och används – kontrolleras inte av språket. Typiska exempel på sårbarheter är att skrivningar sker utanför en allokerad minnes­buffert, och därmed skriver över minne som används till andra saker – exempelvis instruktioner som cpu:n ska exekvera.

Det går att byta till programspråk som Go eller Rust, som har denna typ av kontroll. Samtidigt finns enorma mängder program och system skrivna i C och C++. Att skriva om all kod går helt enkelt inte. 

En lösning måste gå att applicera på befintliga ­kodbaser med noll eller minimal förändring, och måste kunna ­fungera i befintliga system utan att driva kostnad eller försämra prestanda. Inte minst är detta viktigt för inbyggda system med långa livslängder och hårda krav på minimerade resurser och kostnader.

Det går att begränsa skadorna genom att isolera program och system från varandra, exempel­vis genom virtualisering. Det går även att begränsa vilka systemresurser ett program får använda. Ett bra exempel på detta är ’pledge()’ i operativsystemet OpenBSD, där programkoden deklarerar vilka resurser programmet avser att använda. Operativsystemet kan då stoppa access till andra resurser. 

Men dessa metoder löser inte det grundläggande problemet.

2023 uppmanade USA:s cyber­säkerhetsmyndighet Cisa till användning av något som kallas Cheri (Capability Hardware Enhanced Risc Instructions), alltså något som utökar en processors instruktioner med ’kapabilitet’ – men vad är en kapabilitet och varför skulle det vara lösningen?

Hur fungerar Cheri egentligen?

Cheri är från början ett forsk­nings­projekt på Cambridge University. Arbetet har pågått sedan 2014 och börjar nu finnas i produkter. 

Kärnidén i Cheri är att med nya cpu-instruktioner göra det möjligt att från applikationsnivå definiera vad som är en pekare. 

För en Cheri-pekare finns sidoinformation som definierar hur den får användas och inom vilket minnesområde den får användas. Cpu:n ansvarar för att se till att dessa regler efterföljs.

Cheri-pekarna implementeras genom att cpu:ns instruktionsregister kompletteras med ett antal fält.

• Om värdet i registret är en Cheri-pekare eller ej
• Vilka rättigheter pekaren har
• Om pekaren ändrats eller ej
• Vilket minnesområde pekaren får adressera

Utrymmesmässigt innebär fälten att ett register dubbleras i storlek. En 64-bitarspekare växer enligt Cheri-specifikationen till 129 bitar.

Kapabiliteten är vilken typ av operation pekaren får ­användas till, exempelvis läsa, skriva, anropa en extern resurs, och om pekaren får kopieras eller ändras. 

Rättigheterna sätts när pekaren deklareras i källkoden och följer med när en pekare kopieras. Rättigheterna kan ändras – men i så fall bara reducera vad pekaren får användas till – exempelvis från att både få skriva och läsa till att bara få läsa.

Det Cheri åstadkommer är att finkornigt göra det möjligt att veta vad som är en pekare, och sedan med stöd i cpu:n övervaka hur den används och detektera försök att använda pekaren på ett inte godkänt sätt. Och då vidta lämpliga åtgärder. 

Detta gör det möjligt att förhindra många typer av minnes­relaterade problem precis när dom är på väg att uppstå . Cheri ger därmed ett skydd liknande det som språk med kontroll av minnesanvändning ger, men utan att du behöver skriva om applikationen.

Som vi ser är Cheri inte transparent. Programmeraren måste i sin kod deklarera vad som är en Cheri-pekare och vad den ska användas till. Kompilatorn måste kunna generera Cheri-instruktioner.

Vidare måste operativsystemet inte bara kunna hantera signaler från cpu:n när en pekare används på fel sätt. Operativsystemet självt behöver väsentligen också skrivas om för att använda Cheri, eftersom det är i operativsystemet effekten av minnesrelaterade svagheter får störst effekt.

För att stödja Cheri behöver cpu:n utrustas med Cheri-instruktioner, få större register så sidoinformationen får plats, samt funktionalitet som krävs för att använda Cheri-pekarens sidoinformation och utföra den kontroll som krävs. Det innebär även att beteendet hos vissa befintliga instruktioner påverkas. Hoppinstruktioner måste exempelvis ta hänsyn till Cheri-tillståndet för att avgöra hur ett hopp ska exekveras.

I enklare cpu:er typiska i inbyggda system, som inte kan exekvera mer än en instruktion i taget och inte implementerar hoppspekulering, blir påverkan på processorn mindre. Samtidigt är detta ett område där kostnadspressen är hård.

I högpresterande ­processorer – som kan exekvera flera instruktioner samtidigt, som hämtar in ett stort antal instruktioner förväg och som använder hopp­spekulering – finns internt hundratals register. Här slår Cheri-funktionaliteten hårt mot komplexiteten, strömförbrukningen och potentiellt prestandan hos cpu:n.

Samtidigt är kostnaden för programmeraren att använda Cheri relativt begränsad. Det ändrar inte själva beteendet i koden. Det är mycket mindre jobb att göra än att skriva om hela applikationen i ett nytt språk. 

Däremot måste programmeraren tänka till hur en pekare ska komma att användas redan när den deklareras. Om pekaren inte får rätt begränsningar i hur den får användas, eller inga alls, ger Cheri inte mycket högre säkerhet.

När kommer Cheri att finnas på marknaden?

För forskarna från Cambridge är RISC-V idag den primära arkitekturen de utvecklar stöd för. Det finns flera mjuka RISC-V-processorer med stöd för Cheri. Företaget Codasip erbjuder exempelvis flera RISC-V-kärnor för integration i FPGA:er och ASIC:ar. Dessa cores är i första hand avsedda för embedded­applikationer med låga till medelhöga prestandakrav. Kompilatorn Clang kan generera Cheri-instruktioner för RISC-V. Det finns även operativsystem som stödjer Cheri, exempelvis CheriBSD. Men inget av dom stora operativsystemen stödjer Cheri.

Ett område där Cheri verkar kunna få fotfäste är fordons­industrin. Projektet AutoCheri arbetar med att visa hur Cheri kan lösa många av de säkerhets­problem och krav som i dag ställs inom fordonsindustrin. Codasips kärnor riktas reklammässigt mot fordonsindustrin som produktområde.

2019 startade ARM projektet Morello. Syftet med projektet är att utvärdera Cheri i typiska embedded-miljöer. Morello tittar på svårigheten att portera kod, hur effektivt stödja Cheri i typiska operativsystem, samt utvärdera kostnaden för att stödja Cheri i processorer. 2022 släppte ARM ett Morello-cpu-utvecklingskort för denna cpu. Morello har två cpu-cores baserade på Neoverse N1 utökade med Cheri-instruktioner. Morello-chipen är bara till för utvärdering och kommer inte säljas som en produkt.

Inom Morello-projektet arbetar ARM tillsammans med partners med att implementera stöd för Cheri i Linux. Dock är det i skrivande stund långt kvar till att Linux med Cheri är färdigt för användning.

Alternativa lösningar

ARM arbetar i Morello-projektet med att utvärdera Cheri. Men ARM har också en egen lösning: MTE (Memory Tagging Extension). MTE lånar grundidén från Cheri att med sidoinformation göra det möjligt att kontrollera hur minnesresurser får ­användas. Men i MTE är det minnet, inte pekarna som kontrolleras. Kontrollfältet i MTE är fyra bitar, och metoden för hur fel ska hanteras i operativsystemet gör att MTE ger mycket lägre påverkan på cpu:er, system och applikationer.

ARM släppte versioner av ARMv8-A-processorer med stöd för MTE 2019. Samma år kom stöd i Android för MTE. MTE finns alltså redan ute på marknaden. Tidigare i år presenterades en attack på MTE och längden på kontrollfältet visade sig vara en svaghet. Men MTE används redan så vi kan förvänta oss att MTE utvecklas av ARM.

Expertens kommentar

Björn Töpel är en av Sveriges mest erfarna kernel-utvecklare med bakgrund från bland annat Intel. Han arbetar bland annat med utveckling av Linuxkärnan för att stödja högpresterande RISC-V-processorer. Hur ser Björn på Cheri?

– Cheri Introducerar ett nytt ABI som kräver mycket jobb att stödja. Linux har visat sig svårt att porta. Pekare i Linux är typiskt av typen ‘long’, vilket inte stämmer med Cheri. Det blir inte ’bygg om koden’, utan ’porta till en helt ny arkitektur’. Det var mycket diskussioner om ARMs Morello. Men intresset hade varit större om det fanns mer Cheri-hårdvara med liknande prestanda som existerande arkitekturer.

Slutsatser

Cheri har potential att eliminera flera typer av minnesrelaterade säkerhetsproblem, men långt ifrån alla. Cheri kräver viss modifiering av ett programs källkod för att använda Cheri-pekare. Men sedan måste även verktyg, operativsystem och processorn stödja Cheri på olika sätt. 

Detta är stora förändringar, som dessutom måste koordineras mellan olika parter och intressenter för att ge någon effekt. Detta gör att Cheri troligen inte kommer att vara en generell lösning. Men för säkerhetskritiska applikationer och nischer som automotive kan Cheri vara sättet att hantera säkerhetskrav.

Cheri visar vägen – hur hård­vara och programvara kan samarbeta för att faktiskt börja reducera mängden minnes­relaterade sårbarheter, men för generella system stavas implementationen nog MTE.