On Mon, Oct 5, 2009 at 12:12 AM, William Leslie <[email protected]> wrote: > 2009/10/5 Jonathan S. Shapiro <[email protected]>: >> But with safe languages gaining acceptance, I think we now >> would need to re-examine that. > > 0. Language level object models tend to be finer grained than those > exposed by the operating system.
Yes. This can be a blessing or a curse. Finer grain lets you pack concepts more tightly, but there is such a thing as an object that is too small to adequately do the job. We don't teach OO programming very well in school, so this tends to be a problem in real programmers. Another way to say this is that factoring is only good when the concepts involved actually factor. When they don't, you just end up making things more complicated. > The filesystem, for example, feels like a duplicate object model, with > less transparent support from the (most?) language. Perhaps. But recall that it is almost impossible to do a generic security model for a general object system. The fact that the file system interface in POSIX (and most other systems) is designed around streams and directories is core to the R/W/RW security model. The problem is that we need to know the *semantics* of the operation before we can do a security design. If the operation set is subject to change/extension, we lose that. Note that this makes out-of-TCB file systems a huge issue. > 1. Safe languages introduce new opportunities for optimisation. Not in practice. Current safe languages turn out to have a bunch of fairly low-level design issues that make optimization quite difficult. In principle what you say should be true, but in practice we fumbled the early implementations. Trivial example 1: The "readonly" keyword in C# is (correctly and necessarily) ignored by most C# compilers. Exercise for the reader: explain why. Trivial example 2: Most pointers in Java/C# can be null, which carries an enormous optimization penalty. JIT doesn't help either of these. > When > a piece of code can be shown to succeed, and the semantics of the > language(s), preserved by the compiler[0], show that confinement > boundaries are not leaked, pieces of code can be inlined across > address space boundaries. With apologies to Jeff Irving, this insight was known back in the Cedar/Mesa days. > 2. Safe languages provide security benefits that go beyond confinement. > > Even when a stack overflow exploit in a network server can't do any > damage to the filesystem directly, it can forge communications, which > could be just as bad. Safe languages don't eliminate all possible > bugs, but they sure make a difference, and depending on the intended > target audience that could be a serious positive. Yes. They eliminate between 50% and 60% of current vulnerabilities. But be careful. You need to test and calibrate the runtime cost of this... > -1. There is a large amount of legacy code that is not just going to go away. Perhaps, but the beauty of legacy code is that 20% of it dies of old age every 5 years. Most of it's junk. Unfortunately, the code that survives many culls is important and complex code. > JIT compilation is good because it is a general case. JIT code is bad because we don't know how to assure anything as complex as a JIT compiler. shap
