Linux Kernel Architecture

(Jacob Rumans) #1

Chapter 5: Locking and Interprocess Communication


Oncefind_task_by_vpidhas found the task structure of the target process, the kernel dele-
gates the job of checking whether the process has the permissions needed to send the signal to
check_kill_permission, which uses the following query:

kernel/signal.c
static int check_kill_permission(int sig, struct siginfo *info,
struct task_struct *t)
{
...
if ((info == SEND_SIG_NOINFO || (!is_si_special(info) && SI_FROMUSER(info)))
&& ((sig != SIGCONT) ||
(task_session_nr(current) != task_session_nr(t)))
&& (current->euid ^ t->suid) && (current->euid ^ t->uid)
&& (current->uid ^ t->suid) && (current->uid ^ t->uid)
&& !capable(CAP_KILL))
return -EPERM;
...
}

It could be helpful to remember that the^operator implements an XOR operation, but otherwise the
checks are rather straightforward.

The remaining signal handling work is passed on tospecific_send_sig_info.

❑ If the signal is blocked (this can be checked withsig_ignored), handling is aborted immediately
to prevent further waste of time.
❑ send_signalgenerates a newsigqueueinstance (using the cachesigqueue_cachep), which is
filled with the signal data and added to the sigpending list of the target process.
❑ If the signal is delivered successfully and is not blocked, the process is woken with
signal_wake_upso that it is available for selection by the scheduler. TheTIF_SIGPENDINGflag is
also set to indicate to the kernel that it must deliver signals to the process.

Although the signal is sent after these actions, it does not trigger the signal handler. How this is done is
described below.

Processing the Signal Queue


Signal queue processing is not triggered by a system call but is initiated by the kernel each time a switch
is made from kernel mode to user mode, as mentioned in Chapter 14. Implementation is naturally very
architecture-specific because processing isinitiated in the assembly language code ofentry.S. Regardless
of the particular architecture, the ultimate effect of the actions performed is to invoke thedo_signal
function, which, although also platform-specific, behaves in much the same way on all systems.

❑ get_signal_to_delivergathers all information on the next signal to be delivered. It also
removes the signal from the process-specific pending list.
❑ handle_signalmanipulates the user mode stack of the process so that the signal handler is run
and not the normal program code after switching from kernel to user mode. This complicated
approach is necessary because the handler function may not be executed in kernel mode.
The stack is also modified so that thesigreturnsystem call is invoked when the handler
function terminates. How this is done depends on the particular architecture, but the kernel
Free download pdf