Re: [elysium-developers] IDE code

[Kasper V. L. <ve...@da...>]

Adam Langley wrote:
> > I agree that 'real' capabilities would be a better way of doing it.
> > There are some issues about how to create a capability, though. I think
> > the kernel should create the capabilities, but that requires that the
> > kernel is able to check whether or not a process has access to some
> > resource. If the resource is managed by a server it's not trivial to
> > figure out the best way of doing it. It would be great if servers
> > (drivers), such as the keyboard server, could use capability based
> > protection of the resources it manages. I'll elaborate in a later
> > posting.
> 
> Well the kernel could let processes create capabilites of type PRIVATE with the
> processes pid as the obj_id, totally freely. This means a server can churn
> out capabilites and the kernel can check very simply if they are valid. As
> for things like giving out real-only memory capabilites - the process would
> have to present a capability that would grant *at least* that right when
> creating it.

How would a server go about protecting the individual resources it
manages by means of capabilities? If the obj_id refers to the server
process, and the obj_type is PRIVATE how does the server know which
(server internal) object it refers to? Do we need yet another capability
field (obj_pid) and let the obj_id be reserved for object identities? 
 
> As a side note. I think there should be some wide ranging capabilites that
> allow lots of simple things to be done. Security sensitive applications could
> make a lot of more-targetted capabilites and discard the generic one.

Agreed.
 
> > > Where will the IDE code go in the end? I don't think it can securly go in
> > > process code - it would be too easy for a rouge process to do damage. I doubt
> > > it will go in the kernel, so will there be a 'Drive Server'?
> >
> > I expect we'll implement a 'disk block server'. The way it multiplexes
> > the disk blocks will be explained later (it's rather complex - probably
> > the most complex driver of all), but interested people should read 'The
> > Exokernel Operating Systems Architecture' by D. R. Engler. Especially
> > the chapter(s) about XN.
> 
> I would start with the most complex wouldn't I! ;)

Yeah, but if you put some IDE code together we can start with an
unprotected version of the disk block server, which is quite easy. The
FAT16 code should probably go into a standard process library that
communicates with the disk block server. In the end the disk block
server should handle disk block caching, and that could be implemented
without protection as well. The way protection should work is by
uploading functions to the disk block server that given a meta-data disk
block returns the set of disk blocks the meta-data block refers to:

block_set_t *owns(meta_data_t md);

To get access to a disk block it must be in the disk block cache of the
disk block server, and the process requesting access must have access to
the parent disk block (the meta-data disk block that refers to the disk
block in question). When updating a meta-data disk block you pass the
new disk block and a description of your changes (in terms of changes to
the set of referred disk blocks) to the disk block server. The server
checks your modification by running the owns() function before and after
the modification and verifying that the resulting sets are updated
exactly as you have described. 

I'm working on a kernel specification, but once that's done I'll try
describing this particular server in more detail.
 
> Another thought. If the kernel can generate capabilites with the process's PID,
> how do we invalidate them. A process can die and another spawn in its PID. The
> capability is now valid for a different object (namely the new process). Hmm.

As it is now the PID is unique in time - at least quite unique. The PID
is 32-bit, and the kernel tries not to reuse PIDs. We probably need
something better than this, but it's almost there.

/Kasper

-- 
-------------------------------------------------------------------
Kasper Verdich Lund, Computer Science Department, Aarhus University
Office: 34P.218              | Phone: (+45) 8942 5680
Email:  ve...@da...  | WWW: http://www.daimi.au.dk/~verdich