1 / 32

Bytecode Verification on Java Smart cards

This presentation explores bytecode verification on Java smart cards, discussing the role of subroutines, JSR instruction, off-card code transformations, stack normalization, register reallocation, and Chaitin's graph coloring allocator. It covers methods such as invokevirtual, return, and others, as well as optimizations like tunneling and coalescing. Different techniques to ensure correct applet verification are outlined, along with examples and transformations for code size and register efficiency.

nikkia
Download Presentation

Bytecode Verification on Java Smart cards

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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

  3. Algorithm

  4. JSR vs invoke • Methods : invokevirtual, invokenonvirtual, return, areturn, Ireturn • JSR instruction and ret instruction

  5. OffCard code Transformations • Two methods to ensure that all correct applets pass verification: • Using special Java compiler • Using a std Java Compiler and Java Card Converter (for Off-card code Transformation) and pass it to on card verifier

  6. Applet Conversion

  7. Applet Installation

  8. Architecture of the System

  9. Transformations • Stack Normalisation • Register Reallocation

  10. 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

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

  12. 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.

  13. 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

  14. Case a

  15. 1)i ->Branch Target • Case b: If the instruction before i falls thru: • Insert stores to ln..l1 • Load from l1..ln, before i

  16. Case b

  17. 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

  18. Case a

  19. 2)I ->Branch to instruction j • Case b: If instruction I can fall thru (conditional branch) • Insert after I, loads from l1…ln

  20. Case b

  21. Worst case • Example of combination of two transformations: • The instruction before i falls through • i itself falls through

  22. Worst case

  23. 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

  24. Example

  25. Tunneling optimization • Conforms to Requirement R1 • No stack Normalisation needed for this code

  26. Before Register reallocation

  27. After Register reallocation Number of registers stays constant

  28. 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

  29. After compilation and stack normalisation ->JCVM code:

  30. After coalescingsload Rtmp, sstore Rs : Short s; if (b) {s=x;} else{s=y;}

  31. Effect of offcard code transformation on code size and register

  32. Comments?

More Related