Re: ports suggestion

[Richard A. Kelley, Jr.]

Before I say anything else, I will first apologize
for my ignorance.  I have been reading the content
on-line regarding hurd.  Some of what I have to
say may be rehash, but based on two of the most
recent posts to l4-hurd, it appears there is still
room for discussion.  What follows are two
different issues.

Part I

Niels Möller and Espen Skoglund in their posts
make reference to current shortcomings of L4. 
This is not to say that L4 will not in the future
have the world's greatest answer for either of the
issues (ports and smp).  At the same time, it may
be that two years from now it will be evident that
the direction the L4 takes with respect to smp or
ports is the worst thing anyone has seen since
DOS's memory management.  If lucky then L4 turns
out to be the world's greatest choice, and all the
hurd's eggs were in the right basket.  The problem
is what if L4 like Mach does not work for the long
term.  It could again become a matter of deciding
does the hurd continue forward with L4 or go
looking again for a new kernel.  Either prospect
would be less than pleasant if it would again mean
a complete rewrite on large portions of code.

I understand that what I am about to suggest is a
great deal of work, but I believe there would be
many benefits to this course of action.  Rather
than coding for a specific kernel, code for a
virtual kernel.  The virtual kernel would be the
interface between the hurd code and the kernel.  

Let us say, for purposes of illustration that the
virtual kernel is initially called "v-L4".  As has
already been pointed out, the L4 does not use a
port as a communication channel which was a
fundamental part of Mach and based on my
understanding, it is a fundamental part of the
design of hurd.  So, the v-L4 code wise could be a
mix of the current L4 and the parts of the Mach
that kernel wise are most important to the hurd. 
The implimentation of a port on the L4 would then
become the responsiblity of those developing the
v-L4.  For that matter, it could be a "v-Mach"
instead of a "v-L4".  If the code base for the
Mach is fine and the lack of future support is the
problem, then use the Mach as the design for the
virtual kernel and use L4 or whatever kernel as
the kernel that the virtual kernal translates to.

As long as the hurd is being compiled directly to
a specific kernel, there is the problem of
dependency.  If instead the hurd is compiled for
use with a virtual kernel, then it becomes an
issue for the virtual kernel to deal with whatever
changes at the kernel level.  In this manner, the
hurd development can at all times, once the
virtual kernel is in place, continue development
without a major rework because of changes at the
kernel level.  Obviously, this is an over
simplified example.  The point is whether or not
the kernel is designed to handle communications
via port should be immaterial to the hurd
development.  True, if the hurd is developed
directly for a specific kernel, it will run
faster, but at what cost?  Understandably, there
is a heavy upfront cost of time in developing the
virtual kernel layer, but the long term benefit is
immeasureable.

With such a design, it would not be a matter of
recoding sections of hurd to work on different
platforms/kernels.  Instead virtual kernels could
be created on a per kernel basis.  The hurd code
would be able to remain constant.   


Part II

The security issues presented relative to how
ports might be handled concerned me.  This may be
based on my ignorance, but a process should not
have a changeable uid.  It might have a changing
set of rights based on who is accessing it, but at
the core, it should security wise be uniquely
identified.  Example:

A text editor by default would have no rights. 
When I as a user access the text editor, there
would be a certain level of rights transferal, but
even at this point, the text editor should still
retain it's same uid.  Furthermore, just because I
have read write access to my home directory and
all sub content, it does not mean that by default
I would want a text editor accessing my home
directory to have all those same rights.  Maybe a
better example would be an e-mail client.  Given
the problems which have arrisen in the e-mail
environment, I can safely say that while we would
like the client program to be able to read and
write files, we would also like to greatly
restrict what it is access and be notified when it
accesses material which could be inappropriately
used.  ie when I open an e-mail to read it, I
would be horrified to see at the same time it also
opened my address book.  As security becomes a
bigger and bigger issue, the ability to trace all
activities and determine their potential right or
wrongness will become even more fine tuned.  I
believe the work being done by the group working
on Rule Set Based Access Control is a step in the
right direction.


As stated, I may be very ignorant, so any who are
thinking about flames, it would be greatly
appreciated if instead you wouuld point me in the
direction of the correct body of documentation.

Thanks your time and consideration,

Rich