The one program that is running at all times in the computer is the kernel.

The Kernel is the heart of an operating system.

• For example, Ubuntu OS is about 2.7GB, but its Kernel (Linux) size is only about 70MB).
• It operates on the physical space — meaning that it has full knowledge of all physical addresses instead of virtual addresses, and has the complete privilege over all the hardware of the computer system.
• The only way to access the kernel code is when a process runs in the Kernel mode, via very specific controlled entry points.

You have learned this before: for instance via ILLOP, IRQ, and RESET.

Kernel Mode

The kernel runs with special privileges, called the kernel mode. It can do what normal user program cannot do:

1. Ultimate access and control to all hardware in the computer system (mouse, keyboard, display, network cards, disk, RAM, CPU, etc)
2. Know (and lives in) the physical address space and manages the memory hierarchy
3. Interrupt other user programs
4. Receive and manage I/O requests
5. Manage other user program locations on the RAM, the MMU, and schedule user program executions

In order for the kernel to have more privileges than other user mode programs, the computer hardware has to support dual mode operation.

You have learned this before as well, i.e: PC31 in the Beta CPU indicates whether the current instruction is run in the Kernel mode or the User mode.

Hardware Support for Dual Mode Operation

The dual mode is possible iff it is supported by the hardware. The kernel is also uninterruptible and this interruptible feature is also supported by the hardware.

Differences between architectures

In 50.002, we have learned that the control logic unit prevents the PC to JMP to memory address with MSB bit of 1 (where the kernel program resides) when it is at memory address with MSB bit 0 (where user programs reside).

• Also, the control logic unit does not trap the PC onto the handler when an interrupt signal is present if the PC is running in kernel mode (MSB of the PC is 1).

In the Linux system, low memory is dedicated for the kernel and high memory is assigned for user processes. It is essentially the same as what we have learned before: the concept of having dual mode and hardware support.

• Its hardware prevents the PC from jumping illegally (not via handlers) to a lower memory address (MSB = 0) when it was from a higher memory address (MSB = 1).

The Big Picture

A general purpose CPU has at least dual mode operation that should supported by its hardware:

1. The Kernel mode (privileged) : the executing code has complete and unrestricted access to the underlying hardware.
2. The User mode (unprivileged) : all user programs such as a web browser, word editor, etc and also system programs such as compiler, assembler, file explorer, etc. Runs on virtual machine

User programs have to perform system calls (supervisor call) when they require services from the kernel, such as access to the hardware or I/O devices. When they perform system calls, the user program changes its mode to the kernel mode and began executing the kernel instructions handling that call instead of their own program instructions. When the system call returns, the PC resumes the execution of the user program.

Booting

Booting is the process of starting up a computer. It is usually hardware initiated — (by the start button that users press) — meaning that users physically initiate simple hardwired procedures to kickstart the chain of events that loads the firmware (BIOS) and eventually the entire OS to the main memory to be executed by the CPU. This process of loading basic software to help kickstart operation of a computer system after a hard reset or power on is called bootstrapping.

Recall that programs (including the operating system kernel) must load into the main memory before it can be executed. However, at the instance when the start button is pressed, there’s no program that resides in the RAM yet and therefore nothing can be executed in the CPU.

We require a software to load another software into the RAM — this results in a paradox.

The Booting Paradox

To solve this paradox, the bare minimum that should be done in the hardware level upon pressing of the start button is to load a special program onto the main memory from a dedicated input unit: a read-only-memory (ROM) that comes with a computer when it is produced and that cannot be erased. This special program is generally known as firmware or BIOS¹.

After the firmware is loaded onto the main memory through hardwired procedures, the CPU may execute it and initialise all aspects of the system, such as:

1. Prepare all attached devices in a state that is ready to be used by the OS
2. Loads other programs — which in turn loads more and more complex programs,
3. Loads the Kernel from disk
4. When the system boots, the hardware starts in the kernel mode. After being loaded, the Kernel will perform the majority of system setups (driver init, memory management, interrupts, etc). Afterwards, the rest of the OS is loaded and then user processes are started in user mode.

The figure below summarises the booting process:

Note that the figure is heavily simplified for illustration purposes only.

Computer System I/O Operation

There are two types of hardware in the computer system that are capable of running instructions:

1. The CPU (obviously!)
2. I/O device controllers

Each I/O device is managed by an autonomous hardware entity called the device controllers as shown in the figure below:

In other words, I/O devices and the CPU can execute instructions in parallel. They are independent of one another and are asynchronous

Device Drivers

A system must have device drivers installed for each device type. This driver is a specific program to interpret the behavior of each device type. We typically install/download device drivers when we plug in new I/O units to our computers through the USB port.

It provides a software interface to hardware devices so that the device controller is able to communicate with the OS or an application program.

Running Device Drivers

Some default device drivers are part of the kernel code, and may consist of interfaces that control one or more common devices that can be attached to a system, such as hard disks, GPUs, keyboards, mouses, monitors, and network interfaces. In other words, device drivers are modules that can be plugged into an OS to handle a particular device or category of similar devices. Many drivers run in kernel mode (therefore some requires reboot upon installation), but there are also drivers that can run in user mode.

Those drivers that run in user mode will be slower in comparison, since frequent switching to kernel mode is required to access the serial ports of the device controller that’s connected to the external devices. However, if it was poorly written, it will not endanger the system by, for example, accidentally overwriting the kernel memory.

For drivers that run in kernel mode, vulnerabilities in these drivers can pose a serious threat as they can allow an attacker to escalate privileges to the highest level and become highly persistent.

One should only install drivers from trusted vendors.

Device Controllers

Device controllers are electronic components inside a computer that are in charge of specific types of devices. Components that make up the device controllers:

1. Registers — contains instructions that can be read by an appropriate device driver program at the CPU
2. Local memory buffer — contains instructions and data that will be fetched by the CPU when executing the device driver program, and ultimately loaded onto the RAM.
3. A simple program to communicate with the device driver

I/O operation happens when there’s transfer of data between the local memory buffer of the device controller and the device itself.

The I/O operation simply means:

1. Output: Move data from the device controller’s buffer to the output device, or
2. Input: From the input device to the device controller’s buffer.

Since the device controller and our CPU are asynchronous (can operate independently, in parallel), we need to devise a way to coordinate between servicing I/O requests and executing other user programs. This I/O handling issue is handled by our OS Kernel (read along to understand how).

Roles of an Operating System Kernel

There are several purposes of an operating system: as a resource allocator, controls program execution, and guarantees security in the computer system. The next few notes will touch on each of these topics.