Re: [elysium-developers] IDE code

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

On Sat, Feb 26, 2000 at 11:28:27AM +0100, Kasper Verdich Lund 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.

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 cou=
ld
make a lot of more-targetted capabilites and discard the generic one.

I think the main problem with capabilites knowing where they are. *NIX
processes start with fds 0, 1 and 2. But how does a process know that index
1 is a capability to the keyboard server and so on? We could use well-known
indexes, but that possibly means *lots* of well known indexes - and a big
in kernel table. That table would be wasted if those capabilites were not
granted.

Maybe processes should startup with a page of memory (4096/4=3D1024 indexes)
that have the indexes of the kernel table. The process could record the data
it needs and free the rest. e.g.

Kernel cap table:  STDOUT
Process cap table: -1, 0, 0, -1, -1, -1, ....

the process startup could look like this:

out =3D cap_table[CAP_TABLE_STDOUT]
in =3D cap_table[CAP_TABLE_STDIN]
if (in =3D=3D -1)
    /* This program is interactive and must have a STDIN capability! */
    exit (1);

CAP_TABLE_* would be defined in a common header file. This saves on memory.

> =20
> > 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'?
>=20
> 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! ;)

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). Hm=
m.

AGL

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