[kaffe] verifyMode, obsolete flags, a man page patch, and trusted code

[Dalibor Topic]

Hi Rob,

--- Rob Gonzalez <rgonzale at wso.williams.edu> wrote:
> hi everyone,
> 
> I'm currently redoing a few sections of my verifier and adding support for
> subroutine verification (the one major thing that has been lacking from my
> verifier implementation this whole time...so my verifier has never been
> able to check any classes with try-finally clauses), but have a couple
> questions that'll help me get it be ready for sharing.

cool, good to hear you're back!

> In the method verify3() in kaffe/kaffevm/verify.c, a quick check is made
> to see whether verifyMode = 0 and, if so, no verification is performed.
> 
> In kaffe/kaffe/main.c, flags are processed.  According to the kaffe man
> page, -noverify (which sets verifyMode to 0) is the only option that can
> change the way verification is done.  However, main.c also accepts -verify
> (setting verifyMode to 3) and -verifyremote (setting it to 2).  In
> kaffe/kaffevm/jni.c, verifyMode is set to 0 (no verification) by default.
> 
> I cannot find documentation anywhere as to what -verifyremote really
> means.  If this option is obsolete, it should probably be removed from
> main.c's option() method.  Otherwise, I need to know what -verifyremote is
> supposed to do.

I assume that the command line options were modelled after those from Sun's
java 1.1. See the bit about byte code verification on
http://developer.java.sun.com/developer/onlineTraining/Security/Fundamentals/Security.html

> Also, documentation for -verify should probably be included in kaffe's man
> page.  It doesn't make sense to remove this option because, currently, not
> verifying anything is the default, so there should be a way to turn it on
> :)  I've included a patch that adds documentation for -verify to the man
> page.

Thanks, I'll check it in. 
 
> I also have a question regarding the verification of trusted libraries.  
> I know that kaffe now has support for -bootclasspath.  Should the
> verifier, to save time, not verify any classes that are found in the
> -bootclasspath?  Or should it ignore standard library classes to save time
> and, if so, how would it determine which classes are standard library and
> which are not?  At the moment my verifier checks that the first few
> characters of the class being verified are "kaffe/" or "java/" and that
> its loader is the default loader, but I'm not convinced this is 100% safe.  
> Any thoughts would be appreciated.

I'd say it should do as jdk 1.2 does, and skip classes loaded from the
bootclasspath, unless explicitely requested to verify everything. you could use
CodeSource attribute of a class to see where it was loaded from, or check if
its class loader is the primordial classloader.

cheers,
dalibor topic

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com