Hubbry Logo
Memory protectionMemory protectionMain
Open search
Memory protection
Community hub
Memory protection
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Memory protection
Memory protection
Memory protection
View on Wikipedia
from Wikipedia

Memory protection is a way to control memory access rights on a computer, and is a part of most modern instruction set architectures and operating systems. The main purpose of memory protection is to prevent a process from accessing memory that has not been allocated to it. This prevents a bug or malware within a process from affecting other processes, or the operating system itself. Protection may encompass all accesses to a specified area of memory, write accesses, or attempts to execute the contents of the area. An attempt to access unauthorized[a] memory results in a hardware fault, e.g., a segmentation fault, storage violation exception, generally causing abnormal termination of the offending process. Memory protection for computer security includes additional techniques such as address space layout randomization and executable-space protection.

Methods

[edit]

Segmentation

[edit]
Main article: Memory segmentation

Segmentation refers to dividing a computer's memory into segments. A reference to a memory location includes a value that identifies a segment and an offset within that segment. A segment descriptor may limit access rights, e.g., read only, only from certain rings.

The x86 architecture has multiple segmentation features, which are helpful for using protected memory on this architecture.[1] On the x86 architecture, the Global Descriptor Table and Local Descriptor Tables can be used to reference segments in the computer's memory. Pointers to memory segments on x86 processors can also be stored in the processor's segment registers. Initially x86 processors had 4 segment registers, CS (code segment), SS (stack segment), DS (data segment) and ES (extra segment); later another two segment registers were added – FS and GS.[1]

Paged virtual memory

[edit]
Main article: Paged virtual memory

In paging the memory address space or segment is divided into equal-sized blocks[b] called pages. Using virtual memory hardware, each page can reside in any location at a suitable boundary of the computer's physical memory, or be flagged as being protected. Virtual memory makes it possible to have a linear virtual memory address space and to use it to access blocks fragmented over physical memory address space.

Most computer architectures which support paging also use pages as the basis for memory protection.

A page table maps virtual memory to physical memory. There may be a single page table, a page table for each process, a page table for each segment, or a hierarchy of page tables, depending on the architecture and the OS. The page tables are usually invisible to the process. Page tables make it easier to allocate additional memory, as each new page can be allocated from anywhere in physical memory. On some systems a page table entry can also designate a page as read-only.

Some operating systems set up a different address space for each process, which provides hard memory protection boundaries.[2] It is impossible for an unprivileged[c] application to access a page that has not been explicitly allocated to it, because every memory address either points to a page allocated to that application, or generates an interrupt called a page fault. Unallocated pages, and pages allocated to any other application, do not have any addresses from the application point of view.

A page fault may not necessarily indicate an error. Page faults are not only used for memory protection. The operating system may manage the page table in such a way that a reference to a page that has been previously paged out to secondary storage[d] causes a page fault. The operating system intercepts the page fault, loads the required memory page, and the application continues as if no fault had occurred. This scheme, a type of virtual memory, allows in-memory data not currently in use to be moved to secondary storage and back in a way which is transparent to applications, to increase overall memory capacity.

On some systems, a request for virtual storage may allocate a block of virtual addresses for which no page frames have been assigned, and the system will only assign and initialize page frames when page faults occur. On some systems a guard page may be used, either for error detection or to automatically grow data structures.

On some systems, the page fault mechanism is also used for executable space protection such as W^X.

Protection keys

[edit]

A memory protection key (MPK)[3] mechanism divides physical memory into blocks of a particular size (e.g., 4 KiB), each of which has an associated numerical value called a protection key. Each process also has a protection key value associated with it. On a memory access the hardware checks that the current process's protection key matches the value associated with the memory block being accessed; if not, an exception occurs. This mechanism was introduced in the System/360 architecture. It is available on today's System z mainframes and heavily used by System z operating systems and their subsystems.

The System/360 protection keys described above are associated with physical addresses. This is different from the protection key mechanism used by architectures such as the Hewlett-Packard/Intel IA-64 and Hewlett-Packard PA-RISC, which are associated with virtual addresses, and which allow multiple keys per process.

In the Itanium and PA-RISC architectures, translations (TLB entries) have keys (Itanium) or access ids (PA-RISC) associated with them. A running process has several protection key registers (16 for Itanium,[4] 4 for PA-RISC[5]). A translation selected by the virtual address has its key compared to each of the protection key registers. If any of them match (plus other possible checks), the access is permitted. If none match, a fault or exception is generated. The software fault handler can, if desired, check the missing key against a larger list of keys maintained by software; thus, the protection key registers inside the processor may be treated as a software-managed cache of a larger list of keys associated with a process.

PA-RISC has 15–18 bits of key; Itanium mandates at least 18. Keys are usually associated with protection domains, such as libraries, modules, etc.

In the x86, the protection keys[6] architecture allows tagging virtual addresses for user pages with any of 16 protection keys. All the pages tagged with the same protection key constitute a protection domain. A new register contains the permissions associated with each of the protection domain. Load and store operations are checked against both the page table permissions and the protection key permissions associated with the protection domain of the virtual address, and only allowed if both permissions allow the access. The protection key permissions can be set from user space, allowing applications to directly restrict access to the application data without OS intervention. Since the protection keys are associated with a virtual address, the protection domains are per address space, so processes running in different address spaces can each use all 16 domains.

Protection rings

[edit]

In Multics and systems derived from it, each segment has a protection ring for reading, writing and execution; an attempt by a process with a higher ring number than the ring number for the segment causes a fault. There is a mechanism for safely calling procedures that run in a lower ring and returning to the higher ring. There are mechanisms for a routine running with a low ring number to access a parameter with the larger of its own ring and the caller's ring.

Simulated segmentation

[edit]

Simulation is the use of a monitoring program to interpret the machine code instructions of some computer architectures. Such an instruction set simulator can provide memory protection by using a segmentation-like scheme and validating the target address and length of each instruction in real time before actually executing them. The simulator must calculate the target address and length and compare this against a list of valid address ranges that it holds concerning the thread's environment, such as any dynamic memory blocks acquired since the thread's inception, plus any valid shared static memory slots. The meaning of "valid" may change throughout the thread's life depending upon context. It may sometimes be allowed to alter a static block of storage, and sometimes not, depending upon the current mode of execution, which may or may not depend on a storage key or supervisor state.[citation needed]

It is generally not advisable to use this method of memory protection where adequate facilities exist on a CPU, as this takes valuable processing power from the computer. However, it is generally used for debugging and testing purposes to provide an extra fine level of granularity to otherwise generic storage violations and can indicate precisely which instruction is attempting to overwrite the particular section of storage which may have the same storage key as unprotected storage.

Capability-based addressing

