Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 8/23/84; site ucbcad.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!mcnc!decvax!ucbvax!ucbcad!faustus
From: faustus@ucbcad.UUCP (Wayne A. Christopher)
Newsgroups: net.unix-wizards
Subject: Re: /dev/kUmem and other memory questions
Message-ID: <5@ucbcad.UUCP>
Date: Fri, 24-May-85 03:35:26 EDT
Article-I.D.: ucbcad.5
Posted: Fri May 24 03:35:26 1985
Date-Received: Sun, 26-May-85 00:42:42 EDT
References: <437@cadre.ARPA>
Distribution: net
Organization: UC Berkeley CAD Group, Berkeley, CA
Lines: 30

> 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