From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from userp2120.oracle.com ([156.151.31.85]) by Galois.linutronix.de with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1f9Ly7-0004Zm-25 for speck@linutronix.de; Fri, 20 Apr 2018 04:40:11 +0200 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w3K2W2Xa107965 for ; Fri, 20 Apr 2018 02:40:04 GMT Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2120.oracle.com with ESMTP id 2hdrxpam9w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 20 Apr 2018 02:40:04 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w3K2e2a8018652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 20 Apr 2018 02:40:03 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w3K2e2OH008011 for ; Fri, 20 Apr 2018 02:40:02 GMT Date: Thu, 19 Apr 2018 22:39:57 -0400 From: Konrad Rzeszutek Wilk Subject: [MODERATED] Re: [patch 3/8] [PATCH v1.3.1 3/7] Linux Patch 3 Message-ID: <20180420023944.GA26657@localhost.localdomain> References: <20180418141551.07CBB6111A@crypto-ml.lab.linutronix.de> <20180418153712.GD4290@pd.tnic> <20180419205132.GA18190@localhost.localdomain> <20180419211003.GE3905@pd.tnic> <20180420002916.GA30864@localhost.localdomain> MIME-Version: 1.0 In-Reply-To: <20180420002916.GA30864@localhost.localdomain> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Thu, Apr 19, 2018 at 08:29:21PM -0400, speck for Konrad Rzeszutek Wilk wrote: > On Thu, Apr 19, 2018 at 11:10:03PM +0200, speck for Borislav Petkov wrote: > > On Thu, Apr 19, 2018 at 04:51:37PM -0400, speck for Konrad Rzeszutek Wilk wrote: > > > That won't work. The reason is that check_bugs first calls > > > identify_boot_cpu() which calls identify_cpu() which calls > > > this_cpu->init. Once identify_boot_cpu() is done _then_ it walks > > > through the spectre_v2_select_mitigation() and ssb_select_mitigation(). > > > > So call md_select_mitigation() before identify_boot_cpu() in > > check_bugs(). > > That will mean that the init_speculation_control() won't happen > until _after_ md_select_mitigation(). > > And that throws a wrench in that as we need to rdmsrl(SPEC_CTRL) > (which is right now done from spectre_v2_select_mitigation): > > 347 if (boot_cpu_has(X86_FEATURE_IBPB) || boot_cpu_has(X86_FEATURE_IBRS)) > 348 rdmsrl(MSR_IA32_SPEC_CTRL, x86_spec_ctrl_base); > 349 } > > And x86_spec_ctrl_base is then ORed in md_select_mitigation(). > > But > spectre_v2_select_mitigation depends on identify_boot_cpu. > md_select_mitigation depends on spectre_v2_select_mitigation. > > If I move the identify_boot_cpu before md_select_mitigation things > get wonky. > > Maybe it will be easier to explain when I send out the patches? I fixed the circular dependency I mentioned here in the patches. (See the v2 posting, Patch #3). But then I realized we still have one more issue - mainly the X86_FEATURE_MDD. That is you asked in one of the patches review to guard the md_parse_cmdline with: if (!boot_cpu_has(X86_FEATURE_MDD)) return MD_CMD_NONE; And on AMD the X86_FEATURE_MDD (with the v2 patch set just sent) it gets set in c_init as it detects which family can safely touch the MSR_AMD64_LS_CFG MSR: if (!rdmsrl_safe(MSR_AMD64_LS_CFG, &msr_MSR_AMD64_LS_CFG_val)) set_cpu_cap(c, X86_FEATURE_MDD); (as the CPUID.7.EDX[31] is not going to be set on AMD I assume). See the v2 - Patch #9.