The paper on "Termination in language Systems" introduces the concept of the Software termination.The issue to control resource exhuation has been described in this paper.The paper points out that the two methos of software termination ie. safe thread and safe code disabling.In the early part of the paper the author describes the related work in this ield ie on the resource management.Here it gives the reference of the J_Kernel also . The naive termination cann't be practical due to cretical sections,Boundary-crossing threads and Blocking calls.Authors also gives a breif introduction of the Hardware termination before explaning the concept of software termination.In this paper the author describes the formal design and implementation of the software termination for JAVA.This software termination depends on the bytecode rewritting and class loading mechanishm.In the later part of the paper the authors explains the addressing blocking calls issues .optimization ansd three different kinds of terminations.According to the paper the Sun JDK will recover from the deadlock is to terminate JVM.Defensive security is not provided by the system defined here. At the end of the paper the authors discusses the several performances issues and describes the practical implementation of the software termination.
The paper is about termination of run time systems. The paper says that language runtime systems are very prone to buggy or malicious codes, which can abruptly end any other code, which can lead the system to an undefined state from where it cannot recover. The termination of runtime systems is used to terminate such malicious codes in a manner that it does not affect the stability of the runtime system. The paper says that languages like java with properties of static and dynamic type checking can prevent a malicious codelet from forging a reference to an arbitrary memory location and subverting the system. But this cannot be put to full use as most of the systems either run the JVM on different machine or create process like abstraction inside the JVM. The paper describes a termination system called soft termination and implements it on java. The authors claim that the soft termination is portable across languages. They say that the software termination terminates the thread and disables the code. The paper analyses several schemes for implementing soft termination. The basic idea underlying soft termination is a codelet can be used to check for the termination condition during normal course of its operation. The paper deals with the formal design of the soft termination system. The paper goes into the details of the implementation of the system on java. It also deals with performance issues, which were not very clear to me. Overall the paper was not very convincing to me. But I firmly believe that termination of runtime systems is a field, which requires lot of research, as a lot of work needs to be done in it.
A kernel-managed thread can be terminated simply by halting its execution and reclaiming its memory (a little more work is required if the thread is in the midst of a system call). This paper describes a method of terminating a user-level thread without damaging the rest of the running process. Code that has been terminated is blocked from calling new functions, and from looping, but it is not immediately destroyed. Instead, each function is allowed to reach a stopping point before it's terminated. This means that the call chain will unwind, rather than being deleted, and the enclosing process won't be left in an inconsistent state. The authors acknowledge the incompleteness of their implementation, as well as the unreasonable overhead it imposes. In principal, the design is a good one--soft termination would be useful. Still, it seems that a poorly-written (or malicious) piece of code could put the system in an inconsistent state if it simply assumed that all its function calls would return safely. It's strange that Rudys and Wallach mention malicious code in both papers, but don't really address the issue.
In this paper (the first half of Rudys' thesis), the notion of soft termination of codelets is presented. This is done using code re-writing to insert checks into the original program that ensure it's termination upon request (by throwing an exception at an appropriate point). Also, the classes of a codelet can be terminated regardless of thread of execution, in which case all threads trying to use terminated classes will receive an exception. In general, this is a system that enhances java's protection mechanism, and adds to JVMs some extra security from code that can hung the JVM alltogether. Because of the possible termination of threads, another problem arises, that of consistency of data that remain in memory possibly shared between threads, some of which might be terminated while manipulating that data. This issue is addressed on the next paper by the same author.
With the popularity of mobile code to support runtime extensibility, there are many security concerns raised in language run time systems, especially how to terminate mobile code with stability of run time systems. The paper addressed this problem by using soft termination method. The key idea of soft termination is instruct codelet to do termination condition check during its operation. A formal design for a simplified language are explained and proved to be able to terminate all programs when needed. This idea also is implemented in Java language based on class-file byte code rewriting in class loader. Every class is inserted static Boolean field to indicate whether to terminate. And in-line termination operation will check this field then decides whether to proceed or throw an exception. Performance results show reasonable overhead caused by this method. The contribution of this paper is to formalize a termination operation in a simplified language. By the framework in the formal design, they plug the termination check into Java.
This paper raises an interesting and important issue. However, I'm not convinced that their solution is ideal. The primary advantage of this approach seems to be that it does not require modifying the virtual machine. However, the performance overhead is fairly steep considering that it only addresses this one type of attack. I would be interested in seeing a performance comparison between this approach and one using hard termination, with the critical system code separated from the untrusted code. Comparison with KaffeOS and Isolates (from the Incommunicado paper) would also be useful.
In this paper, the active issue is the ability to terminate threads of codelets while still leaving the system in a stable system. To do this, "safe points" need to be determined where a thread can be safely terminated. This paper describes a mechanism which automatically determines these points in a syntactic fashion. It then inserts code at these points that checks a termination flag and throws an exception (which assumably is not catchable by the original codelet).
The soft termination mechanism discussed in this paper was decently presented. Much of the codelet-based infrastructure is similar to the J-Kernel approach, but unlike the J-Kernel paper, this paper concentrates solely on termination. Safe code disabling was not a concept I had encountered before. The code-to-code transformation theory explanation could have been more fleshed out, but at this point in the course, we are accustomed to deciphering theory. I do not have any working knowledge of JVM bytecode, yet the article was written in a way that intimate bytecode knowledge was unnecessary. Also, unlike the Gupta paper, this paper makes a point to address I/O. Like the J-Kernel paper, however, this paper glossed over JVM bytecode generation/rewriting. I would have liked to read the details, but I'm getting the sense that bytecode manipulation is common knowledge among Computer Science researchers. Details were well presented on other subtopics, though. Additionally, the paper provided a good example of what is meant by the term "semantic overloading." Another realization is that JVM bytecode is a convenient machine-level representation to experiment with.
A formal framework is given for termination transformation for language based systems (ie interpreters/vms). An example implementation is given for java and the jvm using java's code transformation tools during class loading. Processes are essentially given a flag which says 'alive' or 'dead' and the running class code is instrumented to check that flag. Instrumentation occurs at backward jumps and function calls- the goal being to be able to kill -either manually or through some automated observer- runaway code with relatively clean unwinding. Side effects with process termination are considered in the later paper on transactions.
Generated: Thu Mar 6 15:39:24 EST 2003 by mwh