[Aegisvm-devel] Future plan for Aegis VM

[Philip F. <pw...@cs...>]

Hi

Someone asked a while ago about what the longer-term goal for the 
Aegis VM project is.  Therefore I think it might be good to outline 
how I would envision the future course of the project.  Of course, 
your input is always welcome.

Once upon a time, there were a number of very well crafted Java virtual
machines, Kaffe VM, Sable VM, IBM VM, etc.  Some of them had nice
performance, the others were research platforms for performance research.
To them, performance is the big thing.

But then performance is not the only thing in the world.  All these
VM shares a fundamental architectural constraint: the primary 
protection mechanism, that bytecode verifier, is hard coded into
the VM.  Users are forced to live with one, non-optimal, protection
mechanism.  There are all these nice research on programming
language security, but none of them can be implemented on a Java
platform because of this fundamental architectural constraint.

It is this niche the Aegis VM tries to fill.  As an enabling
technology, the Proof Linking architecture of the Aegis VM will
allow users to custom build a language protection mechanism that
best fits the problem at hand.  This will make it possible for
programming language researchers to experiment on a realistic
platform with new protection mechanisms that are based on 
static analysis.  I would coin the term "pluggable verification
modules" to refer to such custom-built static analyzers that
could easily be integrated into the dynamic linking process of
a JVM.  My hope is that, our effort will set a new standard of 
how secure mobile code environments are built.

But to make this a reality, the Aegis VM cannot be just a toy
project.  It has to be a realistic mobile code execution platform.
This means our goal is not just to create an idealized VM stripped
of all interesting features of a production JVM, but instead we 
have to embrace the full complexity of both the Java language 
and its execution platform.  I believe that realism brings the most
interesting research.  And realism comes from making the Aegis
VM a useful and practical Java platform.

And this is where we are standing: our work will contribute to the
realism of the Aegis VM, making it a credible Java platform that
offers the benefit of pluggable verification modules.

But how realistic is realistic?  How much work do we need to put in
before the Aegis VM can be considered realistic?  Fortunately, 
the amount of work turns out to be quite tractable.  If you are like 
Pete, who has actually done some coding in the VM core, you will 
notice that the VM itself is quite tractable.  The problem is in 
the class library. That is why we will integrate our VM with the 
GNU Classpath class library, saving us years of work.  In addition,
the license of GNU Classpath is compatible with our licensing 
strategy: it allows the use of the library in commercial products, 
and it works with LGPL.

Does it mean we are locked into Classpath?  No.  We will integrate
Classpath in a way different from what the Classpath authors
expected.  We will actually provide our own version of classes
that requires internal support from the VM.  We call these
built-in classes.  In that way, our VM is more or less independent
of the choice of the class library.  The number of built-in classes
is very small.  Check out the list at the end of the FEATURE file
for the candidates.

So, what will happen in the immediate future?  Release 0.1.0 will
inaugurate the 0.1.x development cycle.  There are two goals to
this release:

  (1) To make Aegis VM more hackable.  This involves a lot of
      refactoring, restructuring, and internal documentation.
  (2) To make Aegis VM more useable.  This involves, for example,
      a preliminary integration with Classpath, which in turn involves,
      for example, implementing the dynamic binding of native 
      libraries.

There are actually a number of tasks in (2) that I would like you guys
to help me with.  The more urgent ones are listed below:
- floating point arithmetics (Pete has almost completed it, so this will
  very likely go into 0.1.0)
- support for the jsr/ret instructions
- more support for the JNI interface 

If you are interested in any of the above, or if there are some other
tasks in the TODO list you would like work on, let me know.

I am almost done with restructuring (i.e. item (1)).  When that is
done, I'll tag the code base, and send you guys the CVS tag.

Hope this very long email gives you an idea of where we are heading.

Philip

*  Philip W. L. Fong
*  School of Computing Science
*  Simon Fraser University, Burnaby, B.C., Canada V5A 1S6
*  pw...@cs...  
*  http://www.cs.sfu.ca/~pwfong/
*  (604)719-2333