[edit]
Main article: Capability-based addressing

Capability-based addressing is a method of memory protection that is unused in modern commercial computers. In this method, pointers are replaced by protected objects (called capabilities) that can only be created using privileged instructions which may only be executed by the kernel, or some other process authorized to do so.[citation needed] This effectively lets the kernel control which processes may access which objects in memory, with no need to use separate address spaces or context switches. Only a few commercial products used capability based security: Plessey System 250, IBM System/38, Intel iAPX 432 architecture and KeyKOS. Capability approaches are widely used in research systems such as EROS and Combex DARPA browser. They are used conceptually as the basis for some virtual machines, most notably Smalltalk and Java. Currently, the DARPA-funded CHERI project at University of Cambridge is working to create a modern capability machine that also supports legacy software.

Dynamic tainting

[edit]

Dynamic tainting is a technique for protecting programs from illegal memory accesses. When memory is allocated, at runtime, this technique taints both the memory and the corresponding pointer using the same taint mark. Taint marks are then suitably propagated while the program executes and are checked every time a memory address m is accessed through a pointer p; if the taint marks associated with m and p differ, the execution is stopped and the illegal access is reported.[7][8]

SPARC M7 processors (and higher) implement dynamic tainting in hardware. Oracle markets this feature as Silicon Secured Memory (SSM) (previously branded as Application Data Integrity (ADI)).[9]

The lowRISC CPU design includes dynamic tainting under the name Tagged Memory.[10]

Measures

[edit]

The protection level of a particular implementation may be measured by how closely it adheres to the principle of minimum privilege.[11]

Memory protection in different operating systems

[edit]

Different operating systems use different forms of memory protection or separation. Although memory protection was common on most mainframes and many minicomputer systems from the 1960s, true memory separation was not used in home computer operating systems until OS/2 (and in RISC OS) was released in 1987. On prior systems, such lack of protection was even used as a form of interprocess communication, by sending a pointer between processes. It is possible for processes to access System Memory in the Windows 9x family of operating systems.[12]

Some operating systems that do implement memory protection include:

On Unix-like systems, the mprotect system call is used to control memory protection.[14]

See also

[edit]

References

[edit]

Notes

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Memory protection

View on Grokipedia
from Grokipedia
Memory protection is a core mechanism in that enforces isolation between different processes by restricting access to memory regions, preventing unauthorized reads, writes, or executions that could compromise system stability or . This feature ensures that each process operates within its own , shielding the operating system kernel, other applications, and critical data from interference by faulty or malicious code. The primary importance of memory protection lies in its role in maintaining system integrity and multitasking reliability, as it mitigates risks such as buffer overflows, rogue processes corrupting shared resources, or one application crashing the entire system. By implementing strict access controls, it enables safe concurrent execution of multiple programs, a foundational requirement for contemporary computing environments ranging from desktops to embedded devices. Without effective memory protection, early systems like MS-DOS suffered frequent crashes from unchecked memory accesses, highlighting its evolution as a critical advancement since the 1970s with the introduction of hardware support. Memory protection is typically implemented through hardware components such as the Memory Management Unit (MMU) or Memory Protection Unit (MPU), which work in tandem with operating system software to translate virtual addresses to physical ones while enforcing permissions. Key techniques include virtual memory with page tables that define access rights (e.g., read-only, read-write, or execute-disabled) for memory pages, and segmentation for finer-grained control over code, data, and stack regions. In privileged modes, the kernel enjoys full access, while user-mode processes face restrictions, with violations triggering faults like segmentation faults to halt errant operations. Advanced variants, such as protection keys, allow dynamic adjustments to these permissions without altering page tables, further enhancing flexibility in systems like Linux on supported architectures.

Fundamentals

Definition and Purpose

Memory protection is a core mechanism in computing systems designed to isolate processes or users, preventing them from accessing memory regions not allocated to them. This isolation is enforced by hardware components, such as the (MMU), which maps virtual addresses to physical ones and validates access attempts, in conjunction with software policies implemented by the operating system. Each process operates within a dedicated address space, comprising the virtual addresses it is permitted to reference, ensuring that attempts to access unauthorized locations trigger exceptions handled by the OS. The primary purpose of memory protection is to safeguard system stability and in multi-tasking environments by blocking erroneous or malicious memory accesses, such as buffer overflows that could corrupt adjacent data or attempts that seek to execute unauthorized instructions. It prevents a misbehaving from damaging the operating system kernel or interfering with other ' data, thereby maintaining overall resource integrity and enabling reliable concurrent execution. Systems typically enforce this through privileged (e.g., kernel) and unprivileged (e.g., user) modes, where sensitive operations require elevated privileges to access protected regions. Key benefits include fault isolation, which confines errors or crashes within a single without propagating to others; data confidentiality, achieved by restricting unauthorized reads; and , upheld by controlling writes to prevent corruption in scenarios. Memory regions are further protected by granular permissions, such as read-only, read-write, or execute-only, which the MMU checks against each access to enforce these guarantees. acts as a foundational enabler, abstracting physical hardware to provide these isolated spaces efficiently.

Historical Development

In the 1950s and early , early systems like the operated without memory protection mechanisms, allowing user programs unrestricted access to the entire physical memory and risking system crashes or from errant code. This lack of isolation stemmed from the era's focus on single-user, non-sharing environments dedicated to scientific computations, where multiprogramming was absent. By the mid-, the push for systems exposed these vulnerabilities, leading to the development of , a collaborative project between MIT, , and starting in 1964. Under the leadership of Fernando Corbató at MIT, introduced pioneering ring-based in 1969 on the GE-645 (later rebranded by after its 1970 acquisition of GE's computer division), using hierarchical protection rings to enforce access controls and segmenting memory to isolate user processes from the kernel and each other. The 1970s saw memory protection evolve with the rise of minicomputers and portable operating systems. At , and developed Unix starting in 1969 on the , initially without robust protection, but ported it to the PDP-11 in 1971, where hardware support enabled initial multi-programming. By 1973, a kernel rewrite in C introduced paging-based , allowing processes to operate in isolated address spaces while sharing physical memory efficiently, influenced by but simplified for practicality. This adaptation prioritized usability in research environments, marking Unix as a foundational system for modern protected multitasking. Widespread adoption accelerated in the with personal computing. Intel's 80386 , released in 1985, extended from the 80286 with 32-bit addressing, supporting up to 4 GB of per process and multilevel protection rings to safeguard the OS from user applications. Operating systems like , launched in 1993, leveraged this hardware for demand-paged , enforcing strict isolation between processes and the kernel to enable secure multi-user environments on desktops. Into the 2000s, enhancements addressed and exploit mitigation. Intel introduced VT-x in 2005, adding hardware extensions to for efficient isolation, allowing guest OSes to run with nested paging and reduced overhead in hypervisors. Concurrently, (ASLR), first implemented in version 3.4 in 2003 and evaluated for its effectiveness in a 2004 study, randomized the layout of code, stack, and libraries in to thwart attacks, gaining adoption in systems like and later mainstream OSes.

