OS Internals for Security Support (CY-501) - Unit 5 Short Notes

UNIT 5: OS INTERNALS FOR SECURITY SUPPORT

I. GENERAL OPERATING SYSTEM CONCEPTS

Kernel Role and Architecture

• Kernel: The core, privileged part of the OS. Manages all system resources (CPU, memory, I/O devices) and provides secure, controlled access to them for user applications.

• Functions:

  • Process management (scheduling, creation, termination)

  • Memory management (allocation, protection, paging)

  • Device management (via drivers)

  • System call interface

  • Security and protection enforcement

• Designs:

  • Monolithic Kernel: Entire OS kernel runs in a single address space in kernel mode. High performance, but less modular and a single bug can crash the system. (e.g., traditional UNIX, Linux).

  • Microkernel: Minimal kernel; only essential services (IPC, memory management, scheduling) run in kernel mode. Other services (file system, drivers) run as user-space servers. More modular, fault-tolerant, but higher IPC overhead. (e.g., QNX, Minix).

• Kernel-mode vs. User-mode:

  • Kernel Mode (Privileged/Supervisor): CPU executes privileged instructions, has full access to all hardware and memory. Kernel code runs here.

  • User Mode (Unprivileged): Restricted environment for applications. Direct hardware access is prohibited; all access goes through the kernel via system calls.

[!TIP] Exam questions often ask for a comparison (pros/cons) of monolithic vs. microkernel designs. Focus on performance, modularity, and fault isolation.

System Calls Overview

• Purpose: The only controlled entry point from user-mode applications into the kernel. They request OS services (e.g., read a file, create a process, send a message).

• Categories:

  • Process Control: fork(), exec(), exit()

  • File Management: open(), read(), write(), close(), create(), chmod()

  • Device Management: ioctl(), read(), write()

  • Information Maintenance: getpid(), time()

  • Communication: pipe(), shmget(), msgget()

  • Protection: chmod(), chown()

II. UNIX OPERATING SYSTEM INTERNALS

Components and Features

• Components:

  • Kernel: Core, manages hardware/resources.

  • Shell: Command interpreter (e.g., bash, sh), user interface.

  • File System: Hierarchical, everything is a file.

  • Utilities: Standard commands/tools (ls, grep, cp).

• Key Characteristics:

  • Multitasking: Multiple processes in memory.

  • Multiuser: Concurrent access for multiple users.

  • Portability: Written in C, runs on various hardware.

  • Small, Simple Tools: Do one thing well, composable via pipes.

Super Block

• Role: The master control block for a mounted file system. Contains all metadata needed to manage that specific file system instance. One per mounted file system, stored in disk memory and cached in kernel memory upon mounting.

• Contents:

  • File system size (total data blocks).

  • Block size.

  • List of free data blocks and free inodes.

  • Pointers to the inode list and data block list.

  • Magic number (identifies file system type).

  • Mount count and last check time.

  • State flags (e.g., clean/dirty).

[!TIP] Remember: One Super Block per mounted file system. It's the "control center" for that filesystem's metadata.

Buffer Cache and Buffer Pool

• Purpose: A kernel-maintained cache of disk blocks in main memory. Reduces frequent, slow physical disk I/O by keeping recently used or anticipated disk blocks in RAM.

• Advantages: Dramatically improves I/O performance (spatial and temporal locality).

• Buffer Header Structure: Each cached block has a header containing:

  • b_dev (device ID), b_blkno (disk block number)

  • b_addr (pointer to data in memory)

  • Status Flags: B_BUSY (buffer in use), B_DONE (I/O complete), B_ERROR (I/O error), B_DIRTY (modified, needs write-back).

  • Pointers for linked lists (hash queue, free list).

• Buffer Pool Organization:

  • Hash Queue: Hash table based on (dev, blkno). Allows O(1) average lookup for a specific block.

  • Free List: Linked list of all available (not B_BUSY) buffers. Used when a new block needs to be cached; the head of the free list is chosen (often LRU-like).

[!DIAGRAM: CANVAS] Draw a diagram showing: 1) Hash table with buckets, each bucket a linked list of buffer headers for blocks hashing to that bucket. 2) A separate, global free list linking all non-busy buffers. Show a buffer header with its fields and flags.

Key System Calls (UNIX-specific)

