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
| ||
|
Date: Wed, 19 Jul 2017 07:52:35 +0200 From: Borislav Petkov <bp@...en8.de> To: "Kani, Toshimitsu" <toshi.kani@....com> Cc: "tony.luck@...el.com" <tony.luck@...el.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>, "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 On Tue, Jul 18, 2017 at 09:20:44PM +0000, Kani, Toshimitsu wrote: > I agree that 'osc_sb_apei_support_acked' should be checked when > enabling ghes_edac. I do not know the details of existing issues, but > it sounds unlikely that this will address all of them since bugs can be > everywhere. No, see below. > For instance, ghes_edac relies on DMI/SMBIOS info, unlike > other EDAC drivers, which can be buggy regardless of this _OSC info. That's the problem with firmware. You can't really fix it and it is buggy as hell. > I agree that making ghes_edac as a normal module is a good thing, but I > do not think it's going to solve this issue. Of course it will - if the firmware says it wants to look at the errors first, then it gets to do so. This is the whole handling of hardware errors in the firmware deal. I admit, sometimes it makes sense because the firmware has the most intimate knowledge of the platform and, in a perfect world, we won't ever need to have platform-specific EDAC drivers. But, we don't live in a perfect world. And the vendor execution of the whole firmware-error-handling deal is an abomination at best. So, if we realize that the firmware is buggy, we can use a platform list to blacklist it (^hint hint^) and have a parameter to disable ghes_edac from loading. But we'll deal with that when we get to cross that bridge. Right now, I'd like to do the loading spec-conform and not fiddle with white-, black-, or any-other-color lists. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. --
Powered by blists - more mailing lists