Core Principles

Memory Isolation

Memory isolation is a core principle of memory protection in operating systems, providing logical separation of address spaces for individual processes to prevent unauthorized access or modification of memory belonging to other processes. This separation creates the illusion of a dedicated memory environment for each process, ensuring that computational activities remain confined and independent. By isolating address spaces, the system mitigates risks from faulty or malicious code, maintaining system stability and security. High-level techniques for implementing memory isolation include base and limit registers, which define the starting point and extent of a process's allowable range, and page tables, which map virtual addresses to physical locations while establishing boundaries. These mechanisms operate abstractly to enforce spatial separation without direct overlap between processes' memory regions. In multiprogramming systems, where multiple processes execute concurrently to maximize resource utilization, memory isolation is essential to prevent data leakage, , or interference that could compromise the of individual processes or the entire . Without such isolation, a single process failure could cascade, halting operations or exposing sensitive information across the shared environment. Memory isolation manifests in two primary types: physical isolation, enforced directly by hardware components such as memory management units that validate access at the circuit level, and logical isolation, managed by software through the configuration of protection data structures like segment descriptors or translation tables. Protection rings complement these by providing hierarchical privilege levels, restricting privileged operations to the most privileged ring (ring 0) for the kernel, with user processes in outer rings like ring 3.

Access Control Models

Access control models in memory protection define the rules and mechanisms for granting or denying operations such as reading, writing, or executing on memory regions, ensuring that processes only access authorized portions of memory. These models provide an abstract framework for specifying permissions, which are then enforced by the operating system kernel in conjunction with hardware. The foundational concept is the , introduced by in 1971, which represents subjects (e.g., processes) as rows and objects (e.g., memory segments or pages) as columns, with entries specifying access rights like read (R), write (W), or execute (X). This matrix separates policy (what rights are allowed) from mechanism (how rights are checked), allowing flexible implementation in operating systems. Discretionary Access Control (DAC) is a common model where the owner of a memory object—typically the that allocated it—has the discretion to set and modify permissions for other subjects. In DAC, permissions are managed through lists (ACLs) or similar structures attached to memory descriptors, allowing the owner to grant R, W, or X rights based on user or group identities. For instance, in systems, a can use system calls like mprotect to adjust page permissions, subject to the owner's privileges. This model promotes user flexibility but relies on the owner's judgment, potentially leading to security risks if misconfigured. In contrast, (MAC) enforces system-wide policies defined by administrators, overriding individual discretion; access decisions are based on security labels assigned to subjects and objects, such as sensitivity levels, ensuring consistent enforcement regardless of owner intent. MAC models, like those inspired by the Bell-LaPadula framework for confidentiality, apply labels to memory regions to prevent unauthorized flows, such as a low-clearance reading high-sensitivity data. Permissions in these models are typically represented by bits in structures, such as page table entries (PTEs) in systems. The R/W/X flags indicate allowable operations: R for reading data, W for writing, and X for executing instructions, with the absence of X enabling no-execute protection to mitigate exploits by preventing code execution in data areas. These bits are set by the kernel during memory allocation or modification, reflecting the underlying DAC or MAC policy. Enforcement occurs through hardware-software cooperation: when a process attempts an unauthorized access, the memory management unit (MMU) detects the violation and generates a trap or interrupt, such as a page fault, which the operating system handler processes. This may result in denying the access, logging the event, or terminating the process via signals like segmentation fault (SIGSEGV) in POSIX systems. An illustrative example is the no-execute (NX) bit, first implemented in hardware by AMD in 2003 for the Opteron processor and by Intel in 2004 for Pentium 4 models supporting execute disable (XD), allowing operating systems to mark data pages as non-executable at the page level, akin to file permissions but applied dynamically to virtual memory regions.

Hardware-Based Mechanisms

Segmentation

Segmentation is a hardware-based memory protection mechanism that divides a program's into variable-sized units known as segments, each corresponding to logical components such as , , or stack. Each segment is defined by a base in physical and a or limit, stored in segment registers or descriptor tables that the hardware consults during access. When a program attempts to access , the processor translates the —comprising a segment selector and an offset—by adding the offset to the segment's base and verifying that the offset does not exceed the segment's limit; violations trigger a hardware fault, such as a general protection exception, preventing unauthorized access. This approach ensures isolation by enforcing boundaries around each segment, allowing different protection attributes like read-only for or read-write for to be applied independently. In implementations like the Intel x86 architecture, segmentation relies on segment descriptors housed in tables such as the (GDT) or Local Descriptor Table (LDT), which specify the base address, limit, access rights, and privilege levels for each segment. The processor uses six segment registers (CS for code, DS/ES/FS/GS for data, SS for stack) to hold selectors that index into these tables, enabling efficient context switching between segments during program execution. Access violations, including out-of-bounds offsets or disallowed operations (e.g., writing to a code segment), result in immediate hardware interrupts that the operating system can handle to enforce protection policies. This mechanism was particularly prominent in systems from the 1960s to the 1980s, originating in designs like the operating system and evolving through processors such as the and 80386. The primary advantages of segmentation lie in its alignment with the natural structure of programs, where segments map directly to modules like procedures or global variables, facilitating intuitive organization and relocation without fixed boundaries. It also enables fine-grained protection by assigning distinct access controls to each segment type—for instance, executable-only permissions for segments to prevent modification—enhancing against buffer overflows or erroneous writes. However, segmentation suffers from external fragmentation, as allocating variable-sized segments in physical leaves unusable gaps between them over time, potentially reducing effective utilization. Additionally, the management of segment descriptors and tables introduces overhead, including table lookups and updates during context switches, which contributed to its decline in favor of paging—a complementary fixed-size allocation method—for modern systems.

Paging and Virtual Memory

