Den snabbt växande mängden fordonsmjukvara och uppkoppling till Internet och andra källor gör att fordonssystem kan utsättas för obehörigt tillträde och attacker. Att göra dessa komplexa och nödvändiga system säkra är en hjärtefråga för tillverkarna och användarna.

Jay Thomas och Chris Tapp från LDRA tittar här på hur MISRA C kan öka säkerheten.

Programvaran har erövrat fordonsindustrin. Idag styrs fordon bokstavligen av miljontals uppförandekoder som innefattar motorkontroll, bromsar, styrning, stabilisering, händelseinformation, inre temperatur, underhållningssystem och mer. Dessa delsystem har olika nivåer av fara; bromsningen är till exempel viktigare än luftkonditioneringen men alla kommunicerar över interna kanaler.

I de flesta fall, innehåller fordonssystemen kapacitet för externa kommunikationer som är nödvändiga för uppdateringar och diagnoser, men som öppnar för oavsiktliga virus eller obehörigt tillträde. Utöver detta går utvecklingen inte bara mot ett uppkopplat fordon utan möjligen mot ett självkörande fordon. Därför är pålitlighet och säkerhet av högsta vikt. Det nu välkända fallet av ett elektroniskt fel i bränsletillförsel som orsakade död, pga en felaktig källkod förenas med det faktum att hackare och sabotageprogram nu kan få tillgång till fordon som inte har anpassad säkerhet.

Funktionell säkerhet för bilar har reglerats i normer som ISO 26262, som åberopar nödvändigheten av säkerhet och pålitlighet och som kräver användandet av kodningsstandarder för genomförandet. En av dessa standarder som utvecklats för fordonsindustrin är MISRA, som är en undergrupp i C -språket för att utveckla applikationer med hög integritet och höga pålitlighetskrav som kallas MISRA C. MISRA-riktlinjer är utformade för att underlätta kodningssäkerhet, säkerhet, överföring och pålitlighet inom kontexten av inbyggda system. Eftersom C är det förvalda språket för så många inbyggda applikationer, har det kommit förbättringar för fler och bättre urval för kraven för de inbyggda servicesystemen, vilket resulterar i att MISRA är standard i ett stort antal industrier. MISRA C:2012 har nyligen fått förtroendet att ge en ökad säkerhet för bilar och de inbyggda systemen generellt sett. Denna ökade önskan om säkerhet kommer i rättan tid för fordonsindustrin.

Utökade riktlinjer
Efter att MISRA C:2012 släpptes på marknaden, publicerade kommittén som är ansvarig för C-standarden riktlinjer för säkerhet; ISO/IEC 17961:2013. MISRA-kommittén släppte även MISRA C:2012 Ändring 1, som är designad för att stödja dessa nya säkerhetskrav. Ändringen är utformad enligt och helt och hållet kompatibel med alla existerande versioner av MISRA språkets riktlinjer och blir standardmodellen för alla kommande utgåvor av MISRA-riktlinjer.

MISRA C:2012 Ändring 1 etablerar speciellt 14 nya riktlinjer för säker C-kodning för att öka den heltäckande säkerheten som nämns i ISO C riktlinjer för säkerhet. Många av dessa riktlinjer nämner speciellt användande som gäller ”ändrad” data – en välkänd säkerhetsrisk. Ändringen innefattar både breda direktiv och specifika regler. Genom att följa dessa tillagda riktlinjer, kan utvecklarna analysera sina koder mer ingående och kan ge förtroende inför regleringsmyndigheterna att de följt en säker kodningspraxis.

Här följer två exempel på regler:

2. Regel 12.5
Sizeof-aktören får inte ha en operand som är en parameter deklarerad som ”array of type”
Bufferöverflöde är en ingång för att implantera skadliga koder utanför ett dataområde. Utrymmet för dataområdet bestäms av sizeof-aktören, så om sizeof används inkorrekt eller på ett ogiltigt sätt, kan det återge ett felaktigt värde av dataområdet och öppna dörren för ett kodområde. Den här regeln säkrar så att området för data och koder är korrekt begränsade för att undvika dessa misstag som kan leda till att data läcker ut.

Det var just ett sådant misstag som ledde till misslyckandet att kontrollera längden av en specifik datamängd och tillät hackare att få tillgång till ”hjärtat” i SSL-flödet som huvudsakligen reglerar kryptering och normalt datautbyte. Hackarna tog fördel av denna kontrollmiss för att få tillgång till en stor del av minnet. Genom att göra detta repetitivt, kunde de få tillgång till i princip all data på servern som okrypterad text och analysera den för att få tillgång till data från miljontals kunder.

