Does all system calls execute in kernel mode?

Question

Title says it all :).

But, let me expand a particular case.

So, far I have studied system calls that all require some interaction from hardware (like read(), write() etc.) so it makes sense to switch to kernel mode before executing those system calls (trap instruction).

Signals as I understand is purely software constructs meaning they are not directly generated by hardware (unlike interrupts). I understand them to be a message passing mechanism between processes (either kernel-kernel, kernel-user or user-user processes).

Kill is a system call which is used to send signals to a process. It does not interact with hardware directly. So why do we need to make costly switch to kernel mode for executing that system call? I have not found any evidence of "special" system calls which do not trap into kernel mode before starting execution. Hence, the question.

Answer 1

Yes, and no.

The original definition of a system call is/was a system support (OS) function that is called by a trap of some kind rather than a "normal" function call. So by that definition, every system call requires a switch to kernel mode, as if it didn't it wouldn't be a system call (just a normal system library call).

Over time, the distinction between system calls and library calls has been blurred, as things that are/were traditionally implemented as system calls (such as getpid or gettimeofday) were implemented other ways -- generally by having some fixed data the kernel would set up (and perhaps occasionally modify) for every process. On Linux, there is a concept of the "vdso" (virtual dynamic shared object) which is created for every user process for precisely this reason, and so some "system calls" are actually implemented as a normal call into this special memory space.

Even with this, the precise definition of which functions are system calls and which are not persists, as, for backwards compatibility, all system calls continue to be available via the trap/interrupt/syscall interface; it's just that those available in the vdso will generally never be called via the trap. This allows very old Linux binaries compiled before the vdso existed to continue to work.

Answer 2

A signal is not a communications channel, it's more like a bonk on the head that gets your attention but carries no information itself.

The semantics of SIGKILL, SIGSTOP, and others are requests to the process scheduler, not the target thread itself, so entry into the kernel space is required.

Signals are delivered by the process scheduler just before a thread is scheduled. This is why processes in uninterruptable sleep (D-state) cannot be removed if they never wake up; they never get scheduled so no signal can be delivered.