Re: verify.c

[Guy Laden <guy@math.tau.ac.il>]

Hi,

> > On the face of it this seems wrong: a 'ret' can return multiple
> > levels (cf. the VM spec, 4.8.2 last item). Some tests with
> > Sun's verifier show this to indeed be the case.
> 
> The comment is probably wrong according to the spec.  The real question
> through is:  Is it ever useful to have code that returns multiple
> level?  Does any compiler generate it?

I doubt any Java compiler generates such code. But given that
many languages, some esoteric, are now compiled to bytecode - who
knows... 

> And also:  Is the code wrong, or just the comment?  Does it reject
> valid code or accept invalid code?  And in a way that matters - as
> in generated by an existing compiler or obfuscator, or that it
> allows an exploitable security hole.

My understanding of the commment is that valid code such as the 
following would be rejected.

	jsr L1
	return
L1:	astore 1
	jsr L2
	; code here won't be reached
	...
L2:	astore v2
	ret 1		; returns to 'return' statement above
			; ie: 'skip' a level

This cant be a security problem since it just rejects otherwise 
valid code. Its an interesting question about obfuscators. Given
that jsr/rets are a common problem for verifiers I'd think an
obfuscator which messed with them too much would probably cause 
code not to verify on many vm's.

> The handling of subroutines is the trickiest part of the verifier.
> It took me quite a bit of work to get it to the current state.

I am working on bytecode analysis where I assume the bytecode is
already verified. Even in this simpler context, subroutines cause a 
major headache- building a CFG becomes non trivial.

Cheers,
Guy