D686 — OS Zero to Hero Study Guide

UNIX STREAMS

A full-duplex I/O interface for character device drivers in UNIX System V

What is STREAMS?

STREAMS is a UNIX kernel framework that provides a standard, modular way to implement character-device I/O and network protocols. It creates a full-duplex communication channel between a user-space process and a device driver, with optional processing modules stacked in between.

Key Insight

A STREAM is like a pipeline of data transformers — raw data enters one end, gets processed by each module in sequence, and exits the other end transformed. Unlike a pipe (one-way), STREAMS are full-duplex (data flows both ways simultaneously).

The 3-Part Architecture

User Space ┌─────────────────────────────────────────┐ │ User Process (app) │ │ read() / write() / ioctl() │ └──────────────────┬──────────────────────┘ │ ┌──────────────────▼──────────────────────┐ ← STREAM HEAD │ Stream Head (sth) │ Interface between user & kernel │ Manages user ↔ kernel boundary │ Handles read/write system calls └──────────────────┬──────────────────────┘ │ ┌──────────────────▼──────────────────────┐ ← MODULE (optional, stackable) │ Module (e.g., TTY) │ Transforms data in both directions │ push() / pop() to add/remove │ Example: encryption, protocol layer └──────────────────┬──────────────────────┘ │ ┌──────────────────▼──────────────────────┐ ← STREAM DRIVER │ Stream Driver │ Actual hardware interface │ Communicates with the device │ Bottom of the stream └─────────────────────────────────────────┘ Kernel Space Device (e.g., serial port, NIC)

Stream Head

Topmost component. Interfaces with user-space. Handles read(), write(), ioctl() system calls. Converts between user and kernel data formats.

Modules

Middleware layers that transform data passing through. They can be pushed onto or popped off the stream at runtime. Examples: error correction, protocol processing.

Stream Driver

The bottommost component. Directly communicates with the hardware device. Like a regular device driver but STREAMS-compatible.

Message Queues

Data flows as messages, not raw bytes. Each component has a read queue and write queue. Enables flow control and priority messaging.

STREAMS vs Pipes

Feature	STREAMS	Pipes
Direction	Full-duplex (bidirectional)	Unidirectional
Data format	Structured messages with type/priority	Raw byte stream
Modularity	Modules can be pushed/popped dynamically	Fixed — no middleware
Flow control	Built-in (back-pressure on queues)	Kernel buffer only
Use case	Device drivers, network protocols	Inter-process communication

Key System Calls

Call	Purpose
`open()`	Opens a STREAM device, creating the stream
`close()`	Dismantles the stream and frees resources
`read() / write()`	Transfer data through the stream head
`ioctl(I_PUSH)`	Push a module onto the stream (add layer)
`ioctl(I_POP)`	Remove the topmost module
`putmsg()`	Send a structured message with control info
`getmsg()`	Receive a structured message

Exam Tip

Know the 3 components (stream head, module, driver) and that STREAMS is full-duplex while pipes are unidirectional. Know that modules can be dynamically pushed and popped.

File Systems

How operating systems organize, store, and retrieve data on disk

Virtual File System (VFS)

VFS is an abstraction layer in the kernel that provides a uniform interface for all file system types. Applications call generic functions like open(), read(), write() — VFS routes them to the correct underlying file system (ext4, NTFS, FAT32, etc.).

Application │ open(), read(), write(), close() ▼ ┌─────────────────────────────────┐ │ Virtual File System (VFS) │ ← Uniform interface └──────┬──────────┬──────────┬───┘ ▼ ▼ ▼ ext4 NTFS FAT32 ← Concrete file systems │ │ │ └──────────┴──────────┘ │ Block Device Layer (disk driver)

Inodes — The Heart of UNIX File Systems

An inode (index node) stores all metadata about a file EXCEPT its name. The directory maps filename → inode number.

What an inode stores:

File type (regular, directory, symlink)
Permissions (rwxrwxrwx)
Owner (UID) and group (GID)
File size in bytes
Timestamps (created, modified, accessed)
Link count (hard links pointing to this inode)
Pointers to data blocks

What an inode does NOT store:

The filename (stored in the directory)
The actual file content (stored in data blocks)

Memory Hook

Directory = Phone book (name → number). Inode = the person (all their info). Data blocks = what they actually say.

File Allocation Methods

Contiguous

All blocks stored consecutively on disk. Fast sequential access. Suffers from external fragmentation. Hard to grow files.

[ A | A | A | B | B | _ | C | C | C ]

Linked

Each block has a pointer to the next. No external fragmentation. Poor random access. Unreliable if a pointer breaks.

[A1|→4] [A2|→7] [A3|→0] scattered blocks

Indexed (FAT)

An index block holds all data block pointers. Supports random access. Index block overhead. FAT32 uses a global file allocation table.

Index: [4][7][12] → actual data blocks

Extents (ext4/APFS)

Stores (start block, length) pairs instead of individual block pointers. Efficient for large files. Reduces fragmentation.

Extent: start=100, len=50 → 50 contiguous blocks

Journaling

Journaling records intended changes to a log (journal) before writing them to disk. If the system crashes mid-write, the journal is replayed on recovery — preventing corruption.

1

Write to journal (log)

Metadata (and optionally data) is written to the journal first

2

Commit

A commit record marks the journal entry as complete

3

Write to disk

Changes are written to their final location on disk

4

Clear journal

Journal entry is freed after successful write

File System	Journaled?	OS
ext2	No	Linux (legacy)
ext3	Yes — metadata	Linux
ext4	Yes — metadata + extents	Linux (modern)
NTFS	Yes — $LogFile	Windows
APFS	Yes — copy-on-write	macOS/iOS
FAT32	No	Windows (legacy/flash)

Free Space Management

Bit Vector (Bitmap)

One bit per disk block. 0 = free, 1 = used. Fast to find contiguous free blocks. Requires extra space for the bitmap itself.

Linked Free List

Free blocks are linked together. No extra space needed (uses the free blocks themselves). Slow — must traverse the list to find contiguous space.

Exam Tips

ext2 = no journal (good for USB/flash). ext3 added journaling to ext2. ext4 added extents + multiblock allocation. NTFS uses $LogFile for journaling. FAT32 = no journal, 4GB file size limit.

Synchronization

Coordinating concurrent access to shared resources to prevent data corruption

The Problem: Race Conditions

A race condition occurs when two or more processes access and manipulate shared data concurrently, and the final result depends on the order of execution — which is unpredictable.

// Two threads both execute: counter++
// counter++ is actually 3 operations:
LOAD  R1, counter    // read value
ADD   R1, #1         // increment
STORE counter, R1    // write back

// If two threads interleave → counter ends up as 1 instead of 2!

Critical Section Requirements

A critical section is a code segment that accesses shared resources. Any correct solution must satisfy ALL three:

1. Mutual Exclusion

Only ONE process can be inside the critical section at a time.

2. Progress

If no one is in the CS and someone wants in, a decision must be made in finite time (no endless deferral).

3. Bounded Waiting

There is a limit on how many times other processes enter the CS before a waiting process gets in (no starvation).

Mutex (Mutual Exclusion Lock)

The simplest synchronization tool. A mutex has two states: locked and unlocked. Only the thread that locked it can unlock it.

mutex.acquire()   // lock — blocks if already locked
  // ← critical section →
  shared_data++
mutex.release()   // unlock — wakes a waiting thread

Pitfall: Deadlock

If thread A holds mutex1 and waits for mutex2, while thread B holds mutex2 and waits for mutex1 → deadlock.

Semaphores

A semaphore is an integer variable accessed only via two atomic operations:

wait() — also called P() or down()

Decrements the value. If value < 0, the process blocks (goes to sleep). Conceptually: "try to acquire a resource."

wait(S):
  S = S - 1
  if S < 0: block()

signal() — also called V() or up()

Increments the value. If there are blocked processes, wakes one. Conceptually: "release a resource."

signal(S):
  S = S + 1
  if S <= 0: wakeup()

Type	Initial Value	Use Case
Binary Semaphore	1	Acts like a mutex — mutual exclusion
Counting Semaphore	N (pool size)	Control access to N identical resources (e.g., 5 printers)
Signaling Semaphore	0	Force ordering — A does something, then signals B to proceed

Monitors

A high-level synchronization construct. A monitor is a class/module where:

Only one process can be executing inside the monitor at any time (mutual exclusion is automatic)
Condition variables allow processes to wait inside the monitor without holding the lock
wait() on a condition variable releases the monitor lock and suspends the process
signal() wakes exactly one waiting process on that condition variable

monitor BoundedBuffer:
  condition not_full, not_empty
  
  procedure insert(item):
    if buffer.full(): wait(not_full)
    buffer.add(item)
    signal(not_empty)
  
  procedure remove():
    if buffer.empty(): wait(not_empty)
    item = buffer.get()
    signal(not_full)
    return item

Spinlock vs Blocking Lock

Feature	Spinlock	Blocking (Mutex/Semaphore)
Waiting behavior	CPU keeps looping ("spinning") checking the lock	Process goes to sleep, yields the CPU
CPU usage while waiting	100% (busy waiting)	0% (blocked)
Best for	Very short waits on multi-core systems	Longer waits or single-core systems
Context switch needed?	No	Yes (overhead)

Process Management

How the OS creates, schedules, and manages running programs

Process States (The 5-State Model)

