From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 22 09:53:02 2008 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E49616A400; Fri, 22 Feb 2008 09:53:02 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 126C013C4CE; Fri, 22 Feb 2008 09:53:01 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id m1M9qsF7001106; Fri, 22 Feb 2008 10:52:54 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m1M9qskE001105; Fri, 22 Feb 2008 10:52:54 +0100 (CET) (envelope-from olli) Date: Fri, 22 Feb 2008 10:52:54 +0100 (CET) Message-Id: <200802220952.m1M9qskE001105@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG, koitsu@FreeBSD.ORG, gizmen@blurp.pl In-Reply-To: <20080222092506.GA25704@eos.sc1.parodius.com> X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Fri, 22 Feb 2008 10:52:55 +0100 (CET) Cc: Subject: Re: cool feature of dmesg.boot file X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hackers@FreeBSD.ORG, koitsu@FreeBSD.ORG, gizmen@blurp.pl List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2008 09:53:02 -0000 Jeremy Chadwick wrote: > Oliver Fromme wrote: > > Upon a reboot, the kernel is usually loaded to the same > > physical addresses in RAM where it was before, so the > > dmesg buffer will be at the same location, too (unless > > you built a new kernel, of course). So all the contents > > from before reboot are still there -- *IF* the system > > BIOS didn't clear the RAM. Then the old contents will > > end up in /var/run/dmesg.boot, too. > > > > You could try looking at your BIOS setup. Some have an > > option called "Quick POST" or similar. If you enable > > it, the BIOS will skip the RAM test (which is rather > > useless anyway) which clears the RAM. It might help, > > but it depends very much on your mainboard and BIOS. > > There is also kern.msgbuf_clear. However, this is a sysctl, which > means if set to 1 in /etc/sysctl.conf, you'd lose your dmesg output > after the OS had started. Bummer. > > It would be useful if there was a loader.conf variable which was the > equivalent of msgbuf_clear. In fact, I'm wondering why the message > buffer isn't cleared on shutdown/immediately prior to reboot... So you can see panic messages and other useful things that happened before the reboot. It's a _feature_, not a bug. > Interesting tidbit: We have one production machine which when booted > into single-user via serial console for a world install, retains all of > the output from that single-user session even once rebooted and brought > back into multi-user mode. This poses a substantial security risk, > especially during the mergemaster phase (we can discuss why if anyone is > curious). sysctl security.bsd.unprivileged_read_msgbuf=0 Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.'