<br><br><div class="gmail_quote">On Sat, Aug 1, 2009 at 9:10 AM, Ben Kloosterman <span dir="ltr">&lt;<a href="mailto:bklooste@gmail.com">bklooste@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<br>
Q1) Capabilities being generated/managed in the Kernel or via a user mode<br>
service.</blockquote><div><br>Perhaps you should add a Q0) should I distinguish kernel and user mode?<br><br>Hardware-level security through address management was introduced as a way to work around failures of the application languages (:shudder:, remembering early implementations of Windows). But if you force applications to compile to a particular language (or bytecode), you can enforce security at the software level and achieve security without the sacrifices to performance that come from partitioning the address space. <br>
<br>Applications are collections of interacting objects - interacting
capabilities - just like the kernel. And that&#39;s the way it should be,
because it allows applications to interact with one another in complex,
ad-hoc ways.<br><br>You seem to be assuming that applications need dedicated work-spaces - an &#39;address space&#39; they can muck around with. If they really need one, give them a mutable map from integer-&gt;integer and say: &#39;here ya go!&#39;.   <br>
<br>RAM is a horrible user-level memory system. The compiler needs it, but users can work with objects.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Obviously it&#39;s difficult (not possible ?)  in a non strongly typed system as<br>
the user could hack and create a capability too easily.  Tips<br>
/comments/Experiences ?</blockquote><div><br>It doesn&#39;t take strong typing to prevent access to capabilities. It does, however, take some considerations for software-enforced memory safety. E.g. users can&#39;t be doing pointer arithmetic, and shouldn&#39;t have access to &#39;pointers&#39; at all except as hidden behind a &#39;reference&#39;. Besides, if you wish to add persistence and high-performance GC and such you&#39;d benefit from tossing memory access anyway to allow for compacting GC and persistence to be integrated.<br>
 <br>David<br><br></div><div></div></div>-- <br>hubris and humility compose<br>perfectionism, paralysis, a curse<br><br>