• open(pathname, flags, mode)

  • Purpose: Open/create a file, returns a file descriptor (integer index into per-process file descriptor table).

  • flags: O_RDONLY, O_WRONLY, O_RDWR, O_CREAT, O_TRUNC, O_APPEND.

  • mode: Permissions (e.g., 0644) if O_CREAT is used.

• read(fd, buffer, count)

  • Purpose: Read count bytes from open file fd into buffer in user space. Returns bytes read or -1 on error.

• create(pathname, mode)

  • Purpose: Create a new regular file with permissions mode. Equivalent to open(pathname, O_CREAT|O_WRONLY|O_TRUNC, mode).

• chmod(pathname, mode)

  • Purpose: Change file permissions (read/write/execute for owner/group/others). mode is octal (e.g., 0755).

III. PROCESS MANAGEMENT

Process Life Cycle and States

• States:

  1. New: Process being created.

  2. Ready: In main memory, waiting for CPU.

  3. Running: Executing on CPU.

  4. Waiting/Blocked: Waiting for an event (I/O, signal, resource).

  5. Terminated: Execution finished, PCB may be kept for exit status.

• State Transitions:

  • New → Ready: Admitted by OS.

  • Ready → Running: Scheduler dispatch.

  • Running → Ready: Time slice expiry (preemptive).

  • Running → Waiting: I/O request, wait().

  • Waiting → Ready: I/O complete, event occurred.

  • Running → Terminated: exit().

Process Control Block (PCB)

• Definition: The OS data structure that is the "manifest" of a process. Contains all info the OS needs to manage, schedule, and suspend/resume the process.

• Components:

  • Process State (ready, running, etc.)

  • Process ID (PID): Unique identifier.

  • Program Counter (PC): Next instruction address.

  • CPU Registers (accumulator, index, stack pointer, etc.): Saved on context switch.

  • Memory Management Info: Page tables, segment tables, base/limit registers.

  • Scheduling Info: Priority, scheduling queue pointers, time slice remaining.

  • I/O Status Info: Open file table pointers, allocated I/O devices, pending I/O requests.

  • Accounting Info: CPU time used, limits.

Process Scheduling

• Objectives: Maximize CPU utilization & throughput, minimize turnaround/waiting/response time, fairness, balance resource use.

• Algorithms:

  • FCFS/FIFO: Non-preemptive. Processes in arrival order. Simple, but Convoy Effect possible. Avg. waiting time often high.

  • SJF/SRTF: Shortest Job (non-preemptive) or Remaining time (preemptive). Optimal for minimizing avg. waiting time, but requires knowledge of CPU burst time; can starve long jobs.

  • Priority Scheduling: Non-preemptive or preemptive. Can starve low-priority processes; Aging (gradually increasing priority) is a solution.

  • Round Robin (RR): Preemptive. Each ready process gets a fixed time quantum (q) in cyclic order. Good for time-sharing. Context switch overhead increases if q is too small; avg. response time good.

• Preemptive vs. Non-preemptive:

  • Preemptive: Scheduler can forcibly take CPU from running process (e.g., RR, SRTF, priority with preemption).

  • Non-preemptive: Process relinquishes CPU voluntarily (e.g., on I/O wait or termination) (e.g., FCFS, non-preemptive priority, SJF).

Principles of Concurrency

• Requirements for Concurrent Execution:

  • Multiprogramming/Multitasking: Multiple processes in memory/CPU.

  • Interleaving/Overlapping: Processes' execution steps intermixed in time (on single CPU) or truly parallel (multi-core).

• Challenges:

  • Race Condition: Multiple processes/threads access shared data concurrently, and the outcome depends on the execution order. Requires mutual exclusion.

  • Deadlock: Circular wait: Process A holds resource X and waits for Y, while Process B holds Y and waits for X. Conditions: Mutual Exclusion, Hold & Wait, No Preemption, Circular Wait.

  • Starvation: Process perpetually denied necessary resources (e.g., always losing in priority scheduling). Fairness mechanisms needed.

IV. INTERPROCESS COMMUNICATION (IPC) AND SYNCHRONIZATION

IPC Mechanisms

• Overview: Mechanisms for processes to exchange data and synchronize.

  • Shared Memory: Fastest. Processes attach a common memory segment. Requires explicit synchronization (semaphores) to avoid races.

  • Message Queues: OS-managed queues. Processes send/receive messages. Provides synchronization (blocking send/receive) and buffering.

  • Pipes: Unidirectional byte stream. Anonymous (parent-child) or named (FIFO). Simple, no message boundaries.

  • Sockets: For network communication, but also for local IPC (Unix domain sockets).

