Re: [elysium-developers] Block devices [revisited]

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

On Thu, Mar 16, 2000 at 10:08:35AM +0100, Kasper Verdich Lund wrote:
> [this mail only considers harddisks -- sorry]
>=20
> I suggest implementing the access to block devices -- e.g. harddisks --
> purely in user-space. A user-level server will initially request the I/O
> port ranges (and perhaps some parts of physical memory) needed to access
> todays sofisticated harddisks. Once the server has access to these
> hardware resources the kernel ensures that it's impossible for any other
> processes to gain access to the specific ports (and memory regions).

Tiny annoyance here. You are using the order of process loading as security=
 -
this is *not* a good thing security-wise. Rather I think init (or whatever =
the
kernel fork()/exec()'s) should pass the disk-server the capibilities for the
I/O ports. But we are far from this point yet ;)

> The server is capable of reading/writing any disk blocks (for efficiency
> a disk block should have the same size as the hardware page -- 4kb) into
> a buffer cache. A process can make a request to read a set of disk
> blocks into the buffer cache. There should be no access checking on this
> request, since reading blocks into the buffer cache does not -- in
> itself -- give access to the blocks in question.

Eccept that a process could flood request blocks and overfill the cache. Wh=
at
is the difference between a heavy load on a httpd and a nasty process flood=
ing?
But processes generally have far more valid data that they could legally re=
ad
(given IBM have just released 75GB drives) then the size of the BC. I don't=
=20
think that access checking will solve this. Hmm.

> Likewise
> flushing/writing parts of the cache should be operations accessible by
> user processes, but it might be that we need some kind of access
> checking on these operations.

see above. Processes could legally write lots of stuff, eating up I/O

> IMHO the most interesting way of doing this is by using UDFs (untrusted
> determistic functions). In this section I do not consider file
> permissions (in the standard *NIX sense), but only explain how to ensure
> that disk blocks that aren't parts of any file can't be accessed. To
> define a filesystem applications upload a function 'owns()' -- written
> in a simple assembly-like language -- that can be verified to be
> deterministic.

I think that UDF's are going to be used a lot in whatever Elysium becomes
(how is the merge going?) so a library is in order. Not a shared library but
a .a file. That sounds like a really Cool Thing (tm), I might start on one.

> To allow maximum flexibility any process should be able to create a
> filesystem (by specifying the 'owns()' function). To keep filesystems
> across reboots (generally a good idea :-) the 'owns()' function should
> be saved on disk along with information on the location of the
> associated root meta-data block.
>=20

Filesystems will have to be protected via standard means or by layering (wh=
ere
a filesystem is implimented in a file). If we store owns() functions in the
filesystem it should be in meta language (not compiled).

I'd support a system of bootstrapping thou. The kernel must have some built=
-in
fs code, in order to launch the first process. That (init) could then load
owns() functions.

And processes must have capabilites for a range of disk blocks before they
can load owns() functions for them.

AGL

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