From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x2265ev9PpfXKR2DHEIboHfW6bZsQZzwP7TLd1Hbay05fgu8WoCKbFeAF40kLiEADrRFWOCCl ARC-Seal: i=1; a=rsa-sha256; t=1516565877; cv=none; d=google.com; s=arc-20160816; b=D5TTk1yGR+33TfBgp1bP5YIIGAtusWMzGwAWXVSL1jaEbslbsFuNlqROkFfbKW+a28 ioxaHw3Bpkx8jDR/TcosV7Gn75spnlq7mR9vQnimdsGLuRiFbtPHy+RMpg1MAZokXQMg xknXUHjrdv0bof/57ca+pD3vWrZ/KXJ7lc5RSi1p0g/mB/hJtuAn0XcOu7w0HfCPffRT qJJc/Ib/PdDhXVe7FHzzaVZqpvTQ56n/9lNO1G1ue6rX0xT/B4mI4k1SZ6s7Nvd8kUrd 0jhTKftvoARhgDo3ITt41i8tWojv+16Gx/HkwL1XECdcsKOv/e8tLbV717vjOY+HEJeW cq0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=IWmqDxWOhHnXoNtsF3Audq9pkctL6yIRDYnD+yPsglo=; b=TDIDjJ7iIZDr3M9x2d1P5F1ZRQF8UYElt7Bwd/h0knDF/5F3pzM7tZS6cYlec0Zdq+ YBMZS1/RrbL/3aWytZPp7SLCPNoc53ETTyxRMvGSz4vQ/ia8c5h3zJeCAaJYLfHANbYD TLz6YJhLmmwvhQF/qs28PI7yjRpGee4anNu3yBuFdis8k6CpuB3baeOVcAoRDu/KIOCH yY6fnwNgMKEAq+i334o9d6gHwK25bb/C10kIB3v4Y2pYAN+6xeEPVhIoLbvhRz9pqIJ8 ffPkQWat+AxpVrWIcVydaWdyTIuPu4v3mNO7n6hsYzzZhUXHqZNeZVTxGUJ5ALwDC6EH 0E8w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of bp@alien8.de designates 2a01:4f8:190:11c2::b:1457 as permitted sender) smtp.mailfrom=bp@alien8.de Authentication-Results: mx.google.com; spf=pass (google.com: domain of bp@alien8.de designates 2a01:4f8:190:11c2::b:1457 as permitted sender) smtp.mailfrom=bp@alien8.de Date: Sun, 21 Jan 2018 21:17:53 +0100 From: Borislav Petkov To: David Woodhouse Cc: arjan@linux.intel.com, tglx@linutronix.de, karahmed@amazon.de, x86@kernel.org, linux-kernel@vger.kernel.org, tim.c.chen@linux.intel.com, peterz@infradead.org, pbonzini@redhat.com, ak@linux.intel.com, torvalds@linux-foundation.org, gregkh@linux-foundation.org Subject: Re: [PATCH v2 5/8] x86/speculation: Add basic support for IBPB Message-ID: <20180121201753.hvcrs7dvhk4vmrrv@pd.tnic> References: <1516528149-9370-1-git-send-email-dwmw@amazon.co.uk> <1516528149-9370-6-git-send-email-dwmw@amazon.co.uk> <20180121180621.ufmc5m7nr6v4tjvc@pd.tnic> <1516560862.9814.47.camel@infradead.org> <20180121190430.ss22poeakvwzvcal@pd.tnic> <1516563099.9814.54.camel@infradead.org> <20180121195407.hbahkbmc37yrrvi4@pd.tnic> <1516565226.9814.63.camel@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1516565226.9814.63.camel@infradead.org> User-Agent: NeoMutt/20170609 (1.8.3) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590195048808685762?= X-GMAIL-MSGID: =?utf-8?q?1590234581709293912?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Sun, Jan 21, 2018 at 08:07:06PM +0000, David Woodhouse wrote: > That bug is the *reason* we're arguing about static_cpu_has vs. > ALTERNATIVE.  > > A conditional branch that the CPU sees can be speculated over... Lemme see if I understand it correctly: you don't want to have any such constructs: testb $1,boot_cpu_data+50(%rip) #, MEM[(const char *)&boot_cpu_data + 50B] jnz .L707 # which could cause any speculation. Instead, you want to have unconditional code which is slapped in by alternatives. Oh, and you don't want to have that at privilege crossing sites, like VMEXIT or so. Am I close? > Now, Andrew is right that in a number of cases there will be another > serialising instruction before we ever hit a problematic indirect > branch. But as I just said elsewhere, I'd really like the *primitives* > to support unconditional operation. In this particular case, WRMSR is already serializing too. So it is hard to exploit stuff here :-) -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.