harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tor-Einar Jarnbjo <Tor-Ei...@Jarnbjo.de>
Subject Re: [arch] VM/Classlibrary interface
Date Fri, 27 May 2005 23:01:18 GMT
Geir Magnusson Jr. wrote:

> I meant execution context.  Is there a clear boundary between code  
> thats executing in the context of the VM and code that's executing in  
> the context of the 'user' app?

Usually not, but it might be possible to emulate something similar using 
several classloaders or implement the necessary mechanisms in the 
default classloader. One similar example can be taken from Java applets. 
They are of course not allowed to load and execute native code, as the 
VM can't enforce any privilege checks on what the native code is doing, 
still though, the applet must of course be allowed to indirectly execute 
native code through the standard API, e.g. to gain allowed network 
access. In this case, the applet classes are loaded by a restricted 
classloader, which does not allow direct access to native code, while 
the standard API classes are loaded by a privileged classloader, which 
grants all privileges on "kernel" level and relies on the implementation 
of the classes to enforce the necessary security checks.

All this magic is however implemented using the mechanisms in the 
security manager and since an application must be allowed to use its own 
security manager, I don't see how it could be possible to prevent an 
application to break through such a protection either.


View raw message