Unix Programming - Virtual Address Space Structure of a Process (Noob question)

Author

Virtual Address Space Structure of a Process (Noob question)

50295@web.de

2005-01-27, 7:54 am

I had written the following program to prove (to myself) that the
pointers seen in normal process execution are Virtual memory addresses:

#include <stdio.h>

main()
{
fork();
{
int i;
printf("Process %d: %p\n", getpid(), &i);
}
}

When complied with the Cygwin gcc complier on a WinXP machine, EVERY
TIME I ran the program, I got the result:

Process 2188: 0x22f064
Process 2308: 0x22f064

I reason that because the integer variable i wasn't being shared by the
parent and child addresses, yet had the pointer value, (i.e. 0x22f064)
they had to be Virtual memory addresses. Anyway, on RadHat machine, I
got:

Process ID 11840 :: 0xbfffbd64
Process ID 11839 :: 0xbfffbd64

Process ID 11842 :: 0xbfff8b74
Process ID 11841 :: 0xbfff8b74

Process ID 11844 :: 0xbffff1e4
Process ID 11843 :: 0xbffff1e4

Process ID 11846 :: 0xbfffce64
Process ID 11845 :: 0xbfffce64

.... You get my drift. This time the result was ALWAYS different; but
this wasn't the surprising bit. What "disturbing" bit was that, I
expected a very small address value like say, 0x13 because the variable
had been declared relatively early in the life of the program. At this
point I started to guess that the Virtual address space of a process
wasn't structured as I expected.

I've done a bit of searching and I now know, a kernel stack also must
exist in the virtual address space of a process. (I already know the
process regions for storing user code and data i.e the stack, and
heap.) I'll be grateful for any pointers or references (preferably
online) that might help me understand the detailed structure of a UNIX
(or Windows) process. Am I making sense?

One last silly question. Bearing in mind that processes are rarely
completely resident in memory but are rather paged in and out bit by
bit (do forgive the non-technical speak), it appears to me that the
entire process image must (first?) be created on the swap file, prior
to paging in and out on demand.

Thanks,

- Olumide

David Schwartz

2005-01-27, 7:54 am

<50295@web.de> wrote in message
news:1106819140.259260.244810@f14g2000cwb.googlegroups.com...

> ... You get my drift. This time the result was ALWAYS different; but
> this wasn't the surprising bit. What "disturbing" bit was that, I
> expected a very small address value like say, 0x13 because the variable
> had been declared relatively early in the life of the program. At this
> point I started to guess that the Virtual address space of a process
> wasn't structured as I expected.

The stack grows downwards in memory on x86. So it's started very high to
leave lots of room for growth. It's randomized at process startup to protect
against certain attacks that only work if the attackers knows or can guess
the stack address of parts of the stack.

> One last silly question. Bearing in mind that processes are rarely
> completely resident in memory but are rather paged in and out bit by
> bit (do forgive the non-technical speak), it appears to me that the
> entire process image must (first?) be created on the swap file, prior
> to paging in and out on demand.

Why? You don't seem to appreciate how sophisticated modern memory
management hardware is. For example, when you execute 'ls', and the 'ls'
executable, it isn't even loaded. All that's done is the paging scheme is
set up to map the 'ls' executable to a range of the process' virtual address
space. When the process jumps to its entry point, the page isn't resident,
and the paging scheme loads that one page from the disk where the 'ls'
executable is stored into one page of physical memory mapped at the
appropriate address.

Swap is only needed to store data that isn't available anywhere else.
For files in filesystems, the file itself can be mapped in, no need for
swap. Only modified data needs to be written to swap before the physical
memory can be freed (because the OS has no other place to get the data
from).

DS

Andrei Voropaev

2005-01-28, 7:52 am

On 2005-01-27, David Schwartz <davids@webmaster.com> wrote:
>
><50295@web.de> wrote in message
> news:1106819140.259260.244810@f14g2000cwb.googlegroups.com...
>
>
> The stack grows downwards in memory on x86. So it's started very high to
> leave lots of room for growth. It's randomized at process startup to protect
> against certain attacks that only work if the attackers knows or can guess
> the stack address of parts of the stack.

Hm. I guess this "randomizing" is distribution specific. I haven't seen
it on my machine

--
Minds, like parachutes, function best when open

Artie Gold

2005-01-29, 2:47 am

Andrei Voropaev wrote:
> On 2005-01-27, David Schwartz <davids@webmaster.com> wrote:
>
>
>
> Hm. I guess this "randomizing" is distribution specific. I haven't seen
> it on my machine

>
It is. It's a RedHat thing (which does, indeed, provide security against
certain attacks -- but also breaks more than a trivial amount of code).

--ag

--
Artie Gold -- Austin, Texas
http://it-matters.blogspot.com (new post 12/5)
http://www.cafepress.com/goldsays

Juha Laiho

2005-01-29, 5:54 pm

"David Schwartz" <davids@webmaster.com> said:
><50295@web.de> wrote in message
>news:1106819140.259260.244810@f14g2000cwb.googlegroups.com...
>
> Why? You don't seem to appreciate how sophisticated modern memory
>management hardware is.

.... never mind the hardware; it isn't that long since when there sill were
OSes that did at least reserve from swap the full size of the process working
set when the process was started (and increased the allocation each time
the working set was expanded). Result: if you had less swap than physical
memory, part of your physical memory couldn't be used.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)

David Schwartz

2005-01-31, 7:52 am

"Juha Laiho" <Juha.Laiho@iki.fi> wrote in message
news:ctgdu1$2jv$1@ichaos.ichaos-int...

> ... never mind the hardware; it isn't that long since when there sill were
> OSes that did at least reserve from swap the full size of the process
> working
> set when the process was started (and increased the allocation each time
> the working set was expanded). Result: if you had less swap than physical
> memory, part of your physical memory couldn't be used.

There are good reasons for this. Reserving swap is cheap, swap is cheap.
Failing to reserve swap can lead to a situation where you don't have enough
swap and have no choice but to kill processes.

DS