Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753135AbeADTkf (ORCPT + 1 other); Thu, 4 Jan 2018 14:40:35 -0500 Received: from smtp.eu.citrix.com ([185.25.65.24]:57492 "EHLO SMTP.EU.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751899AbeADTkd (ORCPT ); Thu, 4 Jan 2018 14:40:33 -0500 X-IronPort-AV: E=Sophos;i="5.46,315,1511827200"; d="scan'208";a="65610154" Subject: Re: [PATCH 0/7] IBRS patch series To: Linus Torvalds , David Woodhouse CC: Tim Chen , Thomas Gleixner , Andy Lutomirski , Greg KH , Dave Hansen , Andrea Arcangeli , Andi Kleen , Arjan Van De Ven , Linux Kernel Mailing List References: <1515093549.29312.11.camel@infradead.org> From: Andrew Cooper Message-ID: Date: Thu, 4 Jan 2018 19:40:31 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; 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: 7bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On 04/01/18 19:33, Linus Torvalds wrote: > On Thu, Jan 4, 2018 at 11:19 AM, David Woodhouse wrote: >> On Skylake the target for a 'ret' instruction may also come from the >> BTB. So if you ever let the RSB (which remembers where the 'call's came >> from get empty, you end up vulnerable. > That sounds like it could cause mispredicts, but it doesn't sound _exploitable_. > > Sure, interrupts in between the call instruction and the 'ret' could > overflow the return stack. And we could migrate to another CPU. And so > apparently SMM clears the return stack too. > > ... but again, none of them sound even remotely _exploitable_. > > Remember: it's not mispredicts that leak information. It's *exploits" > that use forced very specific mispredicts to leak information. > > There's a big difference there. And I think patch authors should keep > that difference in mind. > > For example, flushing the BTB at kernel entry doesn't mean that later > in-kernel indirect branches don't get predicted, and doesn't even mean > that they don't get mis-predicted. It only means that an exploit can't > pre-populate those things and use them for exploits. Retpoline as a mitigation strategy swaps indirect branches for returns, to avoid using predictions which come from the BTB, as they can be poisoned by an attacker. The problem with Skylake+ is that an RSB underflow falls back to using a BTB prediction, which allows the attacker to take control of speculation. Also remember that sibling threads share a BTB, so you can't rely on isolated straight-line codepath on the current cpu for safety. (e.g. by issuing an IBPB on every entry to supervisor mode). ~Andrew