Instituto de Informática and Dipartimento di Automatica e Informatica Universidade Federal do Rio Grande do Sul and Politecnico di Torino Porto Alegre, Brazil and Torino, Italy DFT 2006 Washington, DC, USA Online Hardening of Programs Against SEUs and SETs Carlos Lisbôa Massimo Violante Matteo Sonza Reorda Luigi Carro

Luigi Carro DFT October 4-6, Porto Alegre Brasil Torino Italia Arlington Washington, DC USA A small world...

Luigi Carro DFT October 4-6, Hardening by hardware duplication duplicates the core processor requires additional control hardware  significant area overhead Memory PP bus PP ? error

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

Luigi Carro DFT October 4-6, A hybrid technique Memory PP abus cbus dbus Extra data and code requires modification of the software reduced memory overhead reduced performance overhead I-IP error

Luigi Carro DFT October 4-6, Outline Proposed approach The I-IP Design flow Experimental results Conclusions and future work

Luigi Carro DFT October 4-6, 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

Luigi Carro DFT October 4-6, Overall architecture PP abus cbus dbus I-IP error IRQ abus cbus dbus Code Memory

Luigi Carro DFT October 4-6, 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 Instruction hardening

Luigi Carro DFT October 4-6, PP abus cbus dbus I-IP error IRQ abus cbus dbus Code Memory 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

Luigi Carro DFT October 4-6, 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 Consistency check

Luigi Carro DFT October 4-6, Note: offset = size of the instruction Control flow check memory transfer, data processing and I/O instructions A next = A + offset branch instructions taken: A taken = branch destination not taken: A next = A + offset

Luigi Carro DFT October 4-6, Outline Proposed approach The I-IP Design flow Experimental results Conclusions and future work

Luigi Carro DFT October 4-6, Architecture of the I-IP CPU interface Memory interface Fetch logic Decode logic ALU Control Unit abusdbuscbus abusdbuscbusIRQ

Luigi Carro DFT October 4-6, 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

Luigi Carro DFT October 4-6, Outline Proposed approach Assumptions Overall architecture The I-IP Design flow Experimental results Conclusions and future work

Luigi Carro DFT October 4-6, Design Flow Binary code Disassembler Instruction mix I-IP generator I-IP VHDL model Constraints

Luigi Carro DFT October 4-6, Outline Proposed approach Assumptions Overall architecture The I-IP Design flow Experimental results Conclusions and future work

Luigi Carro DFT October 4-6, Attained experimental results (using an Intel 8051 compatible SoC) (*) related to original SoC area (core processor + memory, without I-IP) = 52,343  m²

Luigi Carro DFT October 4-6, Outline Proposed approach Assumptions Overall architecture The I-IP Design flow Experimental results Conclusions and future work

Luigi Carro DFT October 4-6, 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

Luigi Carro DFT October 4-6, 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)

Luigi Carro DFT October 4-6, Questions ? Contact: Thank You !

Luigi Carro DFT October 4-6, I have some questions: Anybody going to Dulles Friday evening? Willing to share a cab?

Luigi Carro DFT October 4-6, original instruction: 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 FETCH_ADX:opcode dst, src1, src2 source operands and result fetching