[cap-talk] Cap type safe OS questions

[Ben Kloosterman]

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.

BK> Very interesting and adds to the use OO type security  with the reference as the key/capability .  We are getting back to the basics of OS design .  Even without hardware protection an OS  is still scheduling applications  and provides IPC.

Some big questions here a huge OO OS would be very interesting and similar to an application server.

I still think having a user address space ( ok a region in the flat single address space ) is valuable since at the top of my head

1)      Because Garbage collecting a whole system is a major undertaking,  By having an address space  the Allocator receives pages from a memory manager ( Which is very simple it just manages the memory no paging etc and pages are big)  and only has to scan its own objects.  This also allows different collectors like real time etc. 

2)      CPU Cache coherency . Creating objects everywhere is not great. 

3)      Prevents access due to programmer bugs .

4)      Multi threaded code can have more efficient locks, 

 Distinguishing Kernel and User mode 

I see no reason to really distinguish this . The only exception is kernel code can have global address space access ( and if you went addressless ) 

At present the main reasons are

1)      Scheduling primitives are in the HAL  which is only accessed through the Kernel . The Kernel needs access to the user mode scheduling app. 

2)      As above a Capability management app ( though this will prob be a kernel data store app) 

3)      When sending messages from one app to the other app , the message pointer is inserted in the destination  apps receive queue. 


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.

Why does integrating a compacting GC and  persistence require tossing memory access ?  Why can’t it be done within individual memory regions ? 

 

Both your points require a lot more thought, 

Regards, 

 

Ben

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20090803/e980ef13/attachment-0001.html