[kaffe] bytecode verifier

[Dalibor Topic]

Hi Robert,

--- gonzo <Robert.N.Gonzalez@williams.edu> wrote:
> btw - what does the "notyet" mean (code-analyse.h)? 
> there are a couple of
> source files in the project that have "#if
> defined(notyet)", though i
> can't find anywhere where it would potentially be
> defined.  is this
> kaffe-specific notation?  (ie - put #if
> defined(notyet)" around code that
> you don't want to use yet?)
 
It was before my time ;) But your intuition seems
resonable to me.
 
> > I'd like to cite from the cvs log for the
> pocketlinux
> > kaffe code-analyse2.c file:
> > * Major reworking of verifier:
> > 	1. Removed code-analyse.c which didn't really do
> > anything useful
> > 
> > so a merge with that code might be interesting.
> 
> i looked into this, and although one of the CVS
> notes mentioned that
> code-analyse.c was removed, development seemed to
> continued on it for
> months afterwards.  i haven't looked into it much
> beyond that, but it
> makes me a little suspicious about that particular
> commit.

Nope. If you look at the file's CVS log in the attic,
you'll se that the last check in was on June 18th,
with the above message. That message is also present
in the cvs log for code-analyse2.c, which has been
developed further. I assume that they started with
code-analyse2.c after code-analyse.c, developped both
in parallel, and ended up merging the good portions of
the original into the new version.

References:
http://www.pocketlinux.com/viewcvs/kaffe/kaffe/kaffevm/Attic/code-analyse.c
http://www.pocketlinux.com/viewcvs/kaffe/kaffe/kaffevm/code-analyse2.c

> to potentially save me some time, does anyone know
> about the state of the
> pocketlinux verifier off the top of your head?  if
> not, then i can go bug
> their developers :)

You can try the mailing lists, or the IRC channel
#pocketlinux on opennet. there is also #kaffe, but it
is kind of silent ;) You'll find me on both if you're
lucky.

> > On the other hand, there is a patch that adds full
> > bytecode verification for kaffe 1.0.6:
> > 
> >
>
http://www.kaffe.org/pipermail/kaffe/2001-August/007391.html
> 
> i spent some time this morning looking at this, and
> porting the patch to
> version 1.0.7 won't be too difficult at all. i'll
> get back to you
> regarding its completenss once i've had time to test
> it out.

Thanks for looking at it. I'm looking forward to your
input on it. You might want to get in touch with the
authors, too, and see what they can say about it.

> > As you are most likely to call the verifier API
> from
> > ClassLoader.defineClass(byte [], int off, int
> len),
> > the natural choice for the verifier method is
> > verify(byte [] code, int off, int len). then you'd
> > have to write a VerifierManager, that essentially
> has
> > a single static method returning the current
> (system
> > property kaffe.verifier) verifier, and a class for
> > each verifier that manages argument passing. It
> should
> > be about a week of work altogether to get it into
> a
> > releasable form.
> 
> are you sure about this?  according to the JVM
> specs, verification
> occurs at link time, which means that the API would
> be called from
> classMethod.'s processClass(). i want to make sure
> i'm putting the calls
> in the right place before investing too much effort
> in the verification
> layer.

Thanks for catching my mistake. I though that
defineClass was most convenient because the bytecode
was there, after all. It turns out that the VM spec
talks about verification during linking, so it should
be ClassLoader.resolveClass, if you want to put the
hooks in the class loader code, or classMethod.c's
processClass, if you want to put it there. 

I'm not exactly sure which one is preferable: putting
it as an afterstep of linking in resolveClass would be
easier to program as you avoid messing with JNI, but
the inconvenience of access to class byte code is
ugly: I think that you'd need to reload the class
resource in order to get the byte code, or to cache
bytecodes for loaded classes until they are verified.
You don't really want to reload anyway. It leaves you
open to attacks on classes loaded over networks, where
people would send you a malicious class on the first
attemt to load its byte codes, and send you a
sanitized version on the second attemt to load it for
the verifier. So I'd advocate temporary bytecode
caching in that case. Just release the class from the
cache once the veriifer is done with it, and make sure
that defineClass populates the cache when new classes
are defined.

The other option would be to put the hooks in
classMethod, which has the advantage that the
infrastructure is there already, but if you wanted to
use it for the verifier API, you'd end up calling java
code from native code, with the java code eventually
calling native code again. It might be harder for
debugging ;)

If you decide to put the hooks in the library code,
then you should make sure that kaffe's verify
functions don't play nasty optimization tricks with
the bytecode, like annotating it for the JIT. That
information would not be generated if you just used an
external verifier :( I'm just presenting assumptions
here, as I'm not really familliar with the code.

So there is a performance hit for now if you put the
hooks in library code: you might end up verifying the
same code twice (that can be fixed easily for the
internal verifier, though, if the verifier sets a flag
saying how far it got).

> btw - dalibor, thanks a bunch for getting back to me
> with so much info.
> i'm pretty excited to get to work with you guys on
> this :)

I hope some of it was useful ... I have a ClassLoader
patch in the queue [1] that I'd like to check in
tonight, and then you can hack as you please ;)

best regards,

dalibor topic

[1] http://www.kaffe.org/pipermail/kaffe/2002-June/008252.html

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com