memory overcommitment

[D. Hugh Redelmeier]

| From: Lennart Sorensen <lsorense-1wCw9BSqJbv44Nm34jS7GywD8/FfD2ys at public.gmane.org>

| > But: in a properly designed system, much of the memory of a process should 
| > be read-only and never have to be copied: the program code itself and any 
| > constants.  Reading between the lines, it sounds as if Linux doesn't 
| > enforce this.
| 
| x86 had no way to enforce this.  x86_64 added support for marking a page
| no execute (data only).  Well x86 could enforce read only on the code
| pages, but it couldn't prevent a program from executing a data page.
| Of course since some programs thought self modifying code was a good
| idea, I am not sure linux did enforce read only code pages in the past,
| or if it even does now.

x86 sure does allow read-only as opposed to read/write (execution is a
kind of read).  Partial demonstration: that's one of the hardware
mechanisms used in implementing COW.

<http://www.acm.uiuc.edu/sigops/roll_your_own/i386/vm.html>
See the R/W bit in the page table entry.

<http://kernel.org/doc/gorman/html/understand/understand006.html>
See _PAGE_RW in 3.2

Neither of those mention it, but there are even more levels of write
protection exist in x86
- 286 and later segmentation also allows write protection.
- the Page Directory Entry (PDE) allows write protection

Self modifying code is sometimes a good idea.  Examples:

- JIT compilers (including fast emulators to implement virtual
  machines)

- BIT BLIT

- hacking continuations into C

- dynamic loaders

In most of these examples, there is normally still a large area that
isn't simultaineously writeable and executable.
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists