The instruction your program is not allowed to run

Write a C program that opens a file. Compile it, and look at what it actually does with a tracer:

$ strace ./a.out
openat(AT_FDCWD, "notes.txt", O_RDONLY) = 3
read(3, "hello\n", 4096)              = 6
close(3)                               = 0

Your program did not touch the disk. It asked. Three times.

Why it had to ask

The processor runs in one of two modes, and it is the hardware that enforces the difference, not the operating system.

In user mode, the instructions that talk to devices, change memory mappings or alter the interrupt table simply fault. The processor refuses them. It does not matter what language you wrote, how clever the code is, or whether you are root: in user mode those instructions do not work.

In kernel mode they work.

Your program runs in user mode. Always.

The doorway

A system call is the one controlled way across. The program executes a trap instruction, and three things happen at once:

1. 1The processor switches to kernel mode.
2. 2It jumps to an address the kernel chose, not one the program supplied.
3. 3The kernel looks at what was asked and decides whether to do it.

That second point is the whole security model. A program cannot switch to kernel mode and continue running its own code, because the switch and the jump are one indivisible hardware action.