linux-kernel - RE: [PATCH v2 0/5] mm/hwpoison: Fix regressions in memory failure handling

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: <SJ1PR11MB6083F7AC9C5AED072141B8CAFCC52@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Wed, 19 Feb 2025 17:11:00 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: Borislav Petkov <bp@...en8.de>
CC: Shuai Xue <xueshuai@...ux.alibaba.com>, "nao.horiguchi@...il.com"
	<nao.horiguchi@...il.com>, "tglx@...utronix.de" <tglx@...utronix.de>,
	"mingo@...hat.com" <mingo@...hat.com>, "dave.hansen@...ux.intel.com"
	<dave.hansen@...ux.intel.com>, "x86@...nel.org" <x86@...nel.org>,
	"hpa@...or.com" <hpa@...or.com>, "linmiaohe@...wei.com"
	<linmiaohe@...wei.com>, "akpm@...ux-foundation.org"
	<akpm@...ux-foundation.org>, "peterz@...radead.org" <peterz@...radead.org>,
	"jpoimboe@...nel.org" <jpoimboe@...nel.org>, "linux-edac@...r.kernel.org"
	<linux-edac@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>,
	"baolin.wang@...ux.alibaba.com" <baolin.wang@...ux.alibaba.com>,
	"tianruidong@...ux.alibaba.com" <tianruidong@...ux.alibaba.com>
Subject: RE: [PATCH v2 0/5] mm/hwpoison: Fix regressions in memory failure
 handling

> First of all, thanks for explaining - that helps a lot!
>
> > That's how we ended up with *UN*corrected errors tied to *C*MCI.
> >
> > Just to add to the confusion, Linux does take an action (in uc_decode_notifier())
> > to try to offline the page despite the UC*NA* signature name.
>
> So, AFAIU, hw folks are basically trying to tell us: well, this is
> *technically* an uncorrectable error but meh, not really important. We just
> met it while fetching some data while scrubbing so who knows whether you'll
> consume it or not. Meh...
>
> So why don't we simply do that?

We could, but I don't like it much. By taking the page offline from the relatively
kind environment of a regular interrupt, we often avoid taking a machine check
(which is an unfriendly environment for software).

> We report the signature but we do not try to offline anything. When we get to
> *actually* consume it non-speculatively, *then* we run memory failure and then
> we offline the page.
>
> Hmmm?
>
> Would that solve that particular debacle?

Perhaps. It removes the race. But at the cost of always taking a machine
check instead of frequently avoiding it with the uc_decode_notifier() offline.

Modern Intel Xeons (>= SkyLake) support local machine check[1]. Even
newer Xeons report #MC as recoverable from pretty much all user mode
poison consumption. So machine check isn't as painful on modern systems
as it used to be.

We could make the action in uc_decode_notifier() configurable. Default=off
but with a command line option to enable for systems that are stuck with
broadcast machine checks.

On Intel that would mean not registering the notifier at all. What about AMD?
Do you have similar races for MCE_DEFERRED_SEVERITY errors?

-Tony

[1] Some OEMs still do not enable LMCE in their BIOS.