linux-kernel - Re: pstore dump inside an nmi handler

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] [day] [month] [year] [list]

Message-ID: <20110714134949.GS3765@redhat.com>
Date:	Thu, 14 Jul 2011 09:49:49 -0400
From:	Don Zickus <dzickus@...hat.com>
To:	"Luck, Tony" <tony.luck@...el.com>
Cc:	Matthew Garrett <mjg@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: pstore dump inside an nmi handler

On Wed, Jul 13, 2011 at 11:15:24AM -0700, Luck, Tony wrote:
> > But perhaps, if we detect a spinlock is in use, we can bust it and reset
> > the state machine to solve that problem?
> 
> The ERST table specifies a series of actions to perform to make
> the records get saved to (or read from) the platform persistent
> store. These actions will be dependent on the h/w, and also on
> the creativity of the BIOS writer who composed the ERST action
> table.
> 
> Resetting the state machine looks like it might be tricky from
> any arbitrary point in the sequence.

I agree and I think Matthew told me privately, it would probably be an
untested path, which would make things more problematic.  It would be nice
to have an NVRAM implementation.  That looks simpler and more robust in a
panic path.  But that is up to the vendor's BIOS. :-(

Cheers,
Don

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