Compiler-uitdagingen navigeren in functionele veiligheidstoepassingen

Over industrieën heen stelt functionele veiligheid strenge eisen aan ontwikkelaars: code moet defensief geëngineerd zijn om te beschermen tegen onverwachte gebeurtenissen zoals geheugencorruptie of kosmische straling-interferentie. High-level-talen zoals C en C++ bevatten functies wier gedrag niet volledig gedefinieerd is door de taalspecificatie. Deze undefined behaviors kunnen verrassende, potentieel catastrofale uitkomsten produceren in veiligheidskritische systemen. Daarom vereisen standaarden defensief coderen, rigorouse testbaarheid, uitgebreide code-coverage en traceerbaarheid van requirements naar applicatiecode om complete en unieke implementatie van veiligheidsfuncties te waarborgen.

Veiligheidskritische sectoren, vooral automotive, vereisen vaak gesofisticeerde externe diagnostische, calibratie- en ontwikkeltools. Defensief coderen en externe data-toegang zijn concepten die compilers inherent niet begrijpen. Noch C noch C++ accommoderen geheugencorruptie, dus als defensieve maatregelen niet expliciet bereikbaar zijn in de code, kan een compiler ze optimaliseren weg. Verdedigingen moeten daarom syntactisch en semantisch bereikbaar blijven om optimalisatie-passes te doorstaan.

Undefined behavior is berucht moeilijk te spotten. Zelfs wanneer geïdentificeerd, is er geen garantie dat de gecompileerde binair zich zal gedragen zoals bedoeld. "Back-door" data-toegang gebruikt door debug-tools is een ander voorbeeld van taalconstructies die compilers niet overwegen, wat leidt tot onvoorziene bijwerkingen.

Compiler-optimalisatie kan blijkbaar zinvolle defensieve code elimineren als het op infeasibele paden ligt - paden die niet door enige input geoefend kunnen worden. Zelfs code die unit-test-coverage doorstaat, kan tijdens de finale build verwijderd worden. Dus, hoge bron-niveau coverage garandeert niet dat de executable de beoogde veiligheidscontroles bevat.

Object-code-verificatie (OCV) is daarom best practice voor systemen waar falen nefast gevolgen heeft. OCV bevestigt dat de gecompileerde object overeenkomt met de bedoeling van de ontwikkelaar, een kritieke vereiste wanneer compilers code op manieren kunnen transformeren die veiligheidsaannames schenden.

Voor en na compilatie

Functionele veiligheid, beveiliging en coding-standaarden (IEC 61508, ISO 26262, IEC 62304, MISRA C/C++) benadrukken de noodzaak om te demonstreren hoeveel van de broncode geoefend wordt tijdens requirements-gebaseerde testen. Hoewel hoge coverage veldfoutkans verlaagt, steunt het op de aanname dat de compiler bron-niveau gedrag getrouw reproduceert - een aanname die niet gerechtvaardigd kan worden voor de meest kritische toepassingen.

De controle- en data-stroom van de gegenereerde object-code spiegelt zelden de broncode precies. Een 1:1 mapping tussen object-code en assembly onthult discrepanties. Bijvoorbeeld, Figuur 1 toont assembly geproduceerd vanuit een bron-snippet met optimalisatie uitgeschakeld met een TI-compiler. Wanneer optimalisatie ingeschakeld is, verandert de flow-grafiek dramatisch omdat de compiler wiskundige transformaties toepast die de afwezigheid van undefined behaviour aannemen.

Figuur 1: Bron vs. assembly vergelijking die illustreert hoe optimalisatie controle-stroom kan wijzigen.

Compilers kunnen defensieve calls optimaliseren weg als ze bepalen dat de geassocieerde branch onbereikbaar is. Figuur 2 demonstreert een CLANG-compilatie waar een call naar een error-handler verwijderd wordt omdat de compiler afleidt dat de state-variabele slechts twee waarden kan bevatten. Deze optimalisatie, hoewel efficiënt, schendt de veiligheidsintentie van defensief coderen.

Figuur 2: CLANG verwijdert defensieve error-call door onbereikbare branch.

Het wijzigen van de omringende context kan de compiler's optimalisatiebeslissingen veranderen. Figuur 3 voegt een nieuwe functie toe die de state-variabele benadert; de compiler behoudt nu de defensieve call omdat de additionele context de branch potentiëel haalbaar maakt. Verdere veranderingen, zoals het teruggeven van een pointer naar de state, dwingen de compiler om expliciete waarden in de assembly te behouden (Figuur 4).

Figuur 3: Context-wijziging behoudt defensieve branch.

Figuur 4: Pointer-aliasing voorkomt optimalisatie van defensieve code.

In unit-test-harnesses kan het manipuleren van state via pointers defensieve code van het weg-optimiseren weerhouden, maar dit gedrag persisteert niet in de productie-build. Dus, unit-test-coverage alleen kan ontbrekende veiligheidscontroles maskeren.

Object-code-verificatie

OCV biedt een veiligheidsnet door bron en assembly te vergelijken. Figuur 6 toont een eenvoudige functie die, wanneer uitgevoerd met een enkele test-call, 100% bron-niveau coverage bereikt. Echter, de geassembleerde flow-grafiek (Figuur 8) onthult niet-geoefende paden die de unit-test miste. Door tests te forceren om alle assembler-paden te dekken, onthult OCV gaps die bron-niveau tests over het hoofd zien.

Figuur 6: Broncode die 100% coverage bereikt in unit-tests.

Figuur 7: Basic-block flow-grafiek van de bron.

Figuur 8: Geassembleerde flow-grafiek die niet-geteste paden onthult.

Hoewel OCV een compiler niet kan voorkomen van het toepassen van zijn optimalisatieregels, brengt het elke mismatch tussen ontwikkelaarsintentie en executable-gedrag aan het licht, wat correctieve actie mogelijk maakt vóór product-deployment.

Best practice over alle domeinen

Voor veel systemen is bron-niveau unit-test-coverage voldoende om certificeringsinstanties te voldoen. Toch, in de meest kritische veiligheidskritische toepassingen - in luchtvaart, automotive, medisch en industriële sectoren - is het aanvullen van bron-coverage met OCV essentieel. OCV lijnt het gecompileerde product af op de strenge veiligheidseisen die standaarden eisen, wat het hoogste vertrouwen biedt dat de executable zich gedraagt zoals bedoeld.