linux-kernel - Re: [PATCH] x86/mce: Do feature check earlier

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: <20170318105615.fik6nx6cc6utfh7u@pd.tnic>
Date:   Sat, 18 Mar 2017 11:56:15 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     Yazen Ghannam <Yazen.Ghannam@....com>
Cc:     linux-edac@...r.kernel.org, Tony Luck <tony.luck@...el.com>,
        x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/mce: Do feature check earlier

On Wed, Mar 15, 2017 at 12:30:55PM -0500, Yazen Ghannam wrote:
> We may miss some information when errors are logged during boot before the
> feature flags are set. For example, on SMCA systems we will not log the
> MCA_IPID and MCA_SYND registers and we won't mask MCA_ADDR appropriately.

That paragraph really needs to explain what the problem is more
thoroughly. "We may miss some info" is not enough. I've done it for
you now but please take care to do this in the future.

A good way to structure your commit message is this:

 "The current state of affairs is A. This is a problem (because of B).
 In order to fix this, we should do C."

and then you go and fill in A, B and C. Depending on the issue, that
format won't always fit but it works most of the time. The general idea
is to describe the problem sufficiently so that a reader staring at this
months or even years from now can still understand what the issue was.

It is really important to have those things documented because when we
go and change the code in the future, we'd get a continuous picture of
why we did the things the way we did them then and to be able to change
them again.

Thanks.

---
>From 41492678b23bb87319bc409e1ee513a10f38a6c2 Mon Sep 17 00:00:00 2001
From: Yazen Ghannam <Yazen.Ghannam@....com>
Date: Wed, 15 Mar 2017 12:30:55 -0500
Subject: [PATCH] x86/mce: Init some CPU features early

When we poll the MCA banks in __mcheck_cpu_init_generic() for leftover
errors logged during boot or from the previous boot, we need to have
detected CPU features sufficiently so that the reading out and handling
of those early errors is done correctly.

If we don't do it, we may miss some information/get incomplete errors
logged. For example, on SMCA systems we will not log the MCA_IPID and
MCA_SYND registers and we won't mask MCA_ADDR appropriately.

For that, do a subset of the basic feature detection early while the
rest happens in its usual place in __mcheck_cpu_init_vendor().

Signed-off-by: Yazen Ghannam <Yazen.Ghannam@....com>
Cc: Tony Luck <tony.luck@...el.com>
Cc: linux-edac <linux-edac@...r.kernel.org>
Cc: x86-ml <x86@...nel.org>
Link: http://lkml.kernel.org/r/1489599055-20756-1-git-send-email-Yazen.Ghannam@amd.com
[ Massage commit message and simplify. ]
Signed-off-by: Borislav Petkov <bp@...e.de>
---
 arch/x86/kernel/cpu/mcheck/mce.c | 30 ++++++++++++++++++------------
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 177472ace838..5e365a2fabe5 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1702,30 +1702,35 @@ static int __mcheck_cpu_ancient_init(struct cpuinfo_x86 *c)
 	return 0;
 }

-static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 *c)
+/*
+ * Init basic CPU features needed for early decoding of MCEs.
+ */
+static void __mcheck_cpu_init_early(struct cpuinfo_x86 *c)
 {
-	switch (c->x86_vendor) {
-	case X86_VENDOR_INTEL:
-		mce_intel_feature_init(c);
-		mce_adjust_timer = cmci_intel_adjust_timer;
-		break;
-
-	case X86_VENDOR_AMD: {
+	if (c->x86_vendor == X86_VENDOR_AMD) {
 		mce_flags.overflow_recov = !!cpu_has(c, X86_FEATURE_OVERFLOW_RECOV);
 		mce_flags.succor	 = !!cpu_has(c, X86_FEATURE_SUCCOR);
 		mce_flags.smca		 = !!cpu_has(c, X86_FEATURE_SMCA);

-		/*
-		 * Install proper ops for Scalable MCA enabled processors
-		 */
 		if (mce_flags.smca) {
 			msr_ops.ctl	= smca_ctl_reg;
 			msr_ops.status	= smca_status_reg;
 			msr_ops.addr	= smca_addr_reg;
 			msr_ops.misc	= smca_misc_reg;
 		}
-		mce_amd_feature_init(c);
+	}
+}

+static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 *c)
+{
+	switch (c->x86_vendor) {
+	case X86_VENDOR_INTEL:
+		mce_intel_feature_init(c);
+		mce_adjust_timer = cmci_intel_adjust_timer;
+		break;
+
+	case X86_VENDOR_AMD: {
+		mce_amd_feature_init(c);
 		break;
 		}

@@ -1812,6 +1817,7 @@ void mcheck_cpu_init(struct cpuinfo_x86 *c)

 	machine_check_vector = do_machine_check;

+	__mcheck_cpu_init_early(c);
 	__mcheck_cpu_init_generic();
 	__mcheck_cpu_init_vendor(c);
 	__mcheck_cpu_init_clear_banks();
-- 
2.11.0

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.