• Shared Memory:

  • Implementation: shmget() creates/get ID, shmat() attaches to process address space.

  • Advantages: Very high speed (no kernel copy on each access).

  • Synchronization Needs: Absolute requirement. Processes must use semaphores or other locks to coordinate access to the shared region.

• Message Queues - Client/Server Example:

  1. Server: msgget(key, IPC_CREAT | 0666) to create queue. Then msgrcv() to block and wait for messages.

  2. Client: msgget(key, 0) to get existing queue ID. msgsnd() to send a request message.

  3. Server processes request, may send reply via another queue or same queue with client's PID.

Semaphores

• Definition: An integer variable used for synchronization and mutual exclusion, whose only operations are atomic wait() (P) and signal() (V).

• Atomicity: The operation is indivisible; no other process can access the semaphore between checking and modifying its value.

• Types:

  • Binary Semaphore (Mutex): Value is 0 or 1. Used for mutual exclusion (protecting a critical section).

  • Counting Semaphore: Value can be any non-negative integer. Used to control access to a pool of identical resources (e.g., 3 printers).

• Operations:

  
  // wait(P) operation (decrement)
  
  wait(semaphore *S) {
  
      while (S->value <= 0) ; // busy wait (spinlock) - not ideal
  
      S->value--;
  
  }
  
  

  
  // signal(V) operation (increment)
  
  signal(semaphore *S) {
  
      S->value++;
  
      // If any process is waiting on S, wake one up
  
  }
  
  

  In practice, wait() blocks the process if S->value <= 0 (using a wait queue), not busy-wait.

[!TIP] Critical Difference: Mutex is typically owned by a thread (must be released by the same thread that locked it). Binary Semaphore has no ownership concept. For mutual exclusion in user threads, a mutex is safer.

V. SECURITY AND PROTECTION

Authentication and Access Control

• Authentication Methods:

  • Passwords: Knowledge-based. Vulnerable to guessing, sniffing.

  • Biometrics: Something you are (fingerprint, retina). Requires hardware, can have false rejects/accepts.

  • Tokens: Something you have (smart card, OTP generator). Often combined with passwords (2FA).

• Access Control Models:

  • DAC (Discretionary Access Control): Owner decides permissions. Based on Access Control Lists (ACLs) or capabilities. (e.g., UNIX rwx for owner/group/others).

  • MAC (Mandatory Access Control): System-enforced policy based on security labels (e.g., Top Secret, Secret). Users cannot override. (e.g., SELinux, Windows Mandatory Integrity Control).

  • RBAC (Role-Based Access Control): Permissions assigned to roles (e.g., Manager, Engineer). Users assigned to roles. Easier administration in large orgs.

Malware

• Definitions:

  • Virus: Code that attaches to a host program/file. Requires user action to execute and spread. Can be file infector, macro, boot sector.

  • Worm: Self-replicating, standalone program. Exploits network vulnerabilities to spread without user intervention. Consumes bandwidth/resources.

  • Trojan: Disguised as legitimate software. Does not replicate. Provides backdoor, steals data, or causes damage.

  • Rootkit: Software that hides the existence of other malware (processes, files, registry keys). Often installs deep in the OS (kernel level) to evade detection.

• Propagation:

  • Virus: Infected files, email attachments, USB drives.

  • Worm: Network shares, email (as attachment/link), vulnerabilities (e.g., EternalBlue).

  • Trojan: Downloaded from malicious sites, bundled with pirated software.

Common Vulnerabilities and Exposures (CVEs)

• Overview: Standardized list of publicly known cybersecurity vulnerabilities.

• Common Software Vulnerabilities:

  • Buffer Overflow: Writing beyond buffer bounds, overwriting return address/control data. Allows arbitrary code execution. (Classic stack/heap overflow).

  • Injection Flaws (SQL, OS Command, LDAP): Untrusted data sent as part of a command/query, tricking interpreter into executing unintended commands.

  • Misconfiguration: Default accounts/passwords, unnecessary services/ports, verbose error messages, improper permissions.

  • Cross-Site Scripting (XSS): Injecting scripts into web pages viewed by others.

  • Broken Authentication: Weak credential management, session fixation.

