mateli
commented
9 years ago Unfortunately the only example in Java is the old Stanford project I linked to. There are the Google Native client and I also believe that MoonLight use similar technology, but that's not Java-based.
As it rewrites code it can be used to isolate anything from a single class to a whole application. It could be possible to implement process isolation coupled with some very fast zero-copy IPC using similar technology, basically making a Java-based OS with nested containers.
Modern X86 processors usually are RISC processors running "microcode" and do binary translation similar to this. I imagine that most of what "hardware visualization" does are actually done by inserting code during binary translation. We need hardware-level isolation because programmers cannot be trusted to write flawless shared-memory cooperative multitasking applications. However I think that "hardware-level isolation" actually are code transformation combined with some hardware to speed up address translation and similar tasks. However in Java address translation are easy because the JVM handles all memory access.
Now I'm rambling a bit of topic but my point is that using a library like ASM any level of visualization/sandboxing can be achieved, by rewriting the code to isolate itself.
I brought up the Quasar library because it implements effective pseudo-threading this way, by modifying code to hand over execution cooperatively it can remove the cost of preemptive task switching while still be as reliable.
Den 2015-04-26 16:00, hrj skrev:
@mateli https://github.com/mateli I am very interested in the note you added to the wiki, about AOT code verification. Please comment here if you know of a practical example / guide to get that done for a project like gngr.
However, I am removing the added section from the wiki, as that page is about App-sandboxing (isolating the application from the rest of the system).
For reference, the removed section is copied below:
AOT code verifiction (like NaCl)This means that Java Bytecode is recompiled into Java Bytecode while verifying that it does nothing nasty. The quasar fiber library does this using the ADM library in order to enforce cooperative multitasking (fibers). It appears Stanford researched this ages ago (theory.stanford.edu/~jcm/software/bytecode.html).
There are two benefits with this method. First of all it checks/modifies the code before runtime therefore not significantly impacting runtime performance. Call to "unsafe" code outside the sandbox can be redirected to code that is designed to be safe, or flat out replaced with code that throws a security exception. This will likely be faster than the standard Java Sandbox where it is the responsibility of a called method to check the callers security context, also it's probably safer as new Java functions that haven't been white-listed will be unavailable. Secondly it doesn't require any hardware features, which VirtualBOX or lxc-like containers do.
Additionally this could be implemented as an extension to the Quasar library which also brings in fast multitasking capabilities.
— Reply to this email directly or view it on GitHub https://github.com/UprootLabs/gngr/issues/107.
@mateli I am very interested in the note you added to the wiki, about AOT code verification. Please comment here if you know of a practical example / guide to get that done for a project like gngr.
However, I am removing the added section from the wiki, as that page is about App-sandboxing (isolating the application from the rest of the system).
For reference, the removed section is copied below:
AOT code verifiction (like NaCl)
This means that Java Bytecode is recompiled into Java Bytecode while verifying that it does nothing nasty. The quasar fiber library does this using the ADM library in order to enforce cooperative multitasking (fibers). It appears Stanford researched this ages ago (theory.stanford.edu/~jcm/software/bytecode.html).
There are two benefits with this method. First of all it checks/modifies the code before runtime therefore not significantly impacting runtime performance. Call to "unsafe" code outside the sandbox can be redirected to code that is designed to be safe, or flat out replaced with code that throws a security exception. This will likely be faster than the standard Java Sandbox where it is the responsibility of a called method to check the callers security context, also it's probably safer as new Java functions that haven't been white-listed will be unavailable. Secondly it doesn't require any hardware features, which VirtualBOX or lxc-like containers do.
Additionally this could be implemented as an extension to the Quasar library which also brings in fast multitasking capabilities.