CMSC 838Y Paper Reviews

Skip down to paper 0: Algis Rudys, John Clements, and Dan S. Wallach. Termination in language-based systems. In Network and Distributed Systems Security Symposium, 2001. Detailed journal version at [ .html ]

Reviews for paper 0

Review from Prashant lamba<> at Mon Mar 10 17:42:28 EST 2003:

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.

Review from Piyush Bhagat<> at Mon Mar 10 23:22:16 EST 2003:

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.   

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

	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.

Review from Polyvios Pratikakis <polyvios@cs> at Tue Mar 11 10:59:23 EST 2003:

Review from Polyvios Pratikakis <polyvios@cs> at Tue Mar 11 11:12:14 EST 2003:

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.

Review from Yuan Yuan<yuanyuan@cs> at Tue Mar 11 11:59:31 EST 2003:

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.

Review from James Rose at Tue Mar 11 12:02:28 EST 2003:

	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

Review from Jeff Odom <> at Tue Mar 11 12:10:59 EST 2003:

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

Review from Mujtaba Ali <> at Tue Mar 11 12:27:42 EST 2003:

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.

Review from Brian Krznarich at Tue Mar 11 12:28:28 EST 2003:

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 
clean unwinding.  Side effects with process termination are considered in the 
paper on transactions.

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