Honeypots

• Definition: A decoy system (app, server, data) designed to attract, detect, and analyze attack attempts. Appears vulnerable but is isolated and monitored.

• Types:

  • Low-Interaction: Simulates services/OS at TCP/IP stack level. Limited attack surface, safe, but less detailed intelligence. (e.g., Honeyd).

  • High-Interaction: Real OS and applications. Full attack surface, provides deep, realistic attack data. Higher risk if compromised.

• Deployment: Used for attack detection (early warning), threat intelligence (tactics/techniques), and research. Placed in DMZ or isolated network segment.

Ransomware

• Risks & Attack Vectors:

  • Risks: Data encryption (loss/extortion), data theft (double extortion), service disruption, financial loss, reputational damage.

  • Vectors: Phishing emails (malicious attachments/links), RDP brute-force, exploit kits, compromised software supply chains, malicious ads.

• Mitigation Strategies:

  • Regular, Offline Backups: The ultimate recovery method. Test restores.

  • Patching: OS, applications, firmware to close exploit vulnerabilities.

  • User Training: Recognize phishing, avoid suspicious links/attachments.

  • Least Privilege: Users/apps have minimum necessary permissions.

  • Network Segmentation: Limit lateral movement.

  • Email Filtering & Web Security: Block known malicious content.

  • Application Whitelisting: Only allow approved executables.

VI. FILE SYSTEM MANAGEMENT

Mounting and Unmounting

• Mounting: The process of attaching a file system (on a disk partition/device) to the directory tree of the currently active file system. The mount point is an existing directory.

  • System Call: mount(device, mount_point, type, options, data)

  • Process: Kernel reads the Super Block of the device, verifies file system type, integrates it into the VFS (Virtual File System) layer. The mount point's inode now points to the root inode of the new file system.

• Unmounting: Detaches a mounted file system. Flushes all dirty buffers (from buffer cache) to disk, updates Super Block, removes from VFS.

  • System Call: umount(mount_point) or umount(device)

  • Fails if files are open or processes have CWD in that FS.

• Advantages:

  • Modularity: Multiple file systems (ext4, NTFS, NFS) coexist.

  • Organization: Logical grouping of data (e.g., /home on separate disk).

  • Security: Can mount with options (e.g., ro, noexec, nosuid).

• Disadvantages:

  • Single Point of Failure: If root FS (/) corrupts, system may not boot.

  • Pathname Resolution Complexity: VFS layer adds overhead.

  • Dependency: Cannot unmount if busy (open files, current working directory).

VII. WINDOWS INTERNALS

Windows System Architecture

• Layers (Simplified):

  1. Hardware Abstraction Layer (HAL): Isolates kernel from hardware differences (interrupt controllers, timers).

  2. Kernel (NTOSKRNL.EXE): Microkernel-like. Core services: thread scheduling, interrupt/dispatch, exception handling, multiprocessor sync.

  3. Executive: Runs in kernel mode but is more OS-component-like. Provides services to subsystems: Object Manager, Process/Thread Manager, Memory Manager, I/O Manager, Security Reference Monitor, etc.

  4. Subsystems: Run in user mode. Provide API environments:

     • Win32 Subsystem (CSRSS.EXE): Primary, provides Win32 API.

     • POSIX Subsystem, OS/2 Subsystem (legacy).

  5. User-Mode Services & Applications: System services (services.exe), shell (explorer.exe), user apps.

• Key Components:

  • NTOSKRNL.EXE: The Windows kernel.

  • HAL.DLL: Hardware Abstraction Layer.

  • Win32 Subsystem (CSRSS): Manages windows, graphics, input.

[!DIAGRAM: SEARCH] "Windows NT architecture diagram layered" for a clear visual of HAL, Kernel, Executive, Subsystems.

Winsock API and Socket Programming

• Winsock (Windows Sockets): API for network communication, based on BSD sockets. Requires initialization (WSAStartup()).

• Key Functions:

  • socket(): Create an endpoint.

  • bind(): Assign local address/port to a socket (server).

  • listen(): Mark a bound socket as passive, waiting for connection requests (TCP server).

  • accept(): Block until a connection request arrives; returns a new socket for the connection.

  • connect(): Actively initiate a connection to a server (TCP client).

  • send() / recv(): Transmit/receive data on a connected stream (TCP) or datagram (UDP) socket.

  • sendto() / recvfrom(): For connectionless (UDP) communication, specify destination/source address.

