1 Verifying Architecture Jaein Jeong Johnathon Jamison This presentation will probably involve audience discussion, which will create action items. Use PowerPoint to keep track of these action items during your presentation In Slide Show, click on the right mouse button Select “Meeting Minder” Select the “Action Items” tab Type in action items as they come up Click OK to dismiss this box This will automatically create an Action Item slide at the end of your presentation with your points entered.

2 Introduction Processors are more vulnerable to transient errors due to small feature size. Can detect transient errors with more stable processors and execute instructions again if an error occurs. Overhead won't be high for errors occurring rarely.

3 Introduction (Cont.) DIVA: verifies execution each individual instruction with a second, slower. Our idea: a dual-processor verification system. Proof-carrying code: A proof of safety accompanies executable code. Our idea: executable code is annotated with invariants.

4 Assumptions We assume there are no permanent errors. Thus we need not worry about invariants failing always. So, processor can work correctly if it is verified by a more stable processor.

5 Assumptions (Cont.) We assume the processor operates correctly most of the time. Therefore it is reasonable to check for errors rarely. The overhead is not problematic, for errors occur rarely.

6 System Structure Implemented as two communicating processors. The main processor executes instructions and sends the verifier all its registers. If the verifier confirms the execution, the main continues to execute instructions. Otherwise, the main processor loads the old register values and re-executes its instructions.

7 System Structure (Cont.)

8 Programming for SimpleScalar Since gcc can not handle everything, we intervene at the assembly code level. After changing the assembly code, we compile it to object code. The message passing system calls qread and qwrite are not implemented in gcc. So, we insert the syscall instruction and pass arguments by explicitly filling registers.

9 Programming for SimpleScalar (Cont.) addiu $2,$0,258 la $4,MQO subu $5,$16,4 move $6,$0 syscall Writing a message to a queue $L2: addiu $2,$0,259 la $4,MQI addu $5,$sp,16 move $6,$0 syscall bne $7,$0,$L2 Reading a message from a queue.

10 Programming interface for C Assembly language programming is error prone and unproductive. We wrote a interface for C with macros and inline assembly. Since syscall is not accessible in C, we generate a “ jal syscall ” in assembly. A Perl script replaces it with “ syscall ”. Now we can compile the assembly code without further modification.

11 Multiprocessor Program Example long regs[32]; char msg[]="\006\000\000\000cool\n"; long nullmsg[]={0}; char MQI[]="\003min"; char MQO[]="\004mout"; … qwrite(MQO,msg,0,error); do { qread(length,MQI,regs,0,error); } while(error); …

12 Passing Invariants (1 st method) The main program sends the invariant instructions as a message. We enclosed the invariant instructions with.rdata and.text directives and insert the length of the message after.rdata. Then the main can send the instructions as a message. The verifying processor then can load its registers with it, and do a jal to the message that was sent.

13 Passing Invariants (2 nd method) Generate a verifying program specific to the main program. When running the main program, just send the the contents of registers and the invariant number. The verifying processor takes the invariant number, calculates the value of the invariant, and replies.

14 Passing Invariants (Cont.) A bit of a problem for the first method. The verifying program receives invariant instructions as data. Execution of those instructions would bring up the same issues as self-modifying code. Due to pitfalls of first method, we chose the second method.

15 Using Invariants We maintain two sets of registers in the verifier for roll back purposes. Not all registers must be sent to the verifier, just those needed for the invariant or possible rollback. Currently, creating the verifier requires careful inspection of the main program We hope to automate some of this.

16 Performance For best performance, the main processor should not check for the invariant reply immediately. Rather, check when the next invariant is reached, so to give time for verification. Then the read is done, and execution is rolled back or continued as appropriate.

17 Tidbits The message passing mechanism took time to understand. We found we could use the asm directive in gcc so hand modification of assembly was minimized. We encountered a couple bugs in SimpleScalar.

18 Future Work Additional logic for floating point registers, easily extended from what we have now. Memory rollback logic; this is more substantial, for we need to retire memory writes only on invariant confirmation. A program to generate the verifying program automatically.

19 Thoughts Seems like this is an energy intensive method of verification. Invariants are not easy to generate, and must be done by hand. There is a large amount of processing overhead.

20 Summary Decreasing feature size makes verification necessary. DIVA is on attempt to address the problem. We wrote programs for SimpleScalar. This showed that we can have one processor verify another with invariants.

21 Acknowledgement Mark Whitney: –Our work is based on the SimpleScalar multiprocessing extension, written by him. –He also helped us configure SimpleScalar and fixed bugs.