History log of /seL4-refos-master/libs/libmuslc/src/signal/sigqueue.c
Revision Date Author Comments
# 57174444 11-Dec-2013 Szabolcs Nagy <nsz@port70.net>

include cleanups: remove unused headers and add feature test macros


# 7cc49f98 30-Aug-2013 Rich Felker <dalias@aerifal.cx>

fix breakage in synccall due to incorrect signal restoration in sigqueue

commit 07827d1a82fb33262f686eda959857f0d28cd8fa seems to have
introduced this issue. sigqueue is called from the synccall core, at
which time, even implementation-internal signals are blocked. however,
pthread_sigmask removes the implementation-internal signals from the
old mask before returning, so that a process which began life with
them blocked will not be able to save a signal mask that has them
blocked, possibly causing them to become re-blocked later. however,
this was causing sigqueue to unblock the implementation-internal
signals during synccall, leading to deadlock.


# 07827d1a 30-Jul-2011 Rich Felker <dalias@aerifal.cx>

fix race condition in sigqueue

this race is fundamentally due to linux's bogus requirement that
userspace, rather than kernelspace, fill in the siginfo structure. an
intervening signal handler that calls fork could cause both the parent
and child process to send signals claiming to be from the parent,
which could in turn have harmful effects depending on what the
recipient does with the signal. we simply block all signals for the
interval between getuid and sigqueue syscalls (much like what raise()
does already) to prevent the race and make the getuid/sigqueue pair
atomic.

this will be a non-issue if linux is fixed to validate the siginfo
structure or fill it in from kernelspace.


# aa398f56 19-Mar-2011 Rich Felker <dalias@aerifal.cx>

global cleanup to use the new syscall interface


# dc54a7cb 10-Mar-2011 Rich Felker <dalias@aerifal.cx>

fix errors in sigqueue (potential information leak, wrong behavior)

1. any padding in the siginfo struct was not necessarily zero-filled,
so it might have contained private data off the caller's stack.

2. the uid and pid must be filled in from userspace. the previous
rsyscall fix broke rsyscalls because the values were always incorrect.


# 0b44a031 11-Feb-2011 Rich Felker <dalias@aerifal.cx>

initial check-in, version 0.5.0