From owner-freebsd-current Fri Nov 21 15:57:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA25951 for current-outgoing; Fri, 21 Nov 1997 15:57:13 -0800 (PST) (envelope-from owner-freebsd-current) Received: from d198-232.uoregon.edu (d198-232.uoregon.edu [128.223.198.232]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA25942 for ; Fri, 21 Nov 1997 15:57:10 -0800 (PST) (envelope-from mini@d198-232.uoregon.edu) Received: (from mini@localhost) by d198-232.uoregon.edu (8.8.5/8.8.5) id PAA04688; Fri, 21 Nov 1997 15:56:49 -0800 (PST) Message-ID: <19971121155649.49582@micron.mini.net> Date: Fri, 21 Nov 1997 15:56:49 -0800 From: Jonathan Mini To: Evan Champion Cc: Jonathan Mini , Poul-Henning Kamp , Bruce Evans , mike@smith.net.au, freebsd-current@FreeBSD.ORG Subject: Re: Stripping the kernel Reply-To: Jonathan Mini References: <19971121080934.15793@micron.mini.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: ; from Evan Champion on Fri, Nov 21, 1997 at 02:58:19PM -0500 X-files: The Truth is Out There Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Evan, you are absolutely right. It is Bad and Evil to read things out of the kernel memory. I have hated it from the start. However, look at the uses of the kernel tompling, and come up with an effective efficient way to do the same things, and I will even write it for you. :) Evan Champion stands accused of saying: > On Fri, 21 Nov 1997, Jonathan Mini wrote: > > > The problem *I* often have is that there is no /kernel on the filesystem, > > which happens in the case of MFS root'd systems all the time. I have been > > toying with the idea of writing a device that would use the kernel's saved > > symbol table in order to create a pseudo-a.out file which would provide > > a symbol table for things like libkvm and friends to read instead of reading > > the symbols from a /kernel. (I would like to advance that there is no guarantee > > that the kernel image on disk matches the current booted kernel, whereas the > > symbols in the kernel are the ones from the image the kernel was loaded from, > > and hopefully more reliable) > > Not really knowing how things go on, excuse me if I seem a little dense in > the following :-) > > It always struct me that reading symbols out of the kernel is a rather > backwards way of doing things. > > Take for example any other application but the kernel... If you wanted to > know the value of a variable in that program, you wouldn't open the file > up and start looking for symbols... Instead, you'd write an interface > that allowed you to access those symbols indirectly. > > In this case, if nlist() and co. read from a kernel interface instead of > reading /kernel directly, you could run a fully stripped kernel, and it > wouldn't matter whether the kernel on disk was the same as the loaded > kernel, since all that matters is the interface provided by the in-memory > image. > > In a way, that is what you're doing by creating a separate device that > programs can read out of, except that the programs are still reading the > symbols directly (just through the /dev node instead of /kernel). > > Evan > -- Jonathan Mini Ingenious Productions Software Development P.O. Box 5693, Eugene, Or. 97405 "A child of five could understand this! Quick -- Fetch me a child of five."