Research into modifications on the primordial class loader

Mon Aug 2 23:44:35 UTC 2010

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 [iris at agathis.com] On Behalf Of irisg at alum.mit.edu [irisg at alum.mit.edu]
> 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: core-libs-dev at openjdk.java.net
> 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