linux-kernel - RE: [RFC][PATCH 2/2] write callback: Check if existing entry is erasable

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: <3908561D78D1C84285E8C5FCA982C28F1934764C@ORSMSX104.amr.corp.intel.com>
Date:	Thu, 5 Jul 2012 23:12:42 +0000
From:	"Luck, Tony" <tony.luck@...el.com>
To:	Seiji Aguchi <seiji.aguchi@....com>,
	Don Zickus <dzickus@...hat.com>,
	"Matthew Garrett (mjg@...hat.com)" <mjg@...hat.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"mikew@...gle.com" <mikew@...gle.com>,
	"dle-develop@...ts.sourceforge.net" 
	<dle-develop@...ts.sourceforge.net>,
	Satoru Moriya <satoru.moriya@....com>
Subject: RE: [RFC][PATCH 2/2] write callback: Check if existing entry is
 erasable

> Default value of pstore.kmsg_byte is 10KB.
> I think efi_pstore can log 60KB(= 10KB X 6)...

10K is almost certainly more than we need for 99.9% of problems ... I set the
default there to test out that pstore would correctly break a dump into more
than one back-end ERST record (about 7K) and never changed it back. So
don't treat 10K with any magic reverence. It's easy to argue that a smaller
number is good enough.

There are certainly less over-write worries if you can handle a few
(4, 5, 6) simultaneously logged errors of sufficient size to be useful
(must capture all of the panic strings, backtrace and register dump
plus "enough" lines before the panic to see any obvious issues).

If you only get to store two errors, then perhaps one non-over writable
panic type entry, and one other "most recent" type entry?

With just one, like current EFI, then there are certainly hard choices
that might not be the best for certain pathological situations.

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