> For the complete documentation index, see [llms.txt](https://alham-rizvi.gitbook.io/alhamrizvi/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://alham-rizvi.gitbook.io/alhamrizvi/linux-internals/00-foundations-hardware-and-low-level-concepts-for-absolute-beginners.md). # 00 - Foundations: Hardware & Low-Level Concepts for Absolute Beginners > Read this FIRST, before file 01. Every other file in this series assumes you know what a "register," a "bus," or "hex" is. This file assumes you know none of that. If a term here still confuses you later, come back - this is the file every other file's jargon traces back to. ```mermaid flowchart TB CPU["CPU (Central Processing Unit)
the 'brain' - does all calculation
and decision-making"] RAM["RAM (Memory)
fast, temporary storage -
erased when power is off"] Disk["Disk (SSD/HDD)
slow, PERMANENT storage -
keeps data with power off"] NIC["Network Card (NIC)
sends/receives data over
a network"] Bus["System Bus
the 'roads' connecting everything -
wires that carry data + addresses"] CPU <--> Bus RAM <--> Bus Disk <--> Bus NIC <--> Bus ``` * **CPU (Central Processing Unit)**: the chip that actually executes instructions - does arithmetic, makes decisions, moves data around. Everything else in a computer exists to feed it data or store its results. * **Core**: a CPU chip today usually contains multiple independent "cores," each capable of running its own stream of instructions at the same time - this is what "quad-core," "8-core," etc. means. * **Clock speed / clock cycle**: the CPU operates in discrete "ticks" (a crystal oscillator generates a steady electrical pulse). "3.5 GHz" means 3.5 billion ticks per second. Roughly one small step of work happens per tick (modern CPUs actually do several steps per tick via pipelining, but the mental model of "tick = a unit of work" is fine to start with). * **RAM (Random Access Memory)**: the computer's working memory - fast to read/write, but **volatile** (its contents disappear when power is cut). Programs and their data live here while running. * **Disk (SSD or HDD)**: **non-volatile** storage - much slower than RAM, but keeps data when the power is off. Your files, the OS itself, and installed programs live here when not actively running. * **Motherboard**: the physical circuit board everything plugs into; contains the **bus** wiring connecting CPU, RAM, disk controllers, etc. * **Firmware**: small, permanent software built into a hardware device (stored in a chip on the motherboard, not on the main disk) that runs before any OS is loaded - BIOS/UEFI (see file 02) is the motherboard's firmware. * **Bus**: the set of physical wires/circuitry that carries data and addresses between the CPU, RAM, and other components. When you read "the CPU reads from RAM over the memory bus," this is what's meant. * **DMA (Direct Memory Access)**: a mechanism letting a device (like a disk controller or network card) write directly into RAM without the CPU having to manually copy every byte - much faster for large transfers. *** ### 2. Bits, bytes, and how computers represent numbers * **Bit**: the smallest unit of information - a single `0` or `1`. Physically, a tiny electrical signal that's either "low" (0) or "high" (1). * **Byte**: a group of 8 bits, e.g. `01001010`. The standard unit for measuring memory/storage sizes (1 KB = 1024 bytes, 1 MB = 1024 KB, etc). * **Binary**: the base-2 number system computers natively use - every number is written using only digits 0 and 1. `1011` in binary = `11` in normal (base-10, "decimal") counting. * **Hexadecimal ("hex")**: base-16, used constantly in low-level computing as a compact, human-friendlier way to write binary data. Digits are `0-9` then `a-f` (or `A-F`). Written with a `0x` prefix in code, e.g. `0x1F` = 31 in decimal = `00011111` in binary. **Every byte maps cleanly to exactly 2 hex digits** - this is the entire reason hex is used everywhere instead of raw binary or decimal: `0xFF` = one full byte (`11111111` = 255), instantly recognizable. * **Word**: the "natural" chunk size a CPU operates on at once - on a 64-bit CPU, a word is typically 8 bytes (64 bits). "64-bit" and "32-bit" CPUs/systems refer to this natural chunk size (also roughly the size of a memory address the CPU can work with - see below). * **Endianness**: the order bytes of a multi-byte number are stored in memory. "Little-endian" (what x86/x86\_64 uses) stores the *least-significant* byte first. E.g. the number `0x12345678` is stored in memory as bytes `78 56 34 12`, not `12 34 56 78`. This trips up everyone the first time they look at raw memory in a debugger. *** ### 3. Memory addresses and pointers ```mermaid flowchart LR subgraph RAM["RAM - a giant numbered array of bytes"] direction LR b0["addr 0x00
byte: 0x48"] b1["addr 0x01
byte: 0x65"] b2["addr 0x02
byte: 0x6C"] b3["addr 0x03
byte: 0x6C"] b4["addr 0x04
byte: 0x6F"] end ptr["A pointer variable
holding value: 0x02"] -->|"points at"| b2 ``` * **Memory address**: every single byte of RAM has a unique numeric "location," similar to a house number on a street. Programs read/write memory by specifying an address. * **Pointer**: a variable whose *value is itself a memory address* - i.e., instead of holding actual data, it holds "the location where the real data lives." This is the single most important concept for understanding both C programming and memory-corruption security bugs: if you can trick a program into treating attacker-controlled data as if it were a pointer, you can often make it read or write memory it shouldn't. * **Dereferencing** a pointer: following the address it holds to actually read/write the data stored there. * **NULL pointer**: a pointer deliberately set to address `0`, conventionally meaning "this points at nothing valid." Using (dereferencing) a NULL pointer by mistake is one of the most common programming bugs ("segmentation fault" / "null pointer exception"). * **Array**: a sequence of same-sized values stored back-to-back in memory, accessed by an index (0, 1, 2, ...) that the program converts into "base address + index × size" to find each element. * **Buffer**: a chunk of memory (often an array of bytes) reserved to hold data temporarily, e.g. while reading a file or a network packet. A **buffer overflow** - writing more data into a buffer than it was sized to hold, spilling into adjacent memory - is one of the oldest and most common security bug classes in all of computing. *** ### 4. Inside the CPU: registers, instructions, and execution * **Register**: a tiny, extremely fast storage slot built directly into the CPU chip itself (not in RAM) - there are only a handful of these (roughly 16 general-purpose ones on x86\_64), each holding one word (8 bytes) of data. The CPU does essentially all of its actual calculation using registers, only reading/writing RAM when it needs data that doesn't currently fit in a register. * **General-purpose registers (x86\_64 naming)**: `rax`, `rbx`, `rcx`, `rdx`, `rsi`, `rdi`, `rbp`, `rsp`, and `r8`–`r15`. Different instructions use different registers for different conventional purposes (e.g. `rax` commonly holds a function's return value; `rsp` always points at the current top of the stack - see below). * **Instruction**: one single operation the CPU knows how to execute - "add these two numbers," "copy this value from memory to a register," "jump to a different instruction if this value is zero," etc. * **Machine code**: instructions in their raw binary form - the actual bytes the CPU reads and executes. Utterly unreadable to humans directly. * **Assembly language**: a thin, human-readable text representation of machine code - one line of assembly generally corresponds to exactly one machine instruction (e.g. `mov rax, 5` means "put the value 5 into register rax"). This is the lowest level most humans ever actually read or write. * **ISA (Instruction Set Architecture)**: the complete, defined vocabulary of instructions a particular family of CPUs understands. **x86** and **x86\_64** (also called **x64**, **amd64**) are ISA names - x86\_64 is the 64-bit extension of the older 32-bit x86 ISA, and is what almost all modern desktop/server/laptop CPUs (Intel, AMD) implement. * **Compiler**: a program that translates human-written source code (C, Rust, etc.) into machine code ahead of time, producing a runnable binary file. * **Assembler**: a program that translates human-written assembly language directly into machine code (a much more literal, 1-to-1 translation than a compiler does). * **Program counter / instruction pointer (`rip` on x86\_64)**: a special register holding the memory address of the *next* instruction the CPU is about to execute. Changing this value ("jumping") is how loops, function calls, and `if` statements are actually implemented at the hardware level. * **Flags register**: a special register where individual bits record facts about the most recent operation (e.g. "was the result zero?", "did the last subtraction go negative?") - later instructions (conditional jumps) check these bits to make decisions. *** ### 5. The stack and the heap (the two places program data lives) ```mermaid flowchart TB subgraph AS["One process's memory (simplified)"] direction TB Stack["THE STACK
grows DOWNWARD
- function calls, local variables,
return addresses -
automatically managed"] Gap["...unused space..."] Heap["THE HEAP
grows UPWARD
- malloc()'d data -
manually managed by the program"] Code["Program code (instructions)
+ global variables"] end Stack --- Gap --- Heap --- Code ``` * **The stack**: a region of memory used automatically for function calls * every time a function is called, a **stack frame** is pushed containing its local variables and the address to return to when it finishes; when the function returns, that frame is popped off. Managed entirely automatically by compiled code, following a strict last-in-first-out order. * **Stack frame**: one function call's chunk of the stack - its local variables, saved registers, and the **return address** (where execution should resume once this function finishes). * **Return address**: the memory address, saved on the stack when a function is called, that execution jumps back to once that function returns. Overwriting a saved return address (via a buffer overflow in a stack-allocated buffer) is the classic, original "stack smashing" exploitation technique. * **The heap**: a region of memory a program explicitly requests chunks of at runtime (via `malloc()` in C - see file 07) for data whose size or lifetime isn't known in advance. Unlike the stack, the program itself is responsible for both requesting *and later releasing* (`free()`-ing) heap memory - get this wrong and you get memory leaks, use-after-free bugs, or double-frees (file 04 and file 07 cover these in depth). * **Stack overflow**: exhausting all the memory reserved for the stack (commonly from a function calling itself, i.e. recursion, without ever stopping) - the program crashes. * **Segmentation fault ("segfault")**: a crash caused by a program trying to access memory it isn't allowed to touch (e.g. dereferencing a NULL or otherwise invalid pointer). The CPU itself detects this (via the page tables described in file 04) and forces the OS to stop the program. *** ### 6. Cache - why "close to the CPU" matters * **Cache**: a small amount of extremely fast memory sitting physically between the CPU and RAM, automatically storing recently/frequently used data so the CPU doesn't have to wait for slower RAM every time. * **L1 / L2 / L3 cache**: cache comes in tiers - L1 is tiniest and fastest (per-core), L3 is larger and slower but still far faster than RAM (often shared across all cores). Roughly: **register > L1 > L2 > L3 > RAM > disk**, trading size for speed at every step. * **Cache hit / cache miss**: a "hit" means the needed data was already in cache (fast); a "miss" means the CPU has to go all the way to RAM (slow) - a huge amount of hardware and software performance engineering exists purely to maximize cache hits. * **Side channel**: information that leaks not through a program's normal output, but through some observable side-effect of its execution - cache timing is the classic example (measuring how long a memory access took can reveal whether data was cached, which can leak secrets). This is the underlying idea behind Meltdown/Spectre-class CPU vulnerabilities mentioned in file 04. *** ### 7. Basic OS vocabulary this whole series assumes * **Operating System (OS)**: the software layer (Linux, Windows, macOS) that manages hardware on behalf of every other program, so individual programs don't need to know how to talk to a specific disk controller or network card directly. * **Kernel**: the core, most-privileged part of an OS - the part that actually manages memory, processes, and hardware directly (file 01 covers this in full depth). * **Program vs. process**: a **program** is a file sitting on disk (inert, not running); a **process** is that program actually loaded into RAM and executing, with its own memory, registers, and state. The same program file can be run as many separate, independent processes at once. * **Binary / executable**: a file containing compiled machine code, ready to be run as a process. * **Library**: a collection of pre-written, reusable code that other programs can call into instead of rewriting the same logic themselves (file 07 covers `libc`, the most fundamental one on Linux, in depth). * **File descriptor**: a small integer a running process uses to refer to an open file, socket, pipe, or other I/O resource - "fd 0/1/2" are conventionally standard input/output/error for every process. * **Syscall (system call)**: the formal, controlled way an ordinary program asks the kernel to do something on its behalf (open a file, send network data, create a new process) - file 01 covers exactly how this crosses from unprivileged to privileged CPU execution. ### --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://alham-rizvi.gitbook.io/alhamrizvi/linux-internals/00-foundations-hardware-and-low-level-concepts-for-absolute-beginners.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.