Slashdot Mirror
Bill Joy's Takes on C#
f00zbll writes: "Cnet is running an article by Bill Joy on security and how it relates to C# and Microsoft at large. BJ quotes verbatim: 'C# provides the ability to write unsafe code. In unsafe code it is possible to declare and operate on pointers, to perform conversions between pointers and integral types, to take the address of variables, and so forth.'"
No, it is safe because it is verifiable. What that means is a formal proof that the code doesn't violate various constraints (such as accessing memory that it shouldn't - which usually requires some level of type safety, checking arguments to function calls, etc). Once you have that level of "safety", you can then add in security models (e.g., inhibit "unlink" calls) and be sure that the code isn't going to subvert that model (such as roaming a pointer through memory looking for the permissions your code is allowed, and changing it to give yourself more permission once you find it).
It's just a side-effect that the specific byte-codes are designed to be verifiable, where machine code is generally not (and should not - at the implementation level, you eventually have to get down and dirty, and where attempting to be "safe" would be much too slow). Once it's been verified, it can be turned into native code and it remains just as safe.
I think Microsoft is just confusing the issue by calling it "safe" and "unsafe". It should be a matrix of "verifiable" vs. "unverifiable" and "trusted" vs. "untrusted". Code marked as "safe", but which fails the verification proof, should never be run, regardless of any code-signing levels of trust. Other than that, there isn't really any reason to mark code either way, except to avoid the overhead of trying to start checking unverifiable code when you know it is going to fail. It sounds like the "unsafe" attribute is mostly just a way to mark the source code so that a programmer doesn't inadvertently use unverifiable techniques.