Skip to content

Security and Performance Engineering Terminology Glossary

A comprehensive reference for systems security, exploit techniques, mitigations, and performance engineering terminology. Each entry includes a precise technical definition, related terms, and cross-references.

A

ASLR (Address Space Layout Randomization)

A kernel security mitigation that randomizes the virtual addresses of key memory regions — stack, heap, loaded libraries, and the main executable (when compiled as PIE) — each time a process starts. ASLR forces attackers to either guess addresses (probability 1/2^bits of entropy) or use an information leak before exploiting memory corruption vulnerabilities. Linux controls ASLR via /proc/sys/kernel/randomize_va_space (0=off, 1=partial, 2=full). KASLR extends the same concept to kernel memory layout.

  • Related terms: KASLR, PIE, exploit, DEP/NX, RELRO, information leak
  • See also: KASLR, exploit, DEP/NX

B

Buffer Overflow

A memory corruption vulnerability where a program writes data beyond the allocated bounds of a buffer, overwriting adjacent memory. Stack buffer overflows traditionally overwrite the saved return address, redirecting execution to attacker-controlled code. Heap buffer overflows overwrite adjacent heap metadata or objects. Mitigations include stack canaries, ASLR, DEP/NX, CFI, and safe string functions. Buffer overflows remain one of the most exploited vulnerability classes despite decades of effort.

  • Related terms: Stack canary, heap spray, ROP, DEP/NX, ASLR, off-by-one
  • See also: Stack canary, ROP, DEP/NX, ASLR

C

Capabilities (Linux)

A fine-grained privilege model that partitions the traditional all-or-nothing root privilege into distinct units called capabilities, each granting a specific privileged action. Examples: CAP_NET_ADMIN (network configuration), CAP_SYS_ADMIN (broad system administration), CAP_DAC_OVERRIDE (bypass file permissions), CAP_NET_BIND_SERVICE (bind ports below 1024). Capabilities can be granted, restricted, or dropped per-process via the capability bounding set. Container runtimes drop unneeded capabilities by default to reduce attack surface.

  • Related terms: Privilege escalation, seccomp, namespace, DAC, MAC, LSM
  • See also: Privilege escalation, seccomp

CFI (Control Flow Integrity)

