RAM Mapping Script
Michael ODonnell
michael.odonnell at comcast.net
Mon Mar 3 11:23:20 EST 2008
> You won't be able to do this from userland. That spot of memory
> is off-limits because the kernel needs to preserve it in the event
> that another process wants to enter a vm86 mode.
Maybe I haven't been following this thread closely enough, but I
don't see how either User mode accesses or vm86 mode would matter.
I figure that once the kernel has pointed the IDT register elsewhere
that zero'th page of RAM loses any special status and goes into a pool
where it's eligible for allocation like any other.
Well, OK - maybe not like any other. Using the "crash" utility
I queried the system's mem_map[] and it appears (at least on this
steam-powered RHEL3 machine, assuming I'm looking at the correct
bit definitions in include/linux/mm.h) that the first dozen pages
are reserved:
.
.
.
crash> kmem -p
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
c100002c 0 0 0 0 8000
c1000068 1000 0 0 0 8000
c10000a4 2000 0 0 0 8000
c10000e0 3000 0 0 0 8000
c100011c 4000 0 0 0 8000
c1000158 5000 0 0 0 8000
c1000194 6000 0 0 0 8000
c10001d0 7000 0 0 0 8000
c100020c 8000 0 0 0 8000
c1000248 9000 0 0 0 8000
c1000284 a000 0 0 0 8000
c10002c0 b000 0 0 0 8000
c10002fc c000 0 0 0 0
c1000338 d000 0 0 0 0
c1000374 e000 0 0 0 0
c10003b0 f000 0 0 0 0
c10003ec 10000 0 0 0 0
c1000428 11000 0 0 0 0
c1000464 12000 0 0 0 0
c10004a0 13000 0 0 0 0
c10004dc 14000 0 0 0 0
.
.
.
...so just for fun I wrote NULLs to that first page (with
before and after displays for verification) thus:
dd bs=1k count=1 if=/dev/mem | hexdump -C
dd bs=1k count=1 if=/dev/zero of=/dev/mem
dd bs=1k count=1 if=/dev/mem | hexdump -C
...and the system kept on running, which indicates only that the
IDT is elsewhere, though I'm still not %100 certain the page isn't
in use for some other purpose.
More information about the gnhlug-discuss
mailing list