Re: Safety of running and stopping dynamically loaded code

Doug Lea (dl@cs.oswego.edu)
Sat, 20 Mar 1999 07:34:44 -0500 (EST) 


I guess I was conveying the wrong attitude. What I meant was that I
think that these problems, like some of the ones illustrated involving
Thread.stop(), fall under the category of malicious attacks that are
probably best addressd via trust frameworks.

That is not to say that you can't or shouldn't be careful about these
things when protecting the main components of say a mobile code
engine. Although, if I were writing one, I'd go further than:

>   class X {
>     private Object lock = new Object();
>     void foo() { synchronized(lock) { body(); } }
>   }

And use locks from my util.concurrent package (available off my home page)
that allow you to internally recover from various bad things like
deadlock, as well as respond to interrupts. For example:

    class X {
      private Synch lock = new Mutex(); // or a reentrant one, or others
      void foo() { 
        try {
          if (lock.attempt(1000 /*milliseconds*/)) {
            try {
              body(); 
            }
            finally {
              lock.release();
            }
          }
          else { 
            actionOnTimeOut(); // probably deadlocked
         }
       }
       catch(InterruptedException ie) { // interrupted during lock attempt
         recoverFromInterrupt();
       }
     }  
   }

This is not much fun to program, but you'd typically only need/want to
do it for those components for which it is vital to preserve liveness
-- regardless of whether the potential liveness problems stem from
maliciousness, programming errors, or even intentional limitations in
concurrency policies that allow deadlocks to occur, but recover via
timeouts.

...

Also, I should have noted in my first posting that normal Java locks
are among the resources that you CANNOT revoke during cancellation,
even via Thread.stop(). For example, here is a particularly nasty
hostile attack:

class LockAttack {

  void attack() {
    hold(makeList(), 0);
  }
  
  void hold(Object[] objs, int i) {
    if (i >= objs.length) {
       for(;;) {
         try { for(;;); } catch(Throwable t) {} // or respawn or whatever
       }
    }
    else {
      synchronized(obj[i]) { // recurse, holding i'th lock
        hold(objs, i+1);
      }
    }
  }

  Object[] makeList() {
    // Among other possibilities, how about:
    foreach classname in package java.*.*
      add Class.forName(name) to list
    return list;
  }
}

There is good reason that you cannot revoke locks: there aren't
separate lock objects in Java. Every Object can serve as a lock.  This
may or may not be true under the hood as well. In some VMs, every
object maintains its own lock status; in others, the locks are treated
as separate resources acquired on demand. In either case though,
additional space/time resources are internally required in the case of
contention. For example, maintaining nodes in lock wait queues.

So, any Java resource limitation mechanism surrounding the creation or
use of locks will necessarily rely on limitations on creating or using
objects themselves.

-- 
Doug Lea, Computer Science Department, SUNY Oswego, Oswego, NY 13126 USA
dl@cs.oswego.edu 315-341-2688 FAX:315-341-5424 http://gee.cs.oswego.edu/  

----------------------------------------------------------------------------
To unsubscribe (or other requests)            mailto:majordomo@media.mit.edu
List archives, FAQ, member list, etc.   http://gee.cs.oswego.edu/dl/javares/

This archive was generated by hypermail 2.0b3 on Sat Mar 20 1999 - 07:38:50 EST