linux-kernel - Re: [PATCH 3/4] RAS: Add a Corrected Errors Collector

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: <20170323182043.GA32755@intel.com>
Date:   Thu, 23 Mar 2017 11:20:44 -0700
From:   "Luck, Tony" <tony.luck@...el.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     X86 ML <x86@...nel.org>, linux-edac <linux-edac@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/4] RAS: Add a Corrected Errors Collector

On Thu, Mar 23, 2017 at 06:28:39PM +0100, Borislav Petkov wrote:
> Meh, I don't like the idea of keeping an evergrowing list of PFNs we
> can't do anything about anyway.

Keeping every PFN would be overkill (most of them should be taken
offline with no issues).  A fixed array of a few of them with timestamps
to drop the oldest would likely be a good enough(TM) solution.

> And actually, you want the kernel to keep complaining about not being
> able to offline those because then admins should consider speeding up
> the arrival of the maintenance window - the kernel memory itself is
> going sick so that not even RAS actions help here.

Worst case is pretty ugly. A frequently used kernel page with a stuck
bit could be added to the CEC array, overflow, and generate a message
at a pretty high rate.

> I'm wondering if we should make the offlining code dump a more
> comprehensible message with hints what to do...

Maybe ... but it gets into opinion rather than science. Some folks
think that very low numbers of corrected errors warrant DIMM replacement.
Others think that you can keep running almost forever with a several
stuck bits per DIMM.

Some of the best decisions would be made by correlating error logs
from multiple reboots ... which the kernel can't do.

-Tony