A broad class of compiler and hardware mitigations that restrict the set of valid targets for indirect branches and function returns, preventing attackers from redirecting control flow to arbitrary locations (as required by ROP and JOP attacks). Forward-edge CFI protects indirect calls and jumps (e.g., clang's -fsanitize=cfi); backward-edge CFI protects return addresses (shadow stack: Intel CET, ARM PAC). The Linux kernel enables Clang CFI for selected subsystems; hardware CFI (Intel CET, ARM BTI) is increasingly available.

  • Related terms: ROP, ASLR, DEP/NX, shadow stack, Intel CET, stack canary
  • See also: ROP, DEP/NX, stack canary

Cold Start

The performance penalty incurred when a system or component processes a request with no warm cache, just-in-time compilation, or preloaded state. In serverless (FaaS) environments, a cold start occurs when a new function instance is provisioned from scratch, including container startup, runtime initialization, and code loading — adding hundreds of milliseconds of latency. In CPU/memory contexts, cold cache accesses (LLC misses, TLB misses) add latency compared to warm cache accesses. In JIT-compiled languages (JVM, .NET), the first execution path incurs JIT compilation overhead.

  • Related terms: Latency, cache, TLB, JIT, FaaS, profiling
  • See also: Latency, TLB, profiling

CVE (Common Vulnerabilities and Exposures)

A public catalog of security vulnerabilities, each assigned a unique identifier (e.g., CVE-2021-44228 for Log4Shell) and a CVSS severity score. Maintained by MITRE and sponsored by DHS/CISA, CVEs enable unambiguous reference to specific vulnerabilities across vendors, advisories, and tools. NVD (National Vulnerability Database) augments CVEs with CVSS scores, CWE classifications, and CPE affected product lists. Kernel CVEs (e.g., Meltdown: CVE-2017-5754) trigger coordinated disclosure and emergency patching.

  • Related terms: CVSS, exploit, vulnerability, zero-day, patch, supply chain attack
  • See also: Vulnerability, zero-day, exploit

D

DEP / NX (Data Execution Prevention / No-Execute)

A hardware and OS security mechanism that marks memory pages containing data (stack, heap) as non-executable, preventing an attacker from executing shellcode injected into these regions. The CPU enforces this via the NX (No-Execute) bit in page table entries (XD/XN on Intel/ARM). NX/DEP is the foundational binary exploitation mitigation; it effectively defeated simple shellcode injection, forcing attackers to pivot to code-reuse attacks (ROP). The Linux kernel enables NX on all data pages by default.

  • Related terms: ROP, ASLR, CFI, stack canary, executable, page table
  • See also: ROP, ASLR, CFI

Double-Free

A memory safety vulnerability where a program calls free() on a heap pointer that has already been freed. The memory allocator's metadata may be corrupted by the second free, potentially enabling an attacker to gain control over subsequent allocations and achieve arbitrary code execution. Double-frees are a subclass of use-after-free bugs. Mitigations include KASAN (kernel), AddressSanitizer (userspace), safe allocators that detect double-frees, and Rust's ownership system which prevents them at compile time.

  • Related terms: UAF, heap spray, KASAN, AddressSanitizer, type confusion
  • See also: UAF, KASAN, heap spray

E

eBPF Verifier

The in-kernel static analysis component that ensures BPF programs loaded by users are safe to run before they are JIT-compiled and executed in the kernel. The verifier performs: control flow graph analysis (ensures termination, no unbounded loops), register type tracking (detects invalid memory accesses, NULL pointer dereferences), and bounds checking (ensures all memory accesses are within safe bounds). The verifier rejects programs that could crash or compromise the kernel. It is one of the most complex and security-critical components of the eBPF subsystem.

  • Related terms: BPF/eBPF, JIT, kernel exploit, BTF, verifier
  • See also: BPF/eBPF

Exploit

A program, code sequence, or technique that takes advantage of a software vulnerability to cause unintended behavior, typically to achieve privilege escalation, code execution, or data exfiltration. Exploit techniques include: return-to-libc, ROP chains, heap grooming, type confusion, use-after-free exploitation, and kernel privilege escalation. The exploit development process involves vulnerability discovery, debugging, bypassing mitigations (ASLR, NX, stack canaries), and achieving a reliable primitive. Modern exploits typically chain multiple vulnerabilities and mitigations bypasses.

  • Related terms: CVE, vulnerability, ROP, ASLR, DEP/NX, privilege escalation
  • See also: CVE, vulnerability, ROP, privilege escalation

F

False Sharing

A performance phenomenon in multi-core systems where two or more CPU cores repeatedly invalidate each other's cache lines even though they are accessing different variables, solely because those variables reside on the same cache line (typically 64 bytes). False sharing causes excessive cache coherence traffic (MESI/MOESI transitions) and can dramatically degrade performance in multi-threaded programs. Mitigation: pad data structures so that frequently-modified variables owned by different threads sit on separate cache lines (__cacheline_aligned, alignas(64)).

  • Related terms: MESI, MOESI, cache line, cache coherence, SMP, performance
  • See also: MESI, MOESI, cache

Flame Graph

A visualization technique for profiling data, invented by Brendan Gregg, that stacks sampled call frames into a hierarchical chart where the x-axis shows sample frequency (wider = more CPU time or off-CPU time) and the y-axis shows call depth. Flame graphs immediately reveal the hottest code paths. Variants: CPU flame graphs (on-CPU profiling via perf record), off-CPU flame graphs (time blocked, via tracing sleep/wake), memory flame graphs, and latency heat maps. Generated by perf script | stackcollapse-perf.pl | flamegraph.pl.

  • Related terms: Profiling, perf, off-CPU time, PMU, sampling, USE method
  • See also: Profiling, perf, off-CPU time

FLOPS (Floating-Point Operations Per Second)

A measure of a processor's floating-point computation throughput. Modern CPUs achieve GFLOPS to TFLOPS range; GPUs achieve hundreds of TFLOPS to PFLOPS for AI workloads. Theoretical peak FLOPS = frequency × cores × FP operations per cycle per core (e.g., AVX-512 FMA provides 32 FP64 operations/cycle). Achieved FLOPS in practice are lower due to memory bandwidth limitations, instruction latency, and non-FP overhead. FLOPS is used to characterize HPC workload performance and hardware capabilities.

  • Related terms: AVX, FMA, SIMD, GPU, IPC, ALU
  • See also: IPC (instructions per cycle), SIMD

H

Heap Spray

An exploit technique where an attacker allocates a large number of identical objects in the heap, filling it with shellcode or ROP gadgets and NOP sleds, to increase the probability that a corrupted pointer or jump to a guessed heap address lands in the controlled data. Heap spray compensates for ASLR by covering a large portion of the address space. Mitigations include: high-entropy ASLR, guard pages, heap metadata integrity checks, and CFI. Heap sprays are commonly used against browser and document reader exploits.

  • Related terms: ASLR, exploit, ROP, DEP/NX, buffer overflow, JIT
  • See also: ASLR, ROP, buffer overflow

I

IPC (Instructions Per Cycle)

A CPU performance metric measuring how many instructions the processor completes per clock cycle. Higher IPC indicates more efficient execution. IPC depends on: instruction-level parallelism (ILP) in the code, branch prediction accuracy, cache hit rates, and execution unit utilization. Modern out-of-order CPUs (4-6 wide issue) can achieve IPC > 4 in ideal conditions. Memory-bound workloads often achieve IPC < 1. IPC is a key metric for CPU microarchitecture comparisons (different from FLOPS, which counts only FP operations). Measured via perf stat -e instructions,cycles.

  • Related terms: CPI, FLOPS, ILP, OoO, PMU, pipeline, branch prediction
  • See also: FLOPS, PMU, profiling

IOPS (I/O Operations Per Second)

A measure of storage device or storage system throughput in terms of the number of individual read or write operations completed per second. IOPS depends on I/O size, queue depth, and access pattern (random vs. sequential). NVMe SSDs achieve 1–7 million IOPS; HDDs typically achieve 100–200 IOPS. Cloud storage has IOPS limits per volume. IOPS is critical for database and transactional workloads. Small random I/O (4 KB) stresses IOPS; large sequential I/O (1 MB+) stresses bandwidth. Write amplification reduces effective IOPS over SSD lifetime.

  • Related terms: NVMe, latency, throughput, write amplification, storage, queue depth
  • See also: NVMe, write amplification, latency

K

KASAN (Kernel Address Sanitizer)

A dynamic memory error detector for the Linux kernel that detects out-of-bounds accesses, use-after-free, and use-after-return bugs in kernel code. KASAN uses shadow memory (one byte of shadow per 8 bytes of kernel memory) to track whether each byte of kernel memory is accessible. On memory accesses, GCC/Clang-inserted instrumentation checks the shadow memory and raises a kernel oops on violation. Available in two modes: generic KASAN (software, high overhead) and hardware-tag-based KASAN (uses ARM MTE, low overhead). Essential for kernel development and fuzzing.

  • Related terms: KASLR, UAF, double-free, kernel oops, sanitizer, fuzzing
  • See also: UAF, double-free, kernel oops

KASLR (Kernel Address Space Layout Randomization)

A security mitigation that randomizes the base address of the kernel image, kernel modules, and kernel heap in virtual memory at each boot. KASLR makes it harder for attackers to predict the addresses of kernel gadgets needed for ROP attacks or the location of sensitive kernel data structures. The randomization offset is chosen at boot time. KASLR is weakened by information leaks that expose kernel addresses (mitigated by restricting /proc/kallsyms and dmesg to root, and hardware defenses). All modern Linux kernels enable KASLR by default.

  • Related terms: ASLR, kernel exploit, ROP, information leak, SMEP, SMAP
  • See also: ASLR, kernel exploit, ROP

Kernel Exploit

An exploit that targets a vulnerability in the OS kernel (or a kernel module/driver) to achieve privilege escalation from a restricted user context to root, or to escape a sandbox/container. Common kernel exploit primitives: gaining arbitrary kernel read/write via a UAF or buffer overflow, then overwriting credentials or function pointers. Kernel mitigations (KASLR, SMEP, SMAP, CFI, KASAN, seccomp) make kernel exploits significantly harder. Kernel exploits are a critical threat model for multi-tenant cloud environments.

  • Related terms: Privilege escalation, KASLR, SMEP, SMAP, ret2usr, ROP
  • See also: Privilege escalation, KASLR, ret2usr, SMEP, SMAP

L

L1TF (L1 Terminal Fault / Foreshadow)

A speculative execution side-channel attack (CVE-2018-3615, -3620, -3646) that exploits a design flaw in Intel CPUs: when a page table entry is marked not-present (terminal fault), the CPU may still speculatively access the L1 data cache using the physical address in the PTE. This allows a malicious guest VM or process to read arbitrary data from the L1 cache of the host or other VMs. Mitigations include flushing the L1 cache on VM entry/exit and microcode updates. Related to Meltdown but distinct in mechanism.

  • Related terms: Meltdown, Spectre, speculative execution, side-channel, hypervisor
  • See also: Meltdown, Spectre

Latency Percentile

A statistical measure describing the distribution of response times (or other latency measurements) for a system or service. p50 is the median; p95 means 95% of requests are faster than this value; p99 means 99% are faster; p999 means 99.9% are faster. Tail latency (p99, p999) reveals worst-case behavior, which matters for services with large fanouts or SLO requirements. Arithmetic mean is misleading for latency (bimodal distributions, outliers); percentiles are the standard. Tools: HdrHistogram, Prometheus histograms, perf.

  • Related terms: p50/p95/p99, SLA/SLO/SLI, tail latency, histogram, USE method
  • See also: p50/p95/p99, SLA/SLO/SLI

Lockdep (Lock Dependency Validator)

A Linux kernel dynamic analysis tool that detects potential deadlocks and lock ordering violations at runtime by tracking the order in which locks are acquired and building a directed graph of lock dependencies. If a new lock acquisition would create a cycle in the dependency graph (indicating a potential deadlock), lockdep reports the violation even before a deadlock actually occurs. Lockdep is enabled by CONFIG_PROVE_LOCKING and is invaluable for kernel development but adds significant runtime overhead, so it is used only in debug kernels.

  • Related terms: Deadlock, spinlock, mutex, kernel oops, KASAN
  • See also: Deadlock, lock (spinlock/mutex)

M

Meltdown

A speculative execution side-channel attack (CVE-2017-5754) that exploits the fact that Intel (and some ARM) CPUs speculatively execute instructions and access memory before privilege checks complete. An unprivileged user-space program can transiently read arbitrary kernel memory — even though the access is architecturally forbidden — by timing cache accesses (Flush+Reload). The kernel mitigation is KPTI (Kernel Page-Table Isolation), which maps the kernel out of user-space page tables, preventing speculative kernel memory accesses from user space.

  • Related terms: Spectre, L1TF, KPTI, speculative execution, side-channel, KASLR
  • See also: Spectre, L1TF, KASLR

Memory Safety

The property of a program that guarantees it will not perform invalid memory operations: no out-of-bounds reads or writes, no use-after-free, no use of uninitialized memory, and no double-free. Memory-unsafe languages (C, C++) rely on programmer discipline and tooling (sanitizers, fuzzing) to ensure memory safety. Memory-safe languages (Rust, Go, Java) provide this guarantee via ownership/type systems or garbage collection. The majority of severe security vulnerabilities in C/C++ codebases are memory safety bugs; this is driving adoption of Rust in OS and browser development.

  • Related terms: UAF, double-free, buffer overflow, KASAN, Rust, sanitizer
  • See also: UAF, double-free, buffer overflow, KASAN

MESI (Modified-Exclusive-Shared-Invalid)

The most common cache coherence protocol used in multi-core processors, defining four states for each cache line: Modified (dirty, only copy, exclusive ownership), Exclusive (clean, only copy), Shared (clean, multiple copies across caches), Invalid (stale, must be fetched). State transitions are triggered by reads and writes from different cores. A write to a Shared line triggers an invalidation broadcast to all other caches (RFO: Request for Ownership), causing false sharing overhead if multiple cores write adjacent data.

  • Related terms: MOESI, false sharing, cache coherence, SMP, cache line, memory barrier
  • See also: MOESI, false sharing, cache coherence

Mitigation

A software, firmware, or hardware change that reduces the exploitability or impact of a security vulnerability without necessarily fixing the underlying bug. Mitigations are deployed when a complete fix is infeasible, too disruptive, or not yet available. Examples: KPTI (Meltdown), Retpoline (Spectre v2), microcode updates (MDS), stack canaries (buffer overflow), ASLR (memory corruption), seccomp (syscall restriction). Mitigations often carry performance costs (KPTI adds ~5-30% syscall overhead); some can be disabled via kernel parameters (e.g., spectre_v2=off).

  • Related terms: ASLR, KPTI, Retpoline, stack canary, CVE, vulnerability
  • See also: ASLR, Meltdown, Spectre, stack canary

MOESI (Modified-Owned-Exclusive-Shared-Invalid)

An extended cache coherence protocol (used by AMD processors) that adds an Owned state to MESI. The Owned state allows a modified cache line to be shared with other caches without first writing it back to main memory, reducing memory bus traffic. In the Owned state, one cache holds the "authoritative" dirty copy and is responsible for supplying the data to other caches on a miss (cache-to-cache transfer). MOESI reduces write-back overhead in NUMA and multi-socket systems compared to MESI.

  • Related terms: MESI, false sharing, cache coherence, NUMA, cache line
  • See also: MESI, false sharing

N

NVMe (Non-Volatile Memory Express)

A host controller interface and storage protocol designed from the ground up for flash-based SSDs, exploiting PCIe's parallelism with up to 64K I/O queues each supporting up to 64K commands. NVMe replaces AHCI (designed for spinning disks), reducing latency and CPU overhead dramatically. NVMe SSDs achieve sub-100 µs latency and millions of IOPS. The NVMe specification also defines NVMe-oF for networked access. NVMe namespaces provide logical partitioning; NVMe ZNS (Zoned Namespaces) exposes flash erase blocks to eliminate internal FTL write amplification.

  • Related terms: IOPS, NVMe-oF, PCIe, write amplification, storage, ZNS
  • See also: IOPS, write amplification, PCIe

O

Off-CPU Time

The time a thread spends NOT running on a CPU — blocked waiting for I/O, sleeping, waiting for a lock, or descheduled. Off-CPU time is the complement of on-CPU time; together they account for all wall-clock time. Profiling off-CPU time is essential for identifying lock contention, I/O bottlenecks, and scheduler delays that on-CPU profilers (perf sampling) miss entirely. Off-CPU analysis uses kernel tracing (eBPF, ftrace) to record sleep/wake events and their durations. Brendan Gregg's off-CPU flame graphs visualize this data.

  • Related terms: Profiling, flame graph, perf, USE method, context switch, scheduler
  • See also: Flame graph, profiling, USE method

OOM (Out of Memory)

The condition where a process or the system cannot satisfy a memory allocation request. At the process level, malloc() returns NULL; at the kernel level, page allocation fails. The Linux kernel's OOM killer activates to free memory by killing processes. In container environments (Kubernetes), the cgroup memory controller kills processes in the cgroup when the memory limit is exceeded. OOM conditions can be triggered by memory leaks, sudden load spikes, or memory fragmentation. dmesg records OOM kill events with detailed process memory information.

  • Related terms: OOM killer, swap, cgroup, page, memory, fragmentation
  • See also: OOM killer (01-kernel-and-os-terms.md), swap

OpenTelemetry (OTel)

A vendor-neutral, open-source observability framework and CNCF project providing a unified set of APIs, SDKs, and instrumentation for generating, collecting, and exporting telemetry data (traces, metrics, and logs). OpenTelemetry replaces vendor-specific SDKs (Jaeger, Zipkin, Prometheus clients) with a single instrumentation layer. The OTel Collector is a standalone agent/pipeline for receiving, processing, and exporting telemetry to backends (Jaeger, Grafana Tempo, Prometheus, Datadog). Context propagation (W3C TraceContext) enables distributed tracing across service boundaries.

  • Related terms: distributed tracing, metrics, logs, Jaeger, Prometheus, SLI
  • See also: SLA/SLO/SLI, profiling

P

p50 / p95 / p99

Shorthand for the 50th, 95th, and 99th percentile latency values in a latency distribution. p50 is the median response time experienced by half of all requests. p95 means 5% of requests are slower than this value — this is often the SLO target for user-facing services. p99 means 1% of requests are slower — relevant for detecting tail latency issues. p999 (99.9th percentile) matters in high-volume services (1 in 1000 requests). High-percentile latency often reflects lock contention, GC pauses, or disk I/O. Use HdrHistogram for accurate high-percentile measurement.

  • Related terms: Latency percentile, SLA/SLO/SLI, tail latency, histogram, USE method
  • See also: Latency percentile, SLA/SLO/SLI

Perf

The primary Linux performance analysis tool, built into the kernel via the perf_events subsystem. perf stat collects hardware performance counter statistics (cycles, instructions, cache misses, branch mispredictions). perf record samples call stacks at a frequency (using PMU overflow interrupts or software events) and writes a data file. perf report / perf top analyze the data interactively. perf trace is a strace alternative using eBPF. Perf supports kernel and user-space stack unwinding and integrates with flame graph generation.

  • Related terms: PMU, flame graph, profiling, off-CPU time, PMC, eBPF
  • See also: Flame graph, PMU, profiling

PMU (Performance Monitoring Unit)

Hardware components in modern CPUs that count microarchitectural events such as clock cycles, retired instructions, cache hits/misses (L1/L2/LLC), branch predictions and mispredictions, TLB misses, and memory bandwidth. PMUs contain a set of hardware performance counters (PMCs) that can be configured to count specific events. The Linux kernel accesses PMUs via the perf_events subsystem; Intel's VTune and AMD's uProf also use PMUs. Cycle-accurate profiling, cache miss analysis, and bottleneck identification all rely on PMU data.

  • Related terms: Perf, PMC, flame graph, profiling, IPC, cache miss
  • See also: Perf, IPC (instructions per cycle), profiling

Privilege Escalation

An attack that allows a user or process to gain more permissions or a higher privilege level than intended. Vertical privilege escalation: a non-root user gains root access (via a kernel exploit, setuid binary vulnerability, or misconfigured sudo). Horizontal privilege escalation: a user gains access to another user's resources without elevated privileges. Common vectors: kernel vulnerabilities (UAF, buffer overflow in drivers), misconfigured capabilities, SUID binaries, container escapes, and credential theft. Defense-in-depth layers (seccomp, capabilities, namespaces, KASLR) raise the bar.

  • Related terms: Kernel exploit, CVE, capabilities, SUID, seccomp, container escape
  • See also: Kernel exploit, capabilities, seccomp

Profiling

The process of measuring a program's runtime behavior to identify performance bottlenecks — functions consuming the most CPU time, hot memory regions, or latency sources. Profiling techniques: sampling (PMU-based, low overhead, statistical approximation), instrumentation (precise, high overhead), and tracing (event-driven, eBPF-based). Tools: perf (Linux), Instruments (macOS), VTune (Intel), py-spy (Python), async-profiler (JVM). Continuous profiling (always-on, low-overhead) in production environments (Parca, Grafana Pyroscope) enables fleet-wide performance visibility.

  • Related terms: Perf, flame graph, PMU, off-CPU time, USE method, sampling
  • See also: Perf, flame graph, PMU, off-CPU time

R

Race Condition

A software bug where the outcome of a computation depends on the relative timing or interleaving of concurrent operations, producing incorrect results when the expected ordering is violated. Data races (the most severe form) occur when two threads access the same memory location concurrently and at least one access is a write, without synchronization. Race conditions in security contexts (TOCTOU) allow attackers to exploit the window between a check and a use. TSan (ThreadSanitizer) detects data races at runtime; Rust's ownership system prevents them at compile time.

  • Related terms: TOCTOU, TSan, deadlock, synchronization, lock, memory barrier
  • See also: TOCTOU, TSan, deadlock

Red Zone

A small region of memory beyond the end of a stack frame (typically 128 bytes on x86_64 System V ABI) that is guaranteed not to be clobbered by signal handlers or asynchronous events, allowing leaf functions to use it as scratch space without explicitly adjusting the stack pointer. The red zone is also used in KASAN to detect stack-based out-of-bounds accesses: instrumented code places poisoned shadow memory in red zone areas and reports violations. Interrupt handlers and kernel code that handles asynchronous events must not use the red zone.

  • Related terms: Stack canary, buffer overflow, KASAN, ABI, stack frame
  • See also: Buffer overflow, stack canary, KASAN

RELRO (Relocation Read-Only)

A binary hardening technique (linker/loader feature) that marks certain ELF sections read-only after dynamic linking completes, preventing attackers from overwriting them to redirect code execution. Partial RELRO marks the .dynamic and .got (except the PLT-reachable portion) as read-only. Full RELRO additionally resolves all PLT entries eagerly at load time and marks the entire GOT read-only, preventing GOT overwrite attacks. Full RELRO increases load time slightly due to eager symbol resolution. GCC/Clang enable it with -Wl,-z,relro,-z,now.

  • Related terms: PIE, ASLR, exploit, GOT, PLT, linker, binary hardening
  • See also: ASLR, exploit, DEP/NX

ret2usr (Return-to-User)

A kernel exploitation technique where an attacker tricks the kernel into executing user-space code with kernel privileges, typically by redirecting a kernel control flow transfer to attacker-controlled shellcode in the user address space. Before SMEP (Supervisor Mode Execution Prevention) was widely deployed, ret2usr was a primary kernel exploitation primitive. SMEP prevents the CPU (in ring 0) from executing code from user-space pages, blocking ret2usr. Modern kernel exploits must redirect execution to existing kernel code (ROP, JOP) rather than user-space shellcode.

  • Related terms: SMEP, SMAP, kernel exploit, ROP, privilege escalation, KASLR
  • See also: SMEP, SMAP, kernel exploit, ROP

ROP (Return-Oriented Programming)

A code-reuse attack technique that chains together small sequences of existing code ending in a ret instruction (gadgets) to construct an arbitrary computation, bypassing DEP/NX without injecting new code. The attacker controls the stack, placing gadget addresses sequentially; each ret pops the next gadget address from the stack. ROP can synthesize any computation using gadgets found in the program or libraries. CFI, stack canaries, and shadow stacks (Intel CET, ARM PAC) mitigate ROP. ROP chains are the standard technique for modern binary exploitation.

  • Related terms: DEP/NX, CFI, ASLR, stack canary, exploit, ret2usr, trampoline
  • See also: DEP/NX, CFI, stack canary, ret2usr

Rowhammer

A hardware vulnerability in DRAM where repeated, rapid reads to the same row of memory cells cause bit flips in adjacent rows, due to electromagnetic interference between cells. Rowhammer can be exploited by unprivileged code to flip bits in page table entries, escalating privileges or corrupting data. Variants: double-sided Rowhammer (hammering rows above and below a target), TRRespass (bypassing Target Row Refresh mitigations), and Half-Double. Mitigations include ECC DRAM, TRR (Target Row Refresh), and LPDDR5 RFM (Refresh Management).

  • Related terms: DRAM, ECC, privilege escalation, side-channel, hardware vulnerability
  • See also: Privilege escalation, DRAM

S

Sandbox

An isolated execution environment that restricts the capabilities of untrusted code, limiting what system resources it can access and what damage it can do if compromised. Sandboxing mechanisms on Linux include: seccomp-BPF (syscall restriction), namespaces (resource isolation), capabilities (privilege reduction), cgroups (resource limits), and SELinux/AppArmor (MAC policies). Browser sandboxes (Chrome renderer, Firefox content process) combine all of these. Container runtimes add another sandbox layer. The goal is defense-in-depth: even if sandboxed code exploits a vulnerability, the blast radius is contained.

  • Related terms: Seccomp, namespaces, capabilities, cgroup, MAC, SELinux
  • See also: Seccomp, capabilities, namespace (01-kernel-and-os-terms.md)

SMAP (Supervisor Mode Access Prevention)

A CPU security feature (x86, ARM) that prevents kernel-mode code (ring 0) from directly accessing user-space memory pages, unless the kernel explicitly enables access temporarily (via stac/clac instructions around intentional user-memory copies). SMAP prevents kernel exploits that read or write arbitrary user-space data from kernel context (e.g., dereferencing an attacker-controlled user-space pointer passed to the kernel without proper validation). Linux enables SMAP on all CPUs that support it; copy_from_user/copy_to_user temporarily disable SMAP.

  • Related terms: SMEP, ret2usr, kernel exploit, privilege escalation, KASLR
  • See also: SMEP, ret2usr, kernel exploit

SMEP (Supervisor Mode Execution Prevention)

A CPU security feature (x86, ARMv8) that prevents the CPU in kernel mode (ring 0) from executing code located in user-space memory pages. SMEP blocks ret2usr attacks, forcing kernel exploits to use code-reuse techniques (ROP) targeting only kernel-mode pages. Linux enables SMEP on all supporting CPUs automatically. Together with SMAP, SMEP significantly raises the complexity required for kernel exploitation. Hardware enforcement makes it very difficult to bypass without first defeating KASLR to find kernel ROP gadgets.

  • Related terms: SMAP, ret2usr, kernel exploit, KASLR, CFI, DEP/NX
  • See also: SMAP, ret2usr, kernel exploit, KASLR

Spectre

A class of speculative execution side-channel attacks (CVE-2017-5753, CVE-2017-5715) that exploit the CPU's branch prediction and speculative execution to leak information across privilege boundaries. Unlike Meltdown (which is a CPU privilege check bypass), Spectre tricks a victim process into speculatively accessing its own memory at attacker-chosen locations, then uses a cache side-channel to exfiltrate the data. Spectre Variant 1 (bounds-check bypass) requires compiler mitigations (array_index_mask_nospec); Variant 2 (branch target injection) is mitigated by Retpoline (software) and eIBRS (hardware).

  • Related terms: Meltdown, L1TF, speculative execution, side-channel, Retpoline, KASLR
  • See also: Meltdown, L1TF, side-channel

Stack Canary

A security mitigation against stack buffer overflows that places a random "canary" value between a function's local variables and the saved return address. Before returning, the function checks that the canary value has not been modified; if it has (indicating a stack buffer overflow has overwritten it), the program calls __stack_chk_fail() and terminates. Stack canaries (GCC's SSP, -fstack-protector-strong) prevent basic stack smashing but do not protect against overwrites that skip the canary or against format string attacks. They are a standard hardening measure on all modern Linux distributions.

  • Related terms: Buffer overflow, ROP, ASLR, DEP/NX, CFI, red zone
  • See also: Buffer overflow, ROP, DEP/NX

