2.2 Windows, macOS, Linux, Android, and iOS Basics
Two Worlds: User Mode and Kernel Mode
All five platforms split memory the same way. Applications run in user mode, where the CPU refuses direct access to hardware or another process's pages; the kernel runs in the highest privilege level (ring 0 on x86, EL1 on ARM64) and owns drivers, the scheduler, and the filesystem. The only door between the two is the system call: a program executes a special instruction (the syscall opcode on x86-64, svc on ARM64), the CPU switches to kernel mode, validates the call number and arguments, and returns a result. A call like write(fd, buf, 4096) is the kernel acting for the app; refusing a descriptor the app never earned is the sandbox working as designed.
Kernel Paradigms and Sandbox Architectures
The kernels differ in shape. Linux is monolithic: filesystems, network stack, and most drivers share one address space as vmlinuz plus loadable .ko modules, so a single driver bug is a kernel bug. Windows NT is hybrid, pairing the ntoskrnl.exe executive with client/server subsystems like csrss.exe. Apple's XNU (macOS and iOS) welds a Mach microkernel to a BSD layer. Android runs the Linux kernel with mobile-specific pieces such as the binder IPC driver and the zygote process spawner. On top of those kernels, each platform sandboxes differently: Android assigns every app its own UID (visible as u0_a123 in ps) plus an SELinux domain like untrusted_app; iOS confines each app to /var/mobile/Containers/Data/Application/<UUID> and gates features behind code-signing entitlements; macOS App Sandbox uses the Seatbelt policy engine, the same one behind sandbox-exec -p; Windows uses UAC integrity levels and AppContainer SIDs (S-1-15-2-...) for Store apps; and Linux sandboxing is hand-assembled from namespaces plus a seccomp-bpf syscall filter with no_new_privs set, which is exactly what Flatpak and Chrome's renderer use.
Updates Are a Security Boundary, Not a Chore
Patching is how each vendor retires exploited code paths. Windows defers servicing in days via Windows Update for Business rings; a home user just installs the monthly cumulative update. macOS and iOS accept only vendor-signed updates (stub updates shave bytes; full IPSW images restore the whole OS). Linux patching flows through the distribution: sudo apt update && sudo apt full-upgrade or sudo dnf upgrade pulls cryptographically signed packages. Android mixes kernel OTA payloads from the OEM with signed Mainline/APEX modules delivered like apps. Watch for end-of-life: once signed updates stop, every future CVE becomes permanent, the strongest reason to retire old devices.
Architecture Diagram
Key Takeaways
- All five platforms separate user mode from kernel mode; the syscall is the only legitimate door between them.
- Linux is monolithic, Windows NT and Apple XNU are hybrids, and Android is Linux plus
binderandzygote. - Sandbox mechanisms differ (UIDs and SELinux on Android, entitlements on iOS, Seatbelt on macOS, AppContainer on Windows, seccomp plus namespaces on Linux) but all shrink the blast radius of a buggy app.
- Updates deliver signed fixes through rings, IPSWs, distro repositories, or APEX modules; skipping them keeps known exploits alive.
- End-of-life devices stop receiving signed updates, so patching ability should drive hardware retirement decisions.