CMSC 838Y Paper Reviews

Skip down to paper 0: C. Hawblitzel, C.-C. Chang, G. Czajkowski, D. Hu, and T. von Eicken. Implementing multiple protection domains in Java. In 1998 USENIX Annual Technical Conference, pages 259-270, New Orleans, LA, 1998. [ .html ]


Reviews for paper 0

Review from Prashant Lamba<plamba@wam.umd.edu> at Mon Mar 10 15:40:35 EST 2003:

This paper explains the J-kernel which is a java based protection system.This 
paper explores the use of safe language technologies for high performance and 
to construct robust protection domains.In the begning of the paper author 
explains the how java provides the basic mechanism for controlling namespaces, 
through Selective sharing of the reference ,Static acess control and Selective 
class sharing.In the following section the authors explain the straightforward
implementation of protection with safe language environment using the object 
references as capabilities. and points out the drawbacks and limitations of 
this sytem.
In the later part of the paper authors explains the implemantation of the 
J-Kernale system,which overcomes the drawbacks of the straightforward 
system.This implementation heavily depands on java interfaces. It uses Sun's 
RMI specifications.There are some drawbacks of this systme too .such as 
increase in the overhead.But this can be solved with the improvement of the 
JVM.In the end of the paper the authors describes the http server.

Review from Piyush Bhagat <piyushb@glue.umd.edu> at Mon Mar 10 18:41:18 EST 2003:

The paper is about implementing multiple protection domains around different 
components. In the paper this has been implemented in java. The paper says that 
with the increase in the adoption of extensible and component based software 
systems the inter process communication overhead has also grown. This has lead 
to a point where a balance between performance and robustness has to be 
achieved, as both are important for a safe and fast software system. The paper 
provides a way for multiple protection domains through java, which is a type 
safe language with controlled linking. The paper claims that in implementing 
protection domains it relies purely on the language and not the hardware. In a 
type safe language like java the environment calls across the boundaries are as 
cheap as function calls thus removing the communication overhead. The main 
principle underlying multiple protection domains is the usage of linker to 
create multiple namespaces and to use object references for cross-domain 
communication. Thus namespace control is very important and java uses three 
mechanisms for this. The paper argues that it is impossible to define precisely 
the multiple domains in straightforward approach i.e. the approach that just 
uses namespace control provided by java. The paper also talks about problems 
associated with inter-domain dependencies, domain termination and threads. The 
paper finally talks about the implementation giving out the primary goals and 
overheads incurred. Performance issue is also dealt with which to me was not 
clear. The language of the paper was also not upto a standard. I think that 
language based protection systems have certain draw backs but the future 
belongs to them.    

Review from Bryan Payne <bdpayne@cs> at Mon Mar 10 21:15:54 EST 2003:

J-Kernel provides for a safe way to use extensible programs.  This idea has a 
variety of very interesting applications ranging from mobile code to extensible 
services, such as the web server discussed in the paper.  It addresses an 
important area and I felt that the beginning of the paper provided good 
motivation for this work (i.e., the discussion about the growing use of shared 
process space).

The implementation is interesting in its simplicity.  Since Java is already a 
type-safe language, there was only minimal work required to achieve the 
required functionality, especially using the capability-based approach.  The 
downside is that, while performance may be better than diverting IPC through 
the kernel, it is still slow enough to potentially be troublesome.  This is 
made clear when the authors stated that "The J-Kernel null LRMI takes 60x to 
180x longer than a regular method invocation".  So, as usual, developers will 
need to decide if the safety / security is worth the added cost.


Review from Polyvios Pratikakis <polyvios@cs> at Tue Mar 11 07:15:50 EST 2003:

This paper presents J-Kernel, an java library that implements a 
domain-protection system for java programs, providing automatic support for 
"address space"-like executions of applets, servlets or codelets in general.
It is different because it concentrates on specific control on shared objects, 
and does not use the "object sharing" provided by object-orientation. It 
supports revoking of sharing, which is not supported by java as is, it 
addresses threading (although in a primitive way), and domain termination.
J-Kernel uses code re-writing at run time, to generate the stubs necessary to 
interface each shared object (called "capability"), in a sharing domain. In a 
way, it resembles rmi, corba or com (even has some kind of a "naming service"), 
except that it is not distributed, and it targets control of object-sharing 
within a single JVM.

Review from Nathaniel Waisbrot <waisbrot@cs> at Tue Mar 11 10:25:59 EST 2003:

	J-Kernel attempts to provide some of the benefits of separate threads, without 
the overhead of context-switching.  The programmer defines domains, which mimic 
threads.  Objects which are passed between domains must first be wrapped inside 
a capability class, which give a domain greater control over its objects, and 
allows all the objects in a domain to be destroyed when the domain is 
destroyed, even if the capabilities are being used by another domain when it 
happens.
	Since all the domains run in the same thread, it seems reasonable that copying 
objects and calling methods will be cheaper.  However, the benchmarks cited in 
the paper don't ever show the speed differences between a J-Kernel application, 
and a threads application, so there isn't any way to tell if J-Kernel is 
actually any improvement.  Details about how J-Kernel provides the equivalent 
of thread protection were sparse, and they seemed to hint in the conclusion 
that J-Kernel was too slow.

Review from Mujtaba Ali <mujtaba@bitsmart.com> at Tue Mar 11 11:51:23 EST 2003:

Previous papers have highlighted several trends in the Computer Science 
research community, e.g. using domain-specific input to circumvent previously 
hard problems (e.g., in dynamic updating and dynamic compilation).  This paper 
highlighted another concern, which was also seen in SPIN - how to maintain 
safety, yet avoid crossing the user/kernel boundary.  Another not-so-glamorous 
trend this paper adopts is (ab)use of term "domain", but I digress.  
Unfortunately, this paper was more of a technical overview than a detailed 
technical paper.  