Stack Overflow

An error condition where a program's call stack grows beyond its allocated size, typically caused by unbounded or excessively deep recursion. The kernel allocates a fixed-size guard page below the stack; when the stack pointer crosses into it, a page fault triggers SIGSEGV. In kernel context, stack overflows are catastrophic (no guard page, adjacent memory may be corrupted). Linux uses per-CPU kernel stacks and IRQ stacks to limit overflow risk. Stack overflows can be exploited to overwrite adjacent data structures, making them a potential vulnerability beyond just a bug.

  • Related terms: Buffer overflow, segmentation fault, page fault, kernel panic, recursion
  • See also: Buffer overflow, page fault (01-kernel-and-os-terms.md)

Supply Chain Attack

An attack that compromises software or hardware at a point in the production, distribution, or update chain — affecting all downstream consumers — rather than attacking end targets directly. Examples: SolarWinds (trojanized build system), XZ Utils backdoor (CVE-2024-3094, malicious maintainer), NPM typosquatting, malicious Docker images. Mitigations: reproducible builds, code signing, software bill of materials (SBOM/SPDX), dependency pinning, and automated vulnerability scanning. The attack surface includes source code, build infrastructure, package repositories, and update mechanisms.

  • Related terms: CVE, SBOM, SPDX, zero-day, vulnerability, Secure Boot
  • See also: CVE, zero-day, vulnerability

