From joshd@cs.UMD.EDU Fri Jun 21 02:30:46 1996 Received: from tove.cs.UMD.EDU (tove.cs.umd.edu [128.8.128.42]) by suburbia.net (8.7.4/Proff-950810) with ESMTP id CAA20652 for ; Fri, 21 Jun 1996 02:30:05 +1000 Received: by tove.cs.UMD.EDU (8.7.5/UMIACS-0.9/04-05-88) id MAA10586; Thu, 20 Jun 1996 12:29:02 -0400 (EDT) Date: Thu, 20 Jun 1996 12:29:02 -0400 (EDT) From: Joshua Daymont To: koesterb@ncr.disa.mil cc: best-of-security@suburbia.net, ellerj@ncr.disa.mil, martin5s@ncr.disa.mil, veaseyr@ncr.disa.mil, kleinp@ncr.disa.mil, rogalskr@ncr.disa.mil, dunningm@ncr.disa.mil Subject: Re: BoS: amodload.tar.gz - dynamic SunOS modules (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I'm not entirely sure I understand your questions, but I will try to answer them: I designed amodload (and wrote it) on a Sparc IPC at the U. of MD, I started writing, then stoped when it worked well, the design (and the program itself) is pretty simple. I tested it with the example modules that were distributed with it (the machine was running a slightly customized SunOS 4.1.3 kernel). The desired result from amodload is to get no output. By specifing the -v option you can get debugging output, which won't make much sense to you unless you know the SunOS kernel. When using -v any error line should have the word 'error:' in front of it. If if something in amodload goes wrong, the machine would probably recover itself by panic()ing. This can happen if something wrote to the msgbuf while amodload was executing. You might also want to be careful with amodload on newer sparcs. If you do run into problems, feel free to send me a copy of the debugging output and I can probly give you some ideas as to what might be wrong. - JD > > Dear best-of-security@suburbia.net, > > I have been asked to test amodload. I understand Amodload will load > modules of code into a SunOS kernel. > > I would like to know more about Amodload before I try it. > > Can you supply me with details on how it was designed and tested. > What is the desired end result and how can I best recover, if > something goes wrong. > > Thanks alot, > > :-) > > Ben Koester > koesterb@ncr.disa.mil > (703) 681-7923