Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933389AbeALLOt convert rfc822-to-8bit (ORCPT + 1 other); Fri, 12 Jan 2018 06:14:49 -0500 Received: from smtp-out4.electric.net ([192.162.216.195]:57122 "EHLO smtp-out4.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754522AbeALLOs (ORCPT ); Fri, 12 Jan 2018 06:14:48 -0500 From: David Laight To: 'Andi Kleen' , "dwmw@amazon.co.uk" CC: "pjt@google.com" , "linux-kernel@vger.kernel.org" , "gregkh@linux-foundation.org" , "tim.c.chen@linux.intel.com" , "dave.hansen@intel.com" , "tglx@linutronix.de" , "luto@amacapital.net" , Andi Kleen Subject: RE: [PATCH] x86/retpoline: Avoid return buffer underflows on context switch Thread-Topic: [PATCH] x86/retpoline: Avoid return buffer underflows on context switch Thread-Index: AQHTiMf25xdtPmmMlUqD/N/gjeIChqNwGglg Date: Fri, 12 Jan 2018 11:15:26 +0000 Message-ID: <859a318af2c9438ea134c57046b1712b@AcuMS.aculab.com> References: <20180108201531.6782-1-andi@firstfloor.org> In-Reply-To: <20180108201531.6782-1-andi@firstfloor.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Outbound-IP: 156.67.243.126 X-Env-From: David.Laight@ACULAB.COM X-Proto: esmtps X-Revdns: X-HELO: AcuMS.aculab.com X-TLS: TLSv1.2:ECDHE-RSA-AES256-SHA384:256 X-Authenticated_ID: X-PolicySMART: 3396946, 3397078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: From: Andi Kleen > Sent: 08 January 2018 20:16 > > [This is on top of David's retpoline branch, as of 08-01 this morning] > > This patch further hardens retpoline > > CPUs have return buffers which store the return address for > RET to predict function returns. Some CPUs (Skylake, some Broadwells) > can fall back to indirect branch prediction on return buffer underflow. > > With retpoline we want to avoid uncontrolled indirect branches, > which could be poisoned by ring 3, so we need to avoid uncontrolled > return buffer underflows in the kernel. > > This can happen when we're context switching from a shallower to a > deeper kernel stack. The deeper kernel stack would eventually underflow > the return buffer, which again would fall back to the indirect branch predictor. ... Is that really a usable attack vector? Isn't it actually more likely to leak kernel addresses to userspace in the return stack buffer - which might be usable to get around KASR. David