Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751358AbeAEAXl (ORCPT + 1 other); Thu, 4 Jan 2018 19:23:41 -0500 Received: from ppsw-32.csi.cam.ac.uk ([131.111.8.132]:39352 "EHLO ppsw-32.csi.cam.ac.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751108AbeAEAXk (ORCPT ); Thu, 4 Jan 2018 19:23:40 -0500 X-Greylist: delayed 1004 seconds by postgrey-1.27 at vger.kernel.org; Thu, 04 Jan 2018 19:23:40 EST X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Subject: Re: Avoid speculative indirect calls in kernel To: Tom Lendacky , David Woodhouse , Paolo Bonzini , "pavel@ucw.cz" Cc: "tim.c.chen@linux.intel.com" , "linux-kernel@vger.kernel.org" , "torvalds@linux-foundation.org" , "tglx@linutronix.de" , "andi@firstfloor.org" , "gnomes@lxorguk.ukuu.org.uk" , "dave.hansen@intel.com" , "gregkh@linux-foundation.org" , Andrea Arcangeli References: <20180103230934.15788-1-andi@firstfloor.org> <20180104114231.GB1702@amd> <1515066469.12987.112.camel@amazon.co.uk> <94b12025-b27c-04d2-8726-c07a3af6b265@redhat.com> <7a3584c6-0c00-d807-5130-13d1f4b34102@citrix.com> <1515079777.12987.149.camel@amazon.co.uk> <1515082507.12987.159.camel@infradead.org> <1515096331.29312.35.camel@infradead.org> From: Andrew Cooper Message-ID: <5dd8af58-cb09-53c1-dd29-150880e54728@citrix.com> Date: Fri, 5 Jan 2018 00:06:45 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-GB Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On 04/01/2018 23:47, Tom Lendacky wrote: > On 1/4/2018 2:05 PM, David Woodhouse wrote: >> On Thu, 2018-01-04 at 14:00 -0600, Tom Lendacky wrote: >>> Yes, lfence is sufficient.  As long as the target is in the register >>> before the lfence and we jump through the register all is good, i.e.: >> Thanks. Can I have a Reviewed-by: for this then please: > Reviewed-by: Tom Lendacky > > While this works, a more efficient way to do the lfence support would be > to not use the retpoline in this case. Changing the indirect jumps to > do the "mov [rax], rax; lfence; jmp *rax" sequence would be quicker. I'm > not sure if this is feasible given the need to do a retpoline if you can't > use lfence, though. That would be most efficient for AMD, but it isn't compatible with having a single binary which can mitigate itself most efficiently wherever it was booted.  On most hardware, we'll want to dynamically chose between repoline and lfence depending on vendor. One option would be to teach GCC/Clang/Other to output alternative patch-point data for indirect branches in the format Linux/Xen could consume, and feed this into the alternatives framework. The practical option to actually deploy in the timeframe is to use __x86.indirect_thunk.%reg and alternate between repoline and lfence in 15 locations, which does add an unconditional call/jmp over the most efficient alternative, but allows us to switch the thunk-in-use at boot time. ~Andrew