Re: [elysium-developers] Capabilities

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

The end of my phone cable broke off. If you're getting this, I guess the=20
chocolate block worked ;)

On Wed, Feb 23, 2000 at 01:22:38PM +0100, Kasper Verdich Lund wrote:
> Each process will have a list of capabilities (c-list), which can be
> mapped read-only to the process (and other processes).=20

So you are going for the in-kernel, per-process table system. That's ok.

> The first entry
> in the list (entry 0) will hold the process capability for the any given
> process.

Well here you are talking like 'normal' capabilites. How can there be a
process capability if they do not encode objects?
=20
> The capabilities are ordered in a hierarchy. One way of implemented the
> capability would be:
<snip>=20
> This means that the capability with the name 1.3 will dominate the
> capabilities 1.3.1, 1.3.4.5.6, and 1.3.6 - but not 1.4 or 2.

So really they aren't capabilites at all, just a hierarchy of users.

> Using the Capabilities
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> The kernel should protect physical pages, I/O port ranges, and CPU
> quantums with capabilities. As an example consider mapping in a page
> from memory protected by a capability. The system call you should use is
> sys_pte_set(). A protected implementation could look like this:
>=20
> int
> sys_pte_set(uint32_t ptbl, uint32_t pte, uint32_t entry, int cap_index)
> {
>   if (page[pte].status !=3D PAGE_FREE)
>     {
>       if (!cap_dominates(current_process->clist[cap_index],
> page[pte].cap_guard)) return -1;
>     }
>   else
>     {
>       page[pte].cap_guard =3D clist[cap_index];
>     }
>   ptbl[entry] =3D pte;
> }

This means that if you grant a process a certain 'access', you grant it
everything needing that access, or less. It's the *NIX-root problem again.

> Comments? Good ideas?

I *hope* they are good :-)

> P.S.: The design described here is pretty close to the design used in
> Xok (the MIT exokernel).=20

I'd be interrested in reading their finding on this system, if they have an=
y.
=20
> P.P.S.: The term 'capability' might be a bit misused in this discussion.
> Normally a capability encode an object, but the capabilities in this
> design merely represents access rights. Maybe we should change the name
> to EAR (a TLA, which means encoding of access rights). :-)

Well, I'd suggest using real 'capabilites', not EARs.

Let me try something like this:
struct cap {
    int obj_type;
    int obj_id;
    int obj_meth;
    int access;
};

'int' might not be the right datatype for some of these, but that's not
important right now. This system encodes an object and an access. The @acce=
ss
field would be a bitmap like:

#define CAP_READ   1 << 0
#define CAP_WRITE  1 << 1
#define CAP_DELETE 1 << 2
#define CAP_APPEND 1 << 3

etc...

The @obj_type would be something like process, mem_page, I/O port etc. The=
=20
@obj_id would define the actual process, memory page or port etc. The=20
@obj_meth would be one more level (like the method of a server).

A process would be granted capabilies when it started, in well known table
indexes. Like STDIN, STDOUT and STDERR are fd 0, 1 and 2 in *NIX.=20

Lets say a process wanted to give another read-access to one of it's pages.=
 It
would make a capability.

obj_type =3D CAP_MEMPAGE
obj_id =3D <the page number>
obj_meth =3D 0   /* Not used */
obj_access =3D CAP_READ

It would then send this to the kernel. The kernel would check that it had *=
at
least* read access to the page, and give it the capability (returning the i=
ndex
id). It could then give the capability to the other process, like you descr=
ibe.

For another example: a server.

The server generates the capability:

obj_type =3D CAP_PROCESS
obj_id =3D get_pid()
obj_meth =3D MY_SERVER_METHOD_READ;
access =3D CAP_READ | CAP_WRITE

It could then give the capabilites to any process it wants. When they do a =
PCT,
they (via the kernel) present the capability. The server checks the obj_met=
h and
access fields and does the requested work.

This (IMHO) is a far better system. I would recommend this paper:
http://www.eros-os.org/essays/capintro.html

As good reading.

AGL

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