Re: Broken dream of mine :(

[Jonathan S. Shapiro]

On Mon, Oct 5, 2009 at 12:12 AM, William Leslie
<address@hidden> wrote:
> 2009/10/5 Jonathan S. Shapiro <address@hidden>:
>> 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