1

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.