Re: [elysium-developers] IDE code

[Adam L. <ag...@li...>]

On Sun, Feb 27, 2000 at 03:44:23PM +0100, Kasper Verdich Lund wrote:
> > 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 ch=
urn
> > 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 w=
ould
> > have to present a capability that would grant *at least* that right when
> > creating it.
>=20
> 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?=20
>

Well I suggested 3 fields obj_{type|obj|meth} I guess the server could free=
ly
use obj_meth

> 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:
>=20
> block_set_t *owns(meta_data_t md);
>=20
> 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.=20
>=20
> I'm working on a kernel specification, but once that's done I'll try
> describing this particular server in more detail.

Well, it would be quite nice if processes could map disk blocks into their
memory space. But that would give the disk server hell when it wanted to
free pages etc (and 4K isn't fine enough). Oh well

We could setup non-present pages and map those. Actually we could have=20
the whole disk mapped in memory this way (Damm 32-bit addresses) with=20
page-faults on access etc. I don't really know the issues here, so feel
free to simply say "Nope." ;) All those page-faults could kill the speed
thou.

I know it's aginst the principles of exokernels... but why put the disk ser=
ver
in a seperate process? It's going to have to be a secure server (which
applications can't overright) so why not put it in the kernel? Putting it in
a process only gives us more context switches. Are there any reasons for
a server. I guess it's easier to replace, but we could have kernel modules.

> =20
> > Another thought. If the kernel can generate capabilites with the proces=
s's PID,
> > how do we invalidate them. A process can die and another spawn in its P=
ID. The
> > capability is now valid for a different object (namely the new process)=
. Hmm.
>=20
> 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.

Ah, ok.

AGL

--=20
Smoking is one of the leading causes of statistics.