Re: sendsys security issue

[Eric Jacobs <eric@xxxxxxxxxxx>]

On Tue, 8 Nov 2005 10:13:53 +0100
Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx> wrote:

> 
> Other than the memory exhaustion Matt mentions, it is also about atomicy
> of process context state. A lot of the kernel depends on the UID not
> changing over time during a system call. sendsys breaks this and other
> assumptions from the single syscall modell.

Ok, please bear with me as I am new to the DragonFly system, but this
does not quite make sense to me.

sendsys shouldn't introduce any new concurrency issues. All it does is
allocate a sysun and fill in the message structure, and then dispatch to
the syscall using a function pointer. It specifically does not try to
find a service thread or do any queueing or scheduling, and that is IMHO
a highlight of the design.

In fact, sendsys is really quite like syscall currently. The major
differences are the different parameter passing convention and that
sendsys allows (but does not require) an EASYNC return. BTW, the EASYNC
return seems to pass a kernel address back as the error code.

The big departure for sendsys is when it will start interpreting the
'port' parameter to allow a user process access to multiple kernel/user
subsystems, and using lwkt_beginmsg() to act as a standard LWKT message
source. But even this shouldn't have concurrency implications, because
it is still up to each individual subsystem (via how it sets up its
ports) to determine whether it runs the request synchronously in the
thread of the caller or otherwise.

So, as we transition systems to use the service thread model, that seems
to me to be the ideal time to go through and make sure that those
systems can handle letting other code run when they relinquish control.
If there is code that has already been EASYNC-ized that is still
implicitly assuming that it monopolizes the thread of its caller
when it runs its requests, I would like to go through and fix those
systems. Any hints would be greatly appreciated.

Thanks again.
-Eric