Access to kmem - System namelist - ps etc

[William L. Sebok]

> I agree.  I think this was discussed a long time ago.  Most people thought
> it was in poor taste or something, I never did quite understand the 
> objections.  What would be even better is if 4.3 or whatever comes out, 
> and you could map say the proc table into your own space.  And easily 
> write a blazingly fast sysdpy.
> --mike

I did this to the old 4.1 BSD kernel we used to run.  I made public readable
the addresses in which the kernel resides on the Vax (those above 0x8000000).
Doing it wasn't very difficult. I figured that since /dev/kmen was already
readable here and since we have a fairly benign environment that I wasn't
adding any security holes that weren't already there.

I had written here a program called "display" (posted to net.sources last
summer) which displayed and updated a histogram of the percent cpu usage of
the top cpu using processes.  A #define option was placed into display to
let it take advantage of direct access into kernel memory.  It did indeed
run faster but not as much faster as I had hoped.  It turns out that curses
is not terrifically fast.

Of course it is very hard to write a fast program if you want to access
information in the process's user area.  There is no quick way to gain
access to that.  Unfortunately quite a bit of interesting stuff is there.
Thus ps will stay slow.  On the Vax one presently has to emulate the memory
manager with /dev/mem: finding the page tables and seeing if the page is in
memory, doing the address translation and going to /dev/mem if it is or going
to /dev/swap if it is not.
-- 
Bill Sebok			Princeton University, Astrophysics
{allegra,akgua,burl,cbosgd,decvax,ihnp4,noao,princeton,vax135}!astrovax!wls