From owner-freebsd-arch Sun Jul 9 16:57:28 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 4048937BAD7 for ; Sun, 9 Jul 2000 16:57:27 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e69Nv3V08478; Sun, 9 Jul 2000 16:57:03 -0700 (PDT) Date: Sun, 9 Jul 2000 16:57:03 -0700 From: Alfred Perlstein To: Marius Bendiksen Cc: Adam , arch@FreeBSD.ORG Subject: Re: making the snoop device loadable. Message-ID: <20000709165702.V25571@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from mbendiks@eunet.no on Mon, Jul 10, 2000 at 01:54:06AM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Marius Bendiksen [000709 16:54] wrote: > > Why did it exist from FreeBSD-WhoKnowsWhen until 1999? I'd like to use X > > As I recall, this had something to do with shrinking the kernel for > PicoBSD, amongst other things. > > > why NO_LKM is bad but couldn't find anything. Could you help me find a > > discussion on it or tell me why disabling kernel modules is *not* > > security? Assuming I'd notice a reboot and would consequently whup some > > butt if someone did. > > Thing is; disabling kernel modules will avail you little, as an > illegitimate user can still use the memory devices to access physical > memory, and thus binary patch a live kernel. This is hard, but it can, and > has been done. Eivind mentioned one particular case with a person who > binary-patched the kernel of an old Unix to bypass the 14 character file > name length limitation without severing the uptime. I owe that person a beer. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message