Paging divides both virtual and physical memory into fixed-size blocks called pages, typically 4 kilobytes in modern systems, enabling efficient allocation and management without the fragmentation issues of variable-sized units. Virtual addresses generated by a are divided into a page number and an offset within that page, with the page number used to index into a that maps it to a corresponding physical frame in main . This mapping allows non-contiguous allocation of physical to a , simplifying by the operating system while providing a contiguous view to the . Protection in paging is enforced through attributes stored in page table entries (PTEs), which include bits for permissions such as read, write, and execute, as well as a valid bit indicating whether the page is present in physical memory. If a attempts to access a page with invalid permissions or an absent page, the hardware triggers a , allowing the operating system to intervene—either by denying access for protection violations or loading the page from secondary storage. This mechanism isolates by ensuring that each has its own , preventing unauthorized access to other ' memory or kernel space. Virtual memory integrates paging to abstract the physical memory layout from processes, providing each with a large, uniform that appears dedicated and contiguous, regardless of actual physical constraints. paging extends this by loading pages into physical only when first accessed, reducing initial memory demands and enabling support for programs larger than physical RAM through swapping to disk. This abstraction not only enhances protection by isolating but also facilitates efficient resource sharing and multitasking. Hardware support for paging and is provided by the (MMU), a dedicated processor component that performs address translation and permission checks on every access, trapping invalid operations as exceptions. To accelerate translations, the (TLB), a small cache within the MMU, stores recent virtual-to-physical mappings, avoiding full lookups for most accesses and thus minimizing performance overhead. Unlike segmentation, which relies on variable-sized divisions, paging's uniform pages enable straightforward of these hardware mechanisms for robust .

Protection Rings

Protection rings represent a hierarchical model of privilege levels in computer architectures, designed to enforce memory protection by restricting access to sensitive resources based on the executing code's privilege. Originating from the Multics operating system, this approach structures privileges as concentric rings, where inner rings possess greater access rights than outer ones, ensuring that less trusted code cannot interfere with critical system components. In this model, ring numbers increase outward, with the innermost ring (typically ring 0) granting full privileges and outer rings imposing progressive restrictions on operations such as direct hardware access or memory manipulation. The core mechanism relies on CPU-enforced mode switches between rings, where the processor maintains a current privilege level (CPL) to validate every memory access and instruction execution. Transitions between rings are controlled through dedicated entry points, such as gates or procedure calls, which allow upward (to higher privilege) or downward (to lower privilege) shifts only under strict conditions—for instance, system calls from user space invoke a gate to enter the kernel ring without compromising isolation. In the Intel x86 architecture, which supports four rings (0 through 3), ring 0 is reserved for the operating system kernel with unrestricted access, while ring 3 confines user applications to a limited subset of instructions and memory regions, preventing direct manipulation of kernel data structures. Implementation in x86 involves segment descriptors in the (GDT) that specify privilege requirements, with the CPL—encoded in the register—compared against descriptor privilege levels (DPL) for each access. Unauthorized attempts, such as a ring 3 trying to execute a privileged instruction or access kernel memory, trigger hardware exceptions like the general fault (#GP) or (#PF), which transfer control to the kernel for handling. Most modern operating systems, including and Windows, utilize only rings 0 and 3, leaving intermediate rings unused to simplify design while maintaining the hierarchy. By isolating the kernel's virtual address space from user code, protection rings prevent privilege escalation attacks and contain faults, enhancing overall system security and reliability without relying solely on software checks. This hardware-enforced separation ensures that even if user-level code is compromised, it cannot arbitrarily elevate privileges to access protected memory, thereby safeguarding critical system integrity.

Protection Keys

Protection keys provide a hardware-based approach to coarse-grained memory protection by assigning a numeric tag to fixed-size blocks of physical memory, enabling simple without the complexity of full virtual addressing. In this mechanism, each memory block is associated with a protection key, typically a 4-bit value ranging from 0 to 15, stored separately from the addressable data. The processor holds a current protection key in a dedicated register, such as bits 8-11 of the (PSW) in architectures. On every memory access—particularly stores—the hardware compares the current key against the block's key; access is granted if they match or if either is zero (indicating unrestricted access), otherwise triggering a protection exception that halts the operation while preserving the data. This technique originated in the mainframe architecture announced in 1964, where it was introduced as an optional feature to safeguard multitasking environments by isolating up to 15 user programs from each other and the operating system. Early implementations tagged 2,048-byte blocks, a size retained in the System/370 (1970), while later standardized on 4 KB pages for key assignment, allowing protected regions to span from 4 KB up to 1 MB or larger contiguous multiples. Keys are managed via privileged instructions like Set Storage Key (SSK) and Insert Storage Key (ISK), ensuring only the operating system can alter them to prevent user-level tampering. Protection keys offer significant advantages in simplicity and efficiency, imposing no measurable performance overhead since the key comparison is a fast, inline hardware check integrated into memory operations. This makes them ideal for protecting large, coarse regions in resource-constrained or high-throughput systems, where the minimal hardware—essentially per-block registers and comparator logic—reduces complexity compared to more elaborate schemes. Protection keys continue to be utilized in modern systems, such as the z16 introduced in 2022, for efficient protection in high-performance mainframe environments as of 2025. Despite these benefits, protection keys suffer from limited , as their fixed block sizes and small key space (only 16 domains) hinder precise isolation of small or variably sized regions, often requiring wasteful padding or multiple keys for fine control. Consequently, they have become less prevalent in modern general-purpose architectures like x86 and , which prioritize paging for its superior flexibility in combining mapping with per-page permissions. Unlike segmentation, which supports variable-length logical units for more adaptable protection, keys enforce rigid, block-uniform tagging better suited to mainframe workloads.

Software-Based Mechanisms

Capability-Based Addressing

Capability-based addressing is a memory protection mechanism in which access rights to resources are encapsulated in unforgeable known as capabilities. Each capability consists of an object's address and a set of associated access rights, such as read, write, or execute permissions, enabling secure referencing without relying on implicit user identities or global address spaces. These capabilities are treated as first-class objects that can be passed between processes or principals, allowing controlled of access while maintaining isolation. In capability-based systems, capabilities are stored in protected lists associated with each , and hardware or software checks ensure that only valid capabilities can be used for access or resource invocation. This approach provides a uniform way to address both memory segments and resources, decoupling protection from the addressing scheme itself. For , a can transfer or copy a capability to another, but the recipient's are limited to those in the received token, preventing escalation beyond the original grant. Early hardware implementations of capability-based addressing appeared in the , with the System 250 being the first operational computer to employ this scheme for real-time, high-reliability applications. In the System 250, capabilities were stored in dedicated capability-list segments, and hardware enforced access by validating the token's tag and rights during addressing operations. Later software-based realizations, such as the EROS operating system developed in the , implemented capabilities purely in user on commodity hardware, using a single-level store where all persistent objects are addressed via capabilities for both protection and naming. The primary advantages of capability-based addressing include fine-grained control over access rights, as permissions are explicitly bound to each token rather than inherited from process privileges. This enables revocable access, where capabilities can be selectively invalidated to withdraw permissions without affecting unrelated accesses, and inherently prevents unauthorized escalation by requiring explicit handover of . Such systems also simplify , as capabilities provide context-independent references that avoid the pitfalls of pointer or relocation issues in traditional segmented addressing. Despite these benefits, capability-based addressing faces challenges in , as capabilities can proliferate through and , making it difficult to locate and invalidate all instances without centralized tracking or garbage collection mechanisms. Storage overhead is another issue, since each process must maintain capability lists that can grow large with extensive , potentially increasing usage and access times. These complexities have limited widespread , though they inspire modern designs for secure .

