Re: Questions

[Marcus Brinkmann]

On Mon, Oct 27, 2003 at 01:53:58PM +0100, Martin Schaffner wrote:
> 1) Performance:
> 
> In 06/04/2001, "sjames" wrote on slashdot
> (http://slashdot.org/comments.pl?sid=11531&cid=310196):
> 
> > The biggest problem for microkernels is that they have to switch
> > contexts far more frequently than a monokernel (in general).
> >
> > For a simple example, a user app making a single system call. In a
> > monokernel, The call is made. The process transitions from the user to
> > the kernel ring (ring 3 to ring 0 for x86). The kernel copys any data
> > and parameters (other than what would fit into registers) from
> > userspace, handles the call, possably copies results back to
> > userspace, and transitions back to ring3 (returns).
> >
> > In a microkernel, the app makes a call, switch to ring 0, copy data,
> > change contexts, copy data to daemon, transition to ring3 in server
> > daemon's context, server daemon handles call, transitions to ring 0,
> > data copied to kernelspace, change contexts back to user process, copy
> > results into user space, transition back to ring3 (return).
> 
> Am I right in thinking that a syscall on hurd/l4 would work differently?
> If i understand correctly, it would work like this (example: reading data
> from a file):

There are two issues.  The first is how L4 implements IPC.  The second is
how the Hurd uses IPC.  The L4 IPC mechanism is very fast.  It does not copy
the message twice, it copies it directly from the source TCB to the
destination TCB.  If you have out of band data in string items, likewise the
data is copied directly from the source to the destination task in reserved
buffers.  For map items, mappings are installed of course.

An IPC requires a system call into the kernel, which then performs the IPC. 
Assuming that the destination thread is ready, the IPC is performed
immediately, and a normal RPC would then go directly into the receive phase
which blocks.  So, another runnable thread would be scheduled (I am not sure
if in this scenario extraordinarily scheduling takes place and the receiver
thread is elected if the sender has a tiem slice rest - it could be handled
that way I guess, assuming there are no higher priorities).

Of course, you _have_ to switch the context eventually to the server, which
then processes the RPC, and then you have to switch back.  This can
be a problem, but probably cache pollution and TLB flushing is a bigger
problem than the actual context switch (on ia32, TLB must be flushed
completely - there is a potential optimization using small spaces which work
similar how kernel memory is mapped into each task - that can be used for
device drivers).

Note, it is not proved yet if a multi-server microkernel system how we
envision it is feasible, but we have reasons to be optimistic.  One reason
is that modern microkernels like L4 have been scrutinized to be very
efficient in these operations.  Another reason is that by choosing a good
design, other types of optimizations are possible in a most natural way
which are awkward or otherwise unfeasible on monolithical systems (for
example, making paging decisions in each user task rather than in the
kernel).

I don't think you will find anybody who will promise you rivalling
performance under all situations, and without the necessary optimizations. 
Usually, there will be some things that will be easier to optimize in one
system and more difficult to optimize in another.  Especially if you start
to think about SMP for example, thinks get a lot more complicated.
However, if you are looking for special needs and are willing to put in the
work required, you might be more happier in such a design as we work on.
If you want to work on orthogonal persistency, low-latency (soft realtime)
applications like sound, hard-realtime, scalability, and other types of
systems, you have powerful primitives with L4 that you can use to your
advantage.

> The app has previously aquired a capability for the file it wants to read,
> and allocated a buffer. When it calls "read", the glibc function makes an RPC
> directly to the filesystem translator (no going to ring 0, assuming the
> translator is owned by the same user as the calling process),

No, no.  For any IPC you make a system call to the kernel.  Even for local
IPC within a process, and definitely between processes.

> which in turn RPCs
> the driver of the backing store (will probably reside in ring 0) for the data.

Yes.  In fact, there will probably another task inbetween the driver and the
server.
 
> Assuming zero-copy, there is a minimum of data copying, but there are still
> four context switches, which can't be done with super-fast IPCs, since they
> concern three different processes (app, translator, driver).

If you are reading from disk, I don't think the context switches will be
your problem.  If it is in the cache, you don't need to go to the driver.
You are raising tough questions here, and there is certainly need for
research on such issues. 

> Is it likely that l4/hurd will be slower than linux, for things like
> filesystem operations?

It is pretty much certain that the first version will be slower :)
But that doesn't mean that it stays that way.  If we can prevent the I/O
performance disaster of Mach, that would already be a good success.
If we can actually implement zero copy from the driver to the untrusted
user application, that would be a good success (and we have a design for
this).  If after all the obvious optimizations are done there is still a
significant performance gap compared to other systems, you'd have to analyze
what the problem is.