• Socket Types:

  • Stream Socket (SOCK_STREAM): Reliable, bidirectional, connection-oriented (TCP). Guarantees in-order delivery, no duplication. Used for web (HTTP), email (SMTP), file transfer (FTP).

  • Datagram Socket (SOCK_DGRAM): Unreliable, connectionless, no guarantee of delivery/order (UDP). Faster, lower overhead. Used for DNS, VoIP, video streaming, broadcast/multicast, simple request-reply where speed > reliability.

[!TIP] Datagram Socket Use Case: When low latency is critical and occasional loss is acceptable (e.g., live video, gaming, syslog). Or for broadcast/multicast where TCP's connection model doesn't fit.

System Worker Threads

• Role: Special kernel threads that execute system services on behalf of the kernel or other processes. They run in the System Process (System PID 4) context. They handle:

  • I/O completion (after an interrupt, finish processing).

  • Memory management (page faults, working set management).

  • Cache manager activities.

  • Delayed procedure calls (DPCs) and APCs (Asynchronous Procedure Calls).

• Implementation & Scheduling:

  • Created by kernel routines (e.g., KeCreateSystemWorkerThread).

  • Run in kernel mode, at PASSIVE_LEVEL or DISPATCH_LEVEL IRQL.

  • Scheduled by the kernel's dispatcher like any other thread, but with real-time priority often. They are not visible in user-space task managers as regular processes.

Windows Global Flags

• Purpose: System-wide configuration flags stored in the Registry (HKLM\System\CurrentControlSet\Control\Session Manager\Global Flag) or set via gflags.exe. Used for debugging, performance tuning, and altering system behavior.

• Common Flags & Effects:

  • FLG_HEAP_ENABLE_TAIL_CHECK, FLG_HEAP_ENABLE_FREE_CHECK, FLG_HEAP_VALIDATE_PARAMETERS: Enable heap corruption detection (slow, for debug).

  • FLG_KERNEL_STACK_TRACE_DB: Track kernel stack usage (debug).

  • FLG_STOP_ON_EXCEPTION: Break into debugger on first-chance exception.

  • FLG_DISABLE_PAGING_KERNEL: Keep kernel code/data in memory (performance, uses more RAM).

  • FLG_APPLICATION_VERIFIER: Enable Application Verifier checks for a specific process (heap, handles, locks).

VIII. MOBILE OPERATING SYSTEM SECURITY

Android Security Model

• Security Levels (Layered Defense):

  1. Linux Kernel: Base security (user/group IDs, permissions, SELinux enforcing mode). Each app runs as a unique Linux UID.

  2. Sandboxing: Each app runs in its own Linux process and private data directory (/data/data/<package>). By default, apps cannot access each other's files or memory.

  3. Application Permissions: User-granted permissions at install (pre-Android 6.0) or runtime (Android 6.0+). Apps declare needed permissions in AndroidManifest.xml. Principle of least privilege.

  4. SELinux (Security-Enhanced Linux): Mandatory Access Control (MAC). Enforces type enforcement. Policies define what processes (domains) can do (access files, sockets). Runs in enforcing mode on modern Android. Prevents privilege escalation.

• Application Signing: All APKs must be signed with a developer's private key. The certificate identifies the author and allows sharedUserId (apps from same signer can share UID/data). Updates must be signed with same key.

• Isolation: Enforced by Linux UID/GID, SELinux, and the Application Sandbox. System apps have different (often more privileged) UIDs.

Secure Wallet

• Definition: A mobile application or hardware-backed service that securely stores sensitive information (credit/debit card details, loyalty cards, boarding passes, digital IDs) for contactless payments and authentication.

• Security Features:

  • Hardware-Backed Keystore: Sensitive keys (for encryption/authentication) stored in Trusted Execution Environment (TEE) or Secure Element (SE). Isolated from main OS.

  • Encryption: All stored data encrypted with keys protected by hardware.

  • Tokenization: Actual card number replaced with a device-specific token for transactions. Real card number never transmitted/stored on device.

  • Biometric Authentication: Unlock wallet with fingerprint/face (via TEE).

  • Remote Wipe: Can be disabled/cleared via "Find My Device" if phone lost.

  • Secure Communication: Uses NFC with secure channel protocols (e.g., EMVCo).

