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 ; 24 Oct 2019 20:14:12 -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 1iNjUo-0000Mr-Vc for speck@linutronix.de; Thu, 24 Oct 2019 22:14:11 +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 419CC80183E for ; Thu, 24 Oct 2019 20:14:06 +0000 (UTC) Received: from treble (ovpn-121-225.rdu2.redhat.com [10.10.121.225]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B097A60BF3 for ; Thu, 24 Oct 2019 20:14:05 +0000 (UTC) Date: Thu, 24 Oct 2019 15:14:03 -0500 From: Josh Poimboeuf Subject: [MODERATED] Re: [PATCH 3/9] TAA 3 Message-ID: <20191024201403.tibjxoywbd2rrjzq@treble> References: <580e02757c3e639bff00fcea830aa46eba46a92f.1571905227.git.bp@suse.de> <6f1ab744-622c-179b-276b-5506b2fd9ae1@citrix.com> <20191024194503.GH14115@zn.tnic> <20191024195959.nvdja4kxlbjrgq24@treble> <20191024200558.GJ14115@zn.tnic> MIME-Version: 1.0 In-Reply-To: <20191024200558.GJ14115@zn.tnic> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Thu, Oct 24, 2019 at 10:05:58PM +0200, speck for Borislav Petkov wrote: > On Thu, Oct 24, 2019 at 02:59:59PM -0500, speck for Josh Poimboeuf wrote: > > But pre-TSX_CTRL CPUs won't reach the above code, because of the > > tsx_ctrl_is_supported() check at the beginning of tsx_init(). > > Yes, pre-TSX_CTRL won't have those CPUID bits cleared because they > cannot anyway - MSR is not there. > > And even if we clear the corresponding X86_FEATURE_ bits, nothing is > stopping people from using TSX - they won't query /proc/cpuinfo but > CPUID directly. Hell, they can even try the instructions and see if they > fault or not, without querying any feature bits. > > > And post-TSX_CTRL CPUs will have the HLE bit already cleared by > > microcode. > > Yes. > > In both cases, the X86_FEATURE_* bits mirror what's in CPUID. At least > for the two TSX bits: HLE and RTM. Actually, according to the patches, with TSX_CTRL CPUs, HLE is unconditionally disabled, but still enumerated as present in CPUID (why???) If that's the case then it sounds like X86_FEATURE_HLE needs to be forced clear for TSX_CTRL CPUs? -- Josh