Online Hardening of Programs Against SEUs and SETs

1. Online Hardening of Programs Against SEUs and SETs Carlos Lisbôa Massimo Violante Matteo Sonza Reorda Luigi Carro

2. A small world ... Torino Italia Arlington Washington, DC USA Porto Alegre Brasil

3. P Memory ? bus error P Hardening by hardware duplication • duplicates the core processor • requires additional control hardware •  significant area overhead

4. SIHFT: software-implemented hardware fault tolerance cbus Memory P abus dbus Extra data and code • requires modification of the software • duplication of variables • error detection codes • extra instructions to process them •  memory + performance overhead

5. A hybrid technique cbus Memory P abus dbus Extra data and code I-IP error • requires modification of the software • reduced memory overhead • reduced performance overhead

6. Outline • Proposed approach • The I-IP • Design flow • Experimental results • Conclusions and future work

7. Proposed approach • non-intrusive IP core added to SoC • allows hardware and software transparency • no need to modify the source code of the application (which sometimes is not available) • no need to modify the core processor (which sometimes is not available) • the I-IP performs instruction hardening, consistency and control flow checks • scalable technique, with area and performance tradeoffs adjustable at design time

8. Overall architecture error Code Memory abus abus cbus cbus P dbus I - IP dbus IRQ IRQ

9. Instruction hardening • the I-IP intercepts instructions fetched from memory by the core processor • if the instruction is to be hardened (this is a design time option), it is replaced by a sequence of instructions • this sequence is sent to the processor by the I-IP instead of the instruction originally fetched from the application

10. error Code Memory abus abus cbus cbus P dbus I - IP dbus IRQ IRQ Instruction hardening store I-IP-adx, src1 store I-IP-adx, src2 opcode dst, src1, src2 store I-IP-adx, dst branch FETCH_ADX+offset opcode dst, src1, src2

11. Consistency check • the sequence of instructions provides the operand and result values for the I-IP • the I-IP executes the same operation in parallel with the core processor • the consistency of the result produced by the core processor is checked by the I-IP against its own result • in case of mismatch, an error signal is activated

12. Control flow check • memory transfer, data processing and I/O instructions Anext = A + offset Note: offset = size of the instruction • branch instructions taken: Ataken = branch destination not taken: Anext = A + offset

13. Outline • Proposed approach • The I-IP • Design flow • Experimental results • Conclusions and future work

14. IRQ abus dbus cbus CPU interface ALU Control Unit IRQ Fetch logic Decode logic Memory interface abus dbus cbus Architecture of the I-IP

15. Assumptions • the target system is a SoC with a processor core running a dedicated application • the I-IP is inserted in the SoC chip between the program memory and the core processor • there is no instruction cache, or it can be disabled • instruction and data memories hardened by suitable EDAC

16. Outline • Proposed approach • Assumptions • Overall architecture • The I-IP • Design flow • Experimental results • Conclusions and future work

17. Binary code Constraints Disassembler I-IP generator Instruction mix I-IP VHDL model Design Flow

18. Outline • Proposed approach • Assumptions • Overall architecture • The I-IP • Design flow • Experimental results • Conclusions and future work

19. Attained experimental results(using an Intel 8051 compatible SoC) (*) related to original SoC area (core processor + memory, without I-IP) = 52,343 m²

20. Outline • Proposed approach • Assumptions • Overall architecture • The I-IP • Design flow • Experimental results • Conclusions and future work

21. Conclusions • the proposed technique is non intrusive, and requires no change in the core processor IP • it does not introduce any memory overhead in the hardened system • since no change in the application source code is required, source code is not necessary • selection of instructions to be hardened allows to trade cost x reliability  scalability

22. Future Work • hardware implementation of the I-IP to evaluate the area overhead it introduces • extension of the technique to allow the use of the core processor’s cache memory • use of application profiling to detect optimal mix of instructions to be hardened • improve the technique aiming to achieve better performance (lower overhead)

23. Thank You ! Questions ? Contact: carro@inf.ufrgs.br

24. I have some questions: • Anybody going to Dulles Friday evening? • Willing to share a cab?

25. Instruction hardening • original instruction: • FETCH_ADX: opcode dst, src1, src2 • source operands and result fetching • store I-IP-adx, src1 • store I-IP-adx, src2 • opcode dst, src1, src2 • store I-IP-adx, dst • branch FETCH_ADX+offset