Bytecode Verification on Java Smart cards

32
Bytecode Verification on Java Smart cards Xavier Leroy Presentation(Day 2) - Nithya

description

Bytecode Verification on Java Smart cards. Xavier Leroy Presentation(Day 2) - Nithya. JSR. Subroutines -> mostly used for compiling the try-finally construct Subroutines and Sun’s Verfn algorithm Subroutines and our Verfn Algorithm JSR instruction Ret instruction Role of local variable. - PowerPoint PPT Presentation

Transcript of Bytecode Verification on Java Smart cards

Page 1: Bytecode Verification on Java Smart cards

Bytecode Verification on Java Smart cards

Xavier LeroyPresentation(Day 2)

- Nithya

Page 2: Bytecode Verification on Java Smart cards

JSR Subroutines -> mostly used for

compiling the try-finally construct Subroutines and Sun’s Verfn algorithm Subroutines and our Verfn Algorithm

JSR instruction Ret instruction Role of local variable

Page 3: Bytecode Verification on Java Smart cards

Algorithm

Page 4: Bytecode Verification on Java Smart cards

JSR vs invoke Methods : invokevirtual,

invokenonvirtual, return, areturn, Ireturn

JSR instruction and ret instruction

Page 5: Bytecode Verification on Java Smart cards

OffCard code Transformations Two methods to ensure that all

correct applets pass verification:1. Using special Java compiler2. Using a std Java Compiler and

Java Card Converter (for Off-card code Transformation) and pass it to on card verifier

Page 6: Bytecode Verification on Java Smart cards

Applet Conversion

Page 7: Bytecode Verification on Java Smart cards

Applet Installation

Page 8: Bytecode Verification on Java Smart cards

Architecture of the System

Page 9: Bytecode Verification on Java Smart cards

Transformations Stack Normalisation Register Reallocation

Page 10: Bytecode Verification on Java Smart cards

Stack Normalisation

For a branch with non-empty stack: Insert stores to fresh registers

before the branch Loads from the same registers at

the branch target

Page 11: Bytecode Verification on Java Smart cards

Example : C.m(b ? x : y);

Page 12: Bytecode Verification on Java Smart cards

Second pass of SN Case 1: if i is a branch target with

non-empty stack Case 2: if i is a branch to

instruction j and the operand stack is not empty at j.

Page 13: Bytecode Verification on Java Smart cards

1) i ->Branch Target Case a:

If instruction before i doesnt fall thru (uncndl branch/return/throw),

Insert loads from l1…ln before i Redirect the branches to the first load

thus inserted

Page 14: Bytecode Verification on Java Smart cards

Case a

Page 15: Bytecode Verification on Java Smart cards

1)i ->Branch Target Case b:

If the instruction before i falls thru: Insert stores to ln..l1 Load from l1..ln, before i

Page 16: Bytecode Verification on Java Smart cards

Case b

Page 17: Bytecode Verification on Java Smart cards

2) i ->Branch to instruction j Case a:

If instruction i does not fall through (unconditional branch):

Insert before i code to swap the top k words of the stack with the n words

Insert stores ln…l1

Page 18: Bytecode Verification on Java Smart cards

Case a

Page 19: Bytecode Verification on Java Smart cards

2)I ->Branch to instruction j Case b:

If instruction I can fall thru (conditional branch)

Insert after I, loads from l1…ln

Page 20: Bytecode Verification on Java Smart cards

Case b

Page 21: Bytecode Verification on Java Smart cards

Worst case Example of combination of two

transformations: The instruction before i falls through i itself falls through

Page 22: Bytecode Verification on Java Smart cards

Worst case

Page 23: Bytecode Verification on Java Smart cards

Tunneling optimizations Idea: reduce the number of

branches Replace branches “goto lbl” by a

direct branch to lbl Replace unconditional branches

“return” or “throw” by a copy of the return or a throw instruction itself

Page 24: Bytecode Verification on Java Smart cards

Example

Page 25: Bytecode Verification on Java Smart cards

Tunneling optimization

• Conforms to Requirement R1

• No stack Normalisation needed for this code

Page 26: Bytecode Verification on Java Smart cards

Before Register reallocation

Page 27: Bytecode Verification on Java Smart cards

After Register reallocation

Number of registers stays constant

Page 28: Bytecode Verification on Java Smart cards

Chaitin’s graph coloring allocator Compute live ranges for every register Compute principal type for every live range Build the interference graph between live

ranges Nodes -> live ranges

Add interference edges between live ranges that dont have same principal type

Coalescing: Detect reg-to-reg copies Color the interference graph:

Assign a new reg number to every live range that 2 interfering live edges have distinct reg numbers

Page 29: Bytecode Verification on Java Smart cards

After compilation and stack normalisation ->JCVM code:

Page 30: Bytecode Verification on Java Smart cards

After coalescing sload Rtmp, sstore Rs :

Short s; if (b) {s=x;} else{s=y;}

Page 31: Bytecode Verification on Java Smart cards

Effect of offcard code transformation on code size and register

Page 32: Bytecode Verification on Java Smart cards

Comments?