linux-kernel - RE: df36ac1bc2a16 ("pstore: Don't allow high traffic options on fragile devices")

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: <3908561D78D1C84285E8C5FCA982C28F31E2465C@ORSMSX106.amr.corp.intel.com>
Date:	Thu, 10 Apr 2014 18:34:34 +0000
From:	"Luck, Tony" <tony.luck@...el.com>
To:	Borislav Petkov <bp@...en8.de>
CC:	Matt Fleming <matt@...sole-pimps.org>,
	linux-efi <linux-efi@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>
Subject: RE: df36ac1bc2a16 ("pstore: Don't allow high traffic options on
 fragile devices")

> Even though those nvram devices are fragile and can only stomach a
> limited amount of writes, wouldn't it be a nifty feature to have a
> kernel cmdline param of the sort "put_dmesg_in_nvram_this_one_time_only"
> which logs to nvram only once for debugging purposes.

Speed is also a factor ... waiting for flash to update for each printk()
would mess up timing so much that you might not see the problem
you are chasing.

A better EFI trick for this would be "capsules".  They live in regular RAM
and BIOS firmware does stuff with them at warm reset time.  Matt has
been looking at them - but BIOS support for them seems sketchy to none
right now.

-Tony