Computer Science › Systems
The hardware distinguishes exactly two execution modes — kernel and user — and enforces which instructions and memory each one can touch, the single mechanism every other OS-level protection guarantee in this discipline is ultimately built from.
A system call, a hardware interrupt, and a page fault look completely different to the programmer, but the CPU handles all three with the exact same trap mechanism — save the current state, jump to a fixed kernel entry point, and let the kernel sort out why it was called.
Tracing a single call like write() from a user-space library wrapper through the trap instruction, into the kernel's system-call table, through the actual kernel routine, and back — the concrete machinery behind every OS service a program ever asks for.
Every pointer and length a user program hands to a system call is a claim the kernel cannot trust — the same memory-safety failure mode already seen at the application level becomes catastrophic here, because the code trusting bad input is running with full privilege.
The shell's | operator connects one process's standard output directly to another's standard input through a kernel-managed byte buffer — the simplest, oldest, and still most common form of IPC on any Unix-like system.
The kernel maps the exact same physical page into two otherwise-isolated address spaces, giving both processes direct, zero-copy access to the same bytes — the fastest IPC mechanism there is, and the one that hands all synchronization responsibility straight back to the already-covered lock and semaphore mechanics.
Instead of a raw shared buffer or an undifferentiated byte stream, the kernel manages discrete, typed messages with their own delivery and ordering guarantees — trading shared memory's raw speed for safety, since the kernel mediates every access instead of trusting processes to coordinate correctly on their own.
The Berkeley sockets API presents communication with a process on the same machine and a process on the other side of the planet through the exact same read/write interface — the abstraction this discipline's IPC mechanisms converge on, and the one a future networking discipline builds directly on top of.
A hypervisor runs an entire guest operating system — kernel, drivers, and all — as if it had a whole machine to itself, by intercepting every privileged instruction the guest tries to execute and emulating its effect instead of letting it touch the real hardware.
Trap-and-emulate alone could not virtualize the real x86 instruction set, because a handful of privileged instructions failed to trap at all when run in user mode — the real reason Intel VT-x and AMD-V added a second privilege dimension purpose-built for hypervisors.
A container shares the host's single kernel and gets its isolated view of processes, network interfaces, and mounts entirely from namespaces, with cgroups capping the resources it can consume — no guest kernel to boot, which is exactly why containers start in milliseconds where a virtual machine takes seconds.
An access control list attaches to each object the exact list of subjects allowed to touch it and how — Unix's read/write/execute permission bits are a deliberately simplified, three-bucket version of this idea, and the concrete mechanism the OS uses to enforce the authorization policies already discussed abstractly elsewhere.
Instead of asking an object's ACL whether a subject may act on it, a capability is an unforgeable ticket a process already holds that proves it may — a genuinely different model, real in systems like seL4, that sidesteps the classic confused-deputy problem an ACL-based design is prone to.
chroot, seccomp, and dropping setuid privileges are all the same real idea applied at different granularities — give a running process the absolute minimum access it needs to do its job, so that if it is ever compromised, the blast radius is small on purpose, not by luck.
Following a single `docker run` from the shell's fork/exec through namespace and cgroup setup to the sandboxed process's first system call ties together every cluster in this discipline — and closes with an honest, numeric comparison of how much isolation a container, a VM, and a bare process each actually buy, and at what cost.
Part of the Computer Science curriculum.
The hardware distinguishes exactly two execution modes — kernel and user — and enforces which instructions and memory each one can touch, the single mechanism every other OS-level protection guarantee in this discipline is ultimately built from.
A system call, a hardware interrupt, and a page fault look completely different to the programmer, but the CPU handles all three with the exact same trap mechanism — save the current state, jump to a fixed kernel entry point, and let the kernel sort out why it was called.
Tracing a single call like write() from a user-space library wrapper through the trap instruction, into the kernel's system-call table, through the actual kernel routine, and back — the concrete machinery behind every OS service a program ever asks for.
Every pointer and length a user program hands to a system call is a claim the kernel cannot trust — the same memory-safety failure mode already seen at the application level becomes catastrophic here, because the code trusting bad input is running with full privilege.
The shell's | operator connects one process's standard output directly to another's standard input through a kernel-managed byte buffer — the simplest, oldest, and still most common form of IPC on any Unix-like system.
The kernel maps the exact same physical page into two otherwise-isolated address spaces, giving both processes direct, zero-copy access to the same bytes — the fastest IPC mechanism there is, and the one that hands all synchronization responsibility straight back to the already-covered lock and semaphore mechanics.
Instead of a raw shared buffer or an undifferentiated byte stream, the kernel manages discrete, typed messages with their own delivery and ordering guarantees — trading shared memory's raw speed for safety, since the kernel mediates every access instead of trusting processes to coordinate correctly on their own.
The Berkeley sockets API presents communication with a process on the same machine and a process on the other side of the planet through the exact same read/write interface — the abstraction this discipline's IPC mechanisms converge on, and the one a future networking discipline builds directly on top of.
A hypervisor runs an entire guest operating system — kernel, drivers, and all — as if it had a whole machine to itself, by intercepting every privileged instruction the guest tries to execute and emulating its effect instead of letting it touch the real hardware.
Trap-and-emulate alone could not virtualize the real x86 instruction set, because a handful of privileged instructions failed to trap at all when run in user mode — the real reason Intel VT-x and AMD-V added a second privilege dimension purpose-built for hypervisors.
A container shares the host's single kernel and gets its isolated view of processes, network interfaces, and mounts entirely from namespaces, with cgroups capping the resources it can consume — no guest kernel to boot, which is exactly why containers start in milliseconds where a virtual machine takes seconds.
An access control list attaches to each object the exact list of subjects allowed to touch it and how — Unix's read/write/execute permission bits are a deliberately simplified, three-bucket version of this idea, and the concrete mechanism the OS uses to enforce the authorization policies already discussed abstractly elsewhere.
Instead of asking an object's ACL whether a subject may act on it, a capability is an unforgeable ticket a process already holds that proves it may — a genuinely different model, real in systems like seL4, that sidesteps the classic confused-deputy problem an ACL-based design is prone to.
chroot, seccomp, and dropping setuid privileges are all the same real idea applied at different granularities — give a running process the absolute minimum access it needs to do its job, so that if it is ever compromised, the blast radius is small on purpose, not by luck.
Following a single `docker run` from the shell's fork/exec through namespace and cgroup setup to the sandboxed process's first system call ties together every cluster in this discipline — and closes with an honest, numeric comparison of how much isolation a container, a VM, and a bare process each actually buy, and at what cost.