The authors were honest about some of the drawbacks.  The major drawback is the 
extreme dependence on Java language features not only for the J-Kernel 
implementation, but also for the J-Kernel design.  Security issues were 
presented and thoroughly discussed many times in this paper.  I particularly 
enjoyed the example of a malicious user overwriting legal bytecode that had 
already passed class loader verification.  Any paper stressing security should 
also comment on reducing the TCB, and this paper failed in this regard.  This 
paper made clear that the straight-forward approach did not properly 
distinguish between shared and non-shared objects.  Furthermore, domain 
termination was explained very well, which was a relief since I had no idea 
what was meant by termination when reading the title of the other paper.  
Another positive aspect of this paper was the methodology: implement a naive 
approach and if the naive approach is close enough to what you want, patch it 
up a little.  The J-Kernel implementation made innovative (re)use of Java RMI 
concepts and I finally understood how the Remote interface is really just an 
annotation.

The problems with the straight-forward revocation approach mentioned in Section 
2.1 can be resolved.  First, and unrelated to the mentioned issues, the wrapper 
classes require synchronization to ensure atomicity and visibility.  Second, 
wrappers can be implemented using aspect-oriented programming.  To be fair, 
though, AspectJ was not very mature in 1998 when this paper was published.  
Third, wrapped classes can be made package-level and thus inaccessible to any 
class outside their package.  Ideally, the only publicly accessible class in 
the package would be the wrapper class.  The authors present a good counter 
argument.  No matter how elaborately the straight-forward revocation approach 
is implemented, the straight-forward approach is opposite of the desired, 
safe-by-default model.  Still, the approach I propose above is valid if 
performance is a concern, the whole system is trusted, and revocation is the 
only feature of J-Kernel that concerns the client.  

The copy (call-by-value) semantics introduced by J-Kernel negatively affect 
performance.  Furthermore, the fast copy mechanism is not discussed in enough 
technical detail.  Also, even with J-Kernel, cross-domain calls still block and 
therefore the problem is not completely resolved   I was also looking forward 
to reading some technical details regarding J-Kernel bytecode generation, but 
such details were nowhere to be found.

The most disappointing aspect of the paper, however, was the short section 
describing resolvers and shared classes.  These concepts were explained very 
poorly, especially considering that the paper cited shared classes as "the 
basis for cross-domain communication."

Another alarming issue with this paper was the repeated use of unqualified 
statements.  In addition to the meaningless benchmark comparison in Table 6, 
other examples include:

"Given that the implementations of the three operations are independent, one 
could hope for significantly better performance in a system that includes the 
best of both VMs."

"Additional measurements show that the ISAPI bridge accounts for about half of 
that performance gap..."



Review from yuanyuan@cs at Tue Mar 11 11:58:56 EST 2003:

J-Kernel is a capability-based system that use language-enforced protection 
mechanism to achieve portability and better cross-domain performance. It 
provides a fine protection structure to specify capability of access object and 
solve the problems caused by using object references directly as capabilities. 
The key idea here is to implement a Capability class in Java. Any target object 
defines an interface that can be invoked by invoking object. Invoking object 
generates a Capability object that act as a wrapper object for target object to 
provide cross-domain call. 

When an object want to access a target object by calling Capability.creat 
method, a local stub class will be generated at run-time to switch domains, 
copy arguments, support revocation and protect threads. Also with the J-Kernel 
domain, a better protection structure is provided to solve the problem caused 
by traditional systems. The performance results show a much lower cross-domain 
call cost by scheme used by J-Kernel. 

The idea in this paper is valuable; it makes use of the inherent protection 
mechanisms of language, and then introduces additional structure, (Capability 
and Domain class) to fix the problems incurred by original approach (sharing 
anything).


Review from Jeff Odom <jodom@cs.umd.edu> at Tue Mar 11 12:08:55 EST 2003:

The major idea of this paper is the idea of automatically wrapping objects that 
are to be shared between protection domains with a wrapper object that prevents 
access to the original if that original object has been revoked.  Additionally, 
these wrapper objects provide virtual thread switching between caller and 
callee.  This idea solves several problems.  First is the ability to revoke an 
object - that is, to allow the owner of an object to "take back" references to 
that object that have been given out to other domains.  This automatically 
handles the problem of accessing objects that are "owned" by a terminated 
domain.  Once the domain is terminated, the wrapper object will no longer allow 
access to the object, and the last reference to the object (by the wrapper) is 
removed, allowing the garbage collector to reclaim the object.  Lastly, by 
separating threads, the caller can no longer affect the execution of the 
callee's thread (perhaps stopping it in a critical section where resources are 
held), although the converse is not true (a caller will still block until the 
callee returns).

Review from Brian Krznarich <bjkrz@cs> at Tue Mar 11 12:24:35 EST 2003:

Nice system which builds protection domains around Capabilities in java.  
Code rewriting is used to enforce proper use of capabilities- for instance non-
capability objects passed between domains are made pass by value (either 
through 
java serialization or special fastcopy code implemented by the class).  The
system enforces safe defaults and allows for a capability creator to revoke it
immediately- the revocation is handled as an acception by the revokee.  
Performance
penalties are large where serialization is used, but with classes using 
fastcopy
the performance penalty is asserted to be pretty low.  There was one piece
talkin g about a domain respository which used user named string domain names-
Seems there should be some more dynamic method to avoid collisions.   


Generated: Thu Mar 6 15:39:24 EST 2003 by mwh


mwh@cs.umd.edu