linux-kernel - Re: [PATCH 1/4] EDAC, MCE, AMD: Enable error decoding of Scalable MCA errors

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]

Date:	Wed, 24 Feb 2016 11:57:35 -0600
From:	Aravind Gopalakrishnan <aravind.gopalakrishnan@....com>
To:	Borislav Petkov <bp@...en8.de>
CC:	<tony.luck@...el.com>, <hpa@...or.com>, <mingo@...hat.com>,
	<tglx@...utronix.de>, <dougthompson@...ssion.com>,
	<mchehab@....samsung.com>, <x86@...nel.org>,
	<linux-edac@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<ashok.raj@...el.com>, <gong.chen@...ux.intel.com>,
	<len.brown@...el.com>, <peterz@...radead.org>,
	<ak@...ux.intel.com>, <alexander.shishkin@...ux.intel.com>
Subject: Re: [PATCH 1/4] EDAC, MCE, AMD: Enable error decoding of Scalable MCA
 errors

On 2/24/2016 5:28 AM, Borislav Petkov wrote:
> On Tue, Feb 23, 2016 at 04:50:37PM -0600, Aravind Gopalakrishnan wrote:
>> Sorry about that. Looks like this pair is not defined in spelling.txt. So,
>> might be worth adding there as well?
> Oh geez, we have a spelling.txt! I think we can declare the kernel as
> done and go do something else with our lives...

Haha:)

>> It's the block for programming FUSE registers.
> Oh, that's what it is.
>
> So maybe "fuses block" or "fuses" or ... just the capitalized "FUSE" is
> kinda misleading.

Asked about this internally.
Looks like it might be renamed to "Parameter block". So, I'll use that.

>> How about "Unable to gather IP block that threw the error. Therefore cannot
>> decode errors further.\n"
> Or simply "Invalid IP block specified, error information is unreliable."
> and still continue decoding. It might still be recognizable from the
> signature, methinks.

Hmm. We might be able to decode other bits of MCi_STATUS. Not the XEC 
which is what we do in this function.
So better to return early if we can't figure out which IP block to indict.

>> If for some reason the CPUID bit is not set, then we should not assume the
>> processor supports the features right?
> Is that even remotely possible? If yes, then we should keep the warning,
> otherwise it is useless.
>

Yes, it is possible.

Thanks,
-Aravind.