Software Techniques for Dependable Computer-based Systems. Matteo SONZA REORDA

Transcription

1 Software Techniques for Dependable Computer-based Systems Matteo SONZA REORDA

2 Summary Introduction State of the art Assertions Algorithm Based Fault Tolerance (ABFT) Control flow checking Data duplication and comparison A comprehensive approach Conclusions. Matteo SONZA REORDA Politecnico di Torino 2

3 Introduction Cost is becoming a major constraint for many safety-critical applications exploiting microprocessor-based systems Software-implemented hardware faulttolerance (SIHFT) approaches are attractive: Commercial components can be used Hardware redundancy can be avoided High flexibility can be reached. Matteo SONZA REORDA Politecnico di Torino 3

4 SIHFT The aim of SIHFT techniques is to Address temporary faults in the hardware Provide solutions based on software changes SIHFT techniques are cheap flexible but introduce memory overhead performance slow-down. Matteo SONZA REORDA Politecnico di Torino 4

5 Evaluation parameters Detection/correction capabilities Cost Development Memory overhead Performance slow down Generality (e.g., wrt the application characteristics) Flexibility (e.g., wrt the addressed faults). Matteo SONZA REORDA Politecnico di Torino 5

6 Assumptions Microprocessor- (or microcontroller-) based systems Only the software can be modified for system hardening purposes Transient faults are addressed Trading off between reliability and performance is acceptable Software is correct (no bugs). Matteo SONZA REORDA Politecnico di Torino 6

7 The dream Hardened system SW automatic transformation SW* µp mem I/O I/O I/O I/O Matteo SONZA REORDA Politecnico di Torino 7

8 State of the art Assertions Algorithm Based Fault Tolerance (ABFT) Control flow checking Data duplication and comparison Matteo SONZA REORDA Politecnico di Torino 8

9 Assertions Some invariant property is checked during the code execution Originally intended for software bugs identification Can detect hardware faults, also Their insertion is often performed in an empirical way. Matteo SONZA REORDA Politecnico di Torino 9

10 Limits The attained fault detection capability is normally low Assertions insertion can hardly be automated. Matteo SONZA REORDA Politecnico di Torino 10

11 ABFT Introduced by Huang & Abraham in 1984 Set of techniques for hardening some common algorithms, e.g., Matrix multiplication Matrix inversion LU decomposition FFT Based on encoding input so that the algorithm produces an encoded output. Matteo SONZA REORDA Politecnico di Torino 11

12 Example: matrix multiplication Definitions: A column checksum matrix of the matrix A is an (n+1)-by-m matrix A c, which consists of the matrix A in the first n rows, and a column summation vector in the (n+1)st row. A row checksum matrix of the matrix A is an n-by- (m+1) matrix A r, which consists of the matrix A in the first m columns, and a row summation vector in the (m+1)st column. The full checksum matrix A f of the matrix A is an (n+1)-by-(m+1) matrix, which is the column checksum matrix of the row checksum matrix of A. Matteo SONZA REORDA Politecnico di Torino 12

13 Theorem The result of a column checksum matrix A c multiplied by a row checksum matrix B r is a full check-sum matrix C f. The corresponding matrices A, B, and C have the following relation: A * B = C Matteo SONZA REORDA Politecnico di Torino 13

14 Example A B CHECKSUM = C CHECKSUM CHECKSUM CHECKSUM Matteo SONZA REORDA Politecnico di Torino 14

15 Improvements ABFT can be tailored to different targets (fault detection, fault localization, etc.) by changing the adopted checksum. Matteo SONZA REORDA Politecnico di Torino 15

16 Fault detection capabilities ABFT normally has very good detection capabilities (>98%) with respect to Faults in the data memory Faults in the arithmetic units Some faults in the code memory are also detected. Matteo SONZA REORDA Politecnico di Torino 16

17 Overhead When used for fault detection, ABFT overhead is 13% for memory 32% for execution time. When tailored to single error correction, the overhead is 28% for memory 73% for execution time. Matteo SONZA REORDA Politecnico di Torino 17

18 ABFT: summary Advantages: Low memory overhead Low execution time overhead High coverage of faults in the data Disadvantages: Available for some algorithms, only High cost for implementation Some faults escape (e.g., those affecting the data before encoding) Determining the threshold for error identification can be difficult. Matteo SONZA REORDA Politecnico di Torino 18

19 Control flow checking Aims at detecting faults changing the execution flow of a program It is based on Dividing the program code in basic blocks Building the program graph Checking at run-time the correctness of each transition performed during the program execution. Matteo SONZA REORDA Politecnico di Torino 19

20 Basic blocks A basic block is a maximal set of ordered instructions in which the execution begins from the first instruction and terminates at the last instruction There is no branching instruction in a basic block except possibly for the last one A basic block terminates at either an instruction branching to another basic block or an instruction receiving control from two or more places in the program. Matteo SONZA REORDA Politecnico di Torino 20

21 Program graph It is a graph where Vertices are basic blocks Edges are transitions in the execution flow, i.e., branches, call and return instructions, etc. Matteo SONZA REORDA Politecnico di Torino 21

22 Example Matteo SONZA REORDA Politecnico di Torino 22

23 Checking control flow It can be performed on-line by Assigning a signature s i to each basic block i Computing an expected signature difference G for each block Evaluating during execution (each time a new block is entered) the function f = G d i, where d d = s d s s, being s d and s s the signatures of the basic block and its predecessor, respectively. Matteo SONZA REORDA Politecnico di Torino 23

24 Example Matteo SONZA REORDA Politecnico di Torino 24

25 Developing the idea Suitable techniques have been developed for dealing with blocks that can be reached from several blocks optimizing the choice of the signatures assigned to blocks. Matteo SONZA REORDA Politecnico di Torino 25

26 Experimental results According to Oh et al., The percentage of branch faults escaping this mechanism is below 2.5% Memory overhead ranges from 26% to 64% Execution time overhead ranges from 16 to 69%. The overhead mainly depends on the average basic block size Some aliasing effects may arise. Matteo SONZA REORDA Politecnico di Torino 26

27 Improvements Several techniques have been proposed to reduce the overhead and improve the fault coverage by Carefully choosing the signatures Cleverly performing the checks Avoiding unnecessary checks. Matteo SONZA REORDA Politecnico di Torino 27

28 Data duplication and comparison Independently developed by a couple of groups in the last 5 years Addresses faults in the data and code Based on duplicating data and checking copies. Matteo SONZA REORDA Politecnico di Torino 28

29 EDDI Proposed in 2002 by Oh, Shirvani and McCluskey Addresses faults affecting the code Based on duplicating instructions and data at the assembly level Reduces execution time slow down by careful instruction scheduling in superscalar architectures. Matteo SONZA REORDA Politecnico di Torino 29

30 Example Original code ADD R3, R1, R2 Modified code ADD R3, R1, R2 ADD R23, R21, R22 BNE R3, R23, error Matteo SONZA REORDA Politecnico di Torino 30

31 EDDI: results Detection capability for faults in the code segment exceeds 98% Execution time overhead ranges from 72% to 111% for a two-way processor Memory overhead is about 100%. Matteo SONZA REORDA Politecnico di Torino 31

32 A comprehensive approach Proposed by Politecnico di Torino group in 1999 Main characteristics Works on high-level code (e.g., C language) Limited assumptions on addressed faults High independence on hardware High fault coverage Its application can be automated Originally intended for fault detection, only. Matteo SONZA REORDA Politecnico di Torino 32

33 Basic idea A set of rules have been defined Rules transform a high-level code into a hardened one Rules application can be automated. Matteo SONZA REORDA Politecnico di Torino 33

34 Rules (I) Duplicate every variable Execute every operation on the two replicas Check for consistency after each read access. Matteo SONZA REORDA Politecnico di Torino 34

35 Example Original code int a, b; b=a+5; Hardened code int a1, b1, a2, b2; b1 = a1+5; b2 = a2+5; if(a1!=a2) error(); Matteo SONZA REORDA Politecnico di Torino 35

36 Rules (II) Check twice the condition in every conditional statement. Matteo SONZA REORDA Politecnico di Torino 36

37 Example Original code Hardened code if(condition) {/* block A */ }else {/* block B */ } if(condition) {/* block A */ if(!condition) error(); } else {/* block B */ if(!condition) error(); } Matteo SONZA REORDA Politecnico di Torino 37

38 Rules (III) Introduce some control flow checking technique. Matteo SONZA REORDA Politecnico di Torino 38

39 Rules (IV) Additional rules have been defined to cover Cycles Procedure call and return Matteo SONZA REORDA Politecnico di Torino 39

40 Rules (V) Similar rules can be defined for other high-level languages. Matteo SONZA REORDA Politecnico di Torino 40

41 Transformation tool A prototypical tool automating the application of the rules has been developed Reads a C code Produces a hardened C code. Matteo SONZA REORDA Politecnico di Torino 41

42 Overhead The application of all the hardening rules on the whole code on unpipelined or RISC processor systems Increases the size of the code and data areas Factors from 3 to 4 have been observed Slows-down the program execution Factors of about 3 have been observed. Matteo SONZA REORDA Politecnico di Torino 42

43 Experimental results Several fault injection campaigns have been performed to evaluate the fault detection capabilities of the method On a transputer-based system On an 8051-based system On a LEON processor. Matteo SONZA REORDA Politecnico di Torino 43

44 Experimental set up Some sample benchmark programs have been selected Hardened versions have been developed. Fault injection experiments have been performed. Matteo SONZA REORDA Politecnico di Torino 44

45 Fault Classification Effect less No Answer Latent Wrong Answer Undetected incorrect output Detection Hardware: through hardware mechanisms Software: through transformation rules. Matteo SONZA REORDA Politecnico di Torino 45

46 Transputer system: set up Random SEUs are injected in memory Fault Injection Software techniques have been exploited. Radiation experiments Performed at ONERA/DESP, Toulouse, France by the TIMA team Confirmed the fault injection results. Matteo SONZA REORDA Politecnico di Torino 46

47 Faults in the memory data area Wrong Answer SW Detected Effectless Hardened Original % Average of benchmark programs Matteo SONZA REORDA Politecnico di Torino 47

48 Faults in the memory code area Wrong Answer Hardened Original No Answer HW Detected SW Detected Effectless % Average of benchmark programs Matteo SONZA REORDA Politecnico di Torino 48

49 8051 system: set up Injected faults SEUs in the code memory SEUs in the processor memory elements (including hidden registers) SETs in the combinational part Emulation-based fault injection has been exploited. Matteo SONZA REORDA Politecnico di Torino 49

50 SEUs in the code memory Detected Effect-less Latent Hardened Original Wrong Answer ,000 injected SEUs Matteo SONZA REORDA Politecnico di Torino 50

51 SEUs in processor elements Detected Effect-less Latent Hardened Original Wrong Answer ,000 injected SEUs Matteo SONZA REORDA Politecnico di Torino 51

52 SETs on processor gates Detected 0 48 Effect-less Latent Hardened Original Wrong Answer ,000 injected SETs Matteo SONZA REORDA Politecnico di Torino 52

53 LEON system: set up Injected faults SEUs in the processor memory elements (including register file and pipeline registers) Emulation-based fault injection has been exploited. Matteo SONZA REORDA Politecnico di Torino 53

54 SEUs in pipeline registers Wrong answer Latent Hardened Original Effect-less Detected ,000 injected SEUs Matteo SONZA REORDA Politecnico di Torino 54

55 SEUs in register file Wrong answer Latent Hardened Original Effect-less Detected ,000 injected SEUs Matteo SONZA REORDA Politecnico di Torino 55

56 Observations (I) The method detects faults not only in the external memory, but also inside the processor: Cache User registers Hidden registers (e.g., in the control unit, or in the pipeline) Combinational logic. Matteo SONZA REORDA Politecnico di Torino 56

57 Observations (II) The method is able to detect any kind of fault creating a mismatch between the two replicas of a variable most of the faults affecting the code, or the control part of the processor. The method is NOT able to detect some of the permanent faults affecting the execution units of the processor. Matteo SONZA REORDA Politecnico di Torino 57

58 Observations (III) The method can be applied flexibly : A subset of rules may be applied (e.g., only duplication rules) A subset of variables may be hardened A subset of the code may be hardened. In this way, the most suitable trade-off between detection capabilities and overhead can be attained. Matteo SONZA REORDA Politecnico di Torino 58

59 Extension to fault tolerance The rules can be extended to obtain fault tolerance Only faults affecting data have been targeted Some faults affecting the code can be tolerated, also. Matteo SONZA REORDA Politecnico di Torino 59

60 Rules (I) Each variable is duplicated; two sets of variables V0 and V1 are thus obtained Every operation is repeated on the two replicas A checksum variable is introduced for V0 Checksum is updated after each write operation. Matteo SONZA REORDA Politecnico di Torino 60

61 Rules (II) After each read operation, the two copies are checked for consistency If a fault is detected Checksum is exploited to identify the corrupted copy The safe copy is used to correct the other. Matteo SONZA REORDA Politecnico di Torino 61

62 Example: original code int a, b; a = b+5; Matteo SONZA REORDA Politecnico di Torino 62

63 Example: hardened code int a0, a1, b0, b1, c; c = c^a0; a0 = b0+5; a1 = b1+5; c = c^a0; /* c is updated A checksum */ if(b0!=b1)/* error detection variable */ is if(chk()==c) introduced Each { variable b1 = b0; /* b1 is wrong */ is duplicated a1 = a0; /* a1 is wrong */ } else { b0 = b1; /* b0 is wrong */ a0 = a1; /* a0 is wrong */ c = chk(); } Matteo SONZA REORDA Politecnico di Torino 63

64 Example: hardened code int a0, a1, b0, b1, c; c = c^a0; a0 = b0+5; a1 = b1+5; c = c^a0; /* c is updated */ if(b0!=b1)/* error detection */ if(chk()==c) { b1 = b0; /* b1 is wrong */ a1 = a0; /* a1 is wrong Every */ operation } else is performed on { b0 = b1; /* b0 is wrong the */ two copies a0 = a1; /* a0 is wrong */ c = chk(); } Matteo SONZA REORDA Politecnico di Torino 64

65 Example: hardened code int a0, a1, b0, b1, c; c = c^a0; a0 = b0+5; a1 = b1+5; c = c^a0; /* c is updated */ if(b0!=b1)/* error detection */ if(chk()==c) Each time a { b1 = b0; /* b1 is wrong */ variable is a1 = a0; /* a1 is wrong */ modified, the } else checksummust is { b0 = b1; beupdated /* b0 is wrong */ a0 = a1; /* a0 is wrong */ c = chk(); } Matteo SONZA REORDA Politecnico di Torino 65

66 Example: hardened code int a0, a1, b0, b1, c; c = c^a0; a0 = b0+5; a1 = b1+5; c = c^a0; /* c is updated */ if(b0!=b1)/* error detection */ if(chk()==c) { b1 = b0; /* b1 is wrong */ a1 = a0; /* a1 is wrong */ } else { b0 = b1; /* b0 is wrong */ Read variables a0 = a1; /* a0 is wrong */ are checked for correctness c = chk(); } Matteo SONZA REORDA Politecnico di Torino 66

67 Example: hardened code int a0, a1, b0, b1, c; c = c^a0; a0 = b0+5; a1 = b1+5; c = c^a0; /* c is updated */ if(b0!=b1)/* error detection */ if(chk()==c) { b1 = b0; /* b1 is wrong */ a1 = a0; /* a1 is wrong */ } else The checksum is { b0 = b1; /* b0 is exploited wrong */ to identify the a0 = a1; /* a0 is wrong */ corrupted copy c = chk(); } Matteo SONZA REORDA Politecnico di Torino 67

68 Example: hardened code int a0, a1, b0, b1, c; c = c^a0; a0 = b0+5; a1 = b1+5; Correction takes c = c^a0; /* c is updated */ place if(b0!=b1)/* error detection */ if(chk()==c) { b1 = b0; /* b1 is wrong */ a1 = a0; /* a1 is wrong */ } else { b0 = b1; /* b0 is wrong */ a0 = a1; /* a0 is wrong */ c = chk(); } Matteo SONZA REORDA Politecnico di Torino 68

69 Memory overhead Data memory: Variable duplication and checksum introduce a memory overhead of about 2 Code memory: Checksum computation and updating, operation duplication and coherency checking introduce an overhead of between 2 and 3. Matteo SONZA REORDA Politecnico di Torino 69

70 Time overhead It is caused by Operation duplication Coherency checking Checksum computation and updating. It amounts to about 2.5. Matteo SONZA REORDA Politecnico di Torino 70

71 Experimental results Set of benchmark C programs Two versions: original and hardened 8051-based system Simulation-based fault injection experiments on both versions: Random SEUs in data and code memory Matteo SONZA REORDA Politecnico di Torino 71

72 Experimental results % ,48 86,81 12,71 original hardened 5 out of 1,000 0,49 0,64 0,03 Effect-less Wrong Answer Time-Out Matteo SONZA REORDA Politecnico di Torino 72

73 Conclusions Software-implemented fault tolerance is promising (at least to complement other techniques) New techniques have been developed able to Reduce development and product costs Guarantee high detection/correction capabilities. Matteo SONZA REORDA Politecnico di Torino 73

74 On-going work Improving known techniques Investigating hybrid solutions: Duplication is performed in software Consistency check is performed in hardware Validating the method on real applications. Matteo SONZA REORDA Politecnico di Torino 74

75 For more information Matteo SONZA REORDA Politecnico di Torino 75