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: <20110125150834.GD27510@htj.dyndns.org>
Date:	Tue, 25 Jan 2011 16:08:34 +0100
From:	Tejun Heo <tj@...nel.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	"Ahmed S. Darwish" <darwish.07@...il.com>,
	"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

Hello, Ingo.

On Tue, Jan 25, 2011 at 03:09:48PM +0100, Ingo Molnar wrote:
> I think the biggest areas of practical concern would be:
> 
>  - Can this mechanism ever, under any circumstance corrupt any real
>    data, destroy the MBR or do other nasties. Can you think of any
>    additional fail-safe measures where you could _further robustify
>    the BIOS calls_ to make sure it can never go to the wrong
>    sector(s)? I really do not want to think of trusting a BIOS to
>    _write to my disk_.

It's quite unlikely but I wouldn't say it's completely impossible.
It's common for ATA controllers to have dual modes of operation - the
old IDE compatible interface by emulation which is used by BIOS and
older operating systems and newer interface (ahci) to be used by
modern OS.  Some need to be explicitly switched and some just need to
be accessed carefully.  If the controller is accessed by bIOS after
switched to ahci or commands are in progress via ahci, anything can
happen.

There's also HPA which changes the size of the device which we often
unlock.  As it's always at the end, it usually shouldn't cause
problems but there are BIOSen which expect certain things near the end
of the device (BIOS RAID ones).  I'm fairly sure nobody is testing
BIOSen for cases where the size of underlying device changes without
going through POST.

To summarize, it's unlikely but at the same time there are some
_truly_ scary beasts out in the wild.  There's certain level of
danger.

>  - Is there some hidden disk area somewhere on PCs, or somewhere on
>    a real partition on typical Linux distributions, which we could
>    use without having to reinstall the box? This would increase
>    utility and availability enormously. I'm thinking of partition
>    _ends_ which sometimes get rounded in an awkward way and which
>    are potentially skipped by most Linux filesystems. Even a very
>    small, 512 bytes of area would be extremely useful for debugging
>    weird suspend hangs ...

There are holes but writing to them without full knowledge of the
configuration can be quite dangerous.  I don't think it would be
possible to mass deploy it without manual configuration unless we
specifically reserve (and maybe mark) it in the filesystem.

>  - Could we automate the recovery of the dump, and just put it into
>    the regular kernel log on the next (successful) bootup (on a
>    feature-enabled kernel)? That would make the log of the 'previous
>    crash' very conveniently available in dmesg and the syslog. Tools
>    like kerneloops could make use of it immediately.

Yeah, that would be actually quite nice.

> All in one, a very intriguing idea IMO, and the hardest bits
> (lowlevel x86 transition) is all implemented already.

I like the prospect too but am a bit skeptical whether this can be
made reliable enough to be a convenient tool.

Thanks.

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