Acessing kmem, how about a driver?

[Guy Harris]

>      Seems to me that what people have been saying about a system call to
> provide access to various system data structures could be handled very
> effectively with a character device driver.
> 
>      The minor numbers for this driver would provide readonly access to
> various areas, such as '/dev/proc' for the process table, '/dev/smap' for
> the swap area map, '/dev/buf' for looking at the disk buffers, etc.
> 
>      Such a device driver would have the following benifits:
> 
> 	1. Restricted access to memory, with useful error codes for anyone
> 	   trying to write to these read-only areas.

This can be achieved, in large part, by having "/dev/kmem" only writable
by the super-user, and readable by group "0", and by having all programs
that only need to read the data be set-GID 0 rather than set-UID 0.  (While
we're on the topic of group "0", I've found that a lot of programs are set-UID
solely because they need to be able to *read* arbitrary files; would giving
"sub-super-user" privileges to gid 0, i.e., the ability to open arbitrary
files for reading, be useful?)

> 	2. Since the driver is a portion of the kernel, there is no
> 	   chance that the data reads will occur at the wrong address.

Well, if you got the right name list, this shouldn't happen anyway.  It
can happen if the table you're reading has pointers to other structures,
and those other structures move or change between reading the table entry
and the other structure in question, but fixing that would require a driver
which knew about those pointers and made reading the table entry and what
that entry points to an atomic operation.

> 	3. Standard device names can be used, freeing applications code
> 	   from needing to 'nlist' a given kernel file (which may not even
> 	   be booted!).

Unfortunately, a complete solution to this problem requires that you
provide a driver for every piece of data in the kernel that any program
would like to read.  There are a lot of programs in 4.2BSD that rummage
around the kernel ({io,vm,net}stat, just to name three) and they look
at a lot of data structures; it could be hard to anticipate all the
needed data structures.  It might solve part of the problem ("ps", for
instance), but any "complete" solution will break when the next program
is written.

>      By using a driver... data transfer could be as great as, or greater
> than using a 'read' call,

But you would be doing a "read" call to read from the driver anyway.  The
4.2BSD "memory driver" copies stuff from kernel space to user space about
as fast as it can be done - it uses a single "uiomove" call, which is
what your driver would have to do.

> perhaps using something similar to 'physio'?

Not needed - "physio" is used for devices which do direct DMA access;
the CPU can go through directly your machine's MMU to move stuff into
user space.

I'm not sure that anything is badly enough broken by being forced to do
an "nlist" and read from "/dev/kmem" that a fix is called for.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy