[cap-talk] Cap type safe OS questions

[David Barbour]

On Sat, Aug 1, 2009 at 9:10 AM, Ben Kloosterman <bklooste at gmail.com> wrote:

>
> Q1) Capabilities being generated/managed in the Kernel or via a user mode
> service.


Perhaps you should add a Q0) should I distinguish kernel and user mode?

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.

Applications are collections of interacting objects - interacting
capabilities - just like the kernel. And that's the way it should be,
because it allows applications to interact with one another in complex,
ad-hoc ways.

You seem to be assuming that applications need dedicated work-spaces - an
'address space' they can muck around with. If they really need one, give
them a mutable map from integer->integer and say: 'here ya go!'.

RAM is a horrible user-level memory system. The compiler needs it, but users
can work with objects.


> Obviously it's difficult (not possible ?)  in a non strongly typed system
> as
> the user could hack and create a capability too easily.  Tips
> /comments/Experiences ?


It doesn't take strong typing to prevent access to capabilities. It does,
however, take some considerations for software-enforced memory safety. E.g.
users can't be doing pointer arithmetic, and shouldn't have access to
'pointers' at all except as hidden behind a 'reference'. Besides, if you
wish to add persistence and high-performance GC and such you'd benefit from
tossing memory access anyway to allow for compacting GC and persistence to
be integrated.

David

-- 
hubris and humility compose
perfectionism, paralysis, a curse
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20090802/d3ffadca/attachment.html