[elysium-developers] Block devices [revisited]

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

[this mail only considers harddisks -- sorry]

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). 

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. 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. 

When mapping a disk block from the buffer cache into application memory
we need to check that the application is allowed to access the specified
disk block. The real problem is that we don't want the disk block server
to know anything about filesystems -- it should be easy for applications
to define their own filesystem (performance-wise this is vital to an
HTTP server for instance). If the server doesn't know anything about
filesystems who do we check for access rights?

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. Once the function has been uploaded it cannot be changed.
Given a disk block representing some kind of filesystem meta-data (such
as inodes) the function should return the set of disk blocks the
meta-data block refers to. To map a disk block from the buffer cache an
application only has to prove that it has access to the meta-data block
that refers to the disk block it wants to map. Normally the meta-data
block will already be in the buffer cache, but in case it's not you just
have to prove that you've got access to the (meta-)meta-data block that
refers to the meta-data block, and so on. To make the process of proving
terminate applications that need access to a filesystem simply has to
have access to the root meta-data block. 

To create/extend files you'll have to modify meta-data blocks. The
server cannot do this modification for you since it doesn't know enough
about the meta-data (it only has the 'owns()' function) to alter it. To
handle this situation the server allows applications to request a
meta-data block modification by sending the (new) modified meta-data
block along with a brief description of the change (such as "I've added
disk block 17 to the set of blocks the meta-data refers to"). By running
the 'owns()' function before and after the changes and comparing the
resulting sets the server can verify that the modification indeed did
add disk block 17 to the 'owns()' set. 

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.

/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