Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752012AbeADCLO (ORCPT + 1 other); Wed, 3 Jan 2018 21:11:14 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37168 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751935AbeADCLN (ORCPT ); Wed, 3 Jan 2018 21:11:13 -0500 Subject: Re: Avoid speculative indirect calls in kernel To: Alan Cox Cc: Linus Torvalds , Andi Kleen , tglx@linutronix.de, Greg Kroah-Hartman , dwmw@amazon.co.uk, Tim Chen , Linux Kernel Mailing List , Dave Hansen References: <20180103230934.15788-1-andi@firstfloor.org> <20180104015920.1ad7b9d3@alans-desktop> From: Paolo Bonzini Message-ID: Date: Thu, 4 Jan 2018 03:11:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20180104015920.1ad7b9d3@alans-desktop> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 04 Jan 2018 02:11:13 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On 04/01/2018 02:59, Alan Cox wrote: >> But then, exactly because the retpoline approach adds quite some cruft >> and leaves something to be desired, why even bother? > > Performance Dunno. If I care about mitigating this threat, I wouldn't stop at retpolines even if the full solution has pretty bad performance (it's roughly in the same ballpark as PTI). But if I don't care, I wouldn't want retpolines either, since they do introduce a small slowdown (10-20 cycles per indirect branch, meaning that after a thousand such papercuts they become slower than the full solution). A couple manually written asm retpolines may be good as mitigation to block the simplest PoCs (Linus may disagree), but patching the compiler, getting alternatives right, etc. will take a while. The only redeeming grace of retpolines is that they don't require a microcode update, but the microcode will be out there long before these patches are included and trickle down to distros... I just don't see the point in starting from retpolines or drawing the line there. Paolo