┌─────────┐ │ New │ process created └────┬────┘ │ admitted ┌────▼────┐ scheduler dispatch ┌──────────┐ │ Ready │ ─────────────────────────→ │ Running │ │ (queue) │ ←───────────────────────── │ (on CPU) │ └─────────┘ interrupt / timeout └────┬─────┘ ▲ │ │ I/O complete │ I/O request / event wait │ ▼ ┌────┴──────┐ ┌──────────┐ │ Terminated│ ← exit() │ Waiting │ └───────────┘ └──────────┘

State	Meaning
New	Process is being created
Ready	Loaded in memory, waiting for CPU time
Running	Currently executing on the CPU
Waiting	Blocked waiting for I/O or an event
Terminated	Finished execution, being cleaned up

Process Control Block (PCB)

The OS's complete record of a process. Every process has exactly one PCB. Saved/restored on every context switch.

Process ID (PID) — unique identifier
Process state — ready/running/waiting/etc.
Program counter — next instruction address
CPU registers — all register values saved here

Scheduling info — priority, time used
Memory info — page tables, base/limit registers
I/O status — open files, pending I/O
Accounting info — CPU time used, start time

CPU Scheduling Algorithms

Algorithm	Preemptive?	How it works	Pros	Cons
FCFS (First-Come First-Served)	Non-preemptive	Run processes in arrival order; once running, a process holds the CPU until it finishes or blocks	Simple, no starvation	Convoy effect — short jobs wait behind long ones
SJF (Shortest Job First)	Non-preemptive	Run the process with the shortest burst time next; once started, it runs to completion	Optimal average wait time	Starvation of long jobs; burst time hard to know in advance
SRTF (Shortest Remaining Time First)	Preemptive	Preemptive version of SJF — if a new process arrives with a shorter remaining time than the current process, it preempts it	Minimizes average waiting time even more than SJF	High context switch overhead; starvation of long jobs
Priority	Either	Run highest-priority process next. Preemptive variant: a higher-priority arrival immediately preempts the running process	Important jobs run first	Starvation of low-priority jobs (fix: aging — raise priority over time)
Round Robin	Preemptive	Each process gets a fixed time quantum; when the quantum expires it is preempted and moved to the back of the ready queue	Fair, good for interactive/time-sharing systems	High context switch overhead if quantum too small; larger quantum → behaves like FCFS
Multilevel Queue	Either	Multiple queues with different scheduling algorithms each (e.g., foreground uses RR, background uses FCFS); processes are permanently assigned to a queue	Flexible for different process types	Complex; lower queues may starve without inter-queue preemption

Preemptive vs Non-Preemptive

Non-preemptive: Once a process starts running, it keeps the CPU until it voluntarily gives it up (finishes, or blocks on I/O). The OS cannot forcibly take the CPU away.
Preemptive: The OS can forcibly remove a process from the CPU mid-execution — typically when a higher-priority process arrives or a time quantum expires. Requires saving/restoring state (context switch overhead) but gives better responsiveness.

Context Switch

When the CPU switches from one process to another:

1

Save state of current process into its PCB

Registers, program counter, stack pointer, memory mappings

2

Select next process

Scheduler picks the next process from the ready queue

3

Restore state of new process from its PCB

Load its registers, PC, memory context — resumes exactly where it left off

Key Point

Context switch time is pure overhead — no useful work is done during it. This is why too-small time quanta in Round Robin hurts performance.

fork(), exec(), and wait()

Call	What it does	Return value
`fork()`	Creates a new process (child) that is a copy of the parent. Both continue from the same point.	Child gets 0; Parent gets child's PID; -1 on error
`exec()`	Replaces the current process's memory image with a new program. Does not create a new process.	No return on success (process image replaced)
`wait()`	Parent blocks until a child process terminates. Reaps the child's exit status.	PID of the terminated child
`exit()`	Terminates the current process, sends exit status to parent	Never returns

Zombie vs Orphan

Zombie: Child has exited but parent hasn't called wait() yet — PCB still held in memory. | Orphan: Child is still running but parent has exited — inherited by init/systemd (PID 1).

Deadlocks, Starvation & Resource Allocation

When processes get permanently stuck waiting for each other

The 4 Coffman Conditions (ALL must hold for deadlock)

Memorize These

If even one condition is broken, deadlock CANNOT occur.

1. Mutual Exclusion

At least one resource must be non-shareable — only one process can use it at a time. (e.g., a printer)

2. Hold and Wait

A process holds at least one resource AND is waiting to acquire additional resources held by others.

3. No Preemption

Resources cannot be forcibly taken from a process — they must be voluntarily released.

4. Circular Wait

A set of processes {P0, P1, …, Pn} exists where P0 waits for P1, P1 waits for P2, …, Pn waits for P0.

Handling Deadlocks: 4 Strategies

