[cap-talk] Cap type safe OS questions

[Jonathan M. Smith]

Ben:
	I'll try to address Q1s as I understand it.

Q1: The OS is in some ways just a design choice that allows multiple  
language RTEs and applications
to share a common virtual machine model. The more fundamental design  
questions for any system are
which resources to protect and how to protect them. Once the protected  
resources are determined, a
protection mechanism can be devised. Hardware protection plus virtual  
memory forbids certain addresses
from being used. A language system (e.g., that of Alien) can forbid  
direct use of addresses and forbid uttering
names except by privileged modules (OCaml "module thinning"). However  
in the language system, the
protections depend on all programs being compliant, checkable, etc.  
One way to do this is to do a careful
compilation (all the type-checking, etc.), keep the code around, and  
provide a cryptographic hash of the code
with which it can be invoked by remote machines - that is one path to  
a distributed system.

Q2 & Q3: These are probably better addressed by the KeyKOS folks and  
Jonathan Shapiro, respectively.

																					-JMS


On Aug 1, 2009, at 12:10 PM, Ben Kloosterman wrote:

> Hi Jonathan,
>
> Thanks for your reply was quite interesting , I have started reading  
> and
> have read quite a few documents , browsed the coyotes code and  
> unfortunately
> it's a steep learning curve with the devil in the detail . Though  
> after a
> few weeks I think it is definitely the way to go  ( once I get over my
> distributed system concerns).   Im probably going to go for a non pure
> capability system for the practical reason of my experience with  
> Capability
> systems and the fact there is little research on a micro kernel /no  
> ring 0
> privilege /flat space / managed OS using capabilities . Minix and a  
> public
> Singularity paper cover the non capability parts ( and a few  
> others) .   I
> expect Microsoft are looking at these very issues as they seem to have
> recruited some significant members from the capability community for  
> their
> managed OS. While there are no show stoppers , deciding on the best  
> way is a
> challenge.
>
>
> It's a bit intimidating posting to an 11 year old list with lots of  
> experts
> when entering the field. Anyway the best way to learn quick is to  
> read and
> ask stupid /incorrect questions.
>
> Q1) Capabilities being generated/managed in the Kernel or via a user  
> mode
> service.
>
> All the existing OS have the code in the kernel yet a few documents  
> mention
> a capability service ; is there any information on this?
> 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 ?
>
>
> Q2) How does the loader create the capability to a keyring  
> ( nodepage or
> capability page) for a new process
>
> I note : In a capability system, a new program (we'll call it new)  
> gets its
> capabilities in two ways:
>
>   1.New receives an initial set of capabilities when it is created.  
> These
> are supplied by new's creator (which is another program).
>   2.If another program receives a capability to new, it can invoke  
> new and
> pass it additional capabilities if it desires.
> From. http://www.eros-os.org/essays/wherefrom.html
>
> But how is this handled in terms of storage of the capability and  
> storage of
> the pointer to the capability ? Or is there a special case that a  
> process
> can access the keyring without a capability.
>
>
> Q3) User code ( including services) can't call the kernel  
> ( capabilities can
> though I need to decide how to allow capabilities to call the  
> kernel) or
> have a reference outside their address space . However we do have a  
> shared
> memory area which they can have reference to or create /alter  
> objects if
> they are the owner ( eg only 1 writer) . IPC messages are created   
> in this
> shared memory hence we can send strongly typed variable sized  
> messages by
> just passing a pointer ( also note the cost of creating objects here  
> is not
> likely to be much more than the stack) . The issue is do we
> 1) Store Capabilities in shared memory  ( with the kernel or  
> capability
> service as the owner)  , this is nice as the "Invoke" will call the  
> kernel
> but we haven't violated the reference restrictions and the  
> capability is
> calling the kernel. In addition it will work well with the compiler  
> and the
> capabilities will be Garbage collected however this memory region is  
> likely
> to be reference counted for GC purposes so creating references to a
> capability will be more expensive ( but not use or creation of  
> capabilities)
> . Obviously there is a shared memory capability that needs special
> treatment.
> 2) Create a special memory region eg a KeyRing structure which is like
> shared memory . The Process has a reference to this. In many ways  
> this is
> like shared memory but its another type of shared memory to support  
> and
> maintain.
>
> Note since users can't create capabilities ( its constructor is  
> internal to
> the kernel ( or Capability service) ) there is no issue with the
> capabilities being stored in memory readable by the user.
>
> Regards,
>
> Ben Kloosterman
>
> <snip>
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk