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