AOT code verification

[hrj]

@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.

[mateli]

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
#107.