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:   Mon, 24 Jul 2017 20:30:14 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Mauro Carvalho Chehab <mchehab@....samsung.com>
Cc:     Mauro Carvalho Chehab <mchehab@...pensource.com>,
        "Kani, Toshimitsu" <toshi.kani@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mchehab@...nel.org" <mchehab@...nel.org>,
        "rjw@...ysocki.net" <rjw@...ysocki.net>,
        "srinivas.pandruvada@...ux.intel.com" 
        <srinivas.pandruvada@...ux.intel.com>,
        "tony.luck@...el.com" <tony.luck@...el.com>,
        "lenb@...nel.org" <lenb@...nel.org>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
        "linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>
Subject: Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

(Sending to your other mail address because there's some temporary resolution
 issue:

msmtp: recipient address mchehab@...pensource.com not accepted by the server
msmtp: server message: 451 4.3.0 <mchehab@...pensource.com>: Temporary lookup failure
msmtp: could not send mail (account alien8.de from /home/boris/.msmtprc)

Maybe the problem is on my end.)

On Mon, Jul 24, 2017 at 03:10:13PM -0300, Mauro Carvalho Chehab wrote:
> Yeah, having a whitelist is a maintainership's burden, but, on
> the other hand, I suspect that there aren't many systems that
> implement FF, have a reliable BIOS mapping of MB's silkscreen
> and doesn't filters out corrected errors using some sort of
> undocumented mechanism.
> 
> So, I guess it is doable.

Right, let's hope.

> Another alternative, with, IMO, is better would be to add a parameter like:
> 
> 	edac=FF - firmware first;
> 	edac=hw	 - hardware first;
> 	edac=auto - honors FF if set in BIOS. Otherwise, hardware first.

Or maybe edac=try_FF or so. But yeah, I guess we'll need something to
tell the EDAC core to try FF first.

> In order to avoid regressions, and to avoid the need of a whitelist,
> I would keep "edac=hw" as default.

So I don't want to break existing users and thus make only explicitly
known platforms load ghes_edac. In the current case, the HPE machines.
All the rest will simply use the platform drivers and nothing will
change for them.

Later we'll probably need to revisit this decision but right now and
with all things considered, the whitelist seems - as ugly as it is - the
most workable solution for all the different use cases and machines...

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