T

TEE (Trusted Execution Environment)

A secure, isolated execution environment within a processor that provides confidentiality and integrity guarantees for code and data, even against a privileged attacker (OS, hypervisor) on the same platform. TEEs use hardware-enforced memory encryption and access controls. Examples: Intel TDX (Trust Domain Extensions) and SGX (Software Guard Extensions), ARM TrustZone (used in mobile), AMD SEV (Secure Encrypted Virtualization). TEEs are used for DRM, secure enclaves, confidential cloud computing, and hardware attestation. Remote attestation allows a TEE to prove its state to a remote party.

  • Related terms: TPM, SGX, TDX, SEV, attestation, confidential computing
  • See also: TPM, privilege escalation

TLB Shootdown

A multi-processor synchronization operation where one CPU must invalidate TLB entries on other CPUs after modifying page table entries they may have cached. When a page table entry is modified (page unmapped, permissions changed, page migrated), the kernel sends inter-processor interrupts (IPIs) to all CPUs that may have the stale TLB entry, forcing them to flush it. TLB shootdowns are expensive: they interrupt running processes on remote CPUs and involve IPI overhead. PCID (Process Context Identifiers) reduces the scope of shootdowns; huge pages reduce their frequency.

  • Related terms: TLB, IPI, context switch, PCID, page table, NUMA
  • See also: TLB (01-kernel-and-os-terms.md), page table, context switch

TOCTOU (Time-of-Check to Time-of-Use)

A class of race condition vulnerabilities where a program checks a condition (the "check"), then acts on the assumption that the condition still holds (the "use"), but the condition can change between the two operations. A classic example: checking file permissions with access() then opening the file with open() — an attacker can replace the file with a symlink between the two calls. TOCTOU vulnerabilities are common in privileged code dealing with filesystem paths and shared resources. Mitigation: use atomic operations (e.g., openat() with O_NOFOLLOW) that collapse check and use into one step.

  • Related terms: Race condition, symlink, filesystem, privilege escalation, access control
  • See also: Race condition, privilege escalation

TPM (Trusted Platform Module)

A dedicated hardware security chip (or firmware implementation) that provides a secure root of trust for platform integrity measurement and cryptographic operations. TPM capabilities: secure key generation and storage, remote attestation (TPM-signed measurement of boot chain), sealing (data encrypted to current platform state), and random number generation. The TPM stores Platform Configuration Registers (PCRs) that record SHA hashes of each boot stage. Secure Boot relies on the TPM to seal the boot process. Used in disk encryption (BitLocker, LUKS2 with TPM2 enrollment), attestation, and key management.

  • Related terms: TEE, Secure Boot, attestation, UEFI, PCR, disk encryption
  • See also: TEE, Secure Boot

