Re: [Syllable-kernel] Arno's kernel patches

[Jake H. <jh...@po...>]

Kristian Vandervliet wrote:
> 
> The odd thing is that it fixes the SMP boot problems.  Quite why removing
> syncronisation primitives should have that effect is still somewhat of a
> mystery.  However Arno did say that he removed them from functions which
> were already being called with interupts disabled, so they were redundent.

I think there is some dark voodoo involved in bringing up the additional 
CPU's correctly.  Wouldn't disabling interrupts on the active CPU with 
cli() prevent that processor from being able to receive any IPIs 
(inter-processor interrupts) that it needs to work correctly?  Perhaps 
that's the problem.

> See os::Settings, which stores configuration data in
> $HOME/Settings/<appname>/Settings  This settings file is a flattened
> os::Message object streamed to disc, which in a way is a simple
> key::value model with no tree structure.  It works very well.

Cool.  Simple BeOS style.  Yeah, app settings are not exactly rocket 
science to do at the libsyllable level, which is why it is so annoying 
that Microsoft has had so much trouble with the registry over the years.

> One idea I had was to add an events API to the kernel.  Any code, either
> kernel space or user-space, could call event() which would queue up an
> event in a message queue.  A user space process E.g. the Registrar, could
> then pull these simple messages out of the queue.  Applications could
> register with the Registrar to receive events that they are interested
> in.

My understanding is this is basically what d-bus is about.  udev, the 
Linux user-mode /dev management demon and replacement for devfs, 
interfaces with the hardware using hotplug scripts and can fire events 
to d-bus.  An alternative API for routing events is the POSIX Tracing 
API, described here and implemented by RTL-POSIXTRACE as an add-on for 
RT-Linux:

http://www.opengroup.org/onlinepubs/000095399/functions/xsh_chap02_11.html

Since POSIX tracing isn't supported by Solaris or any of the other 
commercial UNIX's and is only available as an obscure add-on for 
RT-Linux, it's not a very useful "standard" for us to support.  OTOH, 
while d-bus seems to have some momentum, integration between it and 
GNOME or KDE is still pretty minimal, as far as I can tell.  Here's a 
good technical article on what d-bus is about, with some sample code:

http://www-106.ibm.com/developerworks/linux/library/l-dbus.html

> Well there is already Syllable Manager, which offers a process list and
> some basic process control.

Yeah, I remember seeing that but forgot what it was called.  Is it 
installed in the default Syllable install or do I have to download it 
from somewhere?

> What you seem to be proposing (& correct me if I'm wrong) is some way to
> pass a dynamic tree of key::value pairs between application and kernel space
> via. a consistent API.  Which is a brilliant idea which would simply the
> entire process of passing data between the kernel and user-space much much easier.

Exactly.  It's a great idea and we can take advantage of the existing 
D-BUS codebase for Linux in addition to the registrar code we have now.

> Just think, a /proc type system without the need to mess with parsing
> human-readable text in the userspace process.  Forward *and* backward
> compatability.  Complex data structures flowing seamlessly...mmm. If you
> coupled this with the event model I describe above, just think of the
> possibilities of kernel and user-space integration we could achieve!

Yeah, /proc is gross.  Something like d-bus could even be used, if fast 
enough, by a debugger to inspect and manipulate processes, instead of 
using /proc or ptrace().

There are a lot of security implications of course, but no different 
from the permission issues of a filesystem or any other resource.  I 
would assume that as part of the SylSec project, we will have some sort 
of global security token system where a process will have permission to 
access a certain branch of the hierarchy or a particular key/value pair 
based on the object's ACL and the process's credentials.  Slightly 
off-topic but I have found Windows NT's implementation of security in 
e.g. Active Directory or NTFS that supports BOTH "allow" and "deny" bits 
for many different operations, and supports different ways of 
propagating permissions up the hierarchy, extremely confusing!

Another aspect that may be challenging is how these security tokens and 
credentials could be manipulated and transferred between the kernel and 
user-mode for implementing objects and events in user-space.  One 
possibility is adding a special system call to allow one process to 
authenticate another over a message port, for example FreeBSD allows you 
to send the pid, uid, and group ID of the sending process to its peer on 
the other end of the socket (only over UNIX local domain sockets, not 
through TCP/IP) with SCM_CREDS (the Linux version is called SO_PEERCRED) 
using a special unspoofable message flag.  Sending credentials between 
machines would require something like Kerberos.  In the case of peer 
authenticating across a socket, you are not actually transferring any 
privileges between processes, just allowing a process to know for sure 
the uid/gid/pid of the process it's talking to.  A more useful thing 
would be a fully transferrable key system such as KeyKOS or EROS:

http://www.cis.upenn.edu/~KeyKOS/
http://www.cis.upenn.edu/~eros/

-Jake