페이지

2022년 4월 18일 월요일

1.4.2 Dual-Mode and Multimode Operation

 Since the operating system and its users share the hardware and sofware resources of the computer system, a properly designed opoerating system must ensure that an incorrect (or malicious) program cannot cause other programs-or the operating system itself-to execute incorrectly. In order to ensure the proper execution of the system, we must be able to distinuish between the execution of operating-system code and user-defined code. The approach taken by most computer systems is to provide hardware support that allows differentiation among various modes of execution.

At the vary least, we need two separate modes of operating; user mode and kernel mode(also called supervisor mode, system mode, or privileged mode). A bit, called the mode bit, is added to the hardware of the computer to indicate the current mode; kernel(0) or user(1). With the mode bit, we can distinguish between a task that is executed on behalf of the operating system and one that is executed on behalf of the user. When the computer system is executing on behalf of a user application, the system is in user mode. However, when a user application requests a service from the operating system(via a system call), the system must transition from user to kernel mode to fulfill the request. This is shown in Figure 1.13. As we shall see, this architectural enhancement is useful for many other aspects of system operation as well.

At system boot time, the hardeare starts in kernel mode. The operating system is then loaded and starts user applications in user mode. Whenever a trap or interrupt occurs, the hardware switches from user mode to kernel mode(that is, changes the state of the mode bit to 0). Thus, whenever the operating system gains control of the computer, it is in kernel mode. The system always switches to user mode(by setting the mode bitg to 1)before passing control to a user program.

The dual mode of operation provides us with the means for protecting the operating system from errant users-and errant users from one another. We accomplish this protection by designating  some of the machine instructions that may cause harm as privileged instructions. The hardware allows privileged instructions to be executed only in kernel mode. If an attempt is made to execute a privileged instruction in user mode. the hardware does not execute the instruction but rather treats it as illegal and traps it to the operating system.

The instruction to switch to kernel mode is an example of a privileged instruction. Some other examples incude I/O control. timer management, and interrupt management. Many additional privileged instructions are discussed throughout the text.

The concept of modes can be extended beyond two modes. For example Intel processors have four separate protection rings, where ring 0 is kernel mode and ring 3 is user mode. (Although rings 1 and 2 could be used for various operating-system services, in practice they are rarely used.) ARMv8 systems have seven modes. CPUs that support virtualization (Section 18.1) frequently have a separate mode to indicate when the virtual machine manager(VMM)is in control of the system. In this mode, the VMM has more privileges than user processes but fewer than the kernel. It needts that level of provilege so it can create and manage virtual machines, changing the CPU state to do so.

We can now better understand the  life cycle of instruction execution in a computer system. Initial control resides in the operating system, where instructions are executed in kernel mode. When control is given to a suer application, the mode is set to user mode. Eventually, control is switched back to the operating system via an interrupt, trap, or a system call. Most contem porary operating systems-such as Microsoft Windows, Unix, and Linux-take advantage of this dual0-mode feature and provide greater protection for the operating system.

System calls provide the means for a user program to ask the operating system to perform tasks rewserved for the operating system on the user program's behalf. A system call is invoked in a variety of ways, depending on the functionality provided by the underlying processor. In all forms, it is the method used by a process to request action by the operating system. A system call usually takes the form of a trap to a specific location in the interrupt vector. This trap can be executed by a generic trap instruction, although some systems have a specific syscall inst5ruction to invoke a system call.

When a system call is executed, it is typically treated by the hardware as a software interrupt. Control passes though the interrupt vector to a service rouine in the operating system, and the mode gbit is set to kernel mode. The system-call service routine is a part of  the operating system. The kernel examines the interrupting instruction to determine what system call has occurred; a parameter indicates what type of service the user program is requesting Additional information needed for the request may be passed in registers, on the stack, or in memory (with pointers to the memory locations passed in registers). The kernel verifies that the parameters are correct and legal, executes the request, and returns control to the instruction following the system call. We describe system calls more fully in Section 2.3.

Once hardware protection is in place, it detects errors that violate modes. These errors are normally handled by the operating system. If a user program fails in some way-such as by making an attempt either to execute an illegal instruction or to access memory that is not in the user's address space-than the hardware traps to the operating system. The trap transfers control through the interrupt vector to the operating system. The trap transfers control through the interrupt vector to the operating system, just as an interrupt does. Wehn a program error occurs, the operating system must terminate the program abnormally. This situaltion is handled by the same code as a user-requested abnormal termination. An appropriate error message is given, and the memory of the program may be dumped. The memroy dump is usually written to a file so that the user or programmer can examine it and perhaps conrrect it and restart the program.



댓글 없음: