Bill Foote (Bill.Foote@Eng.Sun.COM)
Fri, 19 Mar 1999 11:50:19 -0800 (PST)
Godmar Back wrote: > Regarding the stopping of threads. > > We do not believe that a general solution that allows thread X to stop > thread Y is necessary. It might be desirable, but it might also be impossible > because of the problems involved in writing async-signal-safe code, but > it's probably not necessary. > > Instead, we argue to introduce a process model: a given activity, such > as a servlet, applet, or mobile agent, is encapsulated in a "process". > Processes can be asynchronously killed by destroying (a la Thread.destroy) > their threads. > > <...> > > Of course, isolation between processes comes at a price. This price may > be reflected in a higher overall memory consumption, and sometimes in the > form of copying costs. For instance, a normal JVM like Sun's would intern > all utf8consts: in a process-oriented JVM, you'd have to keep the symbolic > information for each process separate in order to be able to separately > account for them. I think there's a really interesting tradeoff to be made between protection and sharing. My intuition tells me that it should be possible to find a "sweet spot" between the sort of draconian no sharing policy of a process model, and the unconstrained sharing you get in a single VM if you do nothing. The 1.2 security model has found such a sweet spot for data access issues -- you can craft a fine-grained security policy fairly easily. Namespace management via classloaders can get us part of the way there for resource sharing. JRes is really promising in this direction, but I bet that a determined attacker could foil it. Of course, there's the well-known absolutelypositivelymustcomplete infinite loop in a finalizer trick, but here's an interestingly subtle DoS attack based on data sharing: synchronized(java.lang.Math.class) { absolutelypositivelymustcomplete { for (;;) { try { Thread.sleep(1000); } catch (Throwable t) {} } } } // for absolutelypositivelymustcomplete, substitute David's catch/respawn // code, or its moral equivalent Now, just synchronizing on a class object by itself isn't necessarily fatal. I can synchronize on, say, java.lang.VerifyError.class all day long, and the only person who'd notice is someone else who's as silly as I am. Math.class is different, because Math has a static synchronized method. By holding the lock, I prevent anyone else from computing random numbers. This is interesting, because it's a subtle DoS attack. A resource protection regime that looks out for threads that consume too much CPU is helpless in this case. The notion of resource to be protected has to include _any_ "system" object that can be manipulated in a damaging way. It's trivially easy to fix the Math class (and doing so doesn't change the API in any way)... But I wonder what other subtle resource-sharing based attacks lurk out there. Any ideas? Has anyone taken one of the DoS-resistant environments, and invited attack? Bill -- Bill Foote bill.foote@eng.sun.com EmbeddedJava VM Group, Sun Microsystems http://java.sun.com/people/billf/
This archive was generated by hypermail 2.0b3 on Fri Mar 19 1999 - 14:51:17 EST