Trampoline

In security context, a small stub of executable code that redirects execution (typically used in shellcode, JIT compilers, and function hooking). Trampolines are used by: ROP (as a controlled pivot from stack to gadget chains), dynamic binary instrumentation (Pin, Valgrind), JIT compilers (patching native call sites to compiled stubs), signal handling (kernel-provided sigreturn trampoline via vDSO), and function interposition (LD_PRELOAD). In the kernel, a trampoline is sometimes used for architecture-specific entry points (e.g., the syscall trampoline that transitions between user and kernel mode safely).

  • Related terms: ROP, JIT, shellcode, exploit, vDSO, signal
  • See also: ROP, exploit

TSan (ThreadSanitizer)

A dynamic analysis tool (developed by Google, integrated into LLVM/GCC as -fsanitize=thread) that detects data races in multi-threaded programs at runtime. TSan instruments all memory accesses and synchronization operations, maintaining shadow memory that records which threads have accessed each location and with what synchronization context. A race is reported when two threads access the same memory without proper synchronization, with at least one write. TSan has 5–20x runtime overhead, making it suitable for testing rather than production. The kernel has KCSAN (Kernel Concurrency Sanitizer) for the same purpose.

  • Related terms: Race condition, KASAN, TOCTOU, memory safety, sanitizer, lock
  • See also: Race condition, KASAN, memory safety

