Interfaces for accessing kernel memory

[Michael Meissner]

In article <1410 at mtxinu.COM> shore at mtxinu.COM (Melinda Shore) writes:

| In article <109449 at convex.convex.com> tchrist at convex.com (Tom Christiansen) writes:
| >I've heard that some vendors have a system (or is it library) call for
| >returning you chunks out of the kernel.  Can anyone tell me how they
| >seem to work?

Data General's unix (DG/UX) had such calls, though since I've not
worked for them for a year, my mind is growing blank on the details.
If somebody has an AViiON, do a man on dg_sys_info (and any other
/usr/include/sys/dg_* include files).  Here are the fragments of
emacs' etc/loadst that gets the load average:

#include <sys/dg_sys_info.h>		/* DG/UX rev 4.00 system information */ 

struct dg_sys_info_load_info load_info;

	/* ... */

      if (dg_sys_info( &load_info,
		       DG_SYS_INFO_LOAD_INFO_TYPE,
		       DG_SYS_INFO_LOAD_VERSION_0 ) == 0){

	      printf("%.2f", load_info.one_minute);
      }

| Both Unicos and Mach have system calls to return the current contents
| of selected kernel data structures.  In both cases you pass in which
| structures you want (header files include constants such as TBL_PROCINFO),
| starting address and number of elements (for arrays), and a pointer to
| where you want the data stuffed.  How do they seem to work?  They seem
| to work great.  The only limitation I've run into with either of them
| is that they don't necessarily provide access to all of the structures
| in which you might be interested.  On the other hand, Mach's table()
| call with give you the u. area for any process, and that's such a win
| that it overrides any regrets I might have about missing structures like
| the file table (which are still available through the standard nlist/
| lseek/read mechanism).
| 
| There's certainly no reason that it has to be implemented as a system
| call.

It depends on whether normal users are allowed to get information from
the kernel.  You generally have a security loophole if you get random
bytes from the kernel (either through a system call or by reading
/dev/kmem).
--
Michael Meissner	email: meissner at osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142

Considering the flames and intolerance, shouldn't USENET be spelled ABUSENET?