cool feature of dmesg.boot file

[Oliver Fromme]

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.'