Interfaces for accessing kernel memory
Michael Meissner
meissner at osf.org
Tue Dec 4 06:56:12 AEST 1990
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?
More information about the Comp.unix.internals
mailing list