Simulated Segmentation

Simulated segmentation is a software technique employed by operating systems to emulate the variable-sized logical segments typical of hardware segmentation, but implemented atop fixed-size paging mechanisms. In this approach, the OS groups contiguous pages into larger, variable-length segments to represent logical divisions such as , , or stack regions, using a segment table to map segment identifiers to the starting page and length within the page tables. This layering allows for isolation and by enforcing boundaries and access rights at the segment level through page-level hardware support. An early implementation appeared in the development of a segmented memory manager for Unix on the PDP-11/50 minicomputer, where software routines managed variable segments by configuring the hardware's base-and-limit registers to overlay logical units onto physical memory regions, providing without native variable paging. In like Windows, simulated segmentation facilitates DLL isolation by mapping dynamic link libraries to distinct virtual address ranges within a process's paged , applying granular page protections (e.g., read-only for code sections) to prevent unauthorized access across modules while sharing common libraries efficiently across processes. The primary benefits include enhanced flexibility, as systems can adopt segmentation's logical organization without requiring specialized hardware modifications, and simplified migration for software originally designed for segmented architectures to paging-based platforms. This method also supports fine-grained protection inheritance from pages to segments, enabling features like shared segments with controlled access. However, simulated segmentation introduces performance overhead from the extra in address —requiring lookups in both segment and page tables—which can increase memory access latency compared to pure paging. Additionally, managing the alignment of variable segments over fixed pages may lead to minor internal fragmentation within boundary pages.

Dynamic Tainting

Dynamic tainting is a runtime mechanism that marks potentially untrusted , such as inputs from external sources, as "tainted" and tracks its through a program's execution to prevent unauthorized accesses or hijacks. Upon allocation, regions and associated pointers are assigned unique taint marks, which are propagated during operations like or arithmetic; any attempt to use tainted for sensitive actions, such as dereferencing a pointer to access unallocated , triggers a check that halts execution if marks mismatch. This approach detects illegal accesses (IMAs) by ensuring that only properly authenticated interacts with protected regions, thereby enforcing fine-grained isolation without relying on static compile-time analysis. Early software implementations of dynamic tainting focused on binary-level to monitor in C programs vulnerable to exploits. For instance, TaintCheck, introduced in , uses dynamic to tag external inputs and propagate taints through registers and memory, detecting buffer overruns and format string vulnerabilities by flagging tainted control data usage. Building on this, a 2007 system employed reusable taint marks (as few as two) applied at allocation time, with propagation rules defined for common instructions, implemented via tools like DYTAN for software and simulated hardware on MIPS for efficiency; it successfully identified all tested IMAs in applications like bc and . These software approaches often utilize shadow memory—a parallel structure mirroring the program's —to store taint tags compactly, avoiding direct modification of original data and enabling low-overhead tracking. Hardware-assisted dynamic tainting emerged in the to reduce overheads inherent in software methods, integrating tag propagation directly into processor pipelines. A 2018 RISC-V extension, D-RI5CY, augments the core with 1-bit tags per word, programmable policy registers for propagation and checking rules, and custom instructions for tag management; tags flow in parallel with , adding negligible latency while detecting memory corruption attacks on IoT devices. This implementation, prototyped on FPGA, incurs zero runtime overhead and minimal area increase (<1% LUTs), demonstrating scalability for embedded systems. More recent advances as of include software-focused optimizations for dynamic taint . For example, a 2023 method applies dynamic tainting to container environments for detecting issues in labels and data flows. In , HardTaint uses selective hardware tracing to monitor taint propagation in and registers with improved efficiency, while AirTaint enhances the speed and usability of dynamic taint for broader application in software . These developments continue to refine tainting for low-overhead in modern systems like IoT and cloud containers. In applications, dynamic tainting safeguards against exploits that manipulate , such as buffer overflows enabling or use-after-free errors leading to data leaks; for example, it blocks tainted inputs from altering in ways that could facilitate by preventing overflow-induced query modifications. Advances include combining tainting with (ASLR) to detect and mitigate information leaks that reveal randomized addresses, enhancing overall exploit resistance. Performance optimizations, like packed shadow arrays, limit overhead to ~1% in hardware prototypes, making the technique viable for production use.

Implementation in Operating Systems

Unix-Like Systems

In systems, including and BSD variants, memory protection is fundamentally implemented through the (VM) subsystem, which uses hierarchical page tables to translate virtual addresses to physical memory while enforcing access controls such as read, write, and execute permissions on individual pages. This approach isolates from one another and separates user-space from kernel-space, preventing unauthorized access to sensitive system resources. The VM subsystem relies on underlying hardware paging support to manage these mappings dynamically, ensuring that each process perceives a contiguous, private . A core distinction in privilege levels underpins this protection: the kernel executes in ring 0 with unrestricted access to hardware and , while user-space applications run in ring 3, confined to their allocated virtual spaces and unable to directly manipulate kernel data structures or other ' . Attempts to violate these boundaries, such as dereferencing an invalid pointer or accessing protected , trigger a hardware exception that the kernel intercepts and translates into a SIGSEGV (segmentation violation) signal delivered to the offending , often leading to its termination unless a handler is installed. POSIX standards, which guide in environments, provide system calls for explicit control over these protections. The mprotect() syscall allows a to modify access permissions on a range of mapped memory pages, specifying protections like read-only or no-execute to prevent unintended modifications or executions. Complementing this, the syscall enables mapping files, devices, or anonymous memory into the with initial protections, facilitating efficient or file-backed allocations while adhering to the specified access rules. Process creation via fork() incorporates (COW) optimization to balance efficiency and isolation: upon forking, the inherits the parent's entries, but physical pages are initially shared and marked read-only, with a private copy allocated only if either process attempts a write, thereby enforcing separation without immediate duplication overhead. To counter exploits like buffer overflows that attempt , early 2000s innovations introduced non-executable (NX) memory protections. The PaX patch, first released in 2000, emulates NX semantics on hardware lacking native support by restricting executable mappings and randomizing address layouts, significantly reducing the attack surface in kernels. Similarly, Red Hat's Exec Shield, introduced in 2003 with Enterprise Linux 3, leverages the on supported processors (or emulates it via segmentation) to mark data pages as non-executable, preventing execution in writable regions. SELinux, developed by the and integrated into the mainline in 2003 as a Linux Security Module (LSM), extends these mechanisms with (MAC) policies that govern memory operations, including restrictions on mmap() and mprotect() to enforce type enforcement and role-based rules beyond standard discretionary access controls.

