Section 8: Memory Protection and Isolation

8.1 Per-Process Isolation

The mechanism: As Section 3.4 explained, each process has its own private virtual address space. The MMU (Section 4) translates every access using that process's own page tables. A virtual address from one process means nothing inside another process. And no instruction in a user-mode program can say "give me physical address X" directly.

Process A's virtual address 0x00400000  →  physical address 0x1A2B3000
Process B's virtual address 0x00400000  →  physical address 0x7C001000
                (same virtual address, completely different, unrelated
                 physical memory — total isolation)

Why this matters: This is the whole reason one buggy or malicious app cannot read your browser's saved passwords, your editor's unsaved text, or any other program's data. It is not a polite software rule. The hardware itself has no way to let it happen.

Analogy: Each tenant's key card opens only their own door. There is no key card that says "open any door".

8.2 User Mode vs. Kernel Mode Access

This builds on Chapter 2, Section 6 and Section 4.6 of this chapter. Page table entries carry a supervisor bit. It says whether user-mode (Ring 3) code is allowed to touch that page at all.

Kernel-mode pages:  Supervisor bit = kernel-only
                    → User-mode access attempt = instant hardware fault

User-mode pages:    Supervisor bit = accessible from user mode
                    → Kernel mode can still access these too

Windows maps kernel memory into the same address space as every user-mode process. This is for efficiency: switching privilege levels then does not need a switch of page tables. But Windows relies fully on the permission bit to keep user-mode code out. That is the real hardware explanation for why an ordinary app "cannot see" kernel memory, even though it is technically mapped close by.

8.3 Access Violations

What it is: The Windows name for what happens when a program's memory access breaks the permission or isolation rules above. It is the OS's reaction to the hardware page fault / protection fault (Chapter 2, Section 7.4) when it is not a normal, fixable case.

Common causes:

• Using a null pointer (accessing virtual address 0, which is deliberately left unmapped so that this common bug is always caught)
• Using memory that was already freed (a "use-after-free" bug)
• Writing to a read-only page (for example, trying to change the code segment)
• Using an address completely outside the process's valid ranges

What happens: The CPU's MMU spots the violation and raises a hardware fault. The OS's fault handler sees that this is not a normal, fixable page fault (like a minor fault or a legitimate page-in from Section 5.2), so it ends the offending process. This is behind the familiar "Application has stopped working" message.

8.4 Stack Overflow

What it is: An access violation that happens when a thread's stack (Section 6.1) grows past its fixed size limit.

Common causes:

• Unbounded recursion: a function that calls itself with no proper stopping rule (a "base case"). Each call pushes a new stack frame until the limit is hit
• Huge local variables: making a very large array as a local (stack) variable instead of putting it on the heap

void recurse() {
    recurse();   // no base case — calls itself forever,
                 // pushing a new stack frame each time,
                 // until the stack's fixed size is exhausted
}

Windows catches this by putting a special guard page just past the end of each thread's stack. The moment the stack grows into the guard page, a fault is raised. This is a deliberate trip-wire, not luck. The process is ended with a stack overflow exception, instead of being allowed to quietly damage whatever memory happens to lie past the stack.

8.5 Buffer Overflow Security

What it is: A bug where a program writes more data into a buffer (a fixed-size block of memory, often on the stack) than the buffer was made to hold. The extra data overwrites the neighbouring memory that should not be touched.

char buffer[8];
strcpy(buffer, "this string is way longer than 8 bytes");
// writes past the end of buffer[8], overwriting whatever
// memory happens to sit right after it on the stack —
// potentially including the function's saved return address

Why this is a serious security problem, not just a bug: If the overflow reaches far enough to overwrite the saved return address on the stack (Section 6.1), an attacker who controls the overflowing data may be able to redirect the program to run the attacker's own code the moment the current function returns. This is the classic mechanism behind many past remote-code-execution attacks.

Modern defences (each links back to ideas from this chapter and Chapter 2):

Key takeaway: Everything in this section — process isolation, privilege-level page permissions, stack guard pages and overflow defences — is one idea used at different scales. Memory protection is not a single feature. It is the combined result of the CPU's MMU, the OS's memory manager, and the compiler/runtime, each enforcing boundaries at its own layer.

Summary