From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from aserp2130.oracle.com ([141.146.126.79]) by Galois.linutronix.de with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1f9JyL-0003Gd-Rb for speck@linutronix.de; Fri, 20 Apr 2018 02:32:19 +0200 Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w3K0WA45163762 for ; Fri, 20 Apr 2018 00:32:10 GMT Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp2130.oracle.com with ESMTP id 2hdrxnjdb5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 20 Apr 2018 00:32:10 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w3K0WAJp028599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 20 Apr 2018 00:32:10 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w3K0W9tS006180 for ; Fri, 20 Apr 2018 00:32:09 GMT Date: Thu, 19 Apr 2018 20:29:21 -0400 From: Konrad Rzeszutek Wilk Subject: [MODERATED] Re: [patch 3/8] [PATCH v1.3.1 3/7] Linux Patch 3 Message-ID: <20180420002916.GA30864@localhost.localdomain> References: <20180418141551.07CBB6111A@crypto-ml.lab.linutronix.de> <20180418153712.GD4290@pd.tnic> <20180419205132.GA18190@localhost.localdomain> <20180419211003.GE3905@pd.tnic> MIME-Version: 1.0 In-Reply-To: <20180419211003.GE3905@pd.tnic> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: 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?