linux-kernel - Re: [RFC] pstore: Don't use persistent store for normal shutdown

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTinG0381opyEFtM4P-OuFoG++b7kvpTC4McoL9E8@mail.gmail.com>
Date:	Mon, 21 Mar 2011 13:27:54 -0700
From:	Tony Luck <tony.luck@...el.com>
To:	Seiji Aguchi <seiji.aguchi@....com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	David Woodhouse <dwmw2@...radead.org>,
	Marco Stornelli <marco.stornelli@...il.com>,
	Artem Bityutskiy <Artem.Bityutskiy@...ia.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RFC] pstore: Don't use persistent store for normal shutdown

On Mon, Mar 21, 2011 at 12:49 PM, Seiji Aguchi <seiji.aguchi@....com> wrote:
> I think we should save the tail of kernel log into persistent store
> for both every shutdown and kexec path because these data are useful
> in enterprise area.
>
> I already described the useful case in lkml (see below).
>
> normal shutdown:
> https://lkml.org/lkml/2010/11/17/249

I hadn't thought about the forensic opportunities to show that a reboot/halt
was the cause of a server shutdown - but these do look useful.  Should
I still try to save as much data in these cases? Saving 1 Kbyte would be
enough to have the last dozen+ lines, including the critical
    <0>[  536.970556] Restarting system.
that you'd like to see.

> kexec:
> https://lkml.org/lkml/2011/2/23/325

In the case of kexec used as a "fast reboot" to another kernel, it might
also be valid to save some small amount of kernel log - but in the case
of kexec to take a kernel dump after a serious problem, it might be good
to have as much kernel log as possible to make sure that we have no
gaps in saved data.  If there isn't an easy way to tell these two kexec
cases apart, we should just save more data in both cases.

I'll make a new patch incorporating these changes.

-Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/