程序如何知晓内存访问是否被允许？程序执行器运行时判断内存访问权限的机制解析

Great question—let's dive into exactly how your OS and hardware team up to catch those invalid memory accesses that cause segmentation faults. This is a tight collaboration between CPU hardware and the operating system kernel.

Virtual Memory & Address Translation Basics #

First, remember modern programs don’t touch physical memory directly—they work with a virtual address space. Every process gets its own isolated set of virtual addresses, making it feel like it has the entire system’s memory to itself.

When your program tries to read or write to a memory address, the CPU sends that virtual address to the MMU (Memory Management Unit)—a hardware component built right into the CPU. The MMU’s core job is to translate that virtual address into a real physical memory address using a lookup table called the page table, which is fully managed by the OS.

Page Table Entries: The Permission Gatekeepers #

Each entry in the page table (called a PTE) does more than just map virtual pages to physical pages—it includes critical permission flags the MMU checks before allowing any memory access:

• Read/Write/Execute flags: For example, code pages (where your program’s instructions live) are marked read-only + execute (so you can’t accidentally overwrite your own code), while data pages are set to read/write.
• Present flag: Marks whether the virtual page is actually mapped to physical memory (or if it’s been swapped to disk, or never allocated at all).
• User/Supervisor flag: Blocks user-space programs from accessing kernel-only memory addresses, preventing them from messing with OS internals.

If your program violates any of these flags, the MMU immediately flags an error. Common examples:

• Writing to a read-only page (like trying to modify a string literal)
• Accessing a virtual address with the "present" flag set to 0 (like a null pointer—most OSes map address 0 to an unassigned virtual page)
• Trying to read/write kernel memory from a regular user program

Hardware Traps & OS Response #

When the MMU detects an invalid access, it triggers a hardware trap—an emergency signal that yanks control away from your program and hands it to the OS kernel. The kernel then inspects the trap to figure out what’s wrong:

• If it’s a clear permission violation or invalid address (like accessing null), the kernel sends the SIGSEGV signal to the offending process. By default, this signal terminates the program and (if enabled) generates a core dump for debugging—this is the segmentation fault you see.
• Some traps are recoverable: For example, a "page fault" happens when the virtual page exists but is swapped to disk. The kernel will load the page back into physical memory, update the page table, and let your program resume without you noticing.

Common Segfault Scenarios to Tie It All Together #

To make this concrete, here are a few everyday cases where this mechanism kicks in:

• Dereferencing a null pointer: Virtual address 0 is mapped to an unassigned page (present flag = 0), so the MMU flags it, and the kernel sends SIGSEGV.
• Stack overflow: The OS allocates a fixed-size virtual address range for the stack. When your program exceeds this range, it tries to access an unmapped virtual page—boom, segfault.
• Use-after-free: When you free heap memory, the OS might mark the corresponding page as unassigned (present flag = 0) or reallocate it to another process. If your program tries to access that memory later, the MMU catches the invalid access.

内容的提问来源于stack exchange，提问作者zell