What role does paging play in respect to security?

By paging I mean memory management technique of splitting file memory into pages

I guess the question is does it make files more secure?

  • 3
    Could you clarify on what you mean by paging? Are you talking about paging in the memory management sense? Perhaps you could add some more detail.
    – chris
    Nov 29, 2011 at 18:34
  • 2
    How does memory paging make files secure? You need to spend some time googling and then think about your answer before posting. Maybe write some c/c++.
    – rook
    Nov 29, 2011 at 18:58

4 Answers 4


Paging is one of the activities of an operating system related to memory management. There may be some terminology issues, so let's get things right.

The MMU and the pages

The Memory Management Unit is a device in a computer which places itself between the physical RAM, and the CPU. These days, the MMU is part of the CPU. When the CPU executes code, it fetches instructions from memory, and the instructions themselves may order the CPU to read bytes from memory, or write some bytes to memory. All these memory accesses use an address: the "addressable memory" is a big array of bytes, numbered sequentially, and an address is a designation for a given slot somewhere in that array. We call the array the address space.

In older days, the address space was the physical RAM, directly: byte at address 762 was the seven hundred sixty third byte of the RAM chip (yes, "third", because addresses start at zero, not one).

The MMU emulates an address space: the MMU decides where each byte actually is physically located, or whether it is located somewhere at all. To do that, the MMU virtually splits the address space into pages. The size of a page depends on the architecture. On a PC in 32-bit mode, the addresses are 32-bit integers (that's what "32-bit mode" means), so there are 232 = 4294967296 possible byte addresses: at any moment, code may "see" up to that many individual bytes (that's 4 GB). The normal page size for a PC is 4096 bytes (4 kB), so the MMU considers the address space as the concatenation of 1048576 individual pages.

For each page, the MMU "knows" what to do, i.e. what should be done when the CPU wants to do an access to some byte within that page. The MMU can either grant the access, by redirecting to a physical RAM page, or reject it, which means that an exception is thrown. That's a CPU exception, not an "exception" in the Java / C++ sense; the exception is a trigger for some specific code within the operating system (in the kernel) which then tries to do smart things. More on that later. The decision taken by the MMU depends not only on the target address but also on the access type (is it an instruction fetch, a data read or a data write ?) and on the current processor "ring" (in short words, whether the code which does the access is application code or kernel code).

The MMU knows what to do by reading it in some dedicated areas of the (physical) RAM; namely, the MMU has access to a blueprint for the mapping of pages from the address space, to pages in the physical RAM. That blueprint is a set of tables which are managed by the operating system.

To sum up: the MMU is a tool by which the operating system can decide the mapping between physical RAM, and the address space as seen by the currently executed code.

Paging, Swapping, and Virtual Memory

Modern operating systems use the MMU to play some games with what application code sees:

  • Each process sees memory as if it was alone in it. Each process has its own address space, and, in practice, most processes will use the same addresses. The OS can maintain such an illusion by attaching to each process its own memory blueprint; whenever the OS decides to let the CPU run the code for a given process, it also instructs the MMU to use the blueprint for that process.

  • Within its address space, the process may access only the pages which it is permitted to do. Each process begins with a small set of accessible pages, all others being marked as "forbidden" in the blueprint for the MMU. To get more pages, the process must ask nicely the kernel to give a few more pages (i.e. mark a few more pages as accessible in the blueprint).

  • Some pages may be marked as inaccessible in the blueprint, while they should be actually "present" as per the programming semantics. The kernel will do that especially for instructions. Instructions normally come from an executable file; the ideal model is that when a program is executed, the file is loaded into RAM, and then the CPU is instructed to start executing the instructions. In practice, the file is not loaded yet. The CPU just marks as "not present" the corresponding pages (the pages where the file should be loaded). When the CPU actually tries to fetch an instruction from one of these pages, this triggers an exception; the kernel takes control, reads the page data from the executable file into a physical RAM page, modifies the MMU blueprint to mark the page as "present", and then instructs the CPU to try again. This means that the executable file is loaded on demand.

  • Similarly, if the OS finds itself a bit cramped in physical RAM (i.e. one process wants some additional pages to play, but there's no free physical page), it can decide to simply evict a page containing instructions. Why can it do that ? Because that page was loaded from a file, and could be loaded again from the file, with the same mechanism. The kernel tries to evict code pages which were least recently accessed, because on-demand loading is not the fastest operation ever. The activity of loading executable pages on demand, and evicting them to regain some free physical RAM, is called paging (yay, so much exposition to get to that point).

  • Sometimes, the OS may need more physical RAM than it can get by simply evicting code pages, so it can do swapping. We saw that paging is about forgetting some data because it is known that a copy of said data is already on the disk, from where it could be loaded again on demand. What about data pages which are not full of code freshly loaded from a file ? Well, that's simple: first write them somewhere on the disk, and then do the paging thing. This is called swapping, or virtual memory. The OS uses a dedicated area on the disk (it can be in special files, or a specific partition) to store the contents of physical data pages that the OS decides to reuse. Swapping is more expensive than paging (paging is like swapping with the "write" part already done), so the kernel will first page, then swap.

All these practices amount to the OS using the MMU to emulate, for the benefit of each process, a virtual view of memory as if it was a single contiguous address space and the process was alone on the system. The OS can even emulate more RAM than is physically present, using the disk as storage area for pages which are not accessed often. It can also handle shared memory between processes (the same physical page, mapped into the address spaces of two distinct processes -- not necessarily at the same address in both !).


The MMU is at the core of the security model enforced by the OS at the process level: each level may access only its own, duly allocated memory. A process shall not be able to alter the memory of another process, or of the kernel. This is all done through the MMU blueprints.

Of course, the "blueprints" are table in RAM so the OS must take care never to allow direct access for a process to the pages which contain its blueprint. Otherwise, that process could alter them to read or write any physical page that it sees fit, including the pages where the kernel resides, or other processes. This is serious matter ! Some game consoles have been attacked that way.

So it is not paging per se, but the MMU (which allows paging to take place) which is important security-wise. It still relies on appropriate action taken by the kernel upon a CPU exception. The MMU, as a chip (actually a part of the CPU), just triggers an exception whenever it does not directly grant a memory access; the rest (including paging and swapping) is up to the kernel code.

Barring bugs in the kernel code, the MMU allows for strict separation of processes; it prevents a single user application from crashing the machine or impacting other applications. The pre-NT Windows (Windows 95, 98, Millenium...) lacked complete MMU support; the MMU was active and applications could not directly read or modify data in other applications, but all could read or write kernel code and data, so any crashing application could blast the kernel into oblivion, bringing down the whole machine.

Although each application "sees" its own address space, there really is only a finite amount of physical RAM, and all applications compete for that RAM. So there can be security issues, if an application is allowed to consume too much RAM. It is an easily seen property of paging that too much of it brings the machine to its knees: a normal random memory access should be done in a matter of a few dozen nanoseconds, whereas a disk access will typically need ten milliseconds: that's one million times slower. Applications which allocate too much RAM (forcing the kernel into heavy paging), or which keep on scanning all their RAM (thus conflicting with policies about evicting to swap space the least-recently accessed pages -- this is the case with many programming languages which use a garbage collector), can have a powerful denial of service effect.

  • 1
    What a high quality answer to a low quality question! I had to upvote the Q because of this (and other) answers. Feb 25, 2013 at 0:28

To answer the question if something is "more secure", you need to specify what you're comparing it with.

Paging wasn't introduced as a security mechanism, but as a way to deal with chunks of memory. It was introduced long before security measures became pervasive in memory management (like ASLR and NX). It's so old, it's hard to imagine an operating system without it. So, I don't think your question can really be answered until you name a different system to compare paging with :-)

  • meh idk its a question on midterm review sheet :( Nov 29, 2011 at 21:20

After your first edit, the question is still ambiguous. Here are my interpretations for various questions:

Modern memory management

Memory is allocated to processes in pages. Each page is linked to the process it is given to and cannot be read or altered by another process in most cases. There are intentional ways to share memory, though. Hopefully the OS zeroes out all the memory allocated to a program before it completes allocation.

Memory mapped files

No special cases

Malloc operations

Programming issues may lead to internal insecurity, but they will not affect other processes.

Paging to disk

Sensitive data will be written to a long-term storage device and remain readable after it is freed. This is usually handled by encrypting the swap file with a key that is kept in memory and forgotten / recreated at each boot.


I don't really understand the question & I haven't read thru all the responses yet, but my thought on this is that paging has little to do with security (per se). The only biggie with regard to security implications is the possibility that confidential info of some sort (such as cryptographic info) could be paged to disk & read in an offline attack (i.e., booting to a live CD, bypassing the primary OS, and reading the file system directly). Modern software won't (or shouldn't) allow sensitive data (cryptographic info) to be paged to disk, but it's up to the ISV to implement properly.

If this is a concern, depending on OS, you might have the option to encrypt the paging and hibernation files, or just use full disk encryption to encrypt the entire disk. All modern OSes seem to now have this option.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .