From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (193.142.43.55:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 14 Apr 2020 21:23:36 -0000 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120] helo=us-smtp-1.mimecast.com) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1jOT1r-0004Hf-79 for speck@linutronix.de; Tue, 14 Apr 2020 23:23:35 +0200 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 5D77F8017F3 for ; Tue, 14 Apr 2020 21:23:30 +0000 (UTC) Received: from treble (ovpn-116-146.rdu2.redhat.com [10.10.116.146]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1038C60BE1 for ; Tue, 14 Apr 2020 21:23:29 +0000 (UTC) Date: Tue, 14 Apr 2020 16:23:27 -0500 From: Josh Poimboeuf Subject: [MODERATED] Re: [PATCH 3/4] V7 more sampling fun 3 Message-ID: <20200414212327.eyo4xdldwuhnqzzz@treble> References: <20200414200237.useaxfticfc4skqm@treble> <20200414210302.GC29751@mtg-dev.jf.intel.com> MIME-Version: 1.0 In-Reply-To: <20200414210302.GC29751@mtg-dev.jf.intel.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Tue, Apr 14, 2020 at 02:03:02PM -0700, speck for mark gross wrote: > > > + [SRBDS_MITIGATION_NOT_AFFECTED_TSX_OFF] = "Not affected (TSX disabled)", > > > > The CPU *is* affected, it just happens to be mitigated, right? > This depends on perspective. > The only mitigation to SRBS is for the uCode to serialize access to the off > core hwRNG and to do a ghost transfer of a through away random number such that > if it leaks you don't get the right random number. I think there may be some > buffer clearing in there too. > > Disabling TSX from that point of view is not mitigating the issue so much as > hiding exposure to it. > > I can see it either way. Not sure which is better. After reading my logic do > you still think it would make more sence to change "Not affected (TSX > disabled)" to "Mitigated: TSX disabled"? >From a user's perspective, "hiding exposure" is the same as a mitigation. So I think it makes sense to call it a mitigation. > > > + */ > > > + if ((ia32_cap & ARCH_CAP_MDS_NO) && > > > + !((ia32_cap & ARCH_CAP_TSX_CTRL_MSR) || > > > + cpu_has(c, X86_FEATURE_RTM))) > > > + goto srbds_not_affected; > > > + > > > + setup_force_cpu_bug(X86_BUG_SRBDS); > > > + } > > > +srbds_not_affected: > > > + > > > if (cpu_matches(NO_MELTDOWN, cpu_vuln_whitelist)) > > > return; > > > > I'm thinking it would be more readable to have the newline between the > > bracket and the 'if', instead of between the label and the 'if'. > so, lose the newline between the label and the if? Yes, and add one between the '}' and the label. -- Josh