Windows

Memory protection in Windows is primarily managed by the NT kernel, which leverages hardware-enforced protection rings on x86 architectures to isolate user-mode applications in ring 3 from kernel-mode operations in ring 0, preventing direct access to system resources. This separation ensures that user processes cannot interfere with kernel memory or other processes without explicit authorization. The kernel employs management to allocate isolated address spaces for each process, using paging mechanisms to enforce boundaries and protect against unauthorized reads, writes, or executions. For legacy compatibility, Windows incorporates s (VDM), which provide an emulated environment for running 16-bit and Windows 3.x applications within a dedicated address space, isolating them from the host system to prevent legacy code from compromising modern protections. VDM achieves this by translating 16-bit calls into 32-bit equivalents through the Windows NT Virtual DOS Machine subsystem, maintaining separation via the 's . Address Space Layout Randomization (ASLR), first implemented as an opt-in feature in and made more robust in in 2009, randomizes the base addresses of key modules such as executables, DLLs, and the stack at load time to hinder exploitation of memory corruption vulnerabilities like buffer overflows. By relocating these elements to unpredictable locations, ASLR increases the difficulty of crafting reliable exploits that depend on fixed layouts. Similarly, Data Execution Prevention (DEP), introduced in Service Pack 2 in 2004, marks certain regions—such as stack and heap—as non-executable, causing hardware exceptions if code attempts to run from data pages, thereby mitigating attacks that inject and execute malicious payloads. Additional protections include guard pages, enabled via the PAGE_GUARD memory protection constant, which serve as one-time sentinels for detecting fine-grained memory access violations, such as stack overflows, by triggering exceptions on first access to allow dynamic expansion or error handling without full crashes. Control Flow Guard (CFG), introduced in in 2014, further bolsters defenses against return-oriented programming (ROP) attacks by validating indirect calls at runtime, ensuring they target only legitimate function entry points marked in a global control flow table, thus disrupting control-flow hijacking attempts. User and kernel separation is reinforced through token-based , where each and thread holds an encapsulating the user's (SID), privileges, and group memberships, which the kernel's Security Reference Monitor uses to authorize system calls and prevent unauthorized escalations from user mode. For mixed architectures, the subsystem enables 32-bit applications to run on 64-bit Windows by emulating an x86 environment in a thunking layer, isolating 32-bit address spaces and preventing direct interaction with 64-bit kernel memory to maintain compatibility without compromising security. A unique aspect of Windows memory protection is its integration with through Virtualization-Based Security (VBS), which employs the to create isolated enclaves for kernel components, enforcing memory integrity via Hypervisor-protected Code Integrity (HVCI) to block malicious modifications even from ring 0 code, providing nested protection layers for critical system processes. This approach extends to safeguard against advanced kernel exploits, with features like shielded virtual machines adding and attestation for hosted workloads. However, Memory Integrity (HVCI) in Windows 11 can introduce performance overhead due to the underlying virtualization-based security mechanisms, which increase latency and consume additional CPU resources. This has led to reports of stutters, freezes, and system-wide lag in games, such as Diablo IV, particularly during asset loading, porting, or character switching, even on high-end hardware. Disabling Memory Integrity has been shown to improve gaming performance by 4-7% in certain titles, though it reduces security protections.

Embedded and Real-Time Systems

Embedded and real-time systems face unique challenges in implementing memory protection due to severe constraints on RAM and CPU resources, often limited to kilobytes of memory and low-power processors. These environments prioritize deterministic behavior to meet strict timing deadlines, avoiding mechanisms like paging or swapping that introduce non-deterministic latency from disk I/O or cache misses. As a result, memory protection must operate with minimal overhead to prevent disrupting real-time guarantees, focusing on isolation without complex virtual memory translation. A primary mechanism in MMU-less embedded systems is the (MPU), which provides hardware-enforced access controls by dividing physical memory into configurable regions with permissions such as read-only, read-write, or execute-never. In processors, the MPU supports up to 16 regions, each defining size, location, and attributes like cacheability, triggering faults on violations to contain errors without full address translation. For real-time operating systems (RTOS), static partitioning complements MPU by pre-allocating fixed memory blocks to tasks or modules at , ensuring spatial isolation and preventing interference in multi-core setups. The seL4 microkernel exemplifies advanced memory protection in embedded contexts through of its capability-based model, which enforces isolation via object capabilities and page tables while proving absence of buffer overflows and unauthorized accesses. Released in 2009, seL4's proofs cover functional correctness down to C code, making it suitable for safety-critical embedded applications like where predictability is paramount. Similarly, integrates MPU support to run tasks in unprivileged mode, restricting stack and heap access per task to prevent corruption, with regions reconfigured on context switches for low-overhead fault isolation. In VxWorks, static partitioning under standards allocates dedicated memory to partitions, protecting against faults in mixed-criticality systems by enforcing boundaries at the kernel level. These approaches involve trade-offs, such as using simplified privilege rings—typically just and user modes in Cortex-M—to reduce context-switch overhead compared to multi-ring architectures, prioritizing fault containment over comprehensive . keys offer a alternative for region tagging in some embedded hardware, enabling quick permission changes without full MPU reconfiguration. Overall, the emphasis remains on efficient, verifiable isolation to maintain in resource-constrained environments.

Challenges and Advances

Common Vulnerabilities

Buffer overflows represent one of the most prevalent memory protection vulnerabilities, occurring when a program writes more to a fixed-size buffer than it can accommodate, leading to corruption of adjacent memory regions and potential hijacking. These flaws enable attackers to overwrite return addresses or function pointers, facilitating or execution of malicious payloads. Memory buffer vulnerabilities, including overflows, constitute approximately 20% of reported vulnerabilities in cryptographic libraries. A key exploitation method for buffer overflows is return-oriented programming (ROP), which circumvents hardware protections like the No eXecute (NX) bit by chaining existing code fragments, or "gadgets," from the program's address space to perform arbitrary operations without introducing executable code. This technique reuses instruction sequences ending in return statements, allowing attackers to bypass write-XOR-execute (W^X) policies that mark data pages as non-executable. Historically, such vulnerabilities have caused widespread breaches; the 1988 Morris Worm exploited a stack buffer overflow in the fingerd daemon on UNIX systems, infecting an estimated 10% of the internet-connected computers at the time and marking one of the first major incidents demonstrating memory protection failures. Race conditions in , particularly time-of-check-to-time-of-use (TOCTOU) flaws, emerge in multi-threaded applications where concurrent access to protected resources lacks adequate , permitting an attacker to alter the resource state between validation and utilization. This can lead to unauthorized modifications or privilege escalations. Side-channel attacks further undermine isolation; the 2018 Spectre vulnerabilities exploit CPU to transiently bypass protections, enabling cross-process data leaks through cache timing discrepancies. Detection of these vulnerabilities often relies on runtime tools such as Valgrind's Memcheck, which instruments code to monitor memory allocations, accesses, and deallocations, identifying overflows, use-after-free errors, and invalid reads/writes before exploitation. Operating system kernels typically enforce protection by inducing panics on detected violations, such as invalid page accesses, to halt execution and prevent further compromise. As a mitigation, dynamic tainting tracks untrusted data propagation to block tainted inputs from influencing in overflow scenarios.

Modern Enhancements

In the realm of hardware-based memory protection, Intel introduced Memory Protection Extensions (MPX) in 2013 to enable efficient bounds checking for memory accesses, allowing compilers to insert hardware-accelerated checks that prevent buffer overflows by verifying pointer bounds at runtime. MPX uses dedicated registers to store bounds information associated with pointers, significantly reducing the overhead of software-based checks while protecting against common memory corruption vulnerabilities. Similarly, ARM's Pointer Authentication, specified in the ARMv8.3-A architecture in 2016, enhances pointer integrity by appending cryptographic signatures (pointer authentication codes) to pointers, which are verified before use to thwart manipulation attacks like return-oriented programming. This mechanism leverages dedicated instructions for signing and authenticating pointers, providing low-overhead protection integrated into the processor pipeline. Confidential computing has advanced with AMD's Secure Encrypted Virtualization (SEV), launched in 2019 as an extension to AMD-V, which encrypts memory using per-VM keys managed by a secure processor to isolate guest data from the and prevent unauthorized access. SEV ensures that memory encryption occurs transparently during walks, offering protection against physical attacks and privileged software exploits without impacting performance in typical workloads. On the software side, (CFI) has evolved post-2010 with implementations that enforce precise control-flow graphs at runtime, limiting indirect branches to valid targets and mitigating code-reuse attacks. Modern CFI variants, such as those using shadow stacks and fine-grained policies, achieve sub-5% overhead on SPEC benchmarks. Browser sandboxing has also progressed, exemplified by Google's Chrome Site Isolation feature enabled in 2018, which renders each site in a separate to isolate cross-site scripting and Spectre-like attacks, reducing the for memory leaks between origins. Virtualization enhancements include Intel's Extended Page Tables (EPT), introduced in 2008 but widely adopted in post-2010 hypervisors, which accelerate second-level address translation by mapping guest-physical to host-physical addresses in hardware, cutting VM exit overheads by up to 50% compared to software-emulated paging. For containerized environments, Linux's seccomp-BPF, added in kernel 3.5 in 2012, allows fine-grained syscall filtering to confine processes, blocking unauthorized memory operations and enhancing isolation in systems like Docker. Emerging trends incorporate AI-assisted to identify security threats in IoT and settings, using models trained on runtime data to achieve detection rates of approximately 96-97% with minimal false positives. Additionally, quantum-resistant protections are gaining traction in the 2020s through integration of into memory encryption schemes, with NIST-standardized algorithms like CRYSTALS-Kyber ensuring long-term confidentiality against quantum threats in platforms. In 2025, ARM's Memory Tagging Extension (MTE) saw significant adoption, notably in Apple's ecosystem with the introduction of Memory Integrity Enforcement on devices like the 17. MTE assigns tags to allocations and pointers, with hardware verifying matches on access to detect safety violations such as buffer overflows and use-after-free errors at runtime, providing low-overhead protection against common memory corruption vulnerabilities.

