[cap-talk] Security by safe language processing

[Mark Miller]

On Sun, Sep 6, 2009 at 3:37 PM, Jed Donnelley<capability at webstart.com> wrote:
> I think I understand the above approach.  Do you agree that such an
> approach is very different from current systems in that with it
> one can't move binaries from system to system?

Who distributes binaries anymore? I'm only party joking. While it's
too early to declare victory, the Uncol
<http://en.wikipedia.org/wiki/UNCOL> idea is definitely on the upswing
with JVM bytecodes, JavaScript (inlcuding JavaScript as a compilation
target), CLR, and the alternate Java instruction set accepted by the
Android. All of these have in common that programs are distributed in
expressed in terms of a memory safe semantics which, modulo bugs, the
submitted program can't violate.


> It seems to me that a cache invalidating event could have serious
> consequences for system performance - at least for a time.


http://www.ics.uci.edu/~franz/Site/pubs-pdf/ICS-TR-06-16.pdf
http://www.ics.uci.edu/~franz/Site/pubs-pdf/ICS-TR-07-12.pdf

I've only read the first paper, which I thought was beautifully simple
and powerful. In looking for it I ran across the second paper which
looks worth readong.
These include the cache invalidation logic needed, even if it is
included for different reasons. See the papers for the performance
consequences of this cache invalidation.

One sign that cache invalidation cost is moderate for all the Uncols
above: I have not heard of any of these writing the dynamically JIT
compiled machine instructions to disk. That means that all consider it
affordable to start all programs with a cold cache.


-- 
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM