linux-kernel - RE: [RFC][Patch]efi_pstore:Introduce an efi_pstore_overwrite parameter to avoid missing messages in NVRAM

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: <3908561D78D1C84285E8C5FCA982C28F1930C820@ORSMSX103.amr.corp.intel.com>
Date:	Wed, 13 Jun 2012 20:43:17 +0000
From:	"Luck, Tony" <tony.luck@...el.com>
To:	Mike Waychison <mikew@...gle.com>,
	Seiji Aguchi <seiji.aguchi@....com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"Matthew Garrett (mjg@...hat.com)" <mjg@...hat.com>,
	"gong.chen@...ux.intel.com" <gong.chen@...ux.intel.com>,
	"keescook@...omium.org" <keescook@...omium.org>,
	"rob@...dley.net" <rob@...dley.net>,
	"dle-develop@...ts.sourceforge.net" 
	<dle-develop@...ts.sourceforge.net>,
	Satoru Moriya <satoru.moriya@....com>
Subject: RE: [RFC][Patch]efi_pstore:Introduce an efi_pstore_overwrite
 parameter to avoid missing messages in NVRAM

>    4. kernel panics again before a user checks the 1st panic messages in NVRAM.
>
>
>    To avoid missing 1st panic messages, this patch adds a new parameter ,efi_pstore_overwrite,
>    to efi_pstore so that we can specify whether efi_pstore overwrites existing entries in NVRAM or not.

Since the EFI backend has so little storage space ... perhaps it should
have some overwrite rules built into it?

E.g. in the case where there is an OOPS already logged, and a panic happens,
then I think the right thing to do is overwrite the oops with the panic.
[The oops *might* have already made it to /var/log/messages, but even if
it didn't, a user with a PICK ONLY ONE choice would have to go for the
log of the panic]

In the situation you describe where we already have a panic, then
I don't think than anyone would want the earlier panic to be overwritten
by the new one.

If this seems a plausible route ... we'd need to tabulate the overwrite
rules.  I think they are:
	shutdown/reboot/kexec - can be overwritten by OOPS
	OOPS can be overwritten by panic
	panic can never be overwritten

I'd like to avoid a kernel parameter ... chances are too high that the
machine would be automatically rebooted without the right boot argument.

-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/