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

[Helmer Krämer]

On Tue, 24 Jun 2003 17:37:20 -0400 (EDT)
Rob Gonzalez <rgonzale at wso.williams.edu> wrote:
 
> The last (and default) is to "only verify things loaded over a network".  
> Like many things in Sun's verifier documentation, this isn't actually how
> it behaves.  In fact, when you use the option "Xverify:remote" it verifies
> everything not in the default bootclasspath, regardless of whether it was
> loaded "over a network", which is as Dalibor suspected.  Grrrrr Sun. 

How would you detect whether a class was loaded via the network?

> Now, in order to implement this behavior we not only have to check that
> the classloader is the primordial classloader (which i *think* is
> trivial...just check whether class->loader == NULL)

Yep, that's right.

> but also that the file
> retrieved is from the bootclasspath, and not simply the classpath, as the
> primordial class loader loads from both. 

Why do think that the primordial classloader also searches the
classpath? Kaffe now has the AppClassLoader, which only searches
the classpath and the PrimordialClassLoader, which only searches
the bootclasspath; if the latter also searches the classpath, it
should be fixed.

> My current idea is to have the
> primordial class loader mark the classes loaded from the bootclasspath by
> setting a "trusted" flag...but I'm having trouble figuring out where
> exactly it is determined whether a class comes from the bootclasspath or
> from the classpath.

It's determined by which classloader is able to load the class.
If the AppClassLoader succeeds in loading the class, it's assumed
to come from the classpath and if the PrimordialClassLoader succeeds
it's assumed to come from the bootclasspath. 

> Question: In libraries/javalib/kaffe/lang/PrimordialClassLoader.java, am I
> right in saying that findResources() searches only the bootclasspath and
> not the classpath?

Yes.

>  If that's the case, I think it makes the above idea
> relatively easy to implement (though, at this point, I haven't messed
> around with where exactly to mark the class as trusted, so I'm not sure
> how easy it's going to be to propagate that information through the method
> calls to where the actual Class object is allocated in memory).
> 
> If anyone can think of a simpler way to do this without modifying the
> PrimordialClassLoader, give a shoutout :)

Why do you have to deal with all this stuff, anyway?
Kaffe's verify3 already contains the necessary checks
to prevent classes that were loaded from the bootclasspath
(those with class->loader==0) from being verified (depending
on the verification mode), which seems fine to me.

If you have a sample of a class whose loader is 0, but
which was loaded from the classpath, we should fix that.
Or in other words, can you give me an example of a class
whose loader is 0, but whose trusted flag is false?

Greetings,
Helmer