System Calls

System Calls

essential for communication between user programs and OS

provide an interface for requesting OS services, such as file handling, memory management, and process control

a controlled entry point into the kernel that allows user-mode applications to request privileged operations

What API does the OS provide to User Programs?

A set of “system calls”

• System call is a function call into OS code that runs at a higher privilege level of CPU

• Sensitive operations (e.g., access to hardware) are allowed only at a higher privilege level

• Some “blocking” system calls cause the process to be blocked and descheduled (e.g., read from disk)

Need a mechanism to enter and exit the kernel safely

• Applications don’t call kernel functions directly - kernels provide protection

OS Block Diagram

top - user mode

bottom - kernel mode

Overview of Simple Calls

1. Indicate to the kernel that our process wants to run a certain system call

2. Switch from user-space to kernel-space through a well-defined mechanism to ensure security and stability

3. Verify security permissions

4. Perform the system call

5. Switch back from kernel-space to user-space

Simple Overview of a System Call

Overview of Longer Calls

Indicate to the kernel that our process wants to run a certain system call

Switch from user-space to kernel-space

Verify security permissions

• Start the system call

• If it takes too long, mark the process as un-runnable

• Context switch to other processes 1 or more times

• Upon finishing the call, mark the process as runnable

Switch back from kernel-space to user-space

Entry Points Provided by the Processor

• Interrupts

• Exceptions

Cause hardware to transfer control to the interrupt/exception handler, a fixed entry point in the kernel

Interrupts

generated by devices to signal needing attention

Interrupt Handler

a function in the kernel that services a device request

Exceptions

caused by processor

faults have occurred during the execution of a program

Entering Kernel-Space

• We cannot just call a kernel-space function with a normal function call command from our process, memory protection will block it

• Instead, the system C library provides a function for each system call which we can call normally

• Inside this function, it transfers into kernel-space

• In Linux/x86 this is traditionally done with an

  • int 0x80 software interrupt instruction

• This interrupt is setup by the kernel at boot time

• CPU will automatically jump to it in kernel mode

What is ‘int 0x80’?

• int 0x80 is a software interrupt instruction (32-bit Linux systems) to make system calls to the kernel

• It acts as a bridge between user-space programs and the kernel, allowing programs to request services such as file operations, memory allocation, and process management

• Executes int 0x80:

  • It triggers an interrupt (0x80)

  • CPU switch to kernel mode

  • Kernel executes the corresponding system call based on the value stored in the EAX register

Verifying Security

• Most OS enforces per-process security models

  • When a user process makes a system call, OS must ensure that the request is secure and valid before executing it. This process is called security verification

• Individual process may or may not be allowed to perform an operation

• If system calls did not require a kernel-space switch then any security checks could be bypassed by directly jmp-ing to the instruction after the check.

• Within the system calls, checks must also be made to ensure every parameter meets requirements, otherwise more security problems

• E.g., buffer overflows while in kernel mode

Other Approaches

Message-Passing in Micro-Kernels

Per-Process Virtualised Devices

Message-Passing in Micro-Kernels

• The primary method for communication between processes and between userspace applications and kernel services

• Unlike monolithic kernels, which use direct function calls, these depend on sending and receiving messages to interact with system components

How Message-Passing in Micro-Kernels Works

1. The process requests a service (e.g., file system, device driver). It constructs a message containing the request details

2. The process requests a system call to send the message. The kernel validates the request and queues the message

3. The kernel delivers the message to the appropriate server process

4. Server Processes the Request and prepares a response

5. The server sends a reply message back to the requesting process

6. The kernel ensures correct delivery and synchronizes communication

7. The client process receives the response and continues execution

Per-Process Virtualised Devices

• Each process perceives and interacts with its own virtual instance of a device, rather than accessing the physical hardware directly

• This approach is commonly used in operating systems to improve security, isolation, and resource management.

• Still a research topic. See DragonFlyBSD and Arrakis for examples

How Per-Process Virtualised Devices Works

1. The process issues a system call (e.g., read(), write(), open())

2. Instead of giving direct access to the physical device, the OS provides a virtualised instance adapted to the process

3. The kernel processes the request via device drivers and, if necessary, interacts with the actual hardware

4. The requested operation is completed, and the response is sent back to the process

Why use System Calls?

• Abstraction: Provides a standardised way to use hardware resources

• Security: Prevents user applications from directly accessing critical system resources

• Convenience: Simplifies complex hardware interactions

System Calls vs Function Calls