HardenedBSD/libexec
John Polstra cf98e66403 Fix a bug which could cause programs with user threads packages to
lock against themselves, causing infinite spinning.  Brian Feldman
found this problem when testing with Mozilla and supplied the fix,
which I have revised slightly.

Here is the failure scenario.  A thread calls dlopen() and acquires
the writer lock.  While the thread still holds the lock, a signal
is delivered and caught.  The signal handler tries to call a function
which hasn't been bound yet.  It thus enters the dynamic linker
and tries to acquire the reader lock.  Since the writer lock is
already held, it will spin forever in the signal handler.  The
thread holding the lock won't be able to progress and release the
lock.

The solution is to block almost all signals while holding the
exclusive lock.

A similar problem could conceivably occur in the opposite order.
Namely, a thread is holding the reader lock and then a signal
handler calls dlopen() or dlclose() and spins waiting for the writer
lock.  We deal with this administratively by proclaiming that signal
handlers aren't allowed to call dlopen() or dlclose().  Actually
we don't have to proclaim a thing, since signal handlers aren't
allowed to call any system functions except those which are explicitly
permitted.

Submitted by:	Brian Fundakowski Feldman <green>
2000-07-17 17:18:13 +00:00
..
atrun
bootpd
comsat
fingerd
ftpd
getNAME
getty
mail.local
makekey
mknetid
named-xfer
pppoed
rbootd
revnetgroup
rexecd
rlogind
rpc.rquotad
rpc.rstatd
rpc.rusersd
rpc.rwalld
rpc.sprayd
rshd
rtld-aout
rtld-elf Fix a bug which could cause programs with user threads packages to 2000-07-17 17:18:13 +00:00
smrsh
talkd
telnetd
tftpd
uucpd
xtend
ypxfr
Makefile
Makefile.inc