linux-kernel - Re: [PATCH 0/2][concept RFC] x86: BIOS-save kernel log to disk upon panic

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 for Android: free password hash cracker in your pocket

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

Message-ID: <1295971355.4955.104.camel@mulgrave.site>
Date:	Tue, 25 Jan 2011 11:02:35 -0500
From:	James Bottomley <James.Bottomley@...e.de>
To:	"Ahmed S. Darwish" <darwish.07@...il.com>
Cc:	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, X86-ML <x86@...nel.org>,
	Tony Luck <tony.luck@...el.com>, Dave Jones <davej@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Randy Dunlap <rdunlap@...otime.net>,
	Willy Tarreau <wtarreau@...a.kernel.org>,
	Willy Tarreau <w@....eu>, Dirk Hohndel <hohndel@...radead.org>,
	Dirk.Hohndel@...el.com, IDE-ML <linux-ide@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Borislav Petkov <bp@...en8.de>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [PATCH 0/2][concept RFC] x86: BIOS-save kernel log to disk
 upon panic

On Tue, 2011-01-25 at 17:36 +0200, Ahmed S. Darwish wrote:
> The complete __roadblock__ I'm currently facing though is restoring the disk
> controllers to the state originally setup by the BIOS Power-on self-test (POST).
> I hope such re-initialization is even technically feasible.
> 
> Without such re-initialization, we'll just be risking the BIOS code exploding.
> That was the case in the 5-minute hang described in the cover sheet (PATCH #0).

So this is the bit that's not really technically feasible.  BIOS tends
to run storage devices in a very primitive way (so it takes basic
settings, for example and sets the device up for one particular channel
of access).  When preparing the device for an operating system, we have
to blow away all the bios stuff and put it into a more generally
performant mode (this isn't just the storage per se, it's also the
interrupt and routing).  Unfortunately, currently, we don't bother to
save the settings the BIOS was using, so there's no way to reinitialise
the device back to bios without an effective reboot.  Most BIOS doesn't
seem to contain storage re-POST code that's usable (it's all embedded in
the boot sequence).

James


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