Just a clarification on terminology. The native loader in the VM is the
bootstrap loader. A class was loaded by the bootstrap loader if its
ClassLoader is reported as "null". There is then a hierarchy of
classloaders created:
- the extensions loader is used to add the ability to load standard
extensions (from lib/ext if I recall correctly) these are classes that
are treated the same as "core" classes for security purposes
- the application-class loader, aka the system classloader (bad name),
is created to load the application class that you want to run
The application can then define its own classloaders.
For a ClassLoader to actually load a class it must use defineClass,
which is implemented in the VM as part of the native loader. Hence any
subterfuge has to be done inside the VM: you need to look at the
systemDictionary and the loader_constraints, which enforce the language
rules.
I really don't know how you would go about doing what you suggest
because the details are the critical points here. You could define a
ClassLoader that returned an arbitrary Class object for a given name,
but that Class object would report it's real identity. If this was part
of an implicit classloading process, then you'd likely get a
ClassCastException, or some other exception if you actually tried to
return a different Class than required.
Good luck.
David Holmes
kammerath i. (ik3g09) said the following on 08/03/10 06:17:
Hello hotspot-runtime-dev, Hotspot-dev and core-libs-dev members,
After initial contact with core-libs-owner, I have been able to get a lot
further.
The idea is to make certain modifications to the primordial/system-ClassLoader that lower security measures to gain a certain insight into higher reload-ability. As far as I currently understand, The Primordial ClassLoader is a mixture of system specific C files and standard Java classes. I am working with the version proposed below by Iris.
When reloading an existing class I am so far forced to create a new classloader, as one classloader always has to return the same class object reference for the same class name. Meaning if I want to reload a class I always need an interface implemented by both the old and the new class-version to have a common type between both the custom and the system classloader, which allows me to access both versions of the class the same way (over a proxy pattern, to make references replaceable).
Now I want to do something that one might consider as highly insecure. I want to allow a classloader to return different class object reference for the same class name. Thus I could bypass the whole interface fiddle and simply access the new object by the same type. I am aware of the fact that this means breaking the type-system/type-safe idea. As this means that two different types are considered as one without any shared inheritance. But logically they are the same type, but simply evolved.
Where am I:
Whilst reading through ClassLoader.java I came along void addClass(Class c)
[line 258] which apperently is used by the JVM to record loaded classes, would
this be where I could interfere by simply not record classes annotated with
reloadable or something like that. Such that when checking whether a class is
already registered it simply wouldn't be, thus I could reload it (probably not).
Further along I came across getSystemClassLoader() in which I found initSystemClassLoader
which lead me to Launcher.java [sun.misc.Launcher] in which I found the top-level nested
class AppClassLoader, which I assume is the actual Primordial/System-ClassLoader. At
least it is what ClassLoader.getSystemClassLoader() returns. In it I found a call
"BootClassLoaderHook.preLoadClass(name);" is this where the C comes into play?
I couldn't find anything else in the Java sources relating to "BootClassLoaderHook". What
is this doing? Is this where I can make my insecure changes? Iris also pointed out ClassLoader.c,
might this be what's hooked in with this specific call? if it is, how is it "hooked in"?
I am open for any other suggestions in terms of: "where I could make changes" and "what changes I could make", to achieve the higher/different (even though less secure) reload ability.
Many thanks in advance
Ivo
________________________________________
From: Iris Clark [[email protected]] On Behalf Of [email protected]
[[email protected]]
Sent: 01 August 2010 03:35
To: kammerath i. (ik3g09)
Subject: RE: Research on the primordial class loader
Hi, Ivo.
I didn't receive your original message. I don't know what happened as it
isn't in the set of pending moderator requests and your message didn't seem
to make it into our archive (see the "archive link") near the top of this
page: http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev
One way to avoid the need for moderation is to become a subscriber. There
is a digest mode if you get inundated with mail. Alternatively, you could
just unsubscribe as soon as you get the information you need.
I think that core-libs-dev is a fine place to ask your question.
Alternatively hotspot-dev or hotspot-runtime-dev may also be good
candidates as that is where a great deal of heavy lifting occurs for class
loading. Here are some pointers for you to begin your investigation. I've
selected subversion files from the JDK7 tl repository, but these files will
reside in similar locations in other JDK repositories.
http://hg.openjdk.java.net/jdk7/tl/jdk/file/4d72d0ec83f5/src/share/classes/j
ava/lang/ClassLoader.java
java.lang.ClassLoader provides the specification for the delegation model
and is the primary implementation. Note that specification comments such
as this: "If the parent is "null", the class loader built-in to the
virtual machine..." and the corresponding null checks are references to
class loader implemented by the VM.
http://hg.openjdk.java.net/jdk7/tl/jdk/file/4d72d0ec83f5/src/share/native/ja
va/lang/ClassLoader.c
The supporting libraries C code for j.l.ClassLoader. This is where
libraries makes the calls into the VM.
http://hg.openjdk.java.net/jdk7/tl/hotspot/file/cb4250ef73b2/src/share/vm/cl
assfile/
I am by no means a VM expert, but I believe that this is where the VM
implements most of class loading. A VM engineer will be able to provide
more details.
http://java.sun.com/docs/books/jvms/second_edition/html/VMSpecTOC.doc.html
I'm sure you've' already found it, but just in case... The VM
specification,
Chapter 5 contains the complete spec for loading, linking, and
initializing:
Hope this gets you started. My apologies for not seeing your earlier
message.
Thanks,
iris
________________________________________
From: Ivo
Sent: 29 July 2010 17:15
To: [email protected]
Subject: Research on the primordial class loader
Hello core-libs-dev members,
In my research on dynamic continuous integration at run-time and dynamic
self-modification.
I reached a point where I would like to have a look at the implementation of
the 'Primordial ClassLoader'.
Which, according to what I read so far, is responsible for loading all
classes, excluding those loaded by any
custom ClassLaoder.
When I downloaded the OpenJDK source I felt a little lost, I could not quite
work out where to look.
As far as I understood, the Primordial ClassLoader is more than just a
bunch of Java classes.
Correct me if I am wrong, but I assume it involves a few C/C++
classes/procedures?
So my question is:
Which classes are involved in the primordial classloading and which files of
the HotSpot are involved in the process?
many thanks in advance
Ivo
