Sandeep
Sandeep

Reputation: 131

Is the code for every system call loaded into address of each process?

I have read a few articles and watched some videos on youtube about system calls. What I've noticed is that a system call doesn't generally require a context switch to another process; instead, it is processed in the context of whichever process invoked it. I read that kernel code for the system calls and table for system calls are placed inside the address space of each process. In the address space of a process, kernel code lies at the top, and below that lies the call stack. But that code is only accessible in system calls. When a particular system call starts execution, its stack frame is also placed in the call stack of the process.

So my question is, when and how do all of these happen- the placement of kernel code for system calls and table for system call?

Upvotes: 0

Views: 700

Answers (1)

Brendan
Brendan

Reputation: 37262

The most common scenario is that that the CPU supports some kind of privilege level/s; the OS maps its code and data into every virtual address space as "requires highest privilege level to access" (in an area called "kernel space"), and normal processes are left using "lowest privilege level" so that if they try to access anything in the kernel the CPU refuses to allow it.

However; the CPU also provides various special control transfers that the OS can configure for things like IRQs and system calls.

Typically, for system calls, a program might call something like "write()" which will call a normal function in a (dynamically linked/shared) library (causing "write()" to be added to the call stack because it's just a normal function and not a system call itself). Inside the library, there'll be code to shuffle values around and prepare for a radically different calling convention, that uses some kind of special instruction (int 0x80 or syscall or sysenter or ...) designed to change the CPU's privilege level and transfer control to the kernel's system call handler. This special control transfer won't show up on the call stack (mostly because the CPU switches to a completely different stack all-together as part of that special instruction).

Once the kernel's system call handler is reached; it will probably (if kernel isn't written in assembly) shift more stuff around in registers to match normal calling conventions compilers use, and use a "function number' parameter to find/call the intended function (typically using an array of function pointers, with an "is the function number within a sane range" check to avoid "index out of bounds" problems).

Note: This is just the most common scenario (and very normal for Windows, OSX, Linux, etc); but different CPUs and different operating systems are different, and some times behavior is different for the same hardware/same OS. For one example, if an OS is running with "Meltdown vulnerability work-arounds" enabled it may do a virtual address space switch early in it's system call handler.

So my question is, when and how do all of these happen- the placement of kernel code for system calls and table for system call?

Most of this is set up during kernel initialization (during boot, likely before the first normal process is started); and once set up it's merely perpetuated (e.g. "kernel space" is preserved/cloned/mapped into each new virtual address space whenever a new virtual address space is created).

Upvotes: 1

Related Questions