Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751626AbeAEMKH (ORCPT + 1 other); Fri, 5 Jan 2018 07:10:07 -0500 Received: from mail-vk0-f67.google.com ([209.85.213.67]:42533 "EHLO mail-vk0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750907AbeAEMKF (ORCPT ); Fri, 5 Jan 2018 07:10:05 -0500 X-Google-Smtp-Source: ACJfBoulbZejkq0Jh8saMx7eiAHE4ocxfaKZfE0Liil0bLlNDVle6dLoVnU+2F9FIi3MN3SSMLnw6Qbw0AlCwgj4H+U= MIME-Version: 1.0 In-Reply-To: References: <1515093549.29312.11.camel@infradead.org> <0575AF4FD06DD142AD198903C74E1CC87A56A873@ORSMSX103.amr.corp.intel.com> From: Paul Turner Date: Fri, 5 Jan 2018 04:09:33 -0800 Message-ID: Subject: Re: [PATCH 0/7] IBRS patch series To: Paolo Bonzini Cc: "Van De Ven, Arjan" , Linus Torvalds , David Woodhouse , Tim Chen , Thomas Gleixner , Andy Lutomirski , Greg KH , "Hansen, Dave" , Andrea Arcangeli , Andi Kleen , 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 Fri, Jan 5, 2018 at 3:32 AM, Paolo Bonzini wrote: > On 04/01/2018 22:22, Van De Ven, Arjan wrote: >> this is about a level of paranoia you are comfortable with. >> >> Retpoline on Skylake raises the bar for the issue enormously, but >> there are a set of corner cases that exist and that are not trivial >> to prove you dealt with them. >> >> personally I am comfortable with retpoline on Skylake, but I would >> like to have IBRS as an opt in for the paranoid. >> > > IBRS actually seems to perform more than decently on Skylake with the > microcode updates we're shipping in RHEL---much more so than Broadwell > or Haswell. Can you confirm that this is expected? > The cost of IBRS performance varies with processor generation. Skylake incurs the least overhead. It is expected that future generations will be better still. There are two distinct costs: The overhead to an indirect branch, and the transition cost for enabling/disabling the feature as we schedule into (and out of) protected code. A naked indirect call (with IBRS enabled) on Skylake and a retpolined call have approximately the same cost. (I have not compared this cost for pre-Skylake uarchs.) The main difference is that a retpolined binary does not incur the transition costs, nor does it interact with sibling execution while protected code is running. A trade-off to consider when choosing between them is that it does on the other hand carry a higher implementation (versus run-time) cost. As Arjan references above, this is also a sliding scale. The bar is significantly raised by compiling with retpoline alone, and the vulnerability is wholly eliminated if the preconditions are also satisfied. (And obviously, if you do not have the sources to the target you are trying to protect, IBRS allows you to run it in a protected fashion -- while it cannot easily be retpolined.)