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.
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.
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.
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.
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.
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..."
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).
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).
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