From: utzoo!decvax!harpo!seismo!hao!hplabs!sri-unix!mike@Brl Newsgroups: net.unix-wizards Title: Protect KMEM! Article-I.D.: sri-unix.4962 Posted: Wed Dec 29 00:28:32 1982 Received: Thu Dec 30 05:04:42 1982 From: Michael Muuss Date: 24 Dec 82 0:19:15-EST (Fri) Programs which look in /dev/kmem are about as non-portable as anything I can imagine, and for that reason should be avoided. Then, there is the security issue. If you let users look in /dev/kmem, they might very well see things that were not intended for them. You make a mockery of the UNIX file protection mechanism. Depending on what you use your computer for, you may even have to worry about legal implications (Privacy Act, etc). Philosophically, I agree with the "open" system argument, but things can only be open to a point, or the usefulness of having the computer around is diminished. At BRL, we consider the computer an extention of the desk, and a normal part of the workplace. We are comitted to providing all of our ~1300 employees with {a desk, chair, phone, terminal, and a sliver of computer}. Most desks are unlocked. Most UNIX files are general read or read/write. Those desks that are NOT unlocked are that way for a reason. UNIX files that are not generally read/write are thay way for a reason too. "We", as "systems administrators", have to take reasonable measures to protect information which users (for whatever reason) designate as private. Alowing people to rummage in /dev/kmem thwarts this protection. ....but I digress.... There are two sets of information in the UNIX kernel which users really are entitled to: static configuration information (many of the #defines from param.h, UP hardware, etc), and dynamic information (# of users, #of procs in use, etc, etc). Rather than provide access to /dev/kmem, our approach has been to implement an additional sub-driver in dev/mem.c called /dev/data. This read-only device returns static & dynamic information about the system, and is generally readable. The format is in , and we guarantee that, while it may get longer, older entries will stay in place, for compatability. I'm not sure that this mechanism is sufficiently general that I want to suggest that everybody do this, BUT it is a *substantial* improvement over allowing access to /dev/kmem. It also provides us with insulation between the user layer and kernel code. Our kernel code changes frequently; no user process has any business knowing how things get done. (Alas, that last statement is not true: PS and the Crash-Dump analyzer do indeed need to know how the kernel works, and we wind up changing them a lot to keep up with the kernel). Best, -Mike