Practical Development of Safe, Secure, Reliable Embedded Software

Transcription

1 ARM TechCon 2017 Practical Development of Safe, Secure, Reliable Embedded Software Pat Rogers

2 Why Safe, Secure, or Reliable? Your car could crash Your flight could crash Your medical implant could fail Your bank account could disappear Your marriage could fail (No? Ashley Madison ) Et cetera Slide: 2

3 Inadequate Code Is Not Inevitable There s no such thing as a silver bullet But there are much better options available We can produce highly-reliable software at a reasonable cost Slide: 3

4 A Better Way: SPARK 2014 A formally-defined programming language supporting static analysis Specifically designed for high-integrity software Plus a set of tools to perform those analyses Based on statically provable contracts + testing Slide: 4

5 What is Static Analysis? [Basic Static Analysis: coding standard checking, metrics, compiler warnings and style checks] Advanced Static Analysis: symbolic execution/interpretation of source code, to find what could go wrong (and right) Formal Verification: verifying high level or abstract properties of your application, giving strong guarantees Slide: 5

6 Why Static Analysis Saves Money Shifts costs from later, expensive phases to earlier, cheaper phase Relative Cost To Fix Bugs Over Life Cycle Requirements Design Code Development Test Acceptance Test Operation Slide: 6

7 How Does Formalism Shift Costs? Bugs that testing would have missed may be caught Bugs that testing would have caught may be caught earlier Passing (nearly) all the tests the first time is cheaper Slide: 7

8 Contracts Express Provable Properties User-defined executable run-time checks Preconditions specify caller obligations Postconditions specify implementer guarantees Obligation Guarantee procedure Push (This : in out Stack; Value : Content) with Pre => not Full (This), Post => not Empty (This) and Top (This) = Value; function Top (This : Stack) return Content; function Full (This : Stack) return Boolean; Slide: 8

9 DMA Device Driver Contract Example type DMA_Status_Flag is (FIFO_Error, Direct_Mode_Error, Transfer_Error, Half_Transfer_Complete, Transfer_Complete); function Status_Indicated (Unit : DMA_Controller; Stream : DMA_Stream_Selector; Flag : DMA_Status_Flag) return Boolean; procedure Clear_All_Status (Unit : in out DMA_Controller; Stream : DMA_Stream_Selector) with Post => (for all Flag in DMA_Status_Flag => not Status_Indicated (Unit, Stream, Flag)); Guarantees no flags remain set after call Slide: 9

10 What Can You Prove, Statically? Freedom from run-time errors No buffer overflow, no numeric overflow, no divide by zero, no invalid array indexes, etc. Data and Information flow contracts No uninitialized variables, unused assignments, etc. Data only goes where you mean it to go Functional correctness at unit level Arbitrary properties, e.g., security and safety Slide: 10

11 Proving Functional Correctness Example procedure Push (This : in out Stack; Item : in Element) with Pre => not Full (This), Post => not Empty (This) and then Top_Element (This) = Item and then Extent (This) = Extent (This'Old) + 1 and then This'Old.Unchanged (Within => This); function Top_Element (This : Stack) return Element with Pre => not Empty (This); function Extent (This : Stack) return Element_Count; function Empty (This : Stack) return Boolean; function Full (This : Stack) return Boolean; function Unchanged (Invariant_Part, Within : Stack) return Boolean; Slide: 11

12 Why Doesn t Everyone Use Formalism? Your software development already does! The ultimate product of software development is a precise, rigorous description of behavior It s machine code Operational semantics defined by the target processor So it s not whether, but when to use formalism Earlier in the life cycle is better Slide: 12

13 Really, Why Doesn t Everybody Use It? Perception that formal methods have flopped due to inability to prove entire programs correct Fear of the mathematics But the math is now hidden behind the tools Now easy enough to adopt and use by regular teams Slide: 13

14 Math Hidden Behind the Tools Typical for engineering disciplines Shock wave (colored by pressure) Booster separation motor plumes (colored by Mach #) Slide: 14

15 How Smart Do You Have To Be? Too Much Too Little Just Right Dr. Frankenstein Igor Inga Slide: 15

16 Sufficiently Easy to Adopt Can do it gradually SPARK is legal Ada 2012 Have some units in SPARK, others in Ada Inside units, parts in SPARK and parts in Ada Can have other languages involved too Plenty of tool support Integrated with GNAT Pro tools and IDEs Slide: 16

17 Sufficiently Easy to Use Provides incremental benefits Usable without up-front work (i.e., no contracts) Increasing benefits with more contracts Is highly interactive Run at different levels of granularity (down to single line) Run at different levels of analysis power Get precise results in the IDE or command line Get results explanations (paths, counter-examples) Slide: 17

18 The Crazyflie 2.0 Example An Open Source software and hardware micro-drone Slide: 18

19 Crazyflie 2.0 Dual MCU System Architecture RF Power Amp. 10 DOF IMU 3-axis accelerometer 3-axis gyro 3-axis magnetometer pressure sensor I2C nrf MHz Cortex M0 16KB RAM, 256KB FLASH UART STM32F MHz Cortex M4 196KB RAM, 1MB FLASH PWM Motors BLE and NRF Radio Flight Control I2C Power Expansion Port EEPROM Slide: 19

20 The Crazyflie 2.0 Challenge 1800 SLOC for stabilization in C + FreeRTOS for threading + SPARK 2014 Slide: 20

21 2 months later 1800 SLOC stabilization in C + FreeRTOS + Re-written in Ada/SPARK 2100 SLOC in SPARK proved no run-time errors! + FreeRTOS + Slide: 21

22 5 months later 1800 SLOC stabilization in C + FreeRTOS + Re-written in Ada/SPARK 2100 SLOC in SPARK proved no run-time errors + Ravenscar tasking + proved no concurrency errors Slide: 22

23 How Do The Implementations Compare? He found some bugs in the C code (and reported them) He added drop recovery But he didn t implement data logging and a few minor things (e.g., a blinking LED) SPARK code size is slightly less (about 3K less) SPARK data size is much less (about 23K less) Slide: 23

24 Lunar CubeSat Created by students at Vermont Technical College Launched into Earth orbit in 2013, still working The only one of the 12 that worked fully Team selected for new version going to the Moon Lunar IceCube Slide: 24

25 MULTOS Certificate Authority MULTOS is an operating system for smartcards 100,000 lines of SPARK code Only 4 defects reported 1 year after delivery 0.04 per KSLOC Corrected under warranty (!) Industry standard is 5 defects per 1,000 lines Thus approximately 500 defects expected Ultra-high reliability achieved Slide: 25

26 MULTOS CA Productivity 28 lines of code per day Fully documented, tested, everything Industry standard is 10 lines of code per day In any language Very high levels of productivity achieved Slide: 26

27 Vehicle Component Research Project By TOYOTA InfoTechnology Center (ITC) To show that software requirements can be transformed into an implementation proven to be free of run-time errors Currently underway Slide: 27

28 C130J Example Project Results Order of magnitude code quality improvement over industry norms for DO 178B Level A software Productivity improved by a factor of 4 over previous comparable programs Development costs half of that typical for non safety-critical code Sutton, James: Cost-Effective Approaches to Satisfy Safetycritical Regulatory Requirements. Workshop Session, SIGAda Slide: 28

29 Multiple Use Cases (1/2) 1. A safe coding standard for critical software No implementation-dependencies Easily analyzable 2. Addressing data and control coupling 3. Proving absence of run-time errors Requires few contracts Typically 95% - 98% proved Proof can be completed by testing Slide: 29

30 Multiple Use Cases (2/2) 4. Safe removal of run-time checks 5. Prove correct integration between components Replaces defensive coding Simple contracts are needed 6. Prove functional correctness Replaces unit testing More complex contracts are needed Slide: 30

31 Combining Proof and Test Because not everything can be proved Focus test coverage on unproven runtime error checks During integration tests, replace unit tests with proofs Contracts already express what the unit tests would test Slide: 31

32 Contracts As Provable Unit Tests procedure Push (This : in out Stack; Item : in Element) with Pre => not Full (This), Post => not Empty (This) and then Top_Element (This) = Item and then Extent (This) = Extent (This'Old) + 1 and then This'Old.Unchanged (Within => This); function Top_Element (This : Stack) return Element with Pre => not Empty (This); function Extent (This : Stack) return Element_Count; function Empty (This : Stack) return Boolean; function Full (This : Stack) return Boolean; function Unchanged (Invariant_Part, Within : Stack) return Boolean; Slide: 32

33 Concluding Remarks How safe/secure/reliable must your software be? Is the status quo good enough? You can do anything with any language but at what cost? High reliability at reasonable cost is demonstrable now You don t need a new team to get there Slide: 33

34 Adoption Guidelines Available From strong semantic coding standard to full functional correctness Every level implicitly builds on the lower levels Lower levels require lower costs/efforts Good match from DAL/SIL to Bronze-Silver-Gold-Platinum Adoption greatly facilitated by detailed level-specific guidance Slide: 34