> 2) Translators on linux
> 
> In 12/04/1999, Marcus Brinkmann wrote on help-hurd
> (http://www.geocrawler.com/mail/msg.php3?msg_id=2949290&list=333):
> 
> > > make more useful translators. Then either Linux will switch to
> > > translators or we will swich to not using Linux.
> > > This is the greatest idea of Hurd, but not widely used yot.
> > > And its already partially implemented in Linux
> >
> > I don`t think it is feasible to add this to Linux, especially if you
> > consider security issues.
> >
> 
> Does this mean that the Linux Userland Filesystem
> (http://lufs.sourceforge.net/lufs/intro.html) poses security risks?

I don't know lufs, so you are the judge.  Does it provide the same features
as user-space translators in the Hurd?  If yes, are these features
implemented securely?  How can you verify that this is the case?

For the first question, can users install lufs without the system
administrators help?  Can they mount their own FS implementations after lufs
was installed (it requires a kernel module)?  Can you use suid/sgid
applications on these filesystems to grant other users in your group access
to scripts that need to rw files which are only accessible by your user ID?
Can you extend the features of the filesystem in a most flexible way (in
conjunction with equivalent changes in glibc)?

For the second and third question: Is the lufs kernel module secure?  Can you
verify that it is secure regardless what other modules are loaded?  Can you
ensure that it stays secure with newer kernel versions?  Can you even ensure
it will compile with future kernel versions?  Can you verify that any users
of the module (either directly, or users of the filesystem that is implemented
using lufs) can not harm the integrity of the system?

Security is relative.  There is no usable absolute security, nor is it
needed.  The question is what amount of security and reliability you can
achieve by maintaining which features, and if you can maintain it.  There
are some interesting secondary security issues in the Hurd design (not
security faults, but things that work differently enough than in Unix to be
able to trick system administrators into doing stuff that harms them) which
we want to address in the redesign (simply by changing the default
implementation in glibc), and there is a wide range of interesting DoS
attacks (many of which have corresponding DoS attacks in Unix), which we
want to solve properly as good as we can.

To answer your question: lufs might be secure, but I would not claim that
without a thorough analysis, nor do I think that it provides a comparable
feature set to the Hurd's translator concept.

Look at the lufs web page:
"The reason for the userspace stuff: there are operations only suited for
userspace (cryptography for example) and implementing them in kernel would
be bloat.
The reason for the kernel stuff: I think it's important to keep the file
system access point at the lowest level in order to allow all the
applications to use it. Consider KDE: it implements its own virtual file
system, a great one, but only KDE applications can take advantage of it. So
does GNOME, MC and others. Suddenly we have lots of overlapping userspace
file system implementations, a real waste..."

This dilemma is exactly what the Hurd solves, by _design_, not as an
afterthought and clever hackery.  The Hurd sits between the kernel and the
application (glibc), and provides transparent to the application a user
extensible operating system, without requiring mutual trust.  Now, you
_might_ be able to bend and break Linux hard and long enough to get similar
features, but that we knew already: You can also write a BASIC dialect in
TeX or implement the Sokoban game in sed.  It's a nice hack, but nobody
would conclude from that that TeX is a great language to write interpreters
in, or that sed is the ideal environment for game programming, nor that you
can implement all language dialects in TeX or all games in sed.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/