Dual Mode Operations & System Calls in operating system

Dual Mode Operations & System Calls in operating system

Dual Mode Operations & System Calls

Dual Mode Operations & System Calls are very important in operating system. Here is the detail article on Dual Mode Operations & System Calls in operating system.



The dual mode of operation provides us protection of the operating system from errant users. We accomplish this defense by designating some of the system instructions as privileged instructions that can cause harm. The hardware only allows for the execution of privileged instructions in kernel mode. An example of a privileged instruction is the command to switch to user mode. Other examples include monitoring of I/O, controlling timers and handling interruptions. To ensure proper operating system execution we must be able to differentiate between machine code execution and user defined code. Most computer systems have embraced the approach of offering hardware support that helps us to distinguish between different execution modes. We need two different operating modes: user mode and kernel mode (also called supervisor mode, system mode or privileged mode). Mode bit is applied to the computer’s hardware to signify current mode as: kernel (0 bit) or user (1 bit). With the aid of mode bit we can differentiate between a function performed on behalf of the operating system and one performed on behalf of the user.


  • Hardware begins in kernel mode at system boot time.
  • The operating system is then loaded, and user programs are started in user mode.
  • If a trap or interrupt occurs, the hardware transitions from user mode to kernel mode (i.e. changes the mode bit status to zero).
  • So it is in kernel mode once the operating system takes control of the machine.
  • Always move the device to user mode (by setting the bit mode to 1) before transferring power to the user program.
  • The device is in User mode while the operating program is working on behalf of the user client.
  • However, when a user application demands a service from the operating system (through a system call), it must switch from user to kernel mode in order to complete the request. This architectural improvement is, as we can see, also useful for many other aspects of device operation.


User Mode:

If user programs such as creating a text document or using some application software are running on the computer system, then the device is in user mode. If the user application requests a service from the operating system or an interrupt or a device call occurs then there will be a switch from user to kernel mode to satisfy the requests. In order to switch from kernel to user mode, then mode bit should be one.


Kernel Mode:

When the system boots, the hardware begins in kernel mode and it begins user program in user mode when the operating system is loaded. We have privileged instructions which execute only in kernel mode to protect the hardware. If user tries to run privileged instructions in user mode then the instructions will be viewed as illegal and the OS will be stuck.


Safe mode Switch:

Either the transition from user to kernel mode, or in the opposite direction, care must be taken to ensure that the kernel is not infected by a faulty or malicious user program. The context switch code needs to be carefully designed, and some amount of hardware support is required. To prevent ambiguity and minimize the risk of error, most operating systems have a standard sequence of kernel entry instructions whether due to interruptions, anomalies or system calls and a standard sequence of user-level return instructions, again regardless of the cause.

This specific sequence must at least provide for:

  • Atomic changes to processor state:

The transformation between the two must be performed atomically, so that at the same time the mode, program counter, stack, and memory security are all modified. The system counter and stack point to memory locations in the user process in user mode; memory security prevents user process access to any memory outside its area. In kernel mode, the program counter and stack point to the kernel’s memory locations; memory security is modified so that the kernel can access both its own data and that of the user process.


  • Limited entry:

The hardware must ensure that the entry point into the kernel is one set by the kernel to pass power to the operating system kernel. For example, the kernel code used to handle a system call for reading a file must first test whether the user program has permission to do so, and if not, the kernel will return an error. Without restricted entry points into the kernel, a malicious program might simply leap to perform the test right after the code, allowing any user to access any file in the file system.


  • Transparent restartable execution:

The processor saves its current state to memory on an interrupt, momentarily defers additional events, and sets the processor to run in kernel mode before switching to the interrupt or exception handler. The steps are reversed when the handler completes the processor state is restored from its saved position, with the program interrupted none the wiser.


types of system calls
types of system calls


System calls in operating system is very important. If a program needs access to the RAM or a hardware resource in user mode, it must ask the kernel to provide access to that resource. It is done by something which is called a system call. The mode is moved from user mode to kernel mode while a program is making a system call that’s as called context switching.


A system call is a way to communicate with the operating system for the programs. System call provides user programs with operating system resources through Application Program Interface (API). This offers an interface between a process and an operating system allowing processes at the user level to request operating system services. The API defines a set of functions that an application programmer has at his fingertips, including the parameters passed to each function and the return values that the programmer may anticipate.


System calls share most of the same interrupt and exception mechanism for switching between user and kernel mode. The kernel must execute its system calls in a manner that protects itself from any errors and attacks that could be caused by interface misuse.


Pair of stub are two short procedures that mediate between two contexts, in this case between the user program and the kernel. In the usual way, the user program calls the user stub, ignoring the fact that the method is actually implemented in the kernel. Trap instruction is named by the user stub. The hardware passes power to the kernel, vectoring the call handler to the machine. On the kernel side the handler serves as a stub, calling for routine implementation in the kernel. The operating system provides a library routine to the system call for each system call. This library routine takes its arguments, reformats them according to the operating system kernel specified calling convention, and executes a trap instruction.

The kernel stub has following tasks:

  • Locate system call arguments:

Any address supplied to a system call by a user program must be checked (to verify that it is a valid address within the user domain) and translated to a physical address that the kernel may use to access the memory.

  • Validate parameters:

Typically a file name would be a zero-terminated string, but the kernel can’t trust the user code to always function properly. The file name may be corrupted, it may point to memory beyond the region of the application or it may start within the memory region of the application but expand beyond it. The application may not be able to access the file, and so on. If an error is found, the kernel returns an error to the user program; otherwise the kernel must perform the operation on behalf of the client.

  • Copy before check:

The problem occurs when the program can change the user memory holding a system call parameter (such as the name of a file) after the check is performed, but before the parameter is used in the actual routine implementation. This is named as “Time of Check vs. Time of Use”, or TOCTOU. Although a mechanism can appear to end when a system call is made, this may be misleading.

  • Copy back any results:

When the system call reads data into a user memory buffer, the stub would need to copy the data from the kernel buffer into user memory to allow the program to access it. Again, the user address needs to be checked first by the kernel and converted to a kernel address before use. When the system call is completed, it returns to the stub which returns to the call handler. At this stage the stub takes steps to transfer back to the user process, the results of the system call.


Types of System Calls:

There are five types of system calls that are as followings:

  1. Process Management or Process Control
  2. File Management
  3. Device Management
  4. Information Maintenance
  5. Communications


Process Management:

Those system calls which deal with the processes such as process creation, process termination etc. It includes end, abort, wait, Signed Event, create, terminate, allocate and free memory. A running process must be capable of stopping execution either normal or abnormal. If execution is abnormally interrupted, a memory dump is always taken and can be searched with a debugger.



CreateProcess() ExitProcess() WaitForSingleObject()         (WINDOWS)

fork() exit() wait()                                                                 (LINUX)



File management:

Those system calls which can handle file manipulation jobs like creating a file, reading, and writing, etc. It also includes deleting, repositioning, opening, closing of a file. It also have a function to get and set file attributes.



CreateFile() ReadFile() WriteFile() CloseHandle()              (WINDOWS)

Open() Read() write() close()                                                (LINUX)


For more information about Operating Systems click here


Was this helpful?

2 / 0

Leave a Reply 0

Your email address will not be published. Required fields are marked *