arm@cadre.ARPA (Alan Martello) (05/22/85)
lately, I have been wondering about accessing the memory of myself or
another process which I own. I know that lots of programs (e.g. ps) does it
via /dev/kmem. With that, am I correct in stating that you just examine the
namelist and you have the location in the CURRENT /dev/kmem (subject to
change without notice, dependent on number of variables, their size, etc.).
It states in my 4.2 mans that "per process data for the current process is
at virtual 0x7ffff000". I this is all well and good, but what about
someone else's memory? Also, even with this access, I can't write to
my own kernel memory (even though in some sense, it is mine). I don't
really have an application in mind, but I though it would be rather
interesting to ponder this. Another question I had was what is /dev/kUmem?
I assumed kernel user mem but my mans have no mention of this (PLEASE, no
flames if I missed something obvious). I noticed /dev/kUmem has major device
number 3 (same as /dev/mem, /dev/kmem, and /dev/null). Any wizards want to
comment on that one? Ok, one final question: what happens when you run a
program. It appears that it 1) reads your program, 2) loads it 3) somehow
runs it (must be magic). My question stems with can you touch that
running executable somehow (just like you can touch the running system
through /dev/kmem). Either direct replies or postings are welcome.
Thanks in advance.
-- Al Martello
UUCP: { akgua | allegra | cmcl2 | idis | ihnp4 | mi-cec | pitt
psuvax1 | sun | sunrise | vax135 } ! cadre ! arm
ARPA: arm@cadrechris@umcp-cs.UUCP (Chris Torek) (05/24/85)
> I know that lots of programs (e.g. ps) [read other processes' memory] Distribution: net Organization: U of Maryland, Computer Science Dept., College Park, MD Lines: 50 > via /dev/kmem. With that, am I correct in stating that you just > examine the namelist and you have the location in the CURRENT /dev/kmem > (subject to change without notice, dependent on number of variables, > their size, etc.). nlist'ing /vmunix gets you the positions of static things in /dev/kmem. They aren't likely to move without the system going down first. Usually you need to also follow some of these static pointers to some dynamic stuff which *can* change. > It states in my 4.2 mans that "per process data for the current process > is at virtual 0x7ffff000". This isn't really true: it's at 0x80000000-UPAGES*NBPG (machine/vmparam.h #define's USRSTACK as this same value). On Vaxen, you can read your u. area with struct user u; u = *(struct user *)USRSTACK; which is useful for routines like unexec (transforms a running process into an a.out image). > Another question I had was what is /dev/kUmem? kernel Unibus memory (it's the same as /dev/kmem, but reads and writes are done a 2-byte word at a time). Occasionally useful for faking device drivers from user-level code. > ... what happens when you run a program. It appears that it 1) reads > your program, 2) loads it 3) somehow runs it (must be magic). When you exec() something, it throws away all your current memory and gets some new memory for the new file (which must start with an a.out header describing how big it is) [well, actually it's more efficient than that]. The proc structure doesn't change (except for statistics). The u. area gets lots of new information though. > My question stems with can you touch that running executable somehow > (just like you can touch the running system through /dev/kmem). Yes, but it's ugly: you have to use /dev/kmem and /dev/mem in machine-dependent ways (you get to simulate the Vax page lookups for processes that are loaded). The ``gcore'' program (4.2BSD) makes a core image from a running process this way. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland
faustus@ucbcad.UUCP (Wayne A. Christopher) (05/24/85)
> It states in my 4.2 mans that "per process data for the current process is > at virtual 0x7ffff000". I this is all well and good, but what about > someone else's memory? Other people's user structures are mapped out while you are running, and you have to look for them either in /dev/mem or /dev/swap (as ps does). > Also, even with this access, I can't write to > my own kernel memory (even though in some sense, it is mine). There is a lot of stuff in there, like your uid, your quotas, the pagemaps for your process, etc, that you shouldn't be allowed to change for obvious reasons... > Ok, one final question: what happens when you run a > program. It appears that it 1) reads your program, 2) loads it 3) somehow > runs it (must be magic). My question stems with can you touch that > running executable somehow (just like you can touch the running system > through /dev/kmem). Again, you have to write to /dev/swap or /dev/mem, which you can't do unless you are root. Writing to these places is a lot worse than just reading them, because if the image gets swapped out from under you (or the swap space re-allocated) between the time that you figure out where to write and the time you write, you will probably hit the wrong thing and trash somebody else's program, instead of just reading garbage. Wayne
donn@utah-gr.UUCP (Donn Seeley) (05/26/85)
Let us not overlook the notorious ptrace() system call... This is used by debuggers to do gross things like modify the text of a process to insert breakpoints, and to read and write a process's 'u' area. Using ptrace() is not very convenient -- there are several restrictions on which processes you may access, what the victim process must do in order to allow you to perform surgery on it, what you can change in the victim process and how much data you can change at each transaction (32 bits, on a VAX). ptrace() does not require dubious sorts of diddling in /dev/mem or /dev/swap (aka /dev/drum), however. On Eighth Edition systems there is a directory named '/proc' which you can use to access a process's address space as though it were a file. Someday this feature will make its way into systems which people other than Peter Honeyman can buy... Donn Seeley University of Utah CS Dept donn@utah-cs.arpa 40 46' 6"N 111 50' 34"W (801) 581-5668 decvax!utah-cs!donn PS -- Shouldn't this sort of stuff go in net.unix?