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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <4D3F0A15.2070703@zytor.com>
Date:	Tue, 25 Jan 2011 09:36:21 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Tony Luck <tony.luck@...el.com>
CC:	"Ahmed S. Darwish" <darwish.07@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, X86-ML <x86@...nel.org>,
	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 01/25/2011 09:32 AM, Tony Luck wrote:
> 
> Using swap space as a dump area has a long and established tradition
> going back to the early roots of Unix - so I don't think that it is all that
> hacky. I think that modern systems even write some magic at the start
> of the swap partition that you could use to verify that you were writing to
> the correct spot ... and it should be easy to retrieve your dumped data
> before the swap gets re-enabled by the new kernel after the reboot.
> [Perhaps the new kernel could do this automatically if it finds some
> signature that your code leaves in the swap area so it could stuff the data
> into my /dev/pstore filesystem?]
> 
> One more "is this bit of the BIOS code safe" concern that I have is that
> you'll be using the "write" path of the INT 0x13 code ... which isn't the
> path that is tested by booting ... it *ought* to be OK - but untested paths
> in BIOS seem to be broken paths all too often.
> 

It's not just that, it's that you're going through it *after the kernel
has run*.  The kernel has wrecked the state of the system -- the disk
hardware, the PCI hierarchy, the interrupt system -- as far as the BIOS
is concerned.  It is no longer safe to trust the BIOS to use your
hardware, especially not for writing.

So what is the solution?  We have to carry our own disk driver for the
emergency.  In other words, we're very quickly starting to make
something that looks a whole lot like kexec/kdump.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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