Type Confusion

A memory corruption vulnerability (or programming error) where a program treats a block of memory as one type when it was allocated (or is actually) a different type, leading to type-unsafe operations. Type confusion bugs are common in C++ (incorrect downcasts, virtual dispatch through wrong type, union misuse) and are exploited by overwriting an object's vtable pointer so it points to an attacker-controlled vtable. CFI mitigates type confusion by checking that virtual dispatch targets the correct class hierarchy. V8, Firefox SpiderMonkey, and WebKit have had numerous type confusion CVEs.

  • Related terms: UAF, CFI, vtable, exploit, C++, OOP, type safety
  • See also: UAF, CFI, exploit

U

UAF (Use-After-Free)

A memory corruption vulnerability where a program uses a pointer to memory that has already been freed, accessing invalid/reallocated data. After free(), the memory may be reallocated for another purpose; reading stale data leaks information, while writing corrupts the new allocation. UAF bugs can be exploited to achieve arbitrary code execution by grooming the heap to control what is allocated in the freed slot. UAF is one of the most exploited vulnerability classes in kernels, browsers, and server software. Mitigations: KASAN, AddressSanitizer, delayed free (quarantine), safe memory allocators, Rust ownership.

  • Related terms: Double-free, KASAN, heap spray, type confusion, memory safety
  • See also: Double-free, KASAN, heap spray, type confusion

USE Method

A methodology for systematic performance analysis developed by Brendan Gregg: for every resource, examine Utilization (the percentage of time the resource is busy), Saturation (the degree to which requests are queued or waiting), and Errors (error events). Applied to: CPUs (utilization via mpstat, saturation via run queue length, errors via MCE), memory (utilization via free, saturation via paging, errors via edac), disks (utilization and saturation via iostat), and network interfaces. The USE method quickly identifies bottlenecks without requiring deep domain knowledge.

  • Related terms: Profiling, flame graph, off-CPU time, perf, latency, bottleneck
  • See also: Profiling, flame graph, off-CPU time, p50/p95/p99

V

Vulnerability

A weakness in a software system (design flaw, implementation error, configuration mistake) that can be exploited by an attacker to cause harm. Vulnerability categories: memory corruption (buffer overflow, UAF, integer overflow), logic errors (TOCTOU, authentication bypass, SSRF), cryptographic weaknesses, and supply chain compromises. Vulnerabilities are classified by CWE (Common Weakness Enumeration) and assigned CVE identifiers. Severity is measured by CVSS score (0–10). The vulnerability lifecycle: discovery → reporting → patch → disclosure (coordinated or responsible disclosure).

  • Related terms: CVE, exploit, zero-day, CVE, CVSS, CWE, patch
  • See also: CVE, exploit, zero-day

W

Workload

A characterization of the demand placed on a system: the type, rate, size, and pattern of requests or operations the system must handle. Workload characterization is the first step in performance analysis (understanding what the system does before measuring how well it does it). Workloads are classified as: CPU-bound (bottleneck is compute), memory-bound (bottleneck is memory bandwidth/latency), I/O-bound (bottleneck is disk or network), or latency-sensitive (tail latency SLO-constrained). Workload generators (fio, iperf, wrk, sysbench) reproduce specific workload profiles for benchmarking.

  • Related terms: Profiling, USE method, benchmarking, IOPS, throughput, latency
  • See also: USE method, profiling, latency

Write Amplification

The ratio of data written to physical storage to the data logically written by the application. Flash SSDs suffer write amplification because flash can only be written in pages (4–16 KB) but erased in blocks (256 KB+); modifying even 1 byte requires reading the block, modifying the page, and writing the entire block. A write amplification factor of 10 means 10 bytes are physically written for every 1 byte of application data. High write amplification accelerates SSD wear, reduces effective bandwidth, and increases latency. Mitigation: sequential writes, large I/O sizes, ZNS (Zoned Namespaces), proper filesystem alignment.

  • Related terms: NVMe, IOPS, SSD, flash, FTL, ZNS, log-structured
  • See also: NVMe, IOPS

X

XSS (Cross-Site Scripting)

A web security vulnerability where an attacker injects malicious scripts (typically JavaScript) into web pages viewed by other users. Stored XSS persists in the server's database; reflected XSS is included in the server's response to a crafted request; DOM-based XSS manipulates the client-side DOM without server involvement. Exploited to steal cookies/session tokens, perform unauthorized actions, or redirect users. Mitigations: output encoding/escaping, Content Security Policy (CSP), HttpOnly cookies, and DOM API safe usage (textContent vs. innerHTML).

  • Related terms: CSP, SSRF, CSRF, injection, web security, XXE
  • See also: Supply chain attack, vulnerability

Z

Zero-Day

A vulnerability that is unknown to the software vendor and for which no patch exists. "Zero-day" refers to the vendor having zero days to prepare a fix before the vulnerability is exploited. Zero-days are highly valuable in offensive security (nation-state actors, commercial exploit brokers pay millions). Once a zero-day is discovered, it may be: used silently (APT operations), disclosed to the vendor (responsible disclosure), sold to governments or brokers, or published publicly. The window from discovery to patch deployment is the maximum exposure period. After patching, it becomes an N-day.

  • Related terms: CVE, exploit, vulnerability, supply chain attack, APT, patch
  • See also: CVE, exploit, vulnerability

End of Security and Performance Engineering Terminology Glossary. Total entries: 60+ terms.