Huge Security Hole in Solaris and JVM

I wonder how Gosling feels about Solaris and the JVM, both of which support execution of C and C++ code (the latter through JNI, the former as the default way lots of UNIX heads (including me) learned to write UNIX code).Seriously, verifiable type safety is a wonderful thing, and I personally strive to stay within those borders every day of my life.The fact that some people can`t is a fact of life, which is why JNI (and the CLR`s P/Invoke and C#`s unsafe) exists.Ignoring the hyperbole (which is sad but a reality of the commercial software business), there was one annoying bit of misinformation about unsafe vs. unmanaged.In CLR speak, there are two modes of execution: managed and unmanaged. Some managed code is verifiably type safe, some is not.Got it That`s three kinds of code:

1. Verifiable and Managed. This is what the C# compiler emits by default, and its the only thing the VB.NET compiler can emit.
2. Non-verifiable and Managed. The C# compiler can be told to emit this sort of code by passing the /unsafe keyword. The only reason to do this is if you are using the unsafe keyword in C#.
3. Non-verifiable and Unmanaged. The CLR makes no attempt to verify type safety on unmanaged code.This code is pretty much opaque to the CLR.

The JVM supports 1 and 3. JVC produces #1. JNI allows you to load #3.The CLR supports all three.You might ask, what good is #2 That`s easy.In systems programming, it`s occasionally necessary to do low-level buffer manipulation, especially in I/O code.In looking at the Indigo code base (which was 1123 C# files as of early last week), only 19 of them use the unsafe keyword. Every single use was to do buffer manipulation, either for low-level XML cracking, SSPI munging, or async I/O buffer management.Could we have written those pieces in unmanaged C or C++Sure.However, by using "Non-verifiable and Managed" C#, we got two advantages. First, the code was written in the same language the rest of the DLL was written in, meaning that it`s less of a cognitive mode switch for a dev to deal with when they go spelunking (or debugging).Secondly, there is no "transition" for the runtime to go through when executing the code. Both the CLR and the JVM have non-trivial runtime costs when transitioning from managed to unmanaged mode. In contrast, unsafe vs. safe is not a runtime mode, rather its just an attribute of an assembly that tells the loader whether or not verification is expected to succeed. In short, this means that yes, its faster.I`d be remise if I didn`t mention that code access security can disallow loading non-verifiable managed code, and the default is that it cannot be loaded from remote stores. You can use caspol.exe to tighten this down further.