References

  1. https://courses.cs.washington.edu/courses/cse451/TLKCopy/mm/memory.html
  2. http://homepage.cs.uiowa.edu/~jones/security/notes/06.shtml
  3. https://developer.arm.com/documentation/107565/latest/Memory-protection
  4. https://docs.kernel.org/core-api/protection-keys.html
  5. https://users.cs.duke.edu/~chase/cps196/slides/machinex6.pdf
  6. http://www.cs.uni.edu/~diesburg/courses/cs3430_sp14/sessions/s12/s12_memory_protection.pdf
  7. https://www.cs.uic.edu/~jbell/CourseNotes/OperatingSystems/8_MainMemory.html
  8. https://apps.dtic.mil/sti/tr/pdf/ADA108830.pdf
  9. http://web.mit.edu/saltzer/www/publications/f7y/f7y.html
  10. https://www.nokia.com/bell-labs/about/dennis-m-ritchie/hist.pdf
  11. https://pdos.csail.mit.edu/6.828/2018/readings/i386.pdf
  12. https://www.cl.cam.ac.uk/teaching/1516/OpSystems/pdf/12-Case-Study-WindowsNT.pdf
  13. https://www.cs.utexas.edu/~witchel/380L/papers/uhlig05ieeecomputer-intel_virtualization_technology.pdf
  14. https://dl.acm.org/doi/10.1145/1030083.1030124
  15. https://dl.acm.org/doi/10.1145/1178597.1178599
  16. https://www.scs.stanford.edu/nyu/03sp/notes/l5.pdf
  17. https://www.read.seas.harvard.edu/~kohler/class/05s-osp/notes/notes9.html
  18. http://bwl-website.s3-website.us-east-2.amazonaws.com/08-Protection/WebPage.html
  19. https://www.jsums.edu/nmeghanathan/files/2015/05/CSC439-Sp2013-5-Access-Control-Models.pdf
  20. https://www.nsa.gov/portals/75/documents/resources/everyone/digital-media-center/publications/research-papers/configuring-selinux-policy-report.pdf
  21. https://pages.cs.wisc.edu/~remzi/OSTEP/vm-segmentation.pdf
  22. https://ics.uci.edu/~aburtsev/cs5460/lectures/midterm-pdfs/intel-segmentation-and-paging.pdf
  23. https://www.scs.stanford.edu/05au-cs240c/lab/i386/s06_02.htm
  24. https://people.csail.mit.edu/rinard/teaching/osnotes/h15.html
  25. https://www.cs.cmu.edu/~410/doc/segments/segments.html
  26. http://www.cs.cmu.edu/~410-s07/doc/segments/old.segments.html
  27. https://multicians.org/protection.html
  28. https://cseweb.ucsd.edu/classes/sp17/cse120-a/applications/ln/lecture11and12.html
  29. https://pages.cs.wisc.edu/~remzi/OSTEP/vm-complete.pdf
  30. http://www.csapp.cs.cmu.edu/2e/ch9-preview.pdf
  31. https://www.cs.cornell.edu/~tomf/notes/cps104/virtual.html
  32. http://denninginstitute.com/pjd/PUBS/ENC/CRC-vm-2013.pdf
  33. https://pages.cs.wisc.edu/~solomon/cs537/html/paging.html
  34. https://courses.cs.washington.edu/courses/cse351/19sp/lectures/23/code/vm_overview.pdf
  35. https://www.princeton.edu/~rblee/ELE572Papers/Fall04Readings/ProtectionRings_Schroeder&Saltzer.pdf
  36. https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.pdf
  37. https://bitsavers.trailing-edge.com/pdf/ibm/360/princOps/A22-6821-0_360PrincOps.pdf
  38. https://bitsavers.trailing-edge.com/pdf/ibm/370/systemGuide/GC20-1734-2_370-145_Guide_Aug72.pdf
  39. https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf
  40. https://www.ibm.com/docs/en/zos-basic-skills?topic=integrity-what-is-storage-protection
  41. https://lwn.net/Articles/643797/
  42. https://dl.acm.org/doi/10.1145/361011.361070
  43. https://homes.cs.washington.edu/~levy/capabook/Chapter1.pdf
  44. https://homes.cs.washington.edu/~levy/capabook/Chapter4.pdf
  45. https://dl.acm.org/doi/10.1145/319344.319163
  46. https://www.usenix.org/system/files/usenixsecurity23-yu-jason.pdf
  47. https://www.cs.cornell.edu/courses/cs513/2005fa/L10.html
  48. https://iris-project.org/pdfs/2021-popl-ucaps-final.pdf
  49. https://www.cs.princeton.edu/courses/archive/spr02/cs217/lectures/paging.pdf
  50. https://apps.dtic.mil/sti/tr/pdf/ADA047170.pdf
  51. https://learn.microsoft.com/en-us/windows/win32/memory/memory-protection
  52. https://www.cc.gatech.edu/fac/milos/clause_ase07.pdf
  53. https://people.eecs.berkeley.edu/~dawnsong/papers/taintcheck.pdf
  54. http://www.cs.columbia.edu/~luca/research/palmiero_HPEC18.pdf
  55. https://doi.org/10.1016/j.cose.2023.103528
  56. https://doi.org/10.1145/3649815.3649860
  57. https://doi.org/10.1109/SP.2024.00001
  58. https://docs.kernel.org/mm/page_tables.html
  59. https://kernel.org/doc/ols/2003/ols2003-pages-315-320.pdf
  60. https://pax.grsecurity.net/docs/PaXTeam-LATINOWARE12-PaX-linux-security.pdf
  61. https://www.redhat.com/en/blog/security-technologies-execshield
  62. https://www.nsa.gov/portals/75/images/resources/everyone/digital-media-center/publications/research-papers/flexible-support-for-security-policies-into-linux-jun2001-report.pdf
  63. https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa
  64. https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/overview-of-threat-mitigations-in-windows-10
  65. https://www.microsoft.com/en-us/msrc/blog/2010/12/on-the-effectiveness-of-dep-and-aslr
  66. https://learn.microsoft.com/en-us/windows/win32/memory/data-execution-prevention
  67. https://learn.microsoft.com/en-us/windows/win32/memory/creating-guard-pages
  68. https://learn.microsoft.com/en-us/windows/win32/memory/memory-protection-constants
  69. https://learn.microsoft.com/en-us/windows/win32/secbp/control-flow-guard
  70. https://learn.microsoft.com/en-us/windows/win32/secauthz/access-tokens
  71. https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/windows-kernel-mode-security-reference-monitor
  72. https://learn.microsoft.com/en-us/windows/win32/winprog64/running-32-bit-applications
  73. https://learn.microsoft.com/en-us/windows/security/hardware-security/enable-virtualization-based-protection-of-code-integrity
  74. https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-vbs
  75. https://www.howtogeek.com/these-windows-settings-are-hurting-your-game-fps/
  76. https://us.forums.blizzard.com/en/d4/t/game-crashes-on-startup/17050?page=2
  77. https://developer.arm.com/documentation/107565/latest/Introduction/Memory-Protection-Unit--MPU-
  78. https://cs-people.bu.edu/rmancuso/files/papers/virt_IDA_rtas19.pdf
  79. https://www.freertos.org/Security/04-FreeRTOS-MPU-memory-protection-unit
  80. https://developer.arm.com/documentation/dui0662/latest/Cortex-M0--Peripherals/Memory-Protection-Unit
  81. https://developer.arm.com/documentation/ddi0439/b/Memory-Protection-Unit
  82. https://www.windriver.com/sites/default/files/2024-10/656381-mitigation-of-interference-in-MC-processors.pdf
  83. https://www.sigops.org/s/conferences/sosp/2009/papers/klein-sosp09.pdf
  84. https://read.seas.harvard.edu/~kohler/class/cs260r-17/klein10sel4.pdf
  85. https://www.windriver.com/sites/default/files/2023-06/514450%2520-%2520Safety-Critical%2520Software%2520Development%2520for%2520Integrated%2520Modular%2520Avionics_Whitepaper.pdf
  86. https://www.freertos.org/Community/Blogs/2021/benefits-of-using-the-memory-protection-unit
  87. https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-955.pdf
  88. https://arxiv.org/pdf/2412.19310
  89. https://hovav.net/ucsd/dist/rop.pdf
  90. https://www.cs.umd.edu/class/fall2023/cmsc614/papers/morris-worm.pdf
  91. https://cwe.mitre.org/data/definitions/367.html
  92. https://arxiv.org/abs/1801.01203
  93. https://valgrind.org/docs/manual/mc-manual.html
  94. https://dl.acm.org/doi/pdf/10.1145/3503222.3507780
  95. https://www.usenix.org/event/sec08/tech/full_papers/dalton/dalton.pdf
  96. https://www.intel.com/content/www/us/en/support/articles/000059823/processors.html
  97. https://www.kernel.org/doc/html/v5.4/x86/intel_mpx.html
  98. https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/armv8-a-architecture-2016-additions
  99. https://www.qualcomm.com/content/dam/qcomm-martech/dm-assets/documents/pointer-auth-v7.pdf
  100. https://www.amd.com/en/developer/sev.html
  101. https://www.qemu.org/docs/master/system/i386/amd-memory-encryption.html
  102. https://users.soe.ucsc.edu/~abadi/Papers/cfi-tissec-revised.pdf
  103. https://www.usenix.org/system/files/sec19fall_liljestrand_prepub.pdf
  104. https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html
  105. https://www.vmware.com/pdf/Perf_ESX_Intel-EPT-eval.pdf
  106. https://www.mdpi.com/2079-9292/14/12/2492
  107. https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards
  108. https://security.apple.com/blog/memory-integrity-enforcement/
Add your contribution
Related Hubs
User Avatar
No comments yet.