Re: light weight user level semaphores

[Bernd Eckenfels]

In article <[e-mail]> you wrote:
>   So FS_create() starts out by allocating the backing store for the
>   semaphore. This can basically be done in user space, although the
>   kernel does need to get involved for the second part of it, which
>   is to (a) allocate a kernel "backing store" thing that contains the
>   waiters and the wait-queues for other processes and (b) fill in the
>   opaque 128-bit area with the initial count AND the magic to make it
>   fly. More on the magic later.

>   So the second part of FS_create needs a new system call.

How will the clean up of the kernelstore work?

> - The user must _not_ be able to fool the kernel into using a completely
>   non-existing semaphore.

In that case the access to kernel level is protected by a very secure
combination of secure hash and magic number checking. But anyway there is a
small chance to get to some kernel memory unauthorized. Do you know if this is
the first (known) interface which has a more practical approach to kernel data
structure security?

If we want to be a bit more strict, we can have a pre-allocated pool of
semaphores and the kernel pointer check can add the kernelk address of the
semaphore region into account. It's faster than the checksum probably and more
secure in protecting the rest of the kernel memory. Spoofing access to other
semaphores would be still possible (but can be protected by a smaller hash).

Greetings
Bernd