Mobile OS Vulnerabilities (Attack Surfaces)

• Bluetooth/Wi-Fi: Vulnerabilities in protocol stacks (BlueBorne, KRACK). Unauthorized pairing, data interception.

• App Permissions: Over-privileged apps (malicious or buggy) request excessive permissions (location, contacts, SMS). Side-channel attacks via permission-granted sensors.

• SMS/MMS: Processing flaws in MMS parser (e.g., Stagefright) allow remote code execution via crafted message.

• OS Components: Vulnerabilities in system services (media server, binder IPC, stagefright), kernel (root exploits).

• Supply Chain: Malicious apps in official stores (Google Play), trojanized legitimate apps.

• Physical Access: Lack of full-disk encryption (older devices), JTAG debugging, chip-off attacks.

IX. SPECIALIZED SECURITY HARDWARE AND TECHNIQUES

Secure Coprocessor

• Definition: A dedicated, tamper-resistant microprocessor designed to provide cryptographic functions and secure storage for secrets (keys, certificates). Isolated from the main CPU.

• Examples:

  • TPM (Trusted Platform Module): Standardized (ISO/IEC 11889). Provides: measured boot (storing hashes in PCRs), key generation/storage (non-exportable), attestation, sealing (binding data to system state). Used for disk encryption (BitLocker), DRM.

  • HSM (Hardware Security Module): High-performance, often network-attached appliance for enterprise key management and cryptographic acceleration. Used by banks, CAs.

  • Secure Element (SE): Small, tamper-resistant chip (e.g., in smartphones, smart cards, SIM cards). Used for mobile payments (Google Pay, Apple Pay), secure authentication.

• Architecture & Security Benefits:

  • Isolation: Separate bus, memory. Main OS cannot directly read its memory.

  • Tamper Resistance: Physical attacks (probing, voltage glitching) trigger key deletion.

  • Secure Boot Chain: Verifies firmware/OS integrity before release.

  • Key Storage: Root keys never leave the chip. Performs crypto operations internally.

  • Attestation: Can cryptographically prove its identity and software state to a remote party.

Virtualization for Security

• Types:

  • Full Virtualization: Guest OS runs unmodified. Hypervisor (Type-1: bare-metal like ESXi, Hyper-V; Type-2: hosted like VirtualBox) traps and emulates privileged instructions. High isolation.

  • Para-virtualization: Guest OS is modified to be aware of hypervisor and makes "hypercalls" for privileged operations. More efficient (Xen).

• Security Applications:

  • Sandboxing/Isolation: Run untrusted code/apps in a VM. Compromise is contained; VM can be discarded/reverted to clean snapshot.

  • Malware Analysis: Dynamic analysis in isolated, instrumented VMs. Safe observation of malware behavior.

  • Honeypots: High-interaction honeypots can be full VMs, allowing deep analysis while containing the attack.

  • Secure Desktop/Workspace: Run sensitive tasks in a separate, encrypted VM (e.g., Qubes OS).

  • Live Forensics: Take memory snapshot of a VM for analysis without affecting host.

  • Cloud Security: Multi-tenancy isolation between customer VMs on same physical host.

X. DATA STRUCTURES IN OPERATING SYSTEMS

Queues

• Application:

  • Process Scheduling: Ready queue (FIFO, priority queue), wait queues (for I/O, events).

  • IPC (Message Queues): Kernel-managed queues for inter-process message passing.

  • I/O Buffering: Device I/O request queues (e.g., disk scheduler queue - elevator algorithm).

  • Spooling: Print spooler queue.

• Implementation: Often circular arrays or linked lists. Operations: enqueue(), dequeue(). Time complexity O(1) for both with proper implementation.

Trees

• Application:

  • File Systems:

    • Directory Structure: Tree (rooted at /). Inodes form a flat array, but directory hierarchy is a tree.

    • B-trees / B+ trees: Used for indexing in file systems (e.g., NTFS MFT entries, ext4 HTree) and databases. Balanced, optimized for disk block access (high fan-out reduces tree height).

  • Process Hierarchies: Parent-child relationships form a process tree (e.g., in ps output). Used for job control, process groups, sessions.

  • Memory Management: Page tables can be implemented as multi-level page tables (tree structure) to save space for sparse address spaces.

• Key Property: Hierarchical organization, efficient search (logarithmic time for balanced trees like B-tree).