XML CO527 Anonymous Questions and Answers Keyword Index

This page provides a keyword index to questions and answers. Clicking on a keyword will take you to a page containing all questions and answers for that keyword, grouped by year.

To submit a question, use the anonymous questions page. You may find the keyword index and/or top-level index useful for locating past questions and answers.

Keyword reference for virtual-memory

Question 68 (2014):

Submission reference: IN3760

When you say, for an application, it has some virtual memory in the real memory, some virtual memory in the swap-space, and the rest is invalid, is the invalid stuff just memory the application will never use?

So, as a really simplified example: If an application had 4GB of available virtual memory and only actually needed 1GB, this used 1GB will be split up between real memory and the swap-space, and the remaining 3GB is invalid?

Answer 68:

That's not the entire set. There may be pages that are marked as "new page", i.e. it's not allocated in RAM or swap, but the resulting page fault when an application tries to access it will cause it to be allocated (in RAM). In the example, only as much virtual memory as needed is typically allocated, and only as needed (on demand). Over simplified, you could imagine that a virtual machine starts life as a whole pile (4 GiB's worth) of "new page"s. In practice this won't happen, as the page table(s) for that would be huge. However, starting with a handful of "new page"s would be sensible. These will be allocated as needed as the virtual-memory is populated with program code, constants, libraries and whatnot. When a page-fault happens in the "invalid" region beyond the page-table, the page-table (and virtual-memory used) are simply extended/grown.

If you look at the slides on the "application environment" you can see some examples of what happens in reality. It's not trivial. For many applications, not much actual RAM (real memory) may be required anew: the pages of the VM that are things like application code can be shared between any other instances of the same program (modulo position independent code or partial relocation), and such pages are mapped on top of files in the file-system (memory mapping, or mapped file-system).

Keywords: virtual-memory

Question 66 (2014):

Submission reference: IN3758

If being able to write to other programs' virtual memory is a bad thing (I assume this is the whole reason behind the protection in the first place) why is it so simple to just change the protection?

void write(DWORD wAddress, int *val, int dataLen) 
{
    unsigned long oldProt;
    VirtualProtect((LPVOID) wAddress, dataLen, PAGE_EXECUTE_READWRITE,
&oldProt);
    memcpy((LPVOID)wAddress, val, dataLen);
    VirtualProtect((LPVOID) wAddress, dataLen, oldProt);
}

or sometimes even simply:

void write(HANDLE hProc, DWORD wAddress, int val)
{
    WriteProcessMemory(hProc, (LPVOID) wAddress, Uvalue, sizeof(value),
NULL); 
}

What's the point of protection if you can just turn it off like this? Is it more of protection against accidental writing to memory?

Answer 66:

In the first code snippet, the process is only writing to its own virtual memory. I.e. the "wAddress" is in the process's own virtual memory. This is simply just changing the permissions of an existing page to read-write, copying some data (from elsewhere in the virtual memory at "val") then putting the protection back again. There might be good reasons why an application would want to do this, but it's not common. On the other hand, if a process wants to trash its own virtual machine, then let it wreck havoc!

The second example is something different, and that will potentially write stuff into a process's virtual-memory. Of course, the calling process must have sufficient permission to do that (without digging through API doc grot, one of your processes at a minimum, appropriate permission on the target page and probably some other restrictions). The docs suggest this is mainly used by debuggers, which would make sense (changing a variable's value in some process being debugged).

These are not common things to be doing in either case, however, and the fact you have to go to some lengths to do it would discourage programmers in the first place. There's no good reason why a program would want to make its entire virtual-memory space writable, for instance, unless it was trying to be malicious, or insanely badly programmed. Protection is not just against accidental code-errors (e.g. writing to an undefined pointer that happens to be in the code segment) but also against what people might try and do to a program (e.g. buffer-overflow exploiting it).

Keywords: virtual-memory