1. Dir 4.14
Giltigheten av värden från externa källor skall kontrolleras
Eftersom fler och fler enheter är kopplade till varandra eller till Internet, har det blivit av största vikt att kontrollera data som kan utsättas för externa källor. Om längden på ett meddelande som kommer från en extern källa inte valideras, kan en inkräktare få tillgång till hela innehållet i en dators minne via distans. I praktiken har olika typer av den här sortens attack används för att få ut ej krypterade lösenord från nätverksserverns hela minnesbuffert. Den här regeln skyddar mot ”läckage från källan” – som sårbara punkter, från vilka hackare kan hämta ut data, inklusive lösenord, i okrypterad text via Internet genom att försiktigt hantera tillgängliga meddelanden.

Det framgår tydligt att bortseendet från någon av dessa riktlinjer kan orsaka seriös skada i bilens system. MISRA:s riktlinjer kan kontrolleras under statisk källkodsanalys.

Lägga grunden för säkerhet
C är ett komplext språk och det är enkelt att göra små misstag i programkodningen även om den kan dölja sårbarheter som inte kommer synas under en tid. Riktlinjerna för pålitlighet och säkerhet som reglerar sådana situationer är även dem detaljerade och komplexa. En mänsklig programmerare, hur erfaren hen än är, kan inte beräknas skapa en helt felfri kod och följa standard riktlinjerna för pålitlighet och säkerhet till exakthet. Utöver detta ökar nivåerna för fordonssäkerhet mer och mer, vilket kräver dokumentation och bevis. Automatiska verktyg blir därför en nödvändighet.

Uppsättningen av LDRA-verktyg kan utföra kodkompatibilitet med MISRA och ISO 26262 samt med andra kodningsstandarder genom användandet av statisk analys av källkodningen. Den här analysen kan även innefatta vilka regler som utvecklaren eller organisationen önskar specificera.

Förutom detta så är det ju också nödvändigt att utföra tester som är baserade på statisk analys, dynamisk täckande analyser och enhetstestning. Testverktygen är utformade enligt idén om att behöva säkerställa både funktionell pålitlighet och säkerhet, i förenlighet med de nämnda standarderna, och möjligheten att spåra de listade utförandena i användarkravdokumenten ner till kodningen och kontrollera aktiviteter och att sammankoppla till de individuella kraven (fig 1).

Fig 1. De tre grundblocken för statisk analys, dynamisk analys och enhetstestning och integrering har pålitlighet och säkerhet som målsättning, förenlighet enligt standard och krav på spårbarhet för att erbjuda ett helt godkänt och certifierat datasystem.

Den funktionella testningen innebär testning för det korrekta och säkra operativsystemet i kodningen, som utförs med dynamiska analyser av den sammanställda koden. Det är också nödvändigt att säkerställa att koden är helt kontrollerad och att inga ”döda” områden har missats. Pga detta går statisk och dynamisk analys ofta hand i hand, eftersom de två huvudområdena är säkerhet av data och kontroll. Frågor: ”Vem har tillgång till vilken data? Vem kan läsa från den och vem kan skriva i den? Vad är dataflödet och från vilka enheter och hur kontrolleras tillgängligheten?” Här kan ”Vem” refereras till personer som utvecklare eller operatörer – och hackare – och det kan också refereras till mjukvarans komponenter antingen inom applikationen eller någonstans inom nätverksstrukturen.

Så utöver att scanna källkoden för förenlighet med MISRA och andra riktlinjer, kräver säkerheten en sträng och genomgående testning för sårbara punkter och för efterföljande av kodningsreglerna och till riktlinjerna i källkoden. Fastställandet beror på den automatiska testningen. Bedrivandet av den automatiska testningen baseras på statisk analys av koden, dvs. innan sammanställning. Informationen som hämtas från statisk analys hjälper den automatiska testgeneratorn att skapa det korrekta stimuli till programvarans komponenter i applikationen.  Utöver detta kan funktionella tester skapas manuellt genom användandet av användarkravdokumentet. Dessa skall inkludera alla funktionella säkerhetstest som t ex det korrekta utförandet av ABS-bromsning.

Utöver att analysera de rena programfunktionerna, så hjälper statisk analys även den dynamiska analysens upprättande för heltäckande testning, funktionell testning, kontroll och dataflödesanalys genom att tillhandahålla rätt stimulansåtgärder för den automatiska testgeneratorn. Den senare är nödvändig för att upptäcka och korrigera potentiella problemområden och producera kvalificerade mjukvaruprodukter. Företag som har som mål att uppfylla de strikta fordonsstandarderna kan komma att behöva uppvisa analyser av dataflöde och kontrollflöde för att kopplas till mjukvarucertifieringen. LDRA-verktygen ger tillgång till detta med grafisk dataflödesanalysrapporter och flödesgrafer (fig2).

Fig 2. Rapporter om varierande parameteranvändning baseras på den nuvarande testningen. Rapporten pekar ut filen och platsen inom filen där variabeln använts, med vanliga filter som tillåter en mer ingående testning (klicka för större bild)

Ta bort sårbara punkter
Statiska och dynamiska analyser kan också upptäcka områden med ”död kod”, som kan vara en källa till fara eller bara ta plats på ett olämpligt sätt. Det är nödvändigt att identifiera sådana typer av koder på ett korrekt sätt och ta itu med problemet – vanligtvis genom att radera dem. Detta är viktigt av många anledningar. För det första av den anledning att de flesta program, även om säkerheten ska integreras från ”uppstarten”, redan har existerande kod som kanske inte har genomgått en så noggrann testning som det nuvarande projektet. Dessa kan innehålla delar som helt enkelt inte behövs av applikationen som utvecklas. Av mer illavarslande karaktär kan ”död” kod ligga i väntan för att aktiveras av en hacker eller någon gömd händelse i systemet för att används i skadligt syfte.

Man måste förstås skilja på ”riktig” död kod och sällan använd kod. Det här är en av de goda anledningarna till vikten av att ha två spårningssätt – för att kunna kontrollera att koden i applikationen uppfyller utförandena, men även att kunna spåra tillbaka koden till utförandena från den nuvarande koden. Om ingen av dessa påvisar en koppling, så hör koden definitivt inte hemma där (fig 3).

Fig 3. Det är viktigt att säkerställa att varje Högnivåutförande täcks av en eller flera Lågnivåutförande och att varje Lågnivåutförande kan spåras tillbaka till Högnivåutförande för att säkerställa en spårning åt två håll.  Utvecklarna måste kunna spåra varje utförande ner till källkoden som genomför det utförandet och på samma sätt kunna spåra från källkoden tillbaka till utförandet (klicka för större bild)

Det är av största vikt att ta hänsyn till att inom fordonsindustrin kommer en stor del av mjukvaran som integreras i det färdiga fordonet från tredje parter, som levererar delar och delsystem som bidrar till den generella designen. Det måste finnas ett sätt att testa och godkänna koder från tredje parter enligt exakt samma standarder för att säkerställa säkerheten. Detta är anledningen till vikten av enhetstestning och integrering.

Enhetstestning och integration
Vad gäller fordonsindustrin, så innebär integrering av delsystem från tredje parter ofta modifieringar i den existerande koden för att göra t ex variabler och adresser kompatibla. När en sådan kod väl är testad och certifierad, kan den behandlas som ett integrerat delsystem i bilens mjukvarusystem.

Pga de tidigare nämnda egenskaperna i kodningsvolym, processorstyrka och uppkoppling – främst med tanke på Internet – görs en stor del av mjukvaruutvecklingen i värdsystem med arbetsstationer med olika projektmedlemmar som jobbar på olika delar i den heltäckande applikationen. Det mesta av detta startas långt innan programvaran är tillgänglig. Utvecklingen kan starta på OS-värdmiljön eller på ett mål som är simulerat på värdsystemet, och slutligen på den aktuella målhårdvaran.

LDRA-verktygen ger medlen att genomföra funktionell testning, och även statisk analys på enhets- och integrationsnivå i värdsystemen och i målhårdvaran när den blir tillgänglig. Utvecklare kan utföra testkörning (nyttjandetester, virustester, kodstubbar) och resultatinriktad support för en rad värde- och målplattformer. LDRA:s instrumenteringsteknologi har kapacitet för att dra ut testinformation även från begränsade 8- och 16 bitars mikrokretsar, och genom högprestanda processorer på 32- och 64 bitar. På så sätt kan hela processen, från utvecklarstationen till målet och de integrerade komponenterna framtagna av olika teammedlemmar samlas i ett större konfigurationssystem med den största delen av utförandena, testutförande, övergripande analys, kontroll av data och kontrollflöde som redan pågår.

För att systemen ska vara pålitliga måste de även vara säkra. För detta krävs att de inte endast är kodade med språkregler utan också följer standarder som säkerställer pålitlighet och säkerhet. Och allt detta måste kunna kontrolleras, vilket innebär att kunna spåra dataflöde och kontroll från utföranden till koder och tillbaka igen. Kontroll av förenlighet med MISRA eller CERT C samt med andra kodningsstandarder kan göras med en regelkontroll som förstärker förenlighet och ger en klar översikt av mjukvarubrister som kanske förbipasserar den färdiga och testade processen och blir latenta problem (fig 4).

Fig 4: LDRA-regler ger dig en insikt i specifika brott mot kodningsstandarder för att se en filtrerad sammanställningsrapport och flödesgrafer för mer klarhet (klicka för större bild)

LDRA-verktygen integrerar nästa generations rapporteringskapaciteter för att visa kodkvalitet, felsökning och metoder för att undvika och erbjuder dessa kompletta egenskaper genom tydliga skärmbilder som klargör komplexiteten och ger trygghet för ett heltäckande och säkert utvecklingsförfarande.
Jay Thomas och Chris Tapp, LDRA

Filed under: Fordonselektronik