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  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:	Mon, 22 Dec 2014 14:56:47 -0600
From:	Aravind Gopalakrishnan <>
To:	Borislav Petkov <>
CC:	<>, <>, <>,
	<>, <>,
	<>, <>,
	<>, <>,
	<>, <>, <>,
	<>, <>
Subject: Re: [PATCH 0/3] Fix MCE handling for AMD multi-node processors

On 12/22/2014 2:15 PM, Borislav Petkov wrote:
> On Mon, Dec 22, 2014 at 02:10:09PM -0600, Aravind Gopalakrishnan wrote:
>> When a MCE happens that is to be logged onto bank 4 of AMD multi-node
>> processors, they are reported only to corresponding node base core of
>> the cpu on which the error occurred.
>> Refer D18F3x44[NbMcaToMstCpuEn] on BKDGs of Fam10h and later for
> Let me try to understand this correctly:
> Does that mean that we could fix this by simply doing:
> D18F3x44[NbMcaToMstCpuEn]=0b
> on each NB?

Not quite..
When this field is 0, BKDG says the error may be reported to the core 
that originated the request *if applicable and known*
Looking at the error signatures table for MC4 (Part 2),
we can see only some errors have 'ErrCoreId' column as valid

Besides, if IO originated the request, then it is reported only to NBC.

So, to take care of all these cases, I am just following one approach 
here: and that is to look at NBC MSRs for any bank 4 errors.
(It seems to be what the BKDG recommends anyway as BIOS by default 
should set D18F3x44[NbMcaToMstCpuEn])

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists