The futex and kutex implementations used the same linked list for waiting,
however the futex implementation used kutexs and the same thread could be in
the same list twice in the case of contention. This case corrupted the wait
lists and led to deadlocks and lost wakeups. This change fixes the problem
by having separate data structures for futexes and kutexes.
Mutexes contended by multiple threads could lead to lost wakeups since only
one contended thread was awoken and subsequent unlocks are unaware of the
unawakened contended threads. This change fixes the problem with a temporary
solution of waking all the contended threads until a better design is
implemented.
Additional details are tweaked to be more reliable and simpler.
The idle thread is now actually run when the system is idle because it
truly goes idle. The idle thread is made power efficient by using the hlt
instruction rather than a busy loop.
The new futex(2) system call is used to implement fast user-space mutexes,
condition variables, and semaphores. The same backend and design is used as
kutexes for truly sleeping kernel mutexes and condition variables.
The new exit_thread(2) flag EXIT_THREAD_FUTEX_WAKE wakes a futex.
Sleeping on clocks in the kernel now uses timers for true sleep.
The interrupt worker thread now truly sleeps when idle.
Kernel threads are now named.
This is a compatible ABI change.
The child processes of pid 1 were being reparented to pid 1, causing an
infinite loop. This change fixes the problem by adding a hook that runs in
the last thread about to exit in a process. When pid 1 exits, the hook will
prevent more processes and threads from being created, and then broadcast
kill all processes and threads. The hook is not run in LastPrayer(), as that
function runs in a worker thread and it can't block waiting for another
thread to run LastPrayer() in the same thread.
This change hardens against invalid calls to sigreturn, which is a very
useful gadget when compromising a process. The system call now verifies
it is a real return from a signal and aborts the process otherwise. This
should render such attacks impossible in threads that are not servicing a
signal, and infeasible in threads that are handling signals they are yet to
return from.
The kernel now keeps track for each thread how many signals are being
handled but haven't returned yet.
Each thread now has a random signal value. It is re-randomized when the
thread handles a signal and the current signal counter is zero. This is
xorred with the context address and used as canary on the stack during
signal dispatch, protecting the saved context on the stack. This works
mostly like the regular stack protector.
The kernel now keeps track of the stack pointer for a single handled
signal per thread. It doesn't seem worth it to keep track of multiple
handled signals, as more than one is rare. Note that each delivered signal
will not necessarily result in a sigreturn because it is valid for a thread
to longjmp(3) out of a signal handler to a valid jmp_buf.
The sigreturn system call will abort if either:
- It was not called from the kernel sigreturn page.
- The thread is not currently processing a signal.
- The thread is processing a single signal, and the stack pointer did not
have the expected value.
- It fails to read the context on the stack.
- The canary is wrong.
I hereby relicense all my work on Sortix under the ISC license as below.
All Sortix contributions by other people are already under this license,
are not substantial enough to be copyrightable, or have been removed.
All imported code from other projects is compatible with this license.
All GPL licensed code from other projects had previously been removed.
Copyright 2011-2016 Jonas 'Sortie' Termansen and contributors.
Permission to use, copy, modify, and distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
