linux-kernel - Re: spurious mce Hardware Error messages in next-20250912

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: <5ba955fe-2b96-429e-b2e8-5e1bf19d8e8e@suse.com>
Date: Thu, 18 Sep 2025 13:20:58 +0300
From: Nikolay Borisov <nik.borisov@...e.com>
To: Yazen Ghannam <yazen.ghannam@....com>, Bert Karwatzki <spasswolf@....de>
Cc: Borislav Petkov <bp@...en8.de>, Tony Luck <tony.luck@...el.com>,
 linux-kernel@...r.kernel.org, linux-next@...r.kernel.org,
 linux-edac@...r.kernel.org, linux-acpi@...r.kernel.org, x86@...nel.org,
 rafael@...nel.org, qiuxu.zhuo@...el.com,
 Smita.KoralahalliChannabasappa@....com
Subject: Re: spurious mce Hardware Error messages in next-20250912

On 9/17/25 22:26, Yazen Ghannam wrote:
<snip>

> Right, so it seems we have bogus data logged in these registers. And
> this is unrelated to the recent patches.
> 
> We have some combination of bits set in MCA_DESTAT registers. The
> deferred error interrupt hasn't fired (at least from the latest
> example).
> 
> There does seem to be some combination of bits that are always set and
> others flip between examples.
> 
> I'll highlight this to our hardware folks. But I don't think there's
> much we can do other than filter these out somehow.
> 
> I can add two checks to the patch to make it more like the current
> behavior.
> 
> 1) Check for 'Deferred' status bit when logging from the MCA_DESTAT.
> This was in the debug patch I shared.

According to AMD APM 9.3.3.4:

"If the error being logged is a deferred error, then the error will be 
logged to MCA_DESTAT."

So this means that when Valid is set in DESTAT then the error MUST BE 
deferred. I.e I think it's in valid to have valid && !deferred in 
DESTAT, no ?

Additionally nowhere in the APM is ti mentioned what's the default value 
of MCA_CONFIG.LogDeferredEn so as it stands you are now working with the 
assumption that it's 1 and DESTAT is always a redundant copy of STATUS.

Btw looking at the output that Bert has provided it seems that indeed 
MCA_CONFIG.LogDeferredEn is 0 by default:

"
LogDeferredEn—Bit 34. Enable logging of deferred errors in MCA_STATUS. 
0=Log deferred errors only in MCA_DESTAT and MCA_DEADDR. 1=Log deferred 
errors in MCA_STATUS and MCA_ADDR in addition to MCA_DESTAT and 
MCA_DEADDR. This bit does not affect logging of deferred errors in 
MCA_SYND or MCA_MISCx.
"

I think the polling code is slightly broken now for AMD. The order of 
operation per poll cycle should be:

1. Check MCA_STATUS -> report if there is anything, clear it the bank
2. (In the same cycle) -> Check DEFERRED and report if there is 
anything, clear the deferred.

> 2) Only check MCA_DESTAT when we are notified by the deferred error
> interrupt.
> 
> Technically, both of these shouldn't be necessary based on the
> architecture.
> 
> So there's a third option: add this error signature to our filter_mce()
> function.
 > > As I write this out, I feel more inclined to option #3. I think it 
would
> be better to stick to the architecture. We may get error reports like
> this. But that may be preferable so that any potential hardware issues
> can be investigated sooner. If there's a real problem, better to get it
> fixed in future products rather than implicitly mask it by our code
> flow.
> 
> Any thoughts from others?
> 
> Thanks,
> Yazen