Elektronikinnehållet i en modern bil är förbluffande stort och mängden programvara kan lätt uppgå till 100 miljoner rader. I och med det ökar också säkerhetskraven och inte minst kraven på att de mindre kritiska systemen skall vara separerade från de kritiska. David Kleidermacher, teknisk chef hos Green Hills Software    diskuterar här problemen tillsammans med Matt Jones, chef för GENIVI Alliance.

 Ett av de första datorsystemen i en bil var 1978 Cadillac Sevilles färddator som kördes på en Motorola 6805 med 128 byte RAM och två kilobyte ROM. Källkoden kunde inte ha varit på mer än ett par sidor.
Som kontrast har även den enklaste bil idag åtminstone ett dussintal MCU-kretsar och prestandabilar har fler än 100 MCU-kretsar. Exempel på datorer i en modern bil visas I fig 1. Med infotainmentsystem som kör sofistikerade operativsystem som Microsoft Windows eller olika distributioner av Linux kan det totala antalet inbäddade system lätt innehålla 100 miljoner rader kod.
Komplexiteten drivs fram av hårda krav på bättre möjligheter, digitalisering av manuella och mekaniska funktioner och uppkoppling till världen runt omkring. Denna ökning av elektroniskt innehåll har varit till nytta för samhället, men är också ökningen en källa till bekymmer för tillförlitlighet, säkerhet, kostnad och time-to-market. Nästa generations arkitektur för infotainmentsystem måste hjälpa utvecklare att hantera denna komplexitet.

Konsolidering av fordonselektronik
En annan viktig trend i fordon är ECU-konsolidering. Eftersom fordon går mot sin omvandling till ett elektroniskt system av system har mängden elektronikkomponenter och tillhörande ledningsdragning i ett fordon ökat dramatiskt. Denna ökning av elektronik medför en signifikant produktionskostnads-, storleks- och time-to-market-utmaning för fordonstillverkare. Reaktionen är att vända på utvecklingen och i stället föra samman disparata funktioner till färre elektronikkomponenter.

Fig 1 – Inbäddade datorer i modern bil

Processorkonsolidering ligger nära trenden mot blandade kritiska system där säkerhets- eller realtidskritiska komponenter måste samexistera med mindre kritiska komponenter. Exempelvis konsolidering av infotainmentmonitorer med säkerhetskritiska realtidsbackkameror och/eller förarinformationskomponenter resulterar i blandade kritiska system av den typ som visas i fig 2.
Nästa generations systemarkitektur för infotainment måste garantera att konsoliderade komponenter inte påverkar varandra på oförutsett sätt och utgöra en tillförlitlighetsrisk för kritiska system.

Säkerhet i fordonselektronik
Forskare från två universitet som 2010 undersökte säkerheten i moderna fordon stängde av ett fordons motor och bromsar under gång genom att hacka sig igenom en diagnostikport på kortet. Detta är ett enkelt exempel på hur säkerheten i fordon står inför överväldigande utmaningar, med äldre komponenter som inte konstruerats för säkerhet och en leveranskedja som man nog kan påstå har nått sina skalningsgränser.
2010 införde dessutom biltillverkare i USA en funktion som gör att bilägaren kan manipulera låsen och starta motorn var helst på jorden med en smart telefon. Denna uppkopplingsmöjlighet ansluter till ett telematiksystem i bilen som har blivit standard på många modeller.
Att ansluta fordonet till ett WAN kan bjuda in till hot från sofistikerade hackare. Ett enkelt fel kan möjliggöra en fjärrattack som kan skada en hel bilpark. Kommunikationen kan vara bil till servicecenter eller andra OEM-infrastrukturer, bil till multimedialeverantör, bil till bil, bil till elnätet (elbilar), bil till smarta telefoner eller till och med bil till bank. Fig 3 visar några exempel på långväga radiokommunikation i nästa generation fordon.

Fig 2 – Nästa generation blandade kritiska system och infotainmentsystem

Till skillnad mot datacenter är det osannolikt att bilar kommer att utrustas med en komplett uppsättning av IDS, IPS, brandväggar och UTM:er. Oavsett detta har de senaste intrången i Sony, Citigroup, Amazon, Google och RSA påtagligt visat att dessa försvarsmekanismer är som en Schweitzerost för sofistikerade hackare.

Isolera
När man blev varse Stuxnet-attacken 2010 föreslog chefen för US DoD CYBERCOM General Keith Alexander att USA:s kritiska infrastruktur skulle isoleras på sitt eget säkra nätverk, helt skilt från Internet. Detta må verka tungrott men det är precis det sorts tänkande som är nödvändigt. Bilens kritiska system måste vara kraftigt isolerat från ECU:er och nätverk som inte är kritiska för säker funktion.
Samtidigt som fysisk nätverksisolation är önskvärd kommer beröringspunkter ofrånkomligen att finnas. Exempelvis fordonets navigationssystem, som på vissa marknader måste stängas av då bilen rör sig vilket kräver kommunikation mellan system med vitt skilda säkerhetsnivå. Denna kommunikation ökar risken för programburna hot som att höja rättigheter med hjälp av fel i operativsystem, sidokanalsattacker på kryptografi och ”denials of service”.

Fig 3 – Exempel på nästa generation extern fordonskommunikation

Nästa generation arkitektur för infotainmentsystem måste hantera dessa viktiga säkerhetshot från grunden. Interaktion mellan kritiska och icke-kritiska system och nätverk måste försvaras på högsta möjliga hanteringsnivå, rigoröst kontrolleras vid körning och analyseras och certifierat sakna sårbarhet på högsta säkerhetsnivå.

Sandlådor
Operativsystem med öppen källkod som MeeGo eller Ubuntu är väl sedda för sina anpassningar till de senaste och bästa multimediastandarderna och tillgänglighet till tredjepartstillämpningar. Emellertid måste vi inte nödvändigtvis vara beroende av multimediaoperativsystemet för kontroll av alla aspekter i nästa generation konsoliderade infotainmentsystem. Generella operativsystem kan inte starta snabbt nog, kan inte garantera realtidsrespons för protokoll som CAN och är inte tillförlitliga och säkra nog för säkerhetskritiska funktioner som backkamera och integrerade instrumentpaneler. Därför behöver vi en systemarkitektur i vilken multimediaoperativsystem och deras tillämpningar tryggt kan samexistera med säkra realtidstillämpningar på ett säkerhetsgaranterat realtidsoperativsystem.

Fig 4 – Hypervisor av Type-2: Tillämpningen på ett generellt operativsystem

En möjlig lösning är att ha flera processorer dedikerade till olika uppgifter. Detta för med sig samma problem som dagens många ECU:er, långsammare kommunikation mellan tillämpningar och ökade problem med avgränsning.
Behovet att köra dessa funktioner på en enda processor är mycket reellt för att optimera kostnader, processcykler, datatillgänglighet och komplexitet. Vi behöver sandlådor (sandboxes) för dessa blandade kritiska tillämpningar. Man kan tänka sig varje sandlåda som en isolerad persona.
Följande fyra angreppssätt för flera persona har kommersialiserats i någon form:
* Multi-boot
* Webtop
* Hypervisor av typ 2
* Hypervisor av typ 1

Multi-boot
Konceptet med multi-boot har försökts på en handfull bärbara datorer under några år. I en multi-boot-dator kan ett nerbantat operativsystem, vanligtvis ett nerskalat Linux, köras i stället för den primära plattformens operativsystem. Det nerskalade operativsystemet används vanligen bara till att surfa med och det primära målet är att göra det möjligt för användaren att surfa inom några sekunder från kallstart. Det sekundära operativsystemet ligger på en separat lagringsplats och körs aldrig samtidigt som operativsystemet på den primära plattformen. I vissa fall exekveras den nerbantade miljön på en sekundär processor (t ex en ARM-SoC oberoende av datorns huvudprocessor).
Det sekundära operativsystemet har god isolation ur ett säkerhetsperspektiv. Emellertid har olägenheten med att behöva starta om och oförmågan att sömlöst byta mellan personas begränsat användningen. Multi-boot-möjligheten är också opraktisk i en konsoliderad infotainmentmiljö som behöver samtidigt nyttjande av personas, t ex multimediainfotainment samtidigt med instrumentpaneler och nätverkskommunikation i realtid.

Webtop
Webtop-konceptet ger begränsad surfningsmiljö (webtop) oberoende av den primära operativsystemmiljön. I stället för dual-boot körs tillämpningen på toppen av det primära operativsystemet. Så länge som webtop kör de icke-kritiska delarna av systemet och det primära operativsystemet kan hantera kritiska tillämpningar isolerade från webtop kan denna metod tillhandahålla behövlig isolation (sandboxing). Emellertid kan en surfningsbaserad miljö kanske inte uppfylla den rika funktionaliteten som förväntas av ett modernt infotainmentsystem.
En närbesläktad metod är att köra webtop eller speglad monitor från en ansluten smart mobiltelefon. Detta skulle också kunna tillhandahålla behövlig isolation (den smarta mobiltelefonens dator används i stället för infotainmentdatorn i bilen). Fjärrtekniken med smarta mobiltelefoner har testats på några fordon och är en intressant möjlighet. En av dess utmaningar är att garantera att den smarta mobiltelefonen kan ge en fordonsanpassad upplevelse.

Hypervisor av typ 2
Hypervisorer av typ 2 liknar webtop i och med att den sekundära persona körs som en tillämpning på det primära operativsystemet. I stället för att bara köra en internetläsare är den sekundära personan ett fullständig gästoperativsystem som körs i en virtuell maskin skapad av en hypervisortillämpning (fig 4). Gästoperativsystemet kan vara ett realtidsoperativsystem anpassat till att hantera kritiska tillämningar som back kamera eller instrumentpanel. Hypervisorn använder det primära operativsystemet för att hantera I/O. Virtualiseringsmetoden uppfyller kraven på att tillhandahålla en funktionell miljö för både kritiska och icke-kritiska persona.

Fig 5 – Mikrokärnehypervisorarkitektur av typ 1

Typ 2-modellen faller på att inte tillhandahålla stark isolation. Fel eller säkerhetsbrister i det primära generella operativsystemet kommer att få påverkan på realtidskritiska funktioner i den virtuella maskinen. Dessutom har hypervisortillämpningar av typ 2 i företagsmiljöer själva befunnits vara behäftade med svagheter som bryter isolationen.

Hypervisor av typ 1
Hypervisorer av typ 1 tillhandahåller också komplett funktionalitet och samtidig exekvering av flera personas. Däremot kan inte personaisolationen besväras av svagheter i personas operativsystem eftersom hypervisorn körs direkt på hårdvaran. Därför representerar hypervisorer av typ 1 en lovande metod ur både funktions- och säkerhetssynpunkt. Emellertid finns det fortfarande sårbarhetshot och alla hypervisorer av typ 1 är inte konstruerade för att uppfylla de högsta säkerhetsnivåerna.
En speciell variant, nämligen mikrokärnebaserad hypervisor av typ 1 är speciellt utvecklad för att uppfylla de krävande behoven av realtid, snabbhet och säkerhet i moderna infotainmentmiljöer. Mikrokärnor har en bättre arkitektur för säkerhet än stora generella operativsystem som Linux, MeeGo, Android och Windows. En mikrokärna kör bara en minimal uppsättning av kritiska systemtjänster som processtyrning, undantagshantering och interprocesskommunikation i ”supervisor”-mod där de får använda resurser som ansetts nödvändiga av systemkonstruktören. En svaghet eller ett fel i en komponent kan inte orsaka skada i en kritisk komponent eftersom det infekterade systemet helt enkelt inte kommer åt de resurserna. Eftersom mikrokärnan är förhållandevis enkel kan den formellt verifieras och certifieras av oberoende kontrollörer till den högsta nivån på säkerhet.
I ett hypervisorsystem av typ 1 är systemvirtualiseringen byggt som en tjänst på mikrokärnan. Förutom att isolera virtuella maskiner tillhandhåller mikrokärnan ett öppet standardgränssnitt för enklare kritiska tillämpningar som förarinformationspaneler, kryptografiska undersystem och CAN-drivrutiner vilka inte kan anförtros till ett generellt gästkonto. En mikrokärnearkitektur av typ 1 visas i fig 5.
Ett exempel på hypervisor av typ 1 är Green Hills Softwares INTEGRITY Multivisor som är byggd på mikrokärnan INTEGRITY och ofta används i infotainmentsystem i fordon och säkerhetskritiska tillämpningar i realtid.

Fig 6 – Mikrokärnehypervisorarkitektur av typ 1 för nästa generation infotainmentsystem

Att applicera en mikrokärnehypervisor av typ 1 på det förutnämnda blandade kritiska infotainmentsystemet som består av det huvudsakliga infotainmentoperativsystemet och säkerhetskritiska tillämpningar för backkamera och förarinformationspaneler resulterar i arkitekturen som framgår av fig 6.

Säkra nätverkstransaktioner
Fig 6 visar också en hanteringsstillämpning. En annan användbar tillämpning för mikrokärnearkitektur av typ 1 är att vara värd för säkra fjärrkommunikationssystem direkt på mikrokärnan. Exempel på nästa generation säkra nätverkstransaktioner i infotainmentsystem är skyddat multimediainnehåll och rättighetsöverföring samt fjärrsystemhantering (t ex firmwareuppgraderingar och fjärrdiagnostik) av tekniker och OEM-leverantörer.
Det viktiga med denna lösning är att det skapas en skyddad kommunikation, logiskt helt utanför huvudsystemet. Eftersom kryptonycklar, servercertifikat och protokollprogram sköts av lättviktiga processer kan dessa kritiska data inte stjälas eller förstöras av gästoperativsystemet oavsett om det är infekterat av skadlig kod eller ej. Dessutom kan det grundläggande säkerhetssystemet dra nytta av TMP-möjligheter (eller liknande) om de finns tillgängliga för härvarubaserad lagring av nycklar för plattformsattest. Den säkra kommunikationen undanröjer attacker från såväl ”mannen i mitten” som attacker från elakartade program som skulle kunna försöka ta kommando över de kryptografiska nycklar som används för säker kommunikation.

GENIVI
GENIVI är en industristandard som är tagits fram för infotainmentreferensplattformar för fordon med målet att reducera time-to-market och utvecklingskostnader. Dessa referensplattformar innehåller de konkurrensneutrala funktioner som varje system anses behöva och gör att olika organisationer kan koncentrera sig på innovativa funktioner som kan ge en konkurrensfördelar. En nyckelprincip för att uppfylla dessa mål är fokus på öppna standarder och tillhörande uppfyllande av certifieringar. När det traditionella infotainmentsystemets roll uppfylles av generella operativsystem bör det inte komma som någon överraskning att GENIVI:s första referensplattformar är fokuserade på Linuxdistributioner som uppfyller kraven på överensstämmelse med GENIVI-bestämmelserna.
Ser man framåt måste intressenter i fordonsinfotainment som OEM-tillverkare och deras leverantörer, myndighetsövervakare och passagerare se bortom multimediasystemet till en ny värld med blandade kritiska krav. Nästa generation programvaruarkitektur är nödvändig för att garantera att framtida komplexa funktionsrika infotainmentsystem har den tillförlitlighet, säkerhet, realtidsprestanda och storlek som fordonsindustrin och konsumenterna kräver. Framtida bilsystem kommer att se en konvergens av säkerhetskritiska funktioner med traditionell telematik och digitala underhällningstillämpningar. Att göra dessa möjligheter tillgängliga på en datorplattform är viktigt för att kunna minimera storlek, vikt, effektförbrukning, produktionskostnad och elektronikkomplexitet. För att göra detta säkert krävs ett ny angreppssätt för systemarkitekturer.
En lovande ”sandboxing”-metod är systemvirtualisering av typ 1 som kan isolera och hantera realtids- och säkerhetskritiska tillämpningar parallellt med multimediaoperativsystem med öppen källkod. Dessutom ger tillgängligheten av virtualiseringsteknologi på många olika datorplattformar utvecklare och tekniker en ultimat öppen plattform med möjlighet att köra vilken variant av operativsystem i vilken kombination som helst och ge oanad flexibilitet för driftsättning och användning. Denna flexibilitet är välkommen såväl i fordon som i bordsdatorer och servar.
David Kleidermacher, CTO, Green Hills Software och Matt Jones, Vice President, GENIVI Alliance

Filed under: Embedded