On 28 Jul 2006 15:35:42 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote:
>It reminds me of one usecase, when a 'maybe-commercial' server running >a JVM accepts deployments of JAR files and cannot predict what users >deploy. So, not-to-crash on SOE is a matter of security for the >server. And this is really important to eliminate this >vulnerability. Readjusting stack size does not work here.
Egor, My impression is that most commercial server design is insulated from vulnerability from user code and similar security breaches by allowing only the process hosting the user application to go down, not the entire web server. Since the user code causing unbounded recursion is an application bug, it may not be worthwhile to try to prevent this failure. The failure that would be good to guard against is the one that happens though the user code is correct, ie., from a genuine lack of stack resources. It would be nice to see a real use case for this. We don't have to be perfect. No VM is. For failures in native code, there are some choices.. 1. Tuning by choosing stack and guard sizes from the command line. This is limited on Windows due to interference from the inbuilt Windows stack growth algorithm. But something like this could yield a good average size setting. 2. Set the exception info on the thread when the exception cannot be raised and check for it and raise it later. This may be the simplest. Is there a reason ( other than choice of approach ) why we can't do this? 3. Proactively check in the Jit to not allow SOE to happen by querying the VM and taking some recovery action eg., failing the compile, disabling optimizations, compiling with a down level compiler etc. This is a lot of work. And only the jit( eg., not the verifier ) can do this. Without seeing a real use case or reliability target, I don't know if it is necessary to do so much. There is a priority question too. Thanks, Rana -- Egor Pasko, Intel Managed Runtime Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
