Sharing locks between several address spaces

[Norman Feske]

Hi Sven,

the Lock is only meant to be used a process-local synchronization
primitive. For inter-process synchronization, we have the signal API.
As you just noticed, we use exregs on OKL4. This system call can
be used to manipulate threads in the same address space. The only
exception is that a pager of a thread can also manipulate the paged
thread residing in a remote address space. So your attempt to use the
Lock as cross-process synchronization facility will not work. If exregs
would be permitted to manipulate any thread, this would be a serious
security issue. So OKL4 prevents that.

The OKL4 mutex will not help you either because it does not provide
the full semantics of a binary semaphore. The OKL4 mutex assumes
that the lock holder is the thread that releases the lock. Genode's
Lock API however, has no such restriction. For example, we use
the Lock for thead-startup synchronization, which is generally not
possible with the OKL4 lock.

> In detail, the L4_ThreadWasHalted call which is performed upon 
> L4_ThreadSwitch returns false, hence the thread which tried the wake 
> operation remains spinning in the forever-loop (this is a nice 
> opportunity for a denial-of-service-attac of a malicious client by the 
> way...).

The Lock should never be shared between client and server but only
used locally. When used locally, this is no denial-of-service issue
because all threads within the same address space mutually trust each
other.

> However, I've started to investigate by replacing the L4_ThreadSwitch 
> syscall by L4_WaitNotify and the wake-operation by L4_Notify. The result 
> was the same.

In the past, we have also experimented with 'L4_Notify' but decided
not to use this mechanism. In contrast to 'L4_Notify', the used
exregs-Mechanism does not interfere with IPC.

> Checking the error code of the L4_Notify syscall with L4_ErrorCode 
> showed that the call had been aborted due to L4_ErrInvalidThread, 
> respectively L4_ErrNonExist (2).

That is the expected behaviour if you attempt to manipulate a remote
thread not paged by the caller.

> Now I wonder if a thread is generally allowed to invoke syscalls on 
> threads which don't belong to its address space (maybe I need some 
> capability? What exactly is env()->pd_session()->bind_thread() for?).

The 'bind_thread' call associates a thread with an protection domain.
On OKL4, the physical thread creation takes place at this point.

> I've also noticed that the thread ids I get from 
> env()->cpu_session()->state() or from thread_get_my_native_id() differ 
> from those the kernel debugger shows (what exactly do you do when you 
> ask  Okl4::__L4_TCR_ThreadWord(Genode::UTCB_TCR_THREAD_WORD_MYSELF) for 
> a thread id? Is that the global thread id?)

It is indeed the global ID, allocated by core. When starting a
new thread, the global ID is written to the new thread's UTCB (the
user-defined handle):

  see file 'src/core/platform_thread.cc'
  function 'int Platform_thread::start'

You can see that this ID is the raw global ID. When the new thread
starts executing, it copies the user-defined handle to another UTCB
location (UTCB_TCR_THREAD_WORD_MYSELF) for later retrieval:

  see file 'src/base/thread/thread_bootstrap.cc'

I really want to discourage you from using the Lock for inter-process
synchronization and go for the signal API instead. This way, your
code stays true to the API and you do not introduce security problems
(as you just noticed). If you have a problem that cannot be solved
using the signal, IPC, and the other existing framework facilities, I
would be glad to design a clean solution together with you and
enhance the framework in a clean and portable manner.

> Perhaps you have an idea what's going wrong here (meanwhile I'd add 
> L4_MutexControl to core :o) ).

For which reason are you investigating the kernel mutexes? I would
not recommend using them. The limitations of the L4 mutex are subtile
and not documented, and will certainly yield to some frustration on
your side .-)

Best regards
Norman