cs205: engineering software?
20 September 2010
What is bad about the jsr instruction?
How can the bytecode verifier make claims about infinitely many possible paths of a Java program?
(from the Java Virtual Machine Specification:)Must security enforcement in Java be divided between the bytecode verifier and reference monitor?
jsr [branchbyte1] [branchbyte2]
Operand Stack: ... ==> ..., address
The address of the opcode of the instruction immediately following this jsr instruction is pushed onto the operand stack as a value of type returnAddress. The unsigned branchbyte1 and branchbyte2 are used to construct a signed 16-bit offset, where the offset is (branchbyte1 << 8) | branchbyte2. Execution proceeds at that offset from the address of this jsr instruction. The target address must be that of an opcode of an instruction within the method that contains this jsr instruction.
The jsr instruction is used with the ret instruction in the implementation of the finally clauses of the Java programming language. Note that jsr pushes the address onto the operand stack and ret gets it out of a local variable. This asymmetry is intentional.
What are the vulnerabilities in the Java security approach?