Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751739AbeAELx1 (ORCPT + 1 other); Fri, 5 Jan 2018 06:53:27 -0500 Received: from mail-vk0-f67.google.com ([209.85.213.67]:33887 "EHLO mail-vk0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751098AbeAELxZ (ORCPT ); Fri, 5 Jan 2018 06:53:25 -0500 X-Google-Smtp-Source: ACJfBouMNipsL8adbq9fDgNjohCOFE//fNKFucwlE2XLBfVh99Q+gZnfjp3i/hAjsB/ipK/SyT+5dHekEaxqLzpLdRA= MIME-Version: 1.0 In-Reply-To: References: <1515093549.29312.11.camel@infradead.org> From: Paul Turner Date: Fri, 5 Jan 2018 03:52:53 -0800 Message-ID: Subject: Re: [PATCH 0/7] IBRS patch series To: Linus Torvalds Cc: David Woodhouse , Tim Chen , Thomas Gleixner , Andy Lutomirski , Greg KH , Dave Hansen , Andrea Arcangeli , Andi Kleen , Arjan Van De Ven , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Thu, Jan 4, 2018 at 11:33 AM, 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_. These are also mitigatable; the retpoline sequence itself will never result in an RSB underflow. So long as the underlying binary satisfies the precondition that it will not underflow its own RSB. Then we if we subsequently guarantee never to _reduce_ the number of entries in its RSB at any point remote to its own execution, then the precondition is preserved and underflow will not occur. This does not preclude perturbing the RSB, only that it's contents contain at least as many (non-exploitable) entries as when execution was interrupted. We do not need to actually track how many entries it's currently using, because returning control to it with a full RSB, guarantees that number of entries cannot have decreased. > > 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. Or worse, that a co-executing SMT sibling is not continually refilling them. > > Linus