Strategy	How	Cost
Prevention	Design the system so that at least one Coffman condition can NEVER hold (e.g., require processes request all resources at once → eliminates Hold & Wait)	Low resource utilization, may be impractical
Avoidance	Dynamically check if granting a request keeps the system in a safe state (Banker's Algorithm). Only grant if safe.	Must know max resource needs in advance
Detection & Recovery	Allow deadlocks to occur. Periodically run detection (wait-for graph cycle check). When found, recover by killing processes or preempting resources.	Recovery overhead; partial work lost
Ignore (Ostrich)	Pretend deadlocks don't happen and just reboot. Used by most consumer OSes (Windows, Linux) because deadlocks are rare enough that prevention overhead isn't worth it.	Inconvenience when it does happen

Prevention: Eliminating Each Condition

Condition to Eliminate	How to Eliminate It
Mutual Exclusion	Make resources shareable (only works for read-only resources like files opened for reading)
Hold and Wait	Require processes to request ALL resources before starting, or release all before requesting more
No Preemption	If a process requests a resource that can't be allocated, preempt all its held resources (save state, restore later)
Circular Wait	Impose total ordering on resource types; processes must request resources in increasing order only

Safe State vs Unsafe State

Safe State

A sequence exists where every process can eventually obtain its needed resources, execute, and release them — allowing the next process to proceed. A safe state guarantees deadlock-free execution.

Unsafe State

No such safe sequence exists. This doesn't mean deadlock IS happening, but deadlock CAN happen depending on future requests. Avoidance algorithms refuse requests that would lead here.

Safe State → Unsafe State → Deadlock (avoidance prevents crossing the Safe→Unsafe line)

Starvation vs Deadlock vs Livelock

Term	Definition	Example
Deadlock	All involved processes are permanently blocked, each waiting for another in a cycle. No progress possible.	P1 holds R1, wants R2. P2 holds R2, wants R1.
Starvation	A process is perpetually denied resources even though they become available — always losing to higher-priority processes.	Low-priority job never runs because high-priority jobs keep arriving. Fix: aging (increase priority over time).
Livelock	Processes keep changing state in response to each other but make no useful progress. They're "active" but stuck.	Two people in a hallway each step aside to let the other pass, then step the same way, repeat forever.

Classic Concurrency Problems

Foundational problems that model real-world synchronization challenges

🍝 Dining Philosophers Problem

Setup: 5 philosophers sit at a round table. There are 5 forks, one between each pair. To eat, a philosopher needs BOTH adjacent forks. They alternate between thinking and eating.

[P0] / \ fork4 fork0 / \ [P4] [P1] \ / fork3 fork1 \ / [P3]─fork2─[P2]

The Deadlock Scenario

If all 5 philosophers pick up their LEFT fork simultaneously, each holds one fork and waits for the right fork (held by their neighbor) → circular wait → deadlock.

Solutions:

Solution 1: Max N-1 Diners

Allow at most 4 philosophers at the table at once. At least one can always eat. Simple but wasteful.

Solution 2: Asymmetric

Odd philosophers pick left-then-right. Even philosophers pick right-then-left. Breaks circular wait.

Solution 3: Monitor/Waiter

A monitor or "waiter" semaphore grants permission to pick up BOTH forks atomically. Only pick up if both are available.

📦 Producer-Consumer Problem (Bounded Buffer)

Setup: Producers generate data and add to a shared buffer of size N. Consumers remove data. Producers must wait when buffer is full; consumers must wait when buffer is empty.

Semaphore	Initial Value	Purpose
`mutex`	1	Mutual exclusion for buffer access
`empty`	N (buffer size)	Count of empty slots — producer waits on this
`full`	0	Count of filled slots — consumer waits on this

Producer:

wait(empty)     // wait for a slot
wait(mutex)     // lock buffer
  add item to buffer
signal(mutex)   // unlock
signal(full)    // notify consumer

Consumer:

wait(full)      // wait for an item
wait(mutex)     // lock buffer
  remove item from buffer
signal(mutex)   // unlock
signal(empty)   // notify producer

Order Matters!

Always wait on the counting semaphore (empty/full) BEFORE waiting on mutex. Reversing the order causes deadlock.

📖 Readers-Writers Problem

Setup: A shared database. Multiple readers can read simultaneously (no conflict). A writer needs exclusive access — no readers or other writers while writing.

Semaphore/Variable	Initial	Purpose
`rw_mutex`	1	Exclusive access for writers (and the first/last reader)
`mutex`	1	Protects the `read_count` variable
`read_count`	0	Number of readers currently reading

Reader:

wait(mutex)
  read_count++
  if read_count == 1:
    wait(rw_mutex)  // first reader blocks writers
signal(mutex)

  // ← read data →

wait(mutex)
  read_count--
  if read_count == 0:
    signal(rw_mutex) // last reader releases
signal(mutex)

Writer:

wait(rw_mutex)   // exclusive access
  // ← write data →
signal(rw_mutex) // release

Two Variants

1st problem: Readers have priority — writers may starve.
2nd problem: Writers have priority — readers may starve.

🏦 Banker's Algorithm

A deadlock avoidance algorithm. Before granting a resource request, the OS checks if the resulting state is safe. Named after a bank that only loans money if it can still satisfy all potential future withdrawals.

Key Data Structures (for n processes, m resource types):

Structure	Size	Meaning
`Available[m]`	m	How many of each resource are currently free
`Max[n][m]`	n×m	Maximum resources each process may ever need
`Allocation[n][m]`	n×m	Resources currently allocated to each process
`Need[n][m]`	n×m	Remaining resources each process may still request: Need = Max − Allocation

Safety Algorithm (find a safe sequence):

Safety Check

Work = Available.copy()
Finish = [False] * n

repeat:
  find i where: Finish[i] == False AND Need[i] <= Work
  if found:
    Work += Allocation[i]   // process finishes, releases resources
    Finish[i] = True
  else:
    break

if all Finish[i] == True: → SAFE STATE ✓
else: → UNSAFE STATE ✗

Worked Example

3 processes (P0, P1, P2), 1 resource type. Available = 2.
Allocation: P0=1, P1=2, P2=0. Max: P0=3, P1=3, P2=2.
Need: P0=2, P1=1, P2=2.

Try P1: Need[P1]=1 ≤ Work=2 ✓ → Work = 2+2 = 4, Finish[P1]=true
Try P0: Need[P0]=2 ≤ Work=4 ✓ → Work = 4+1 = 5, Finish[P0]=true
Try P2: Need[P2]=2 ≤ Work=5 ✓ → Work = 5+0 = 5, Finish[P2]=true
All finished → Safe sequence: <P1, P0, P2> ✓

Resource Allocation Graph & Wait-For Graph

Visual tools to detect and analyze deadlocks

Resource Allocation Graph (RAG)

A directed graph with two types of nodes:

Process nodes: Circles (○) — represent processes
Resource nodes: Rectangles with dots (▣) — each dot = one instance

Two types of edges:

Request edge P→R: Process P is waiting for resource R
Assignment edge R→P: Resource R is held by process P

(P1) ──request──→ [R1•] ↓ assign (P2) ←─assign── [R2••] │ └──request──→ [R1•] ○ = Process [•] = Resource (dots = instances)

Deadlock Detection via RAG

Condition	Deadlock?
Cycle in RAG, single-instance resources	YES — definitely deadlock
Cycle in RAG, multi-instance resources	MAYBE — possible but not guaranteed
No cycle in RAG	NO deadlock

Deadlock example: (P1)──→[R1]──→(P2)──→[R2]──→(P1) Cycle with single instances = DEADLOCK ✗ No deadlock example: (P1)──→[R1] [R1]──→(P2) No cycle → SAFE ✓

Wait-For Graph

A simplified version of the RAG — only processes, no resource nodes. Used when all resources have single instances.

An edge Pi → Pj means "Pi is waiting for Pj to release a resource"
A cycle in the wait-for graph = deadlock
The OS periodically runs a cycle-detection algorithm on this graph

RAG: Wait-For Graph: (P1)──→[R]──→(P2) → (P1)──→(P2) If P1 waits for R, and R is held by P2, then P1 is "waiting for" P2.

RAG vs Wait-For Summary

RAG: processes + resources, two edge types, works with multi-instance resources.
Wait-For: processes only, simpler, only valid for single-instance resources — cycle = deadlock.

Deadlock Recovery Options

Process Termination

Kill one or more processes in the deadlock cycle. Either abort all (safe but costly) or abort one at a time and re-check (more targeted).

Resource Preemption

Forcibly take a resource away from a process (roll back to a safe state). Must handle: which process to preempt, rollback, and starvation prevention.

I/O Operations

How the OS communicates with hardware devices

Three Methods of I/O

Polling (Busy Waiting)

CPU continuously checks the device status register in a loop until the device is ready. Simple but wastes CPU cycles. Good only for very fast devices.

while (device.status != READY)
  ; // spin

Interrupts

CPU starts I/O and continues other work. Device interrupts the CPU when done. CPU saves state, runs interrupt handler, resumes. Efficient for slow devices.

start_io()
// do other work...
// interrupt fires:
  handle_interrupt()

DMA (Direct Memory Access)

A DMA controller transfers data directly between device and memory without CPU involvement per byte. CPU only involved at start and end (interrupt). Best for bulk transfers.

setup_dma(src, dst, len)
// CPU does other work
// DMA interrupt when done

Interrupt Handling

1

Device asserts interrupt request line (IRQ)

Device signals it needs attention on the interrupt bus

2

CPU detects interrupt after current instruction

Checks interrupt request line after each instruction completes

3

CPU saves state

Pushes registers and program counter onto the kernel stack

4

Looks up interrupt vector

Uses the interrupt number as index into the interrupt vector table to find the handler address

5

Executes interrupt handler (ISR)

The device-specific handler runs, processes the event, clears the interrupt

6

Restores state and resumes

Pops state off stack, returns to interrupted process

Maskable vs Non-Maskable

Maskable: Can be temporarily disabled (ignored) during critical code sections. Most device interrupts are maskable.
Non-maskable (NMI): Cannot be disabled. Used for critical hardware failures, memory errors.

Disk Scheduling Algorithms

The disk arm must move to different tracks to service read/write requests. The order in which requests are serviced affects total arm movement (and thus speed).

Assume: Head starts at track 50. Requests: 0, 10, 55, 70, 100, 105.

Algorithm	Head Movement	Definition	Problem
FCFS	Service in order received	First-come, first-served. Simple but inefficient.	High seek times — arm may bounce wildly
SSTF	50→55→70→100→105→10→0	Shortest Seek Time First — always go to nearest request.	Starvation of far requests
SCAN (Elevator)	50→55→70→100→105→0→10	Head sweeps in one direction, services all requests, then reverses.	Requests just behind head wait longest
C-SCAN	50→55→70→100→105→[jump to 0]→10	Like SCAN but only services requests in ONE direction. Jumps back to start without servicing on return.	More uniform wait times than SCAN
LOOK / C-LOOK	Like SCAN/C-SCAN but stops at last request (doesn't go all the way to end)	Optimization of SCAN/C-SCAN — doesn't waste time going past last request.	Best practical choice

Security

Protecting systems, data, and users from threats

Cryptography Quick Reference

Type	Also Known As	Encrypt With	Decrypt With	Algorithm	Speed
Symmetric	Secret-key / Private-key	Private (shared secret)	Same private key	DES, AES	Fast
Asymmetric	Public-key	Public key	Private key	RSA	Slower

Real-World Usage

HTTPS uses asymmetric encryption to securely exchange a symmetric key. Then all actual data is encrypted with the faster symmetric key. Best of both worlds.

Stream Cipher vs Block Cipher

Stream Cipher

Encrypts data one bit or byte at a time continuously. Good for real-time communication (phone calls, streaming). Example: RC4.

Block Cipher

Encrypts data in fixed-size chunks (e.g., 128-bit blocks). Each block is encrypted independently or with chaining. Example: AES (128/192/256-bit blocks).

Security Threats — Quick Definitions

Threat	What it is
Man-in-the-Middle	Attacker intercepts communication between two parties, can read or alter messages without either party knowing
Phishing / Social Engineering	Tricking humans into revealing credentials or performing actions — exploits people, not software vulnerabilities
DoS (Denial of Service)	Overwhelm a system with requests to make it unavailable to legitimate users
DDoS	DoS from many distributed sources (botnet) simultaneously — much harder to block
Session Hijacking	Stealing a valid session token to impersonate an authenticated user
Ransomware	Encrypts victim's files, demands payment for decryption key
Spyware	Secretly monitors user activity and sends data to attacker (no ransom)
Logic Bomb	Malicious code that lies dormant until a trigger condition is met (date, event)
Back Door	Hidden entry point bypassing normal authentication, installed by devs or attackers
Trojan Horse	Malware disguised as legitimate software; doesn't self-replicate
Virus	Attaches to host file, spreads when file is executed (requires user action)
Worm	Self-replicating, spreads autonomously across networks without user action
Rootkit	Hides itself deep in the OS, gives persistent privileged access while concealing presence
Boot Virus	Infects the Master Boot Record (MBR), executes before OS loads
Code Injection	Malicious code inserted into a vulnerable application and executed (SQL injection, XSS)

Authentication Factors

Something You Know

A secret in your memory. Password, PIN, security question answer, passphrase.

Something You Have

A physical object. Smart card, hardware token, phone (SMS code), authenticator app.

Something You Are (Biometrics)

A physical trait. Fingerprint, face recognition, retinal scan, voice pattern.

Two-Factor Authentication (2FA)

Requires ANY two factors from DIFFERENT categories. Password + SMS code = 2FA. Password + security question = NOT 2FA (both are "something you know").

Defense in Depth

A layered security strategy where multiple independent controls protect a system. If one layer fails, others remain. Like an onion — attacker must break through multiple layers.

Layer 1: Physical security (locked server room) Layer 2: Network perimeter (firewall, IDS) Layer 3: Host-based (antivirus, host firewall) Layer 4: Application (input validation, auth) Layer 5: Data (encryption, access control) ↓ Data at the center

Hash Functions

A hash function takes input of any size and produces a fixed-size output (digest). Properties:

One-way: Cannot reverse a hash to get the original input
Deterministic: Same input always produces same output
Avalanche effect: Tiny change in input → completely different hash
Collision resistant: Extremely hard to find two inputs with the same hash

Examples: MD5 (broken, don't use), SHA-256 (secure), SHA-3. Uses: password storage, file integrity checks, digital signatures.

Basic Linux Commands

You already know this — here's your quick-reference cheat sheet

Navigation & Files

Command	What it does	Example
`pwd`	Print working directory (where am I?)	`pwd` → /home/torx
`ls`	List files. `-l` = long format, `-a` = show hidden	`ls -la`
`cd`	Change directory. `cd ..` = go up one level, `cd ~` = home	`cd /etc`
`mkdir`	Make a new directory. `-p` = create parent dirs too	`mkdir -p a/b/c`
`rm`	Remove file. `-r` = recursive (directories), `-f` = force	`rm -rf folder/`
`cp`	Copy file or directory. `-r` for directories	`cp file.txt backup/`
`mv`	Move OR rename a file/directory	`mv old.txt new.txt`
`touch`	Create an empty file or update timestamps	`touch file.txt`
`find`	Search for files by name, type, size, etc.	`find / -name "*.log"`
`locate`	Fast search using pre-built index database	`locate passwd`

Viewing & Editing Files

Command	What it does	Example
`cat`	Display entire file contents to screen	`cat file.txt`
`more`	Display file one page at a time (forward only)	`more bigfile.txt`
`less`	Like more but also backwards. Better.	`less bigfile.txt`
`head`	Show first N lines (default 10)	`head -20 file.txt`
`tail`	Show last N lines. `-f` = follow (live log)	`tail -f /var/log/syslog`
`grep`	Search for pattern in file(s). `-r` = recursive	`grep "error" log.txt`
`sed`	Stream editor — find/replace text in files	`sed 's/foo/bar/g' file.txt`
`wc`	Word count. `-l` = lines, `-w` = words, `-c` = bytes	`wc -l file.txt`
`diff`	Show differences between two files	`diff file1.txt file2.txt`
`cmp`	Compare two files byte-by-byte, show first difference	`cmp file1 file2`

Permissions & Ownership

Command	What it does	Example
`chmod`	Change file permissions (numeric or symbolic)	`chmod 755 script.sh`
`chown`	Change file owner (and optionally group)	`chown user:group file`
`sudo`	Run command as superuser/root	`sudo apt update`

chmod Numbers

Each digit = permissions for Owner / Group / Others.
4=read, 2=write, 1=execute. Add them up:
chmod 755 = Owner(rwx=7) Group(r-x=5) Others(r-x=5)

Processes & System

Command	What it does	Example
`ps`	List running processes. `aux` = all processes with detail	`ps aux`
`top`	Live view of processes and resource usage (CPU, memory)	`top`
`kill`	Send a signal to a process by PID. `-9` = force kill	`kill -9 1234`
`killall`	Kill all processes by name	`killall firefox`
`bg / fg`	Move job to background / foreground	`bg %1`
`jobs`	List current background/suspended jobs	`jobs`

Networking

Command	What it does	Example
`ping`	Test network connectivity to a host	`ping google.com`
`ifconfig`	View/configure network interfaces (older systems)	`ifconfig eth0`
`ip addr`	Modern replacement for ifconfig	`ip addr show`
`ssh`	Securely connect to a remote machine	`ssh user@192.168.1.1`
`scp`	Securely copy files over SSH	`scp file.txt user@host:/path`
`curl`	Transfer data from URLs; test APIs	`curl https://api.example.com`

Archives & Compression

Command	What it does	Example
`tar`	Archive/extract files. `-czf`=create gzip, `-xzf`=extract	`tar -czf out.tar.gz folder/`
`gzip`	Compress a file to .gz format	`gzip file.txt`
`gunzip`	Decompress a .gz file	`gunzip file.txt.gz`
`zip / unzip`	Create/extract .zip archives	`zip archive.zip file1 file2`
`sort`	Sort lines of text files	`sort names.txt`
`whoami`	Print currently logged-in username	`whoami`
`man`	Open manual page for any command	`man chmod`
`mount / umount`	Mount / unmount a file system	`mount /dev/sdb1 /mnt`

OS-Specific Technologies

What's unique to each operating system — know these cold

File Systems by OS

OS	Native File System	Also Supports	Key Features
Linux	ext4 (modern default)	ext2, ext3, Btrfs, XFS, ZFS, NTFS (read/write), FAT32	Journaling, extents, multiblock allocation, 1EB volume limit
Windows	NTFS	FAT32, exFAT, ReFS	Journaling ($LogFile), MFT, ACLs, encryption (EFS), compression
macOS	APFS (2017+)	HFS+ (legacy), FAT32, exFAT	Copy-on-write, snapshots, cloning, native encryption, SSD-optimized
UNIX (legacy)	UFS / FFS	NFS, ZFS	Fast File System layout (cylinder groups), inodes
Flash/USB drives	FAT32 / exFAT	ext2 (Linux)	FAT32: universal compatibility, 4GB file limit. exFAT: no file size limit

ext2 vs ext3 vs ext4 — Know the Differences

Feature	ext2	ext3	ext4
Journaling	No	Yes (metadata)	Yes (metadata + data opt.)
Max file size	2 TB	2 TB	16 TB
Max volume size	4 TB	32 TB	1 EB
Extents	No	No	Yes
Best use	Flash/USB (no journal = less write wear)	Older Linux systems	Modern Linux systems

Unique Technologies by OS

Linux / UNIX

VFS — Virtual File System layer (abstracts all FS types)
/proc filesystem — virtual FS exposing kernel/process info as files
POSIX — standard API (fork, exec, signals, semaphores)
inode-based file systems
Everything is a file — devices, sockets, pipes all appear as files
GRUB — common Linux bootloader
systemd / init — PID 1, manages services

Windows

NTFS — MFT, journaling, ACLs, EFS encryption
Win32 API / WinAPI — common interface for system calls
Registry — hierarchical config database (unique to Windows)
Active Directory — centralized auth/policy management
NTLM / Kerberos — Windows authentication protocols
DLL (Dynamic Link Library) — Windows equivalent of .so files
NTFS Alternate Data Streams — hidden data attached to files

macOS

APFS — copy-on-write, snapshots, native encryption
Mach kernel — microkernel at the core (part of XNU kernel)
launchd — macOS init system (replaces both init and cron)
Gatekeeper — app signing/notarization enforcement
Keychain — secure credential storage system
Spotlight — system-wide search (indexing daemon)

General OS Concepts

FAT32 — universal compatibility; 4GB max file size
exFAT — FAT replacement for flash; no file size limit; no journaling
NFS — Network File System (UNIX/Linux network FS)
Swap partition — Linux's virtual memory overflow area on disk
Page file — Windows' equivalent of swap space

Quick OS Memory Tricks

NTFS = Windows. ext4 = Linux (modern). APFS = macOS. UFS = UNIX. FAT32 = anywhere (flash drives, cross-platform). exFAT = flash drives without 4GB limit. ext2 = USB drives on Linux (no journaling = less wear).

Mounting — The 3 Steps

How the OS makes a file system accessible in the directory tree

What is Mounting?

Mounting attaches an external file system (on a USB drive, partition, network share, etc.) to a directory in the existing file system tree — called the mount point. After mounting, the contents of the device appear at that directory path.

Before mounting: / ├── home/ ├── etc/ └── mnt/ ← empty mount point After: mount /dev/sdb1 /mnt / ├── home/ ├── etc/ └── mnt/ ← now shows USB drive contents ├── photos/ └── readme.txt

The 3 Steps of Mounting

1

Verify the device contains a valid file system

The OS reads and validates the device's superblock (or volume control block). It checks that the file system type is recognized, the magic number is correct, and the volume is not corrupted. This confirms there is actually a mountable file system on the device.

2

Create an entry in the OS mount table

The OS adds a record to its internal mount table linking the device to the chosen mount point. This entry records the device path, the mount point directory, the file system type, and mount options (read-only, permissions, etc.).

3

Attach the file system to the directory tree at the mount point

The mount point directory's inode is updated to point to the root of the newly mounted file system. All path lookups that reach the mount point are transparently redirected into the new file system. The device is now accessible.

Unmounting (Reverse)

Unmounting reverses this: flush all cached writes to disk, remove the mount table entry, and detach the file system from the directory tree. The mount point directory returns to its original (usually empty) state.

Linux Mounting Commands

Command	Purpose	Example
`mount`	Mount a device to a directory	`mount /dev/sdb1 /mnt/usb`
`mount -t`	Specify file system type explicitly	`mount -t ext4 /dev/sdb1 /mnt`
`umount`	Unmount a device (by device or mount point)	`umount /mnt/usb`
`mount -a`	Mount all file systems listed in /etc/fstab	`sudo mount -a`
`df -h`	Show currently mounted file systems and disk usage	`df -h`
`cat /proc/mounts`	View the current mount table in the kernel	`cat /proc/mounts`

/etc/fstab

The file /etc/fstab lists all file systems to automatically mount at boot. Each line specifies: device, mount point, FS type, options, dump, and fsck order.

Key Terms Related to Mounting

Term	Definition
Mount Point	The directory in the existing tree where a new file system is attached (e.g., /mnt, /media/usb)
Mount Table	OS data structure listing all currently mounted file systems, their devices, mount points, and options
Superblock	The first block of a file system containing metadata about the volume (size, block count, free block list, FS type)
Volume Control Block	Same as superblock — the "volume descriptor" checked in Step 1 to validate the file system
/proc/mounts	Linux virtual file showing the kernel's current mount table (live view)
Bind mount	Mount a directory (not device) onto another directory path — makes the same content appear in two places