Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1557797ybt; Mon, 15 Jun 2020 03:32:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxCNfgpqDptcRdO12nV0mT/JQx0cLJ3O32a9gnY8CSQ64pj88X2ThXovg+MD6JahbdUl8WK X-Received: by 2002:aa7:d359:: with SMTP id m25mr22331126edr.365.1592217135086; Mon, 15 Jun 2020 03:32:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592217135; cv=none; d=google.com; s=arc-20160816; b=U93n30VMWUQq3sz8YEGdOQjvQID9WrCMfJ+rabOnQtbrRBF/Vkvx2lXezmBXK3iZlf HY2oILrA7a4PtuvX/FdYlZOgepaIjosIHulwwDqZvWL4WygRllwxnA3TnrkNDEgJCCfV WWvfY1xZ+YSeF8efX8EKGX/Mr35iJM38lGYwYQ0d1QKACguav9j6Mc53/ncDQ3StLzL+ R8Jcix6rmUfygkO4Q6z/R770Q3/ZrjXinrtaku5SgWWJqiGuRXByucBBHm3C5syfE6pM i/YYLblOdUOTtBiDkLUeSjCd7EgiqLplTEFLOSwX8F6+9P2QiXQvpJKrWqbxjqi/Ci6i ZqZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=JjjXXaBIhzC1v0IVvSmAxKBiZBAcVDriBKWDAEuTavo=; b=d7wr2NSSU+trhXPrCfDFnjfZlLCEBeUZM4MByyqFokBq1jHUTa3nLXjkcfbS4KnQ7a fz/DIkDKMD2bAyPqN4AE3QbGbBCCLs44qmj0CHkNFAlmQRY9YaKcnWTX26cdGsXsrGag PqXcYUxkSlAR847nsjEbqKVvdrCxWpmzJohtkfmGQiQ07HOSclrsH0yMjZ9n+3Pjeh1a Tp8IWmKwBPkIGSHEzXW3MhmhsAmNQTZq0R9VcsvOElFTKiMGrYRmfJwo1yzunT/Y8PJq sWot01VlHHP8bzjrgbRxwexewT/LYS8WWwBFZSrb3zPcu8C4NPf4MEWVjG2PmZJZ/p6E zqJw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i13si8755591ejc.659.2020.06.15.03.31.53; Mon, 15 Jun 2020 03:32:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729280AbgFOK1s (ORCPT + 99 others); Mon, 15 Jun 2020 06:27:48 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:34781 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728369AbgFOK1r (ORCPT ); Mon, 15 Jun 2020 06:27:47 -0400 Received: from 200-158-207-52.dsl.telesp.net.br ([200.158.207.52] helo=mussarela) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1jkmLA-0003OU-NJ; Mon, 15 Jun 2020 10:27:45 +0000 Date: Mon, 15 Jun 2020 07:27:38 -0300 From: Thadeu Lima de Souza Cascardo To: Borislav Petkov Cc: linux-kernel@vger.kernel.org, Mark Gross , x86@kernel.org, "H. Peter Anvin" , Ingo Molnar , Thomas Gleixner , John Johansen , Steve Beattie Subject: Re: [PATCH] x86/speculation/srbds: do not try to turn mitigation off when not supported Message-ID: <20200615102738.GZ4342@mussarela> References: <20200609174313.2600320-1-cascardo@canonical.com> <20200615082858.GC14668@zn.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200615082858.GC14668@zn.tnic> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 15, 2020 at 10:28:58AM +0200, Borislav Petkov wrote: > On Tue, Jun 09, 2020 at 02:43:13PM -0300, Thadeu Lima de Souza Cascardo wrote: > > When SRBDS is mitigated by TSX OFF, update_srbds_msr will still read and > > Are you talking about this case in srbds_select_mitigation(): > > if ((ia32_cap & ARCH_CAP_MDS_NO) && !boot_cpu_has(X86_FEATURE_RTM)) > srbds_mitigation = SRBDS_MITIGATION_TSX_OFF; > > ? > That's the case that it hits, correct. > and you have a system which: > > * Check to see if this is one of the MDS_NO systems supporting > * TSX that are only exposed to SRBDS when TSX is enabled. > > i.e., no SRBDS microcode for it and the fix is to disable TSX? It was booted without the microcode update. There was microcode available, but systems may be booted without it, thus causing warnings due to the MSR read/write. > > If so, I think the right fix should be to do: > > if (!boot_cpu_has(X86_FEATURE_SRBDS_CTRL)) > return; > > in update_srbds_msr() with a comment above it explaining why that check > is being done. That's exactly the fix in the patch I sent, right? Do you want me to resend with a comment, then? Thanks. Cascardo. > > Hmmm. > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette