Verifying Architecture

1. 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. Verifying Architecture Jaein Jeong Johnathon Jamison

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 syscallWriting a message to a queue • $L2: addiu $2,$0,259 la $4,MQI addu $5,$sp,16 move $6,$0 syscall bne $7,$0,$L2Reading 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 (1st 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 (2nd 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.