How can the Operating System run on the same chip it is supposed to be managing?

Question

From my readings about Operating Systems (reading the basic material on Wikipedia, tech sites, etc) I've learned that the Operating System is a program that allows programs and applications to interact with the hardware in an efficient and safe way.

However I'm confused about how the Operating System oversees the computer's operation when it itself needs to be operated.

What do I mean? Well, the way I would imagine an Operating System to work, is that on a computer, there would be two CPUs. One that runs the OS all the time, and another that the OS uses to run the computer. However, it turns out that the OS is running on the same CPU that the other processes are. This is like a manager having to work on the same production line as his employees, and only gets to use the power tools when another employee is done with them. He would not be a very effective manager, since he wouldn't have the ability to issue orders if his employee is even slightly undisciplined.

So how can it be that the OS only runs part of the time on the same CPU that has to be shared between all the other processes? How does this end up working out?

Answer 1

Modern CPUs are aware of the OS up to a certain degree. They provide some "power tools" for the first one who claims them. Usually this is the boot loader, which then hands over control to the OS. One usually speaks of "kernel mode" vs "user mode" or "ring 0" vs "ring 3" to distinguish between the one process with the extra privileges and the rest.

These "power tools" are certain privileges for resource management: Control the memory, access to the hardware and how long user level code may be executed without interruption.

The CPU executes the OS with its special privileges when one of the following events occurs:

1. A user mode process explicitly hands over the control to the kernel mode process. This is called a syscall.
2. The kernel mode process can use its special privileges to register for certain events (e.g. external hardware sends a special signal to the CPU or a user space process tries to access a reserved resource). When such an even occurs, the CPU stops the user mode process immediately and hands over the control the the kernel mode process. Usually one speaks from an interrupt.

So the OS can run on the same chip because the chip is built for this. It can reserve special privileges for itself. The CPU may interrupt all other pieces of code without these special privileges anytime and hand over the control to the OS.

Some chips with very limited support (e.g. a microcontroller) don't have this support for special privileged code. These chips usually run without an OS. There is only one big program running, that can access the hardware directly, must respond to the hardware interrupts and can access any resources anytime. If that program makes one mistake, usually the whole thing crashes.

Answer 2

In their most primitive form, operating systems rely on processes being well-behaved and handing control back to the operating system from time-to-time. If a process is not well-behaved, then indeed it can happen that the operating system freezes.

Most CPU's however, have interrupts: an interrupt pauses the current process (preemption) and hands control back to the operating system. You can schedule interrupts to happen at specific intervals, or be triggered externally (for instance pushing the reset button).

Basically, the CPU switches back and forth between running the OS and running processes at a blazingly fast speed. Furthermore, CPU's have "user mode" and "kernel mode". Processes run in user mode and the OS runs in kernel mode. Running in user mode prevents a process from executing restricted commands (such as IO). If a process wants to write to the disk, it has to ask the OS to do so. The OS switches to kernel mode and does the write on behalf of the process (after making sure the process has the required permissions).

Answer 3

You don't need two different processor for microprocessor to run userspace and kernel space code. Basically it works in this way when you turn your computer on your Bios loads Bootloader( 512kb code on disk which ends 55aa bootloader signature) to ram and thru this bootloader your kernel get loaded to ram and runs forever till you shut your computer down. And your kernel manages memory and doesn't allow your kernel code which sits on ram won't get overwritten by user space code. For this purpose there are system calls which userspace code invoked by using these system calls and add your userspace code to ram and start to execute it. In operating systems this concept is researched as a Memory Management. Here is the link you can read it is very good for starting https://www.cs.bham.ac.uk/~exr/lectures/opsys/10_11/lectures/os-dev.pdf

Answer 4

To build on other answers, it is easier to understand if you think that the kernel itself is not a process but a management code. Any user process can shift from user mode to kernel mode and execute kernel code(priviledged instructions) by using some part of the kernel space. Then the process can go back to user mode and run in the user space again.