Characterization of COTS Microkernel-based Systems using MAFALDA

Transcription

1 Characterization of COTS Microkernel-based Systems using MAFALDA Jean-Charles Fabre LAAS-CNRS Toulouse, France IFIP Working Group 1.4 Meeting Paraty, Brazil March 1-3, 21

2 Problem statement Building executive supports for dependable systems, two options: Development from scratch is complex & expensive Use of commercial components is questionable Main tendency for embedded systems Use of COTS componentized microkernels Define a specific instance for the application System development : two options syn sch mem com syn sch new com application Microkernel instance application Middleware layer Microkernel instance

3 Outline The objectives of MAFALDA MAFALDA in action Experimental results Lessons learnt

4 Objectives of MAFALDA Characterization by SWIFI (S/W Implemented Fault Injection) Identification of failure modes Evaluation of error detection coverage Identification of propagation channels Assessment of interface robustness MAFALDA Microkernel Assessment by Fault injection AnaLysis and Design Aid Wrapping framework Definition of formal wrappers Definition of a reflective implementation framework Application to both white-box & black-box candidates Rack of target machines Evaluation of the wrapped microkernel instance Host Machine controlling the experiments

5 Application Corruption Wp i Failure modes Wp j Application Oracle! Application failure " Erroneous results " Application hang Application / middleware Propagation API Error Microkernel! Internal System hang Corruption! Internal detection Error Propagation " Error Status " Exceptions µkci µkcj S e v e r i t y

6 Fault injection experiment

7 Sample of measures

8 Campaigns Microkernels Candidates: " Chorus Classix r3.1 (Kernel API), " Lynx OS v 3..1 (Kernel/Posix API) Components: " Synchronisation (semaphores) " Memory (protected regions) " Communication (message passing) " Scheduling (preemptive FIFO) Campaign parameters Same workload mapped on two different APIs Running on the same Pentium-based platform Between 1 to 3 experiments for each component All components targeted Both microkernel and parameters fault injection experiments

9 Chorus vs. LynxOS Code segment fault injection Synchronisation Kernel Scheduling Fail Syst. Chorus Classix r3.1 LynxOS r 3..1 Exception Error Status No Obs

10 Chorus vs. LynxOS Code segment fault injection Communication Chorus Classix r3.1 LynxOS r Kernel Fail 8 Syst. Exception Error Status No Obs 7 6 Memory

11 Chorus vs. LynxOS Parameter fault injection API Synchronisation Kernel Memory Fail Syst. Chorus Classix r3.1 LynxOS r 3..1 Exception Error Status No Obs

12 Chorus vs. LynxOS Parameter fault injection Chorus Classix r3.1 LynxOS r 3..1 Communication API Kernel 2 1 Fail * * Syst. Exception Error Status No Obs Similar behavior, except that a system call with given parameters can hang the application or even the kernel

13 Chorus vs. LynxOS Parameter fault injection Chorus Classix r3.1 LynxOS r 3..1 Communication API Kernel 2 1 Fail * * Syst. Exception Error Status No Obs int portmigrate (options, srcactorcap, portli, dstactorcap, seqnum) int portdelete (actorcap, portli) KnCap

14 Running mode impact Downloading application code into kernel space (Synchronisation workload) User mode Kernel mode No Obs 28.5% Undetected 9% 6% Syst. 1.4% No Obs 35.9% Undetected 41,5% Error status 3% Exception 38.1% KDB 13.9% Exception 21.1%.4% Syst..3% KDB,8% Code segment fault injection experiments carried out on Chorus Classix r 3.1

15 Detailed system call analysis Kernel call Parameter number Type Activated faults Application failure Application hang Exception Error status No observation GetPriority SetPriority int which int pid int which int pid int prio % % 64 3.% % % % 3 1.7% % % %.%.% 79.3% 7.8% Total % 3.3% % % Most of individual cases can be analysed Examples: " Priority out-of-bounds (Error status) " Invalid priority (Application failure) Possible conclusions: " The corrupted input value can be detected (assertion missing) " The corrupted input is valid for the kernel and cannot be checked (to be checked at the application/middleware level) The input space is randomly corrupted (sometimes all bits)

16 Some Lessons learnt Interpretation of results " One campaign : a microkernel instance + an activation profile " Variability of results: stand-alone vs. Posix-based version Raw data analysis reactive vs. static application " Analysis of logged data precise analysis of faulty situations " User-defined semantics of the failure modes Integrator s vs. supplier s viewpoint " Integrator: weaknesses revealed ED mechanisms (wrappers) " Supplier: bugs not yet revealed product improvement Target system evolution " A slightly new instance new campaign needed " Is the new release/version acceptable?