Hi,
On Sun, Jul 22, 2007 at 03:56:41PM +0200, Carl Fredrik Hammar wrote:
> Having special channel classes (or perhaps some other type of modules)
> for it seems like the right way to go. But the problem that these
> channels can live in several translators remain.
OK, let's look at an example:
,-----. ,-----. ,-----
,--->| mod |-> ... ->| mod |-->| app1
----. ,-----. ,-----. ,-----. `-----' `-----' `-----
dev |-->| mod |-> ... ->| mod |-->| tee |
----' `-----' `-----' `-----' ,-----. ,-----. ,-----
`--->| mod |-> ... ->| mod |-->| app2
`-----' `-----' `-----
^ ^
| |
My feeling about this is that while all the modules behind the tee can
be loaded into the respective application processes, the tee itself
should run as a real translator -- in an own process. This one can in
turn load all the modules before the tee.
The reason why this makes sense is that libchannel is really just an
(almost transparent) optimization: It serves the purpose of avoiding
crossing multiple process boundaries unnecessarily, if several modules
live in the same protection domain. But this is not always the case --
sometimes we actually have multiple protection domains.
The tee is one example: It is a shared resource used by multiple
applications -- one of which could actually be malicious. (Maybe just
buggy, but that doesn't matter for the purpose of security evaluation.)
The tee must be protected from this malicious process, so that the other
applications can't be harmed.
Another example might be a module that filters some raw data, where for
security reasons the application is only allowed to see the filtered
data. Such a filter module would also have to reside in an own
protection domain (i.e. translator process), even though in this case
all the modules form just a straight chain.
-antrik-
_______________________________________________
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
