linux-kernel - Re: x86/mce merge, integration hickup + crash, design thoughts

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: <495B7457.1040605@linux.intel.com>
Date:	Wed, 31 Dec 2008 14:32:07 +0100
From:	Andi Kleen <ak@...ux.intel.com>
To:	Russ Anderson <rja@....com>
CC:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org, "H. Peter Anvin" <hpa@...or.com>
Subject: Re: x86/mce merge, integration hickup + crash, design thoughts

Russ Anderson wrote:

> Summary ASCII information is useful, especially if the error
> is clearly a hardware error.  Andi is right that decoding the
> information to print the specific failing hardware (ie which 
> DIMM) may be too dificult to decode on the way down.  It would
> be great to identify the failing hardware component on the
> way down, when possible.

This will hopefully happen in the future. In fact mcelog has support
to decode using DMI tables, but it turns out this doesn't work
very well in practice (both because of BIOS problems and because
the DMI standard was not really designed for this). That is why
I wouldn't advocate right now to move this code from mcelog
into the kernel. This might change later.

>>> It turns out that users don't really find this more enlightening (most 
>>> users have no clue what a Northbridge is).  They think it's some kind of 
>>> kernel bug even with the HARDWARE ERROR header.
>> You should not assume that administrators/users reading kernel crash 
>> messages are dumb. (an ordinary user wont see it most of the time anyway) 
>>
>> The usage patterns i see is that admins who get an MCE crash often fail to 
>> write down the whole MCE message (not realizing that it is important) and 
>> have to go back and reproduce the MCE crash once again before they can get 
>> any meaningful information.
> 
> This is why saving the error records to MVRAM is so useful.
> After reboot the records can be read, formatted, and logged.

I've been looking at using EFI runtime services for this, but it's
also somewhat problematic (e.g. getting the messages out again in
a useful way without risking duplicating events)

There are also a few other candidates like the Management Engine
interface on many Intel platforms, but it's also not available everywhere.

Short term just changing the MCE panic to timeout by default
is the best option. I'll probably submit that for .30

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