Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932263AbeAIBQ0 (ORCPT + 1 other); Mon, 8 Jan 2018 20:16:26 -0500 Received: from ppsw-32.csi.cam.ac.uk ([131.111.8.132]:42415 "EHLO ppsw-32.csi.cam.ac.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755580AbeAIBQN (ORCPT ); Mon, 8 Jan 2018 20:16:13 -0500 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Subject: Re: [PATCH v6 11/10] x86/retpoline: Avoid return buffer underflows on context switch To: Linus Torvalds , Andi Kleen Cc: "Woodhouse, David" , "linux-kernel@vger.kernel.org" , "tim.c.chen@linux.intel.com" , "peterz@infradead.org" , "tglx@linutronix.de" , "riel@redhat.com" , "keescook@google.com" , "gnomes@lxorguk.ukuu.org.uk" , "pjt@google.com" , "dave.hansen@intel.com" , "luto@amacapital.net" , "jikos@kernel.org" , "gregkh@linux-foundation.org" References: <1515363085-4219-1-git-send-email-dwmw@amazon.co.uk> <1515455051.15588.7.camel@infradead.org> <1515455902.4423.59.camel@amazon.co.uk> <20180109004415.GG6718@tassilo.jf.intel.com> From: Andrew Cooper Message-ID: <3aadb8a0-08c8-bdf9-7b91-0fa774a9e1ab@citrix.com> Date: Tue, 9 Jan 2018 01:15:57 +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 09/01/2018 00:58, Linus Torvalds wrote: > On Mon, Jan 8, 2018 at 4:44 PM, Andi Kleen wrote: >> Essentially the RSB are hidden registers, and the only way to clear them >> is the FILL_RETURN_BUFFER sequence. I don't see how clearing anything else >> would help? > Forget theory. Look at practice. > > Let's just assume that the attacker can write arbitrarily to the RSB > state. Just accept it. > > If you accept that, then you turn the question instead into: are there > things we can do to make that useless to an attacker. > > And there the point is that even if you control the RSB contents, you > need to find something relevant to *put* in the RSB. You need to find > the gadget that makes that control of the RSB useful. This is where the problem lies.  An attacker with arbitrary control of the RSB can redirect speculation arbitrarily.  (And I agree, this is a good default assumption to take). If SMEP is not active, speculation can go anywhere, including to a user controlled gadget which can reload any registers it needs, including with immediate constants. If SMEP is active, the attackers control of speculation is restricted to supervisor executable mappings. The real question is whether it is worth special casing the SMEP-active case given that for the SMEP-inactive case, your only viable option is to refill the RSB and discard